> ## Content Index > Fetch the complete content index at: https://lucasfogaca.dev.br/llms.txt > Use this file to discover other available public pages before exploring further. # Agentes escrevem código. Engenharia decide se ele sobrevive. - URL: https://lucasfogaca.dev.br/agentes-escrevem-codigo-engenharia-decide-se-ele-sobrevive/ - Published: 2026-08-17T20:53:52.000Z - Updated: 2026-08-17T20:53:51.000Z - Author: Lucas Fogaça - Tags: noticias Agentes escrevem código. Engenharia decide se ele sobrevive. # 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\]](#fonte) ## 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\]](#fonte) 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. **Fonte** \[1\] Joseph Heck, [*Software Engineering fundamentals matter more than ever*](https://rhonabwy.com/2026/08/15/software-engineering-fundamentals-matter-more-than-ever/?ref=lucasfogaca.dev.br), 15 ago. 2026.