Senar: por que agentes de IA não substituem programadores e mudam o processo de desenvolvimento

Na segunda parte da série sobre o SENAR, o autor analisa não a qualidade dos modelos, mas o próprio processo de desenvolvimento com agentes de IA. A ideia central é simples: o agente pode escrever código mais rápido que uma pessoa, mas não se comporta como um engenheiro quando esbarra numa lacuna de conhecimento.

Onde o agente erra

O caso mais revelador é a auditoria de um sistema Java antigo com 17 módulos e sem documentação atualizada. O agente montou um mapa de arquitetura convincente: dependências, interfaces, descrições de componentes, ligações entre serviços. Quase tudo parecia correto até ele chegar a uma antiga camada de proxy que sobrou da migração para uma fila de mensagens. No código, essa camada parecia uma chamada HTTP comum, e o agente a descreveu com confiança como parte normal da arquitetura. Para quem já trabalhava no projeto, porém, era uma gambiarra temporária e um resquício de uma solução antiga.

É aqui que aparece a diferença-chave entre um agente e um desenvolvedor. Uma pessoa costuma notar uma construção estranha, sinaliza o risco e vai perguntar à equipe ou ao autor do código qual é a história daquela decisão. O agente, com mais frequência, completa por conta própria a explicação que falta: formula um motivo lógico, inventa uma finalidade e não separa o fato do repositório da sua própria reconstrução. Quanto mais caprichado parece o resultado, maior a chance de o erro passar na revisão e de uma hipótese ser tomada como verdade arquitetural.

«A diferença entre o programador e o agente não está na velocidade».

Cinco conclusões principais

Desse caso o autor extrai cinco padrões recorrentes que, na experiência dele, surgem em quase todo projeto com agentes de IA para desenvolvimento. Eles dizem respeito não só à qualidade do código, mas também a como o agente percebe a tarefa, o contexto e as consequências de suas decisões. Somados, explicam por que a mesma ferramenta pode acelerar muito o desenvolvimento em tarefas simples e criar problemas ocultos com a mesma rapidez nas complexas.

• O agente não tem memória do projeto: se a história das decisões não é passada de forma explícita, ela não existe para ele.
• Ele executa a tarefa ao pé da letra e não completa o contexto de negócio como faz um desenvolvedor experiente.
• Uma única suposição errada se multiplica rapidamente por uma série de arquivos e utilitários parecidos.
• O agente não enxerga a arquitetura além do prompt atual e escolhe o caminho localmente mais conveniente.
• Ele não convive com as consequências de suas decisões, então a responsabilidade pelo release e pelos dados continua com o humano.

A conclusão prática dessas observações é rígida: a tarefa precisa ter não só objetivo e critérios de aceitação, mas também cenários negativos, restrições, proibições e limites de arquitetura. Se sobrarem lacunas, o agente as preencherá sozinho. Por isso o portão de qualidade de entrada do SENAR exige reunir primeiro a especificação e o contexto, e só depois iniciar a geração. A velocidade só é útil aqui quando uma pessoa estreitou de antemão o espaço para suposições.

O preço da automação rápida

O código rápido do agente cria outro tipo de dívida: a cognitiva. Um módulo pode funcionar, os testes passam e o linter não reclama, mas a equipe não entende por que ele foi construído assim nem quais decisões estão embutidas nele. O autor cita o exemplo de um módulo de cache de cerca de 500 linhas: umas duas semanas depois, foi preciso mudar a estratégia de descarte de dados obsoletos e, em vez de uma hora de ajuste, gastou-se meio dia para recuperar uma lógica que nenhuma pessoa tinha decidido nem registrado de forma explícita.

Para não mascarar falhas sistêmicas com correções manuais, o autor propõe medir o MIR: a parcela de tarefas em que, depois do trabalho do agente, foi preciso mexer no código à mão. Em projetos maduros, essa métrica ficou em torno de 5–15%; no início de um projeto novo, em torno de 20%. O objetivo não é um relatório bonito, mas o feedback: se as correções manuais se repetem, o problema não está em um arquivo, e sim no contexto, na especificação, nos limites de arquitetura ou no modelo escolhido.

O novo papel do engenheiro

Por isso muda também o papel da pessoa na equipe. Na estimativa do autor, hoje até 60% do tempo vai para definir tarefas, reunir contexto e tomar decisões de arquitetura, cerca de 30% para verificar resultados e mais 10% para configurar ferramentas, métricas e o próprio processo. Escrever código deixa de ser o centro do trabalho: o engenheiro se parece cada vez mais com quem define tolerâncias, decompõe um sistema complexo e verifica se a saída caprichada do agente não virou um erro caro.

Uma conclusão é dura: tudo o que não está escrito não existe para o agente. Se os limites dos módulos, as convenções de API, os motivos de decisões passadas e as dependências proibidas vivem só na cabeça do tech lead, o agente quase certamente vai violá-los, porque tecnicamente o import pode funcionar e os testes podem passar. Por isso a documentação no modelo SENAR existe não para prestar contas, mas como interface de trabalho entre a pessoa, o agente e os futuros desenvolvedores que precisarão manter esse código.

O que isso significa

Para as equipes que adotam agentes de IA a sério no desenvolvimento, a principal notícia não é que eles aceleram o trabalho. Importa muito mais outra coisa: sem especificação rígida, registro das decisões e verificação constante, a velocidade logo vira dívida cognitiva, e o engenheiro deixa de ser autor do código para virar editor, arquiteto e controlador de qualidade.