Agentes escrevem código. Engenharia decide se ele sobrevive.

Ferramentas de IA já atravessaram a pergunta mais simples: conseguem produzir software que roda? Conseguem. O problema começa logo depois: esse software cabe no sistema, explica seus próprios erros e continua mudando sem virar uma sala cheia de fios expostos?

No texto que inspira esta reflexão, Joseph Heck separa a demonstração de capacidade do trabalho de engenharia. Ele reconhece o ganho dos harnesses e modelos para construir e testar código, mas insiste que os pontos de junção — APIs, camadas, contratos e integração com o que já existe — continuam exigindo julgamento.[1]

Código funcionando não é a definição de pronto

Um agente pode gerar uma feature, passar nos testes que recebeu e ainda entregar uma mudança difícil de depurar. Isso acontece quando o pedido descreve o comportamento imediato, mas não explicita as decisões que mantêm o sistema habitável:

• quais invariantes não podem ser quebradas;
• onde a responsabilidade começa e termina;
• que erro precisa aparecer para quem opera o serviço;
• que teste protege uma decisão de negócio, e não só uma linha de código;
• o que pode variar e o que precisa permanecer estável.

Essas perguntas não são burocracia de desenvolvimento. São o desenho da manutenção futura. Sem elas, a velocidade de gerar arquivos vira velocidade de transferir dívida técnica para a próxima pessoa.

O novo gargalo é escolher bem

A IA reduziu o custo de tentar uma implementação. Isso aumenta, em vez de diminuir, o valor de escolher a implementação certa.

Quando produzir código leva minutos, fica barato aceitar alternativas demais. Um time pode gerar três integrações, dois modelos de dados e uma camada de abstração antes de decidir qual problema estava resolvendo. O ganho real vem de encurtar esse ciclo: formular a hipótese, fixar limites, validar o resultado e descartar o que não serve.

É por isso que arquitetura continua sendo uma atividade concreta. Não é desenhar caixas antes de programar; é definir os contratos que permitem substituir uma parte sem quebrar as outras. É manter a carga cognitiva do sistema em um nível que uma pessoa consiga inspecionar durante um incidente.

Use agentes onde existe feedback confiável

O melhor cenário para agentes não é “faça o sistema inteiro”. É uma sequência curta e verificável:

1. descreva o comportamento e as restrições;
2. peça uma mudança pequena;
3. rode testes, lint, análise estática e checks de segurança;
4. entregue ao agente o resultado objetivo dessas ferramentas;
5. revise o desenho e a mudança, não só o diff bonito.

Heck destaca justamente o valor de dados concisos no momento certo e de validações determinísticas com feedback em linguagem natural para que o agente consiga se corrigir.[1] Essa é uma orientação útil: se o único retorno é “parece bom”, o processo depende de sorte. Se há contratos, testes de integração, logs consultáveis e critérios de aceite claros, a ferramenta consegue iterar em cima de sinais reais.

As fronteiras merecem mais atenção

O custo de um erro raramente está no método que o agente acabou de escrever. Ele aparece nas fronteiras: na migração que não admite rollback, na API que expõe uma suposição interna, no job que não é idempotente, no tratamento de falha que apaga contexto, na permissão concedida para que uma automação leia ou publique mais do que deveria.

Isso também muda a revisão de código. Em vez de perguntar apenas “a implementação está correta?”, vale perguntar:

• este contrato continua compreensível para quem não participou da mudança?
• como o sistema falha e como alguém descobre a causa?
• o que acontece quando a dependência externa responde duas vezes, demora ou não responde?
• qual limite impede que a automação amplie seu próprio alcance?

São perguntas de engenharia de software antes de serem perguntas sobre IA.

A ferramenta aumenta a responsabilidade pelo resultado

A melhor consequência dos agentes pode ser devolver tempo para o trabalho que costuma ficar sem dono: ler o sistema, esclarecer uma interface, escrever uma migração reversível, melhorar uma mensagem de erro e remover uma abstração que só existe porque alguém a criou cedo demais.

Não precisamos escolher entre usar IA e respeitar fundamentos. Quanto mais fácil fica gerar código, mais importantes ficam os critérios que o tornam operável, legível e modificável. O diferencial não será quem pede mais arquivos ao modelo. Será quem constrói o ciclo de feedback e toma as decisões que o modelo não pode assumir por conta própria.

Sources

[1] https://rhonabwy.com/2026/08/15/software-engineering-fundamentals-matter-more-than-ever — Software Engineering fundamentals matter more than ever — Joseph Heck