Trabalhamos com agentes de código todo dia, o dia inteiro. Eles mudaram de verdade o custo da parte repetitiva do trabalho, e não temos nenhum interesse em minimizar isso.
É exatamente por isso que vale ser preciso sobre o que eles não mudaram. Quem vende aceleração sem essa segunda lista está vendendo uma expectativa que vai quebrar no meio do projeto.
O que ficou mais rápido de fato
Um primeiro protótipo navegável pode sair em dias, e isso muda a ordem do projeto. Validar um fluxo com quem vai usar ficou mais acessível antes de comprometer a construção definitiva.
Partes repetitivas ficaram mais rápidas: cadastros, integrações, telas administrativas e relatórios. A mecânica de uma migração também pode acelerar, embora decidir o que fazer com dados inconsistentes continue exigindo contexto.
Criar testes também ficou mais rápido. Isso não garante uma boa cobertura por si só, mas reduz o trabalho mecânico necessário para chegar até ela.
O que não se moveu um centímetro
Entender como a operação funciona de verdade
A parte mais difícil de qualquer sistema sob medida é descobrir como o negócio realmente funciona, incluindo as partes que contradizem o manual. O processo oficial diz uma coisa; a pessoa que faz aquilo há oito anos faz outra, por um motivo excelente que ninguém nunca escreveu.
Isso se obtém sentando junto, olhando a tela de quem trabalha, perguntando "e quando dá errado?" e ouvindo a história inteira. Um agente pode organizar a transcrição ou resumir o que foi dito. Ele não percebe sozinho a hesitação antes de uma resposta, a exceção que parece banal nem a regra que só aparece quando alguém mostra o trabalho acontecendo. É aqui que muitos projetos dão errado, não na digitação do código.
Decidir o modelo de dados
Modelar é apostar no futuro: quais entidades existem, o que é atributo e o que é entidade própria, o que vai precisar de histórico daqui a três anos.
Errar essa aposta é o erro mais caro que existe em software, porque ele contamina tudo o que é construído em cima. E é justamente onde o agente é mais confiante e menos responsável: ele vai propor um modelo plausível, bem-formado, coerente, e completamente alheio ao fato de que essa empresa fatura de um jeito que a estrutura proposta não comporta.
Migrar dado sujo
O gargalo real de quase todo projeto de substituição de sistema não é construir o novo. É que o antigo tem doze anos de dado acumulado com clientes duplicados, data em três formatos, valor negativo que significa estorno, e um campo de texto livre chamado "observações" que carrega uma regra de negócio inteira que ninguém formalizou.
Escrever o conversor ficou rápido. Decidir o que fazer com cada anomalia continua sendo uma conversa entre pessoas, uma por uma.
Decidir o que não construir
Quando construir fica barato, a tentação é construir tudo. É um erro caro de um jeito diferente: cada funcionalidade que existe é uma funcionalidade que precisa ser mantida, entendida por quem chega, e considerada em toda mudança futura.
Um agente tende a ser um conselheiro ruim nessa hora. Ele responde ao que foi pedido e consegue desenvolver uma ideia com muito mais facilidade do que questionar se ela deveria existir. Dizer "isso aqui não vale a pena" exige contexto sobre custo, operação e estratégia. É trabalho de quem responde pelo resultado, não pelo volume.
Responder por um problema em produção
Às duas da manhã, quando algo quebra, existe uma pessoa que precisa acordar, entender e resolver. Responsabilidade não é transferível para ferramenta, e essa é a diferença entre um fornecedor que entrega e um que responde.
A armadilha da proporção
Tem um efeito de segunda ordem que aparece pouco na conversa e importa muito.
Quando escrever fica barato, revisar vira o gargalo. O volume de código que passa pela revisão cresce na mesma proporção em que o custo de produzi-lo cai, e a atenção humana disponível continua exatamente a mesma de antes.
O resultado, num time desatento, é código gerado em quantidade indo para produção com uma revisão superficial. Ele funciona nos casos testados. Ele carrega decisões que ninguém tomou conscientemente. E ele vai ser mantido por anos.
Código barato não é código de graça. É código que você vai manter, e o custo de manter não caiu na mesma proporção do custo de escrever.
Um teste útil é separar duas perguntas. A primeira é se a ferramenta consegue produzir a alteração. A segunda é quem consegue afirmar que aquela alteração representa corretamente o negócio, pode ir para produção e vale o custo que criará depois. A primeira ficou muito mais barata. A segunda continua precisando de alguém que conheça o contexto e assuma a decisão.
O que isso muda na prática
Muda onde o tempo é gasto.
Se a parte cara agora é entender, decidir e responder, então o projeto precisa alocar mais tempo em diagnóstico e desenho, e não menos, mesmo que a construção tenha encolhido. É contraintuitivo: a fase que ficou barata é a que costumava ocupar o cronograma inteiro, e a tentação é embolsar a economia e prometer prazo menor.
A gente prefere usar essa folga na parte que continua difícil. Agentes aceleram o código; a revisão e a responsabilidade continuam sendo nossas.
É por isso também que seguimos poucos projetos por ano. O gargalo nunca foi a velocidade de escrever.