O que é desenvolvimento agêntico e porque muda o SDLC

Um programador em 2026 passa mais tempo a descrever e a rever do que a escrever. Não é uma previsão. É o que acontece numa equipa que trabalha com agentes todos os dias. O editor continua aberto, mas o que está no ecrã é cada vez mais uma especificação, um plano, um diff para aprovar. O código em si é escrito por outra coisa.

A essa forma de trabalhar chamamos desenvolvimento agêntico. Este artigo explica o que é, o que muda em cada fase do ciclo de vida do software e, talvez mais importante, o que não muda.

O que é

Desenvolvimento agêntico é delegar tarefas do ciclo de vida do software a agentes: programas construídos sobre modelos de linguagem que planeiam, executam ferramentas (editor, terminal, testes, navegador) e verificam o próprio trabalho antes de o entregar. O humano fixa a intenção e o critério. O agente percorre o caminho.

A diferença para o "autocompletar inteligente" de há três anos está na palavra percorrer. Um assistente sugere a linha seguinte. Um agente recebe um objectivo, decide os passos, corre-os, lê os resultados e corrige-se. Pode demorar minutos ou horas. Pode criar ficheiros, instalar dependências, abrir um pull request. A unidade de trabalho deixa de ser a linha e passa a ser a tarefa.

Isto não torna o programador dispensável. Torna-o responsável por coisas diferentes.

O que muda em cada fase

Planeamento

A especificação passa a ser o artefacto principal. Quando o código é barato de produzir, o que é caro é saber exactamente o que se quer. Uma spec de duas páginas, com decisões fechadas e critérios de conclusão claros, vale mais do que mil linhas escritas à pressa. As reuniões de planeamento deixam de discutir "quanto tempo demora" e passam a discutir "o que conta como feito".

Código

O diff deixa de ser o produto. A verificação é. Se um agente consegue produzir três implementações diferentes numa tarde, a pergunta certa não é "qual é mais bonita" mas "qual passa nos testes, cumpre a spec e é a mais pequena". O gosto continua a importar, mas aplica-se à revisão e não à digitação.

Testes

Os agentes escrevem-nos primeiro, ou não há confiança. Um agente que implementa sem um teste a falhar antes está a adivinhar, e adivinha com muita convicção. A disciplina de ver o teste vermelho, depois verde, deixa de ser uma boa prática opcional e passa a ser o único sinal fiável de que o trabalho foi feito. Equipas que já faziam TDD adaptam-se depressa. As outras descobrem porque é que ele existia.

Revisão

Rever intenção, não sintaxe. O código gerado tende a ser sintacticamente correcto e estilisticamente uniforme. O que falha é o enquadramento: a funcionalidade a mais, o caso limite esquecido, a abstracção que ninguém pediu. O revisor humano lê o diff com a spec ao lado e pergunta se o que está ali é o que foi pedido, nem mais nem menos.

Deploy e operação

Agentes a ler logs e a propor correcções. O mesmo mecanismo que escreve código consegue ler um stack trace às três da manhã, localizar o commit que o introduziu e abrir um pull request com o teste que o reproduz. A pessoa de serviço aprova ou rejeita. O tempo entre sintoma e correcção encolhe, e o cansaço também.

O que não muda

Três coisas continuam a ser humanas, e são as que importam.

Responsabilidade. O agente não assina o contrato, não responde ao cliente e não é despedido. Quem aprova o diff é dono do diff. Isto não é um detalhe legal; é a razão pela qual a revisão não pode ser delegada.

Gosto. Saber que uma solução é pequena demais ou grande demais, que uma API vai envelhecer mal, que um nome está errado. Os modelos imitam gosto, mas não o têm. Quem o tem continua a ser o recurso escasso.

Decisão. Qual o problema que vale a pena resolver, qual o compromisso aceitável, quando parar. Um agente optimiza o que lhe pedem. Decidir o que pedir é o trabalho.

Como a Container Hub trabalha

Na prática, o nosso ciclo tem três regras.

Specs curtas, fechadas antes de qualquer código. Uma spec que ainda tem perguntas em aberto não vai para implementação.

Planos executáveis, com tarefas pequenas, cada uma com o seu teste e o seu commit. O agente segue o plano; os desvios ficam registados com a razão.

Verificação antes de afirmar conclusão. "Deve funcionar" não é um estado. Um teste que correu e passou é.

Calma

A promessa do desenvolvimento agêntico não é escrever mais depressa. É errar menos. A velocidade aparece como consequência: menos retrabalho, menos incidentes, menos reuniões para perceber o que alguém quis dizer. O programador de 2026 trabalha com mais calma do que o de 2020, não porque faz menos, mas porque faz as coisas pela ordem certa.