Por que bons desenvolvedores têm tanta cautela com o desenvolvimento agentic?
Programadores experientes estão debatendo se as ferramentas de codificação agentic com IA melhoram ou corroem a qualidade de software e a habilidade dos desenvolvedores. Muitos elogiam os agentes por acelerar dramaticamente a implementação rotineira e a depuração, mas alertam que delegar demais o design e a codificação pode destruir modelos mentais de um sistema, incentivar revisões superficiais de grandes mudanças de código e empurrar humanos para papéis de QA com pouco contexto. Outros argumentam que o uso cuidadoso de agentes por engenheiros fortes, apoiado por bons testes e observabilidade, pode ser uma vantagem competitiva, enquanto a dependência excessiva por equipes menos experientes arrisca sistemas frágeis, pouco compreendidos e a degradação de longo prazo da expertise.
Por que a cautela?
- Muitos argumentam que a cautela se baseia em experiência, não em medo: os agentes atuais frequentemente produzem código que “funciona”, mas é frágil, incoerente ou difícil de raciocinar.
- Há preocupação de que o desenvolvimento agentic enfraqueça o próprio processo que forma bons desenvolvedores: praticar design, depuração e التفكير arquitetônico.
- Alguns comparam isso à terceirização: ganhos de curto prazo, erosão de longo prazo da expertise local.
Qualidade de código, risco e modelos mentais
- Desenvolvedores seniores enfatizam que “construído” ≠ “pronto para produção”: um único bug sutil pode causar incidentes graves, e agentes podem gerar esses bugs mais rapidamente.
- Escrever código à mão força a clarificação de requisitos e trade-offs; delegar a agentes permite que o modelo resolva ambiguidades em silêncio e tome decisões arquitetônicas.
- Diferenças grandes geradas automaticamente (por exemplo, PRs de 3 mil linhas) são difíceis de revisar de verdade; os desenvolvedores perdem um mapa mental profundo do sistema e tornam-se dependentes do agente para cada mudança.
Confiança, responsabilidade e dependências
- Alguns dizem que não confiam em código que não entendem, mas outros observam que já confiamos em camadas opacas: compiladores, sistemas operacionais, vastas árvores de dependências.
- Contraponto: bibliotecas OSS têm reputação comunitária, histórico e escrutínio compartilhado; um trecho gerado por IA é uma peça isolada, sem histórico.
- Debate sobre “rede de confiança”: quem é responsável quando um agente escreveu a maior parte do código? Alguns argumentam que a responsabilidade ainda recai sobre o humano que fez o commit; outros temem que a responsabilidade se torne difusa.
Como e quando os agentes ajudam
- Há amplo consenso de que os LLMs são ferramentas poderosas para: tarefas pequenas e bem delimitadas, caça a bugs, atualização de APIs, boilerplate, funcionalidades derivadas e experimentos rápidos.
- Vários afirmam que os “melhores” desenvolvedores usam agentes de forma agressiva, mas mantêm controle rígido: especificam arquitetura, testes e guardrails, e depois verificam as saídas.
- Outros relatam que os agentes são mais úteis em domínios desconhecidos do que em áreas nas quais já têm profunda expertise.
Padrões de adoção, cultura e preocupações de longo prazo
- Visões divididas: alguns veem a resistência como teimosia ou ameaça à identidade; outros veem o uso irrestrito de agentes como “vibe coding” imprudente.
- Preocupações com uma cultura de “se passou nos testes, publique”, tickets excessivamente especificados escritos por IA e gestores pressionando para usar agentes para “ir mais rápido” enquanto os desenvolvedores ainda assumem as consequências.
- Temores de longo prazo incluem atrofia de habilidades, degradação dos dados de treinamento e uma enxurrada de código “slop” de baixa qualidade; os otimistas preveem que estruturas mais fortes de testes/observabilidade tornarão os detalhes de implementação menos críticos.