Por que as fábricas de software falham (ou: engenharia de infraestrutura não basta)
As “fábricas de software” movidas por IA, que tentam gerar e entregar código com intervenção humana mínima, estão esbarrando em limites difíceis de qualidade de código, manutenibilidade e design de longo prazo. Os comentaristas argumentam que, embora os modelos modernos consigam produzir features e refatorações impressionantes, eles tendem a acumular “sujeira” arquitetural sem planejamento, verificação e senso estético guiados por humanos — especialmente em bases de código grandes e em evolução. Muitos veem o caminho mais promissor como equipes disciplinadas usando agentes como multiplicadores de força dentro de especificações, testes e processos de revisão fortes, em vez de automação total com “luzes apagadas”.
Estado das “fábricas de software” e contexto da StrongDM
- Alguns comentaristas observam que o trabalho de IA da StrongDM acabou se desdobrando em uma empresa de consultoria, interpretado tanto como sucesso (as ideias eram valiosas) quanto como sinal de que o produto precisava de muitos serviços.
- Um membro do laboratório da StrongDM esclarece que o “boletim meteorológico” deles vem recebendo atualizações regulares e afirma que a maioria dos problemas de software cede às técnicas de fábrica deles, especialmente com modelos mais novos.
- Outros argumentam que ainda estamos em uma fase inicial e experimental; ainda não existe uma “metodologia padrão” estável.
Rigor, manutenibilidade e especificações
- Há amplo consenso: as equipes que mais tiram proveito da IA já tinham alta disciplina, código limpo, testes e higiene.
- Muitos veem a manutenibilidade como o principal problema ainda não resolvido: os modelos conseguem implementar funcionalidades, mas aos poucos degradam a arquitetura e o acoplamento ao longo do tempo.
- As pessoas exploram especificações normativas no estilo RFC e restrições tipadas para delimitar agentes, mas observam que especificações muito detalhadas começam a se parecer com código e não deixam claro que economizam esforço.
- Alguns propõem configurações de RL que recompensem a saúde de longo prazo da base de código, mas observam que não existe um oráculo rápido e objetivo para “bom design”.
Code review, PRs e processo
- Há uma divisão forte sobre code review:
- Um grupo acredita que a revisão humana é essencial para compartilhamento de conhecimento, senso estético, supervisão de design e conformidade; usar LLMs para simular revisões é visto como negligência.
- Outro grupo automatiza revisões e afirma que as organizações se importam principalmente com prevenção de bugs e velocidade; argumenta que devemos revisar software em execução, não diffs.
- Muitos reclamam da UX de PR, de diffs enormes gerados por agentes e de comentários em “LLMês”.
- Alguns defendem minimizar as barreiras de PR por meio de checagens automatizadas pesadas, testes, linters e rollback fácil; outros argumentam que isso ainda deixa passar problemas de arquitetura e de compatibilidade retroativa.
Capacidades dos modelos, RL e longo contexto
- Há desacordo sobre o quanto os modelos de ponta (Opus, Fable, GPT-5.6 etc.) mudaram o jogo. Alguns relatam entregar features inteiras aos agentes; outros dizem que tentativas com “luzes apagadas” ainda produziram sujeira ou designs ruins que se reforçam a si mesmos.
- Vários observam que os modelos conseguem refatorar bem quando isso é explicitamente pedido, mas não percebem autonomamente quando refatorações são necessárias.
- O comportamento em longo contexto é misto: alguns veem pouca degradação; outros mostram exemplos de modelos esquecendo fluxos de trabalho simples em contextos grandes.
- Muitos enfatizam que o RL hoje otimiza principalmente o sucesso da tarefa, não a qualidade do design, então reward hacking e testes frágeis são comuns.
Papel dos engenheiros e do “senso estético”
- Vários comentários enquadram a principal função de um engenheiro de software como propriedade do sistema, design de longo prazo e senso estético, não apenas digitar código.
- Boa arquitetura é descrita como sutil, difícil de medir e aprendida por meio de experiência dolorosa; os comentaristas duvidam que os modelos atuais consigam tomar essas decisões de design de forma confiável.
- Um tema recorrente: padrões da base de código funcionam como “prompts implícitos”, então os humanos precisam proteger com vigilância as abstrações e os padrões, ou a sujeira se acumula.
Onde as fábricas podem funcionar hoje
- Muitos veem as “dark factories” como mais viáveis para:
- Apps pequenos, de baixo risco ou de hobby.
- Experimentos e scripts de curta duração.
- Para sistemas complexos, que geram receita ou são regulados, a maioria defende fábricas com humano no loop, com mais planejamento antecipado (produto, sistema, design de programa) e restrições mais rígidas, não autonomia total.