Software Factory: Como Combinar Código e Agentes para Engenharia Real

Tem um vídeo que vi recentemente que mudou um pouco como eu entendo engenharia agêntica — não é sobre rodar um agente, nem sobre orquestrar múltiplos agentes em paralelo. É sobre combinar três coisas: um engenheiro, código, e agentes. Código propõe estrutura, agentes propõem trabalho, código valida e dispõe o resultado. "Agents plus code beats agents alone." Se você só empilha skills e sub-agentes sem um gate de validação determinística entre as fases, você vai pagar isso depois em custo, velocidade e alucinação acumulada.

Por que Software Factory Importa Agora

Vibe coding (não saber como seu sistema funciona e não olhar) é a morte lenta de um pipeline agêntico. Agentic engineering (saber como seu sistema funciona tão bem que você não precisa olhar porque a validação automática já faz por você) é o próximo degrau. A diferença é o código validando agentes, não agentes validando código. Quem fica só gerando saída sem checkpoint determinístico vai descobrir no mile 1000 que os agentes acumularam um viés ou um erro sistemático, e aí recuperar é caro.

Observável — A Linha Fina Entre Cego e Perdido

Se você não consegue medir seus agentes, não consegue melhorá-los. A Super Simple Software Factory (SSSF) abre uma "swim lane" view de cada fase do pipeline — cada prompt compilado (system + user), cada tool call, cada breakdown de custo por agente visível. Você vê exatamente o que foi pedido, o que foi respondido, quanto custou. Não é telemetria genérica — é o prompt REAL que rodou, com o valor REAL que cobrou. Quando um agente falha, você vê o stack trace daquele agente específico, não um erro agregado de "modelo retornou null".

Observabilidade é o que transforma "meu agente está ruim" em "ah, o prompt do scouting tá pedindo features demais no passo 1, vou cortar 3 linhas e rerunnar". Medição rápida = iteração rápida.

Customizável — O Core Four Está Tudo em Um Arquivo

Um único arquivo YAML controla o "core four" de cada agente no time: contexto, modelo, prompt, e tool access. Não é XML aninhado, não é banco de config — é YAML simples, legível, versionável. "Domine o core four, domine o agente." Você muda um modelo pra tentar Gemini 3.6 Flash no scouting (mais rápido, mais barato) e deixa Opus 5 no planeamento pesado? Uma linha do YAML. Você quer passar contexto a mais pra um agente específico? Outro bloco YAML. Não tem framework oculto, configuração por convenção, ou "magic" — tudo é explícito e legível.

Isso importa porque quando um agente tá ruim, você não tá debugando um framework preto. Você tá olhando direto pro YAML e pensando: "esse prompt tá claro?", "esse modelo é o certo pra essa fase?", "esse tool tem permissão?". Simplicidade é documentação de graça.

Reusável — /install Vai em Qualquer Codebase

Um comando `/install` instala a fábrica inteira em qualquer codebase. E isso importa porque um agente consegue operar E instalar sozinho — é uma skill que outro agente consegue chamar, não é um deployment manual. Você tem um codebase novo? Agente chama `/install`, bootstrap acontece automático, e você já tá rodando o pipeline. Em produção, um agente de operações consegue girar up novas fábricas por conta própria sem você tocar.

Três Workflows na Prática

O vídeo rodou 3 exemplos ao vivo, em complexidade crescente. O primeiro, Scout, é bem simples: 1 agente, 2 fases. Agente mapeia o app e sugere 3 features novas. Usa Gemini 3.6 Flash (modelo "workhorse" barato, ~$1.50 de input total). A sacada: ele parou de fixar num modelo só e pensa em "model stack" — modelo barato pro scouting, modelo potente pro planeamento.

O segundo, Plan→Build→Test, é intermediário. Kimi K3 planeja (primeiro modelo open-weights em tier state-of-the-art, mas "pensa" bastante, mais lento). Gemini 3.6 Flash constrói. Depois de construir, 2 checks determinísticos rodam automaticamente — se falhar, devolve pro agente de build corrigir. A chave: código validando, não agente validando.

O terceiro é o SDLC completo: Plan → Build → Test → Fix (se precisar) → Review → Revise (se precisar) → Document → Commit. Entre cada fase, gate checks determinísticos decidem se avança. Opus 5 planeja (apesar de benchmark dizer que Opus 5 supera Fable 5, ele comenta que na prática ainda sente Fable 5 mais forte em situação crítica). Mas a novidade é que entre fases, não tem agente decidindo — é código verificando. Test suite que já passou não volta pro context window do agente — deixe o código validar, só devolva pro agente quando falha. Essa é a linha fina entre vibe coding e engenharia agêntica.

Por Que Isso Importa Para Devs

(1) Observabilidade mata alucinação cumulativa. Cada prompt visível, cada custo visível, cada falha rastreável. Não é "o sistema tá estranha", é "fase 3 do workflow gerou saída inválida porque o prompt tá pedindo algo impossível".

(2) Customização rápida premia iteração. Arquivo YAML, não framework. Mudar modelo, contexto, ou tool em 30 segundos. Quando você tá aprendendo o que funciona, velocidade de iteração é o gargalo real.

(3) Código como árbitro, não agente. Determinístico bate heurística quando escala. No mile 1, agente julgando output é ok. No mile 1000, só código validando mantém a confiabilidade.

Conclusão

Vibe coding é não saber como seu sistema funciona e não olhar. Engenharia agêntica é saber como seu sistema funciona tão bem que você não precisa olhar porque a validação já faz por você. Software factory é o infrastructure pra isso — simples, visível, customizável, reusável. Quem só empilha agentes sem validação determinística vai descobrir tarde que a escala traiu. Quem combina código e agentes já tá vencendo.

Todo o conteúdo e os 3 workflows estão detalhados no vídeo completo do IndyDevDan.