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

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

Onde o agente falha

O caso mais revelador é uma auditoria de um sistema Java antigo com 17 módulos e sem documentação atualizada. O agente compilou um mapa arquitetural convincente: dependências, interfaces, descrições de componentes e relacionamentos entre serviços. Quase tudo parecia preciso até chegar a uma camada proxy antiga que permaneceu após a 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 padrão da arquitetura, embora para as pessoas que haviam trabalhado no projeto antes fosse um remendo temporário e um vestígio de uma solução antiga. É aqui que a diferença fundamental entre um agente e um desenvolvedor se torna aparente. Uma pessoa típica nota uma construção estranha, assinala o risco e vai esclarecer o histórico da decisão com o time ou com o autor do código.

Um agente frequentemente reconstrói a explicação faltante por conta própria: formula uma razão lógica, inventa um propósito e não distingue entre fatos do repositório e sua própria reconstrução. Quanto mais polido esse resultado parecer, maior a chance de passar despercebido em uma revisão e aceitar uma hipótese como verdade arquitetural.

"A diferença entre um programador e um agente não é velocidade."

Cinco conclusões principais

A partir desse caso, o autor extrai cinco padrões recorrentes que, em sua experiência, surgem em quase qualquer projeto com agentes de IA para desenvolvimento. Eles não se preocupam apenas com a qualidade do código, mas também com a forma como o agente percebe tarefas, contexto e consequências de suas decisões. No geral, isso explica por que a mesma ferramenta pode acelerar dramaticamente o desenvolvimento em tarefas simples e criar rapidamente problemas ocultos em tarefas complexas.

• O agente não tem memória do projeto: se o histórico de decisões não for transmitido explicitamente, ele não existe para o agente.
• Ele executa a tarefa literalmente e não preenche o contexto comercial da forma que um desenvolvedor experiente faria.
• Uma suposição incorreta se multiplica rapidamente em uma série de arquivos e utilitários semelhantes.
• O agente não vê a arquitetura além do prompt atual e escolhe o caminho localmente conveniente.
• Ele não vive com as consequências de suas decisões, então a responsabilidade pelo lançamento e dados permanece com os humanos.

A conclusão prática dessas observações é dura: a tarefa deve conter não apenas metas e critérios de aceitação, mas também cenários negativos, restrições, proibições e limites arquiteturais. Se deixar lacunas, o agente as preencherá. É por isso que a porta de entrada de qualidade no SENAR exige primeiro coletar especificação e contexto, então iniciar a geração. A velocidade é útil apenas quando o espaço para especulação é reduzido antecipadamente por um humano.

O custo da automação rápida

Código rápido de um agente cria um tipo diferente de dívida—cognitiva. Um módulo pode funcionar, os testes passam, o linter fica silencioso, mas o time não entende por que está estruturado assim e quais decisões estão codificadas nele. O autor dá um exemplo de um módulo de cache com aproximadamente 500 linhas: após algumas semanas, foi necessário mudar a estratégia de limpeza de dados obsoletos, e em vez de uma hora para retrabalho, metade do dia foi gasto restaurando lógica que ninguém havia explicitamente aceito ou registrado.

Para evitar mascarar falhas do sistema com correções manuais, o autor propõe calcular MIR—a proporção de tarefas em que foram necessárias edições manuais de código após o trabalho do agente. Em projetos maduros, essa métrica ficou em torno de 5–15%, no início de um novo—cerca de 20%. O ponto não é um relatório bonito, mas feedback: se as correções manuais se repetem, o problema não está em um arquivo mas em contexto, especificação, limites arquiteturais ou no modelo escolhido.

O novo papel do engenheiro

Isso muda o papel dos humanos no time. De acordo com o autor, até 60% do tempo agora vai para especificação de tarefas, coleta de contexto e decisões arquiteturais, cerca de 30% para verificação de resultados e outros 10% para ajustar ferramentas, métricas e o próprio processo. Escrever código em si deixa de ser o centro do trabalho: engenheiros cada vez mais se assemelham àqueles que definem tolerâncias, decompõem sistemas complexos e verificam se o resultado polido do agente não se tornou um erro custoso.

Uma conclusão separada soa dura: tudo não escrito não existe para o agente. Se limites de módulos, convenções de API, razões para decisões passadas e dependências proibidas vivem apenas na cabeça de um tech lead, o agente quase certamente as violará, porque tecnicamente a importação pode funcionar e os testes podem passar. É por isso que a documentação no modelo SENAR é necessária não para conformidade, mas como uma interface de trabalho entre humanos, agentes e futuros desenvolvedores que terão que manter esse código.

O que significa

Para times que estão adotando seriamente agentes de IA no desenvolvimento, a grande notícia não é que eles aceleram o desenvolvimento. O que importa muito mais é isto: sem especificação rígida, registro de decisões e verificação constante, a velocidade rapidamente se transforma em dívida cognitiva, e o engenheiro muda de autor de código para editor, arquiteto e controlador de qualidade.