Fábricas de software com IA devem codificar julgamento humano
O problema por trás da fila de review
Robert Glaser observa que equipes de engenharia estão obcecadas com code review porque agentes produzem mais código e a fila de merge requests cresce. Ele argumenta que isso expõe um problema preexistente: uma equipe que antes passava 7 dias construindo a coisa errada em um único merge request já tinha o problema de produto - a fila apenas parecia administrável. A IA amplifica a cultura em que chega: times que experimentam ganham mais espaço para isso; organizações dirigidas por engenharia que negligenciam o trabalho de produto agora produzem as consequências dessa negligência mais rápido.
Transformar julgamento humano em feedback de máquina
A tese central é que humanos devem tornar seu julgamento utilizável por máquinas, para que máquinas revisem trabalho de máquina e corrijam problemas antes de chegarem às pessoas. Glaser descreve mecanismos concretos:
- Backpressure: feedback rápido e barato durante o ciclo de trabalho do agente, como erros de compilador, testes focados falhando, verificações de arquitetura (por exemplo, dependência indevida entre módulos) e checagens de acessibilidade.
- Gates de review com agentes especializados: revisores de segurança, UX e UI com instruções próprias e contexto fresco, capazes de desafiar o resultado independentemente do agente autor.
- Outcome Grading: converter julgamento de produto e domínio em algo avaliável repetidamente - bons e maus exemplos, cenários realistas e razões explícitas de rejeição. Ele cita a abordagem do HumanLayer: "sucesso é silencioso, apenas falhas produzem saída verbosa", para não inundar o contexto do agente.
Ele alerta que um avaliador confiantemente errado consegue manter a fábrica ocupada, e que uma cultura só de engenharia pode codificar más premissas de produto tão eficientemente quanto boas. O conhecimento do time de produto precisa moldar as rubricas; contato com cliente e discordância humana continuam importando.
Colaboração humana antes da especificação
Glaser critica o spec-driven development como cura universal: a especificação é útil, mas não dá para terminar de entender o trabalho antes de construí-lo. Em vez de gastar tempo humano transformando discussões ricas em documentos formais, ele propõe usar a IA para estruturar o que emerge da colaboração - hesitações, exemplos quase descartados e discordâncias carregam mais intenção do que a frase arrumada do ticket. O tempo economizado deve virar mais colaboração.
Construir é parte de especificar
O contato com o material importa: protótipos expõem conceitos faltantes, integrações revelam que duas pessoas usavam a mesma palavra para coisas diferentes. Ele cita Drew Breunig e seu Spec-Driven Development Triangle, que mantém specs, testes e código evoluindo juntos. A implementação mais barata permite testar várias abordagens sérias antes de escolher uma, desde que próximas de dados e restrições reais. O grau de delegação ao agente pode variar por tarefa, do trabalho de horas a objetivos bem entendidos até mudanças de direção a cada poucos minutos.
A fábrica como modelo operacional
A fábrica de software é tratada como modelo operacional: como o time organiza o trabalho com agentes, decide e assume responsabilidade. Ela precisa ser construída durante o próprio trabalho de produto - melhorar contexto quando o agente erra regras de domínio, antecipar verificações quando reviews capturam falhas recorrentes. Isso exige tempo e ownership além das features, gerando um backlog próprio da fábrica. A responsabilidade permanece: para mudanças consequentes, o time deve explicar decisões de arquitetura, premissas e o que fazer quando falha.
O conceito de Loop Intelligence torna visíveis padrões entre pessoas e times - correções repetidas de contexto, revisões pós-conclusão - e deriva recomendações, como nova conexão de ferramenta ou novo cenário de avaliação. Glaser é cauteloso com a promessa de uma fábrica autorrefinadora: ela exige desenvolvimento guiado por avaliação desde o início. As métricas também devem distinguir exploração útil (mudança de direção por aprendizado) de retrabalho contra requisito acordado.
A conclusão é prática: começar com uma peça real de trabalho de produto, discutir em conjunto, construir o suficiente para testar premissas e dar aos problemas recorrentes um lugar no backlog da fábrica.