--- title: "Amper Kotlin: Como Funciona o Novo Build Tool | Kotlin Brasil" url: "https://kotlin.dev.br/blog/amper-kotlin-guia-2026/" markdown_url: "https://kotlin.dev.br/blog/amper-kotlin-guia-2026.MD" description: "Entenda o Amper para Kotlin em 2026: configuração, módulos, testes e integração com Gradle em um guia prático para projetos modernos." date: "2026-04-10" author: "Karina Melo" --- # Amper Kotlin: Como Funciona o Novo Build Tool | Kotlin Brasil Entenda o Amper para Kotlin em 2026: configuração, módulos, testes e integração com Gradle em um guia prático para projetos modernos. O ecossistema Kotlin sempre teve uma relação muito forte com o Gradle. Ele continua sendo a principal ferramenta de build para boa parte dos projetos Android, backend e multiplataforma. Mas em 2026 a JetBrains acelerou um movimento importante: o **Amper**, uma nova ferramenta de build e automação pensada para oferecer uma experiência mais simples, previsível e amigável para projetos Kotlin modernos. Se você já sentiu que configurar `build.gradle.kts`, plugins, convention plugins, versões de JDK e módulos multiplataforma exige tempo demais, o Amper merece sua atenção. Neste guia, você vai entender o que é o Amper, quando usar, como estruturar um projeto e onde ele faz mais sentido no dia a dia. ## O que é o Amper? O **Amper** é uma ferramenta da JetBrains voltada para simplificar a configuração e a manutenção de projetos Kotlin e JVM. Em vez de começar por uma DSL extensa como a do Gradle, a proposta do Amper é trabalhar com arquivos declarativos menores, foco em convenções e menos boilerplate. Na prática, o Amper tenta resolver dores comuns como: - configuração inicial demorada; - excesso de detalhes para tarefas simples; - diferença grande entre projetos pequenos e setups corporativos; - complexidade para onboarding de pessoas novas no repositório. Isso não significa “substituir o Gradle em todos os cenários” imediatamente. A ideia atual é oferecer uma camada mais direta para casos em que times querem produtividade, menos configuração manual e um caminho mais guiado pela JetBrains. ## Por que o Amper ganhou relevância em 2026? A evolução recente do Amper trouxe recursos que o tornam mais viável para uso real em projetos de equipe. Entre os destaques mais comentados pela comunidade estão: - provisionamento de JDK mais simples; - melhor organização por módulos; - integração com plugins de compilador; - conversão de projetos Maven; - experiência mais consistente para Kotlin Multiplatform. Esse movimento acompanha a maturidade do ecossistema Kotlin. Hoje já temos um compilador mais moderno com o [K2 como padrão](/blog/kotlin-21-novidades-2026/), mais projetos usando [Kotlin Multiplatform](/blog/kotlin-multiplatform/) e uma busca maior por pipelines reproduzíveis em times que também trabalham com [CI/CD em Kotlin](/blog/kotlin-github-actions/). ## Como o Amper se diferencia do Gradle? O Gradle é extremamente poderoso. O problema é que esse poder normalmente vem com mais camadas de configuração, mais DSL e mais decisões arquiteturais logo no começo do projeto. O Amper tenta reduzir esse custo cognitivo. ### Comparação prática | Aspecto | Gradle | Amper | |---|---|---| | Flexibilidade | Muito alta | Alta, mas mais guiada | | Complexidade inicial | Média para alta | Baixa para média | | Boilerplate | Maior | Menor | | Curva de aprendizado | Mais longa | Mais curta | | Convenções prontas | Menos opinativo | Mais opinativo | Se você trabalha com automação e build tooling, vale lembrar que essa busca por configuração mais previsível também aparece em outras linguagens. O ecossistema Go costuma priorizar ferramentas com convenções simples e pouca configuração, enquanto o ecossistema Python muitas vezes combina ferramentas menores para empacotamento, lint e automação. ## Estrutura básica de um projeto com Amper Um projeto com Amper tende a ser mais declarativo. Em vez de concentrar tudo em um `build.gradle.kts` enorme, você descreve módulos, dependências e targets de forma mais enxuta. Um exemplo conceitual de estrutura pode ficar assim: ```text meu-projeto/ ├── amper.yaml ├── app/ │ ├── src/commonMain/kotlin/ │ ├── src/jvmMain/kotlin/ │ └── module.yaml ├── backend/ │ ├── src/main/kotlin/ │ └── module.yaml └── shared/ ├── src/commonMain/kotlin/ └── module.yaml ``` A proposta é que cada módulo exponha apenas o necessário, com uma definição mais legível para quem acabou de entrar no time. ## Exemplo de configuração declarativa A sintaxe do Amper pode evoluir com o tempo, mas a ideia geral é declarar módulo, plataforma e dependências sem a verbosidade comum de builds muito customizados. ```yaml product: type: app platforms: [jvm] modules: - ./shared - ./backend dependencies: - org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.1 - io.ktor:ktor-server-core:3.0.0 - io.ktor:ktor-server-netty:3.0.0 test-dependencies: - org.jetbrains.kotlin:kotlin-test - org.junit.jupiter:junit-jupiter:5.10.2 ``` Mesmo que o formato exato varie por versão, a diferença de filosofia fica clara: você descreve o projeto em termos de intenção, e não de orquestração detalhada de tasks. ## Criando um módulo compartilhado Um dos cenários mais interessantes para o Amper é o de projetos com código compartilhado. Isso aparece muito em setups multiplataforma, SDKs internos e bibliotecas reutilizáveis. ```yaml product: type: library platforms: [jvm, ios, android] dependencies: - org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0 - org.jetbrains.kotlinx:kotlinx-datetime:0.6.0 ``` E no código Kotlin: ```kotlin import kotlinx.datetime.Clock import kotlinx.serialization.Serializable @Serializable data class BuildInfo( val nomeProjeto: String, val versao: String, val geradoEm: String, ) fun gerarBuildInfo(nomeProjeto: String, versao: String): BuildInfo { return BuildInfo( nomeProjeto = nomeProjeto, versao = versao, geradoEm = Clock.System.now().toString(), ) } ``` Esse tipo de módulo pode ser consumido por uma aplicação Android, um backend ou um utilitário interno sem repetir lógica de serialização e metadados. ## Testes com Amper Projetos modernos precisam de testes como parte do fluxo desde o primeiro commit. O Amper ajuda ao deixar a configuração mais previsível, sem impedir o uso das bibliotecas tradicionais do ecossistema Kotlin. ```yaml test-dependencies: - org.jetbrains.kotlin:kotlin-test - io.mockk:mockk:1.13.10 - org.jetbrains.kotlinx:kotlinx-coroutines-test:1.8.0 ``` Com isso, você consegue manter um setup de testes familiar: ```kotlin import io.mockk.every import io.mockk.mockk import kotlin.test.Test import kotlin.test.assertEquals class SaudacaoService(private val relogio: Relogio) { fun mensagem(): String { return if (relogio.horaAtual() < 12) "Bom dia" else "Boa tarde" } } interface Relogio { fun horaAtual(): Int } class SaudacaoServiceTest { private val relogio = mockk() private val service = SaudacaoService(relogio) @Test fun `deve retornar bom dia antes do meio-dia`() { every { relogio.horaAtual() } returns 9 assertEquals("Bom dia", service.mensagem()) } } ``` Se você quiser aprofundar essa parte, depois vale ler nosso guia de [testes em Kotlin com JUnit 5 e MockK](/blog/kotlin-testes-junit5-mockk-guia/). ## Onde o Amper faz mais sentido? Hoje o Amper tende a ser especialmente interessante em alguns contextos: ### 1. Projetos novos Quando você ainda não acumulou dezenas de plugins, scripts e integrações históricas, fica mais fácil aproveitar uma abordagem mais limpa. ### 2. Times que querem onboarding rápido Menos DSL e menos arquivos espalhados normalmente significam menos tempo até alguém conseguir rodar o projeto localmente. ### 3. Projetos multiplataforma Quanto mais targets você adiciona, maior costuma ser a dor de build. Uma ferramenta mais opinativa pode reduzir inconsistências. ### 4. Bibliotecas internas e ferramentas de equipe Nem todo projeto precisa da flexibilidade total do Gradle. Ferramentas internas se beneficiam muito de convenção. ## Quando talvez o Gradle ainda seja melhor? O Gradle continua sendo a melhor escolha em vários cenários, especialmente quando você precisa de: - integrações muito específicas com plugins corporativos; - tasks customizadas complexas; - pipelines fortemente acoplados ao ecossistema Gradle; - compatibilidade com builds já estabilizados em produção. Ou seja: o Amper não elimina o Gradle. Ele oferece uma opção interessante para reduzir complexidade em casos onde o Gradle pode ser mais ferramenta do que o projeto realmente precisa. ## Integração com CI Se o seu time adota integração contínua, a principal vantagem do Amper é a previsibilidade do ambiente. Menos configuração manual tende a significar menos divergência entre máquina local e runner. Um pipeline conceitual pode seguir este formato: ```yaml steps: - checkout - setup-jdk - amper build - amper test ``` A ideia é simples: baixar o código, garantir a JDK correta, compilar e rodar testes. Em ambientes que já usam GitHub Actions, Gitea Actions ou outro sistema de CI, isso pode reduzir o número de detalhes específicos do build script. ## Amper e Kotlin Multiplatform O Amper chama atenção principalmente quando combinado com KMP. Em projetos multiplataforma, a configuração de source sets, targets e dependências costuma crescer rápido. Uma ferramenta declarativa ajuda a enxergar melhor a estrutura do projeto. Isso é especialmente relevante para quem acompanha a evolução de interfaces compartilhadas com [Compose Multiplatform](/blog/kotlin-compose-multiplatform-ui-2026/) e targets web com [Kotlin/Wasm](/blog/kotlin-wasm-novidades/). ## Vale a pena aprender Amper agora? Para quem trabalha profissionalmente com Kotlin, a resposta mais equilibrada é: **sim, vale acompanhar de perto**. Mesmo que seu time continue no Gradle pelos próximos meses, entender o Amper ajuda a: - acompanhar a direção da JetBrains; - avaliar novos projetos com menos boilerplate; - testar abordagens mais simples para módulos internos; - participar cedo de uma mudança potencialmente importante no ecossistema. Aprender Amper agora não significa migrar tudo. Significa adquirir contexto para decidir melhor quando ele amadurecer ainda mais. ## Conclusão O Amper representa uma tentativa séria de simplificar o build no ecossistema Kotlin sem abrir mão da experiência moderna de desenvolvimento. Ele conversa bem com um momento em que o Kotlin está mais amplo, com backend, Android, multiplataforma e ferramentas de produtividade evoluindo ao mesmo tempo. Se você quer reduzir atrito de configuração, facilitar onboarding e experimentar uma abordagem mais declarativa, o Amper já merece um projeto piloto. E se o seu foco ainda é Gradle, conhecer essa ferramenta agora ajuda a entender para onde a JetBrains está empurrando a experiência de build. Para continuar explorando o ecossistema, leia também nosso conteúdo sobre [Kotlin e DevOps](/blog/kotlin-devops-ci-cd/), [Kotlin com GitHub Actions](/blog/kotlin-github-actions/) e o [guia de Kotlin para backend](/guias/kotlin-para-backend/).