A poesia do desenvolvimento agêntico: como programar com agentes quando a facilidade gera complexidade

Facilidade contra simplicidade

O autor do Habr arturdumchev programa com agentes todos os dias há um ano e meio e propõe um novo olhar sobre o desenvolvimento com IA. Sua tese: os agentes permitem escrever código rápido, mas a responsabilidade pelos erros continua sendo do desenvolvedor, e os sistemas resultantes costumam ficar excessivamente complexos.

A distinção central é entre o fácil (easy, subjetivo, depende da experiência) e o simples (simple, uma propriedade objetiva do sistema). O russo é fácil para um falante nativo, mas difícil para um estrangeiro. Já a complexidade é o entrelaçamento de aspectos independentes, uma 'multiplicidade de dobras' no sentido literal. O DRY pode ser um code smell, mas às vezes a duplicação simplifica o sistema e reduz o acoplamento do código.

Fazer vibe coding com agentes é muito fácil, mas os sistemas resultantes costumam ser complexos. O desenvolvedor carrega toda a responsabilidade pelo código do LLM, e quanto mais complexo esse código é, mais difícil fica entendê-lo, menor é sua confiabilidade e mais fracas são as garantias de time-to-market e SLA.

O LLM entende complexidade?

A resposta é ambígua. As pesquisas mostram que os modelos raciocinam bem sobre complexidade, mas são ruins em evitá-la.

Lista de estudos: • τt-Bench: os agentes automatizam a escrita de código, mas não o pensamento de engenharia. Quando um teste falha, o agente corrige o teste em vez do código. Eles ignoram requisitos de produção, reusabilidade e limites arquiteturais.

• SlopCodeBench: o LLM gera 2,3 vezes mais linhas de código do que humanos. A degradação na métrica de erosão estrutural (acúmulo de complexidade dentro das funções) é de cerca de 6 vezes. O melhor modelo nos experimentos foi o GPT-5.

5. • Estimating problem difficulty: a correlação entre as estimativas de dificuldade do LLM e das pessoas é de 0,8 (Pearson). • Can LLMs Estimate Student Struggles: os modelos não se adaptam à experiência de uma pessoa específica e não preveem suas dificuldades pessoais.

• Rethinking Code Complexity: um estudo da complexidade por meio da profundidade de aninhamento e da ramificação. • Beyond Strict Rules: DeepSeek-R1, GPT-5 mini, Llama-3.3 e Qwen2.

5-Code detectam code smells simples, mas deixam passar os mais complexos, visíveis para humanos. • The Modular Imperative: o Claude Sonnet 4 divide o código em arquivos e escreve sobre separation of concerns, mas, ao mesmo tempo, conecta entidades de forma implícita e emaranha o sistema.

O equilíbrio entre controle e autonomia

Há dois extremos: o controle total (o desenvolvedor faz tudo, a complexidade é mínima, mas o esforço é máximo) e a autonomia total (o agente escreve tudo, o esforço é zero, mas a complexidade cresce). Graficamente, essa relação é inversa.

O autor sugere que existe um ponto ótimo a partir do qual novos investimentos de esforço rendem cada vez menos (a lei dos retornos decrescentes). Por exemplo, depois de escrever um template para 50 testes semelhantes, você gasta bastante esforço, mas o agente consegue replicá-los por analogia sozinho — o valor estava concentrado naqueles primeiros 20% de esforço.

Formalmente, é impossível encontrar o equilíbrio ideal — ele depende do contexto do projeto, de sua evolução, da equipe e dos requisitos. Mas, empiricamente, o autor chegou a um conjunto de princípios baseados em valores de manutenibilidade do código: maior controle sobre a arquitetura, separação explícita de responsabilidades e minimização da complexidade acidental.

Nenhuma linha do artigo foi escrita por um LLM. Os agentes foram usados apenas para buscar informações, revisar erros e gerar diagramas de texto. Cada palavra foi digitada no teclado.