Por que os agentes de programação são tão burros?

Artigo original ↗ Discussão no Hacker News ↗

A frustração está crescendo entre desenvolvedores que acham que os “agentes de programação” construídos sobre LLMs modernos ainda lutam com trabalho de software do mundo real, desde coordenar subtarefas e escolher modelos apropriados até manter a qualidade do código e seguir a arquitetura do projeto ao longo do tempo. Os comentaristas se dividem entre os que veem as limitações atuais como sintomas de harnesses e fluxos de trabalho imaturos — argumentando que, com contexto cuidadoso, ferramentas personalizadas e orquestração de agentes, os resultados podem ser excelentes — e os que acreditam que a tecnologia, fundamentalmente, entrega menos do que promete em codificação autônoma. A troca destaca uma divisão emergente: alguns engenheiros estão investindo pesado em frameworks e ferramentas próprias para agentes, enquanto outros continuam usando LLMs como assistentes, em vez de deixá-los conduzir o desenvolvimento complexo.

Sentimento geral

  • Muitos concordam que os agentes de programação atuais parecem “burros” na prática, mas há uma divisão:
    • Alguns dizem que modelos recentes de primeira linha, junto com melhores configurações, resolveram em grande parte os problemas do artigo.
    • Outros relatam meses de frustração, especialmente em projetos não triviais e de longa duração.

Harnesses vs. modelos

  • Vários argumentam que a maioria dos problemas está nos harnesses/orquestração, não nas limitações do modelo:
    • Prompts padrão ruins; nenhuma ênfase em subagentes, paralelismo ou separação de papéis.
    • Alguns harnesses (por exemplo, versões mais novas) conseguem criar muitas subtarefas assíncronas; outros continuam sequenciais ou frágeis.
    • As pessoas descrevem orquestradores personalizados que delegam a modelos mais baratos/rápidos e usam papéis distintos.

Subagentes, paralelismo e seleção de modelo

  • Experiências mistas:
    • Alguns relatam resultados excelentes com agentes autônomos que pegam tickets e abrem PRs, ou executam muitos agentes em um único repositório.
    • Outros acham que subagentes tornam tudo mais lento e pioram os resultados.
  • A seleção dinâmica de modelo (inteligente vs. barato) ainda é, em grande parte, manual ou guiada por prompt; a estimativa totalmente automática de dificuldade é vista como difícil.

Qualidade do código e fluxos de revisão

  • Muitos reclamam que código escrito por IA “funciona, mas é feio”:
    • Excessivamente complicado, tipagem fraca, arquitetura pouco clara, mau “gosto”.
  • Mitigações sugeridas:
    • Desenvolvimento guiado por documentação; escrever especificações/docs primeiro com o agente.
    • Codificar filosofia e estilo em AGENTS.md e em documentos markdown “fonte da verdade”.
    • Usar hooks/subagentes de revisão que critiquem e reescrevam automaticamente o código contra estilo explícito e a “definição de pronto”.

Prompting, contexto e engenharia de ambiente

  • Alguns insistem que um design cuidadoso de contexto/prompt/ambiente é essencial:
    • Tratar tudo o que o modelo vê — arquivos, docs, estrutura — como parte do prompt.
    • Construir ferramentas e habilidades locais em vez de depender de plugins genéricos.
  • Outros rebatem, observando que a maioria dos usuários não tem tempo para passar meses construindo frameworks sob medida.

Segurança e sandboxing

  • Forte preocupação com agentes com acesso ao sistema de arquivos/rede:
    • Sandboxes/contêineres são recomendados, mas ainda têm riscos de fuga e de cadeia de suprimentos (por exemplo, scripts em .git).
    • Alguns dão aos agentes acesso git somente leitura e os isolam nas redes.

Meta: expectativas e maturidade

  • Vários dizem que a lista de desejos de recursos “óbvios” deveria vir embutida nos harnesses por padrão, mas ainda estamos no início da “era da IA”.
  • Há tensão entre “se você quer, construa com um agente” e “a maioria das pessoas razoavelmente espera um comportamento melhor pronto para uso”.