- Usa vários agentes de IA (claude/o3/sonnet etc.) para automatizar desde a geração até a validação de código em um workflow pessoal de "fábrica de IA"
- Quando surge um problema, o ponto central é melhorar as entradas (Input), como plano, prompt e composição dos agentes, em vez de corrigir diretamente o código (Output) para elevar o nível de automação
- Ao melhorar iterativamente as entradas dessa forma, os agentes evoluem continuamente e maximizam a produtividade em tarefas repetitivas
- Divisão de papéis entre os agentes: planejamento (o3/sonnet4), execução (sonnet3.7/4), validação (o3/sonnet4) etc., implementando processamento paralelo e um loop automático de feedback
- Erros de código e problemas de estilo também são incorporados aos templates de planejamento para que as próximas gerações já saiam melhores; com a melhoria iterativa das entradas, a própria fábrica evolui
Visão geral da fábrica de IA e princípios centrais
- Mantém ambientes de trabalho isolados abrindo várias janelas do claude code em diferentes git-worktree
- o3 e sonnet 4 são usados para definir o plano; sonnet 3.7 ou sonnet 4 ficam com a execução; e o3 faz a avaliação dos resultados
- Planejamento, execução e validação são distribuídos em paralelo entre os agentes para ganhar eficiência
Princípio central – "Melhorar a própria entrada (Input) em vez de corrigir o resultado (Output)"
- Quando ocorre um problema, em vez de aplicar patch diretamente no código gerado, busca-se uma melhoria automatizada ajustando plano, prompt e mistura de agentes
- O conceito é criar, como no jogo Factorio, uma rede de agentes de IA em estilo fábrica que cresce automaticamente
- Nessa estrutura, o loop de planejar → programar → validar → melhorar circula continuamente, criando um ambiente em que agentes de IA produzem, validam e aprimoram código por conta própria
Workflow do dia a dia – a estrutura da fábrica
- A interface principal é o claude code; localmente, usa mcp, Goose (para conexão com modelos do Azure OpenAI), o3 etc.
Etapa 1: Planejamento (Planning)
- Insere uma tarefa de alto nível no claude code → o o3 faz perguntas adicionais e gera um plano (
<task>-plan.md)
- O plano inclui tanto os requisitos originais quanto o plano de implementação
Etapa 2: Execução (Execution)
- O sonnet 4 revisa o plano e o converte em uma lista de tarefas
- O claude code executa o trabalho e usa sonnet 3.7 ou 4 de acordo com a complexidade da tarefa
- Como o claude registra commits em cada etapa do trabalho, fica fácil fazer rollback quando surge algum problema
Etapa 3: Validação e feedback (Verification → Feedback)
- O sonnet 4 faz uma validação inicial do código gerado com base no plano
- Em seguida, o o3 realiza uma validação mais rigorosa comparando com o plano e os requisitos iniciais
- O o3 aponta com rigidez código desnecessário (por exemplo, flags para ignorar lint) ou estruturas ultrapassadas
- Os problemas identificados na validação são refletidos não por correção direta do código, mas por melhorias no template de planejamento
- Com git worktree, várias instâncias do claude code podem rodar em paralelo, permitindo múltiplos trabalhos simultâneos
Por que a "entrada" é mais importante do que a "saída"
- O resultado (Output) pode ser descartado, mas plano/prompt (Input) continuam se acumulando e melhorando como um ativo cumulativo
- Fazer debug na parte de entrada (plano, prompt) pode ser expandido para todos os trabalhos futuros
- Isso transforma os agentes de simples geradores em entidades que aprendem e colaboram por conta própria
- Ex.: faz com que o código deixe de carregar um CSV inteiro em memória e passe a processá-lo em stream; depois, esse padrão é refletido no plano para todos os CSVs, permitindo validação automática no futuro
Expansão da fábrica e colaboração entre agentes
- Com MCP, agentes especializados são alocados a tarefas diferentes e executados em paralelo
- Ex.: reunir todo o código Clojure e operar um agente dedicado à aplicação de regras locais de estilo, corrigindo problemas de estilo que surgem no ciclo de lint/test/debug do claude
- Mesmo no código de bibliotecas internas, reforça produtividade e consistência, por exemplo substituindo uso antigo de retry e
Thread/sleep por uma biblioteca própria de retry
- Ao construir vários agentes de pequena granularidade, é possível combiná-los por subtarefa específica e automatizar até workflows complexos
- Ex.: a partir de especificações de API e casos de negócio, uma combinação de agentes cuida automaticamente de integração, testes e documentação
- Essencialmente, as entradas são continuamente ajustadas e o processo é repetido; quando há falha, estagnação ou falta de contexto, o feedback é refletido na tentativa seguinte para gerar melhoria
- O código em si é consumível; o verdadeiro ativo são as instruções (entrada) e a configuração dos agentes
- As lições de todos os problemas — falha, estagnação, contexto insuficiente etc. — são incorporadas à próxima entrada, completando o loop da fábrica
Próximos passos e direção futura
- Pretende fortalecer a coordenação geral entre agentes para rastrear o workflow completo e introduzir mais automação
- Quer melhorar a conexão entre documentos de negócio e informações dos agentes, capturando e usando de forma mais eficaz sobretudo informações em nível mais alto de abstração
- Busca implementar workflows cada vez mais complexos, ampliando a colaboração e as interações sofisticadas entre agentes
- Também estuda formas de aproveitar ao máximo as cotas de tokens de vários fornecedores e alternar entre eles com facilidade (especialmente para lidar com o limite de tokens do bedrock sonnet 4)
Conclusão
- Atualmente, a fábrica de IA já tornou automática a geração e validação de código no dia a dia, a ponto de código poder ser implantado durante uma pausa para o café
- Ainda não chegou à automação total, mas o princípio de "melhorar a entrada em vez de corrigir a saída" já se consolidou como a essência da fábrica
1 comentários
Comentários no Hacker News
Acho que este texto vai ser quase impossível de entender para quem ainda não teve aquele momento de "aha" com o Claude Code
Se você remove as restrições de permissão com
claude --dangerously-skip-permissionse deixa um problema complexo nas mãos dele, dá para ver o Claude usando várias ferramentas livremente para resolver a questãoHoje mesmo fiz ele compilar, executar e depurar por conta própria um gerador de fractal de Mandelbrot em assembly 486 via Docker
Ele fez isso muito bem
link do gist
Acho que esse é um exemplo bem fácil para IDEs ou LLMs assim
Assembly está bem representado nos datasets de treino, e Docker também
Já deixei o Cursor correr solto pela minha base de código também
Espero que as ferramentas mais recentes um dia realmente cheguem lá, mas sinto que ainda não estamos nesse ponto
Também queria recomendar este vídeo do Dagger (e do fundador do Docker) apresentado na conferência AI Engineer
Esse vídeo também pode ser meio difícil de acompanhar
Estou escrevendo isso caso ajude alguém
Eu fiz downgrade do Claude Max para o Pro, e por US$ 20 por mês o limite de uso é mais do que suficiente
Parece que está competindo com o Gemini CLI, então agora fico feliz por estar pagando menos
Acho que praticamente qualquer LLM consegue resolver esse tipo de exemplo ou contexto sem muita dificuldade
Eu já passei por upgrades bem mais complexos de dependências em Rust, repetindo o processo mais de 30 vezes, com código wasm customizado no meio
O Claude conecta várias ferramentas como context7 e mcp-lsp para juntar os detalhes
Mas, conforme você continua usando, acaba esbarrando nos limites; se pressionar para tarefas mais refinadas e difíceis, as fraquezas aparecem
Sobre essa frase de que, com
claude --dangerously-skip-permissions, ele usa várias ferramentas para resolver problemas complexosEu já vi o Claude passar mais de uma hora tentando corrigir código do jeito errado
No fim, tive que intervir e mandar: "primeiro escreva testes unitários e, depois que eles passarem, escreva o código e me avise de novo"
Claude Code é uma ferramenta realmente incrível, mas a realidade é que ainda preciso repetir e fornecer o mapa básico da arquitetura o tempo todo
Acho difícil avaliar esses setups sem saber como o resultado do código é usado na prática
Se for um app de vibe coding para uso pessoal, é bem fácil acreditar nesse tipo de relato,
mas dizer que escreve código de alta qualidade em ambientes de produção complexos já é bem mais difícil de engolir
Concordo totalmente
Eu aumento bastante minha velocidade de programação com o Claude Code, mas sempre confiro pessoalmente toda mudança no código para garantir que o melhor sistema possível está sendo construído
Nas poucas tentativas em que só deixei rodando sozinho, ele acabou entregando bugs para os usuários
Na real, não acho que entendi muito bem o workflow ou os conceitos descritos neste texto
Talvez porque a explicação esteja meio vaga
No meu dia a dia, lido com sistemas complexos de produção usando estruturas em que vários agentes conversam entre si, agentes assíncronos,
git work treee coisas assimNão é que eu nunca mude o resultado produzido, mas, quando o resultado que eu queria não sai, costumo tratar isso como um sinal para melhorar meu workflow
Também venho tentando um workflow parecido, então queria compartilhar minha experiência
A base de código em Go com que trabalho tem centenas de milhares de linhas, e é usada de fato por dezenas a centenas de milhares de usuários B2C
Há bastante folga de performance, mas estamos no setor financeiro, onde precisão e confiabilidade são extremamente importantes
Como estou em um ambiente que usa apenas chave da OpenAI, fico só com um setup básico usando codex-cli e scripts simples para clonar repositório, configurar agentes, executar prompts etc.
As instâncias do codex me avisam quando é a minha vez via notificações do sistema, e uso
fzfpara me conectar à sessão dotmuxquando precisoAinda não usei MCP, mas está na minha lista de interesse
Esse jeito de trabalhar ajuda muito em tarefas pequenas e dispersas, e agora estou produzindo muito mais PRs pequenos
A metáfora de "cattle not pets" ainda se aplica; para trabalhos pequenos, eu simplesmente disparo prompts rápido para reduzir a distração
Para coisas maiores, ainda não parece encaixar tão bem, embora talvez eu mesmo ainda não tenha criado um flywheel de contexto suficiente
Na maior parte do tempo, sempre leio e ajusto o código resultante antes de enviar para revisão
Também faço quase toda a gestão de mudanças manualmente, e crio branch/commit/push por conta própria
Já experimentei algumas ferramentas de automação, mas ainda não consegui migrar totalmente
Concordo 100% com a mentalidade de "conserte a entrada, não a saída"
Isso já é um princípio muito poderoso mesmo sem IA, e o setor vem adotando isso cada vez mais
Com processos não determinísticos como os LLMs, não é tão fácil aplicar, e parece mais prática do que ciência
Obrigado pelo ótimo texto
Eu apresento um workflow parecido, mas um pouco mais simples, em um texto chamado "Vibe Specs"
post/artigo relacionado
Eu aplico essa regra à base de código inteira e faço a IA agir de duas formas diferentes
(1) antes de qualquer coisa, fazer perguntas
(2) antes de programar, criar um documento
spec.mdA ideia central é parecida, mas eu me limito a um único LLM
Acho que a maioria de nós está tentando isso de forma parecida
Como desenvolvedor solo, experimento várias automações de produção com uma mentalidade bem voltada à engenharia
Para mim, o objetivo final é obter confiança no código a partir de testes e2e gerados automaticamente pelo agente, independentemente da implementação
Ainda não cheguei totalmente lá
Agora o Claude Code também dá suporte nativo a esse fluxo com o “plan mode”
Criar arquivos
.mdmanualmente na verdade parece lento e incômodoA ideia básica é que você pode continuar documentando o que o sistema deve fazer, tanto em alto nível quanto nos detalhes funcionais, como provar que ele funciona e até como implementá-lo, incluindo arquitetura e estilo de código
A razão para usar vários modelos é reduzir viés e ampliar as opções de ajuste fino adequadas a tarefas específicas
Em algum momento, até sistemas grandes e complexos poderão ser reconstruídos com base em conjuntos de requisitos, e só então o software passará a corresponder de verdade à especificação
Nesse ponto, o único “código legado” que vai restar serão documentos de especificação legados
A ideia é corrigir a especificação, não o código gerado
imagem de meme relacionada
Fico me perguntando o que exatamente estão construindo de verdade
Sempre que falam sobre workflow com IA, é difícil saber se estão descrevendo um fluxo meio de sonho ou se estão mesmo usando isso de forma produtiva
Se o LLM escreve o código todo, eu simplesmente perco o interesse
Dos meus cerca de 50 projetos, só 2 foram feitos com LLM, e mesmo esses eu mexi manualmente
Nos outros, eu só tinha aquela sensação de “seria legal se existisse algo assim”, mas na prática não ligava muito para o resultado
No fim, você fica preso num loop de brigar com o computador, lidando com vários modelos e detalhes de implementação, e, quando o comportamento desejado não sai, joga em cima dele documentos de design, prompts, dados de exemplo, tudo o que puder
É muito mais rápido e bem menos estressante só deixar ele complementar pequenos trechos de código
Olhando para trás, parece que só gastei tempo e dinheiro para obter um software que mal funciona
Quando há requisitos claros ou uma base de código existente, e eu consigo guiar ativamente, os agentes ajudam bastante, mas esse fluxo de vibe coding, fora scripts pequenos ou apps de nicho, não tem graça nenhuma e raramente entrega a qualidade que eu quero
Também é caro demais, e o código continua bagunçado
No fim, parece só tempo gasto em discussões intermináveis com o computador
A essa altura, é muito melhor simplesmente fazer eu mesmo
Um problema que surge quando vários agentes trabalham cada um em sua própria
work treeé que cada agente acaba propondo ideias completamente diferentes em todos os detalhes, então a experiência do usuário fica totalmente inconsistentePor exemplo, agentes encarregados de criar o dashboard de Documents e o dashboard de Design podem projetar tudo com perspectivas completamente diferentes
Não há unidade nem no design, nem na estrutura, nem no schema de banco de dados, nem no design da API
Mesmo com a mesma entrada, as saídas diferem
No fim, quando você vai aumentando os arquivos de instrução para manter consistência, projetos grandes acabam facilmente chegando a alguns milhares de linhas, e a context window já não dá conta
No fim das contas, acho que faz mais sentido usar um LLM pequeno treinado só em regras e schemas específicos
Em vez de um LLM grande lidando por prompt com ideias tão vastas quanto o universo, um LLM pequeno talvez seja a resposta certa
Resultados totalmente diferentes entre agentes, falta de consistência no design
No fim, um sênior continua sendo indispensável
Seja IA ou humano, não tem jeito: você precisa fornecer pessoalmente a estrutura mínima e a flexibilidade necessárias para que as coisas andem na direção desejada
Sem estrutura, é muito melhor só programar você mesmo
Eu criei a primeira versão com as próprias mãos e, depois disso, ficou mais fácil manter a consistência dizendo ao Claude Code: "faça como neste exemplo"
Programação estilo ADHD, tentando gerar um produto na marra e repetindo até encaixar?
Não seria melhor simplesmente escrever você mesmo um código que possa evoluir no futuro?
A visão aqui é só não aumentar a pegada de carbono à toa
O objetivo final é remover o desenvolvedor desse processo
O dono do negócio pede um novo app CRUD e ele já vai direto para produção
Claro, o resultado vai estar cheio de bugs, ser lento e gravar dados em um banco não autenticado, mas isso não é problema meu
No final, encerra com uma expressão exagerada sobre tomar um chá quente de uma vez só
A programação mudou para sempre, e é preciso aceitar essa mudança rapidamente
Dizer “é só escrever o código” é como defender que todo mundo continue cuidando da própria carruagem
Carros também quebram, então não faz muito sentido insistir nos métodos antigos por causa disso
Fico me perguntando por que sempre aparece esse papo de “é só escrever você mesmo um código extensível para o futuro”
Hoje em dia até assistentes de código conseguem escrever código extensível e de fácil manutenção em zero-shot; dá vontade de perguntar se quem fala isso já tentou pedir exatamente isso na prática
Humanos também, no fim, encontram respostas por tentativa e erro contínuos
Quanto mais experiência, maior a diferença apenas no nível de simulação mental
Se a pegada de carbono é o problema, então a visão seria: se os datacenters de IA funcionarem com energia renovável, isso já resolveria?
Acho que precisamos descobrir como integrar melhor a IA ao workflow
Quem adotou IA de forma mais agressiva provavelmente já passou por preocupações parecidas, e ainda não há uma solução definitiva
Nesta fase, o essencial parece ser atribuir à IA papéis mínimos, mas muito bem definidos
Por exemplo, em um workflow de agentes para pesquisa de ações, dá para criar duas IAs, o ‘Bullish Guy’ e o ‘Bearish Guy’, e fazê-las debater os prós e contras de um mesmo papel
Ao colocá-las para pesquisar de posições opostas, o resultado tende a ser uma análise mais abrangente e também mais profunda
Essa ideia, na verdade, veio de observar o jeito como discussões acontecem nas redes sociais
Em vibe-coding, parece que o resultado raramente vai além de algo autorreferente, e no fim tudo isso se parece mais com o sucessor da impressão 3D: um hobby caro e uma atividade sem fim de fabricar brinquedinhos
Hoje em dia, o equivalente ao “benchy” do vibe coding não seria algo como um app de tarefas?
Quem projeta produtos ou trabalha com engenharia usa isso o tempo todo
A única razão de consumidores comuns não utilizarem mais é que quase qualquer item de plástico de que precisam já pode ser encomendado na Amazon
Se compras online não existissem, isso seria muito mais útil para a pessoa média
Daqui para frente, provavelmente será uma tecnologia realmente necessária só para quem consegue projetar arquivos customizados por conta própria