Não existe mais algo como uma pequena equipe de software
Afirmações de que agentes de codificação com IA transformarão cada grupo de engenharia em uma “equipe grande” ao permitir centenas de mudanças paralelas estão enfrentando forte ceticismo. Comentadores argumentam que dividir sistemas em milhares de microsserviços para alimentar agentes apenas transfere a complexidade para a operação, torna a coordenação mais difícil e arrisca uma enxurrada de código de baixa qualidade otimizado para contagem de PRs em vez de valor para o usuário. Muitos veem os LLMs como ferramentas poderosas para desenvolvedores individuais e monólitos pequenos e bem arquitetados, mas alertam que a dependência excessiva de agentes ameaça a manutenção, o foco no produto e o papel de longo prazo dos engenheiros de software humanos.
Agentes, “pequenas equipes” e métricas de produtividade
- Vários comentadores duvidam que “pequenas equipes” fazendo 100 PRs/dia por meio de agentes represente progresso significativo.
- Contagens altas de PR/commit são vistas como métricas vaidosas fáceis de manipular, ainda mais distantes do valor para o usuário na era da IA.
- Segundo relatos, algumas organizações agora pressionam “atrasados” a usar mais IA, mesmo quando o trabalho gerado por IA precisa ser discretamente refeito.
Microsserviços vs monólitos com IA
- Muitos argumentam que microsserviços adicionam complexidade operacional (deploys, rede, retries, consistência, versionamento) sem remover a complexidade inerente do produto.
- Vários dizem que monólitos bem estruturados, com código modular e limites claros, continuam sendo superiores, especialmente porque um LLM pode manter mais contexto.
- Outros afirmam que serviços mais granulares (até “nano-services”) se alinham melhor com os limites de contexto dos LLMs e com o paralelismo dos agentes, mas isso é contestado.
Qualidade, correção e coordenação
- Há forte ceticismo de que agentes possam modificar com segurança milhares de serviços: eles não têm contexto completo do sistema e podem introduzir falhas sutis entre serviços.
- “Enxames” paralelos de agentes correm o risco de gerar conflitos semânticos em vez de simples conflitos de merge, tornando mais difícil a integração e a coordenação de releases.
- Alguns sugerem usar IA para manutenção: impor invariantes, simplificar código ou reduzir sistematicamente a dívida técnica – mas outros relatam que os modelos muitas vezes ignoram invariantes à medida que o contexto cresce.
Experiência do desenvolvedor e impacto no trabalho
- As experiências divergem: alguns devs solo/de pequenas equipes afirmam produtividade dramática e até reescritas inteiras de apps viabilizadas por LLMs; outros são eficazes sem eles.
- Debate sobre papéis futuros: de “você é um engenheiro de prompt ou está demitido” até a visão de que design de sistemas, entendimento e artesanato continuam essenciais.
- Preocupação de que o conhecimento arquitetural de seniores sendo substituído por mudanças opacas geradas por IA possa aumentar as quedas de serviço quando a equipe experiente se desfalcar.
Preocupações éticas, econômicas e sociais
- Preocupações com dependência de fornecedores externos de LLM, custos imprevisíveis, riscos de privacidade, questões de direitos autorais e atrofia de habilidades.
- Alguns veem a produtividade impulsionada por IA como desalinhada com as necessidades da sociedade (“mais apps ruins”, não software “melhor”), e movida por FOMO de investidores e “tokenmaxxing”.
- Outros argumentam que a IA é uma onda tecnológica permanente e transformadora; pode haver um “inverno” de capex, mas não um retorno ao desenvolvimento de software pré-IA.