Amper Kotlin: Como Funciona o Novo Build Tool | Kotlin Brasil

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, mais projetos usando Kotlin Multiplatform e uma busca maior por pipelines reproduzíveis em times que também trabalham com CI/CD em Kotlin.

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

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:

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.

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.

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:

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.

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:

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<Relogio>()
    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.

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:

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 e targets web com Kotlin/Wasm.

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, Kotlin com GitHub Actions e o guia de Kotlin para backend.