Oito meses depois de o Kiro atingir general availability, a ideia duradoura acaba sendo a spec, e a parte menos duradoura acaba sendo o IDE. O Kiro foi lançado como um IDE agêntico cujo discurso era que você trabalha no nível da especificação e deixa o agente implementar. A parte que colou é o artefato: uma declaração escrita de intenção que um humano revisa antes do código existir. A parte que discretamente se perdeu é a suposição de que o editor é onde isso acontece. O Kiro lançou uma CLI no GA, adicionou modo headless, e o terminal é para onde foi o uso interessante.

Escrevi sobre o GA do Kiro no fim do ano passado em AWS Monthly (Dec '25): The Kiro Era Begins, com mais entusiasmo do que distância. Oito meses é tempo suficiente para dizer quais partes daquilo se sustentaram.

O que de fato foi lançado

O Kiro entrou em preview em julho de 2025 e atingiu GA em 17 de novembro de 2025. O GA não foi um release de estabilidade, foi um release de escopo: testes baseados em propriedades que derivam casos de teste dos critérios de aceitação de uma spec, checkpointing para que as mudanças de um agente possam ser revertidas, suporte a workspace multi-root, planos de equipe gerenciados centralmente pelo AWS IAM Identity Center, e o Kiro CLI, que colocou o agente no terminal.

Desde então a trajetória tem sido consistente e nada glamorosa. O Kiro CLI ganhou modo headless em abril de 2026, então o agente roda em pipelines em vez de ao lado de um humano. Os lançamentos de CLI de janeiro de 2026 foram sobre allowlists e blocklists de quais URLs um agente pode buscar, atalhos de teclado para agentes customizados, diffs melhores. Isso não é um roadmap perseguindo uma demo. É uma ferramenta sendo ajustada para produção, e o formato do ajuste diz o que as pessoas de fato estão fazendo com ela.

A spec foi a boa ideia

A contribuição real do Kiro é ter transformado a especificação num arquivo. Requisitos, design, e tarefas, no repositório, versionados, revisáveis, com diff. Isso soa como uma coisa pequena perto de "a IA escreve seu código" e é a única parte que eu defenderia sem ressalvas.

O motivo é para onde isso move a revisão. Codificação agêntica sem governança produz um diff grande e pede a um humano que avalie depois do fato, que é o pior momento possível: o trabalho está pronto, o autor é uma máquina sem memória do seu raciocínio, e rejeitar significa jogar fora algo que parece terminado. Revisar uma spec inverte isso. Você está lendo intenção, no ponto em que mudá-la custa uma frase. A economia de "não, não assim" é completamente diferente antes e depois da implementação.

Essa propriedade não tem nada a ver com IA, o que é precisamente por que ela sobreviveu. É revisão de design com um ciclo de feedback mais curto, e vale tanto se quem implementa é um agente, um contratado, ou você mesmo na próxima terça-feira.

Onde não se sustentou

Três falhas honestas, e todas eram visíveis cedo para quem usou em trabalho real.

Specs desviam

Requisitos e design são gerados no início e não se atualizam sozinhos quando a implementação revela que o design estava errado. Times relatam exatamente a dinâmica que você previria: o código anda, a spec não, e em poucas semanas a spec é um documento descrevendo um sistema que não existe mais. Isso não é uma falha de IA, é a falha mais antiga da documentação de software, reintroduzida por uma ferramenta que tornou o documento barato de produzir e nada mais barato de manter. Barato de escrever e caro de manter verdadeiro é a combinação específica que gera artefatos obsoletos.

A sobrecarga não cabe em trabalho pequeno

A versão direta, de quem tentou isso numa correção de bug pequena, é que o fluxo de spec é uma marreta para uma porca. Requisitos, design, e quebra de tarefas para mudar uma regra de validação é pior do que simplesmente mudar a regra de validação. A cerimônia é proporcional a nada, e a maior parte do trabalho de engenharia é pequena.

A rigidez é real

Spec-first presume que você sabe o que quer antes de começar. Muito software é escrito por pessoas descobrindo o que querem enquanto o escrevem. Para trabalho exploratório, adiantar a especificação não é disciplina, é um palpite formalizado num documento que agora tem autoridade que não conquistou. A crítica de que desenvolvimento orientado a spec reimporta dinâmicas de cascata não é totalmente injusta, mas também não é totalmente errada, e a diferença depende de se seu time trata a spec como um contrato ou como um rascunho.

Então para quem é

O padrão que emergiu é mais estreito que o discurso e mais defensável. Specs valem a sobrecarga quando requisitos são ambíguos, quando as pessoas envolvidas estão distribuídas o suficiente para que entendimento compartilhado não possa ser presumido, ou quando rastreabilidade é uma obrigação em vez de uma gentileza. Num contexto regulado, "aqui está a spec revisada, aqui está o diff que a implementa" não é sobrecarga. É o artefato de auditoria que você teria que construir de qualquer forma, produzido como subproduto.

Para um time pequeno num código bem compreendido, a sobrecarga é majoritariamente custo. Isso não é uma crítica ao Kiro. É uma declaração de escopo que o marketing nunca ia fazer.

O que os IDEs de IA de fato mudaram

Aqui está a afirmação retrospectiva, e a sustento com reservas.

A mudança não foi que a IA escreve o código. Isso aconteceu, é genuinamente útil, e já é banal o suficiente para que discutir sobre isso seja chato. A mudança é que a unidade de revisão humana se moveu rio acima, do diff para a intenção. As specs do Kiro são uma implementação. AGENTS.md e arquivos de steering são outra. O padrão é o mesmo: humanos autoram restrições e revisam intenção, agentes produzem implementações, e o artefato que humanos discutem deixa de ser o código.

A segunda mudança é que o IDE acabou não sendo o container certo. O próprio CLI e o modo headless do Kiro provam o ponto melhor que qualquer crítico conseguiria. Se um humano não está lendo cada mudança conforme ela chega, o editor é uma interface para algo que não precisa mais de uma, e o agente pertence a onde vive o resto da sua automação. O IDE era a rampa de acesso, não o destino.

A conclusão

Oito meses após o GA, a contribuição duradoura do Kiro é a especificação como um arquivo revisável e versionado, que moveu o julgamento humano para o ponto onde é mais barato de aplicar. Os custos são reais e específicos: specs desviam porque gerá-las é barato e mantê-las não é, e a cerimônia não cabe em trabalho pequeno ou exploratório. Use onde ambiguidade ou rastreabilidade justificam a sobrecarga e pule onde não justificam. E note que a saída mais útil do IDE agêntico foi uma CLI, o que é a indústria te dizendo para onde isso está indo.

Leia isto a seguir

O lado de pipeline de rodar agentes em CI, runners, credenciais, e raio de impacto, vive nas notas de campo em ercan.cloud. O hub está em ercanermis.com.