Desde o fim de 2025, venho pensando bastante em como melhorar meu fluxo de desenvolvimento com agentes de IA. Como muitos desenvolvedores, comecei usando agentes da maneira mais simples: manualmente. Um agente, uma tarefa, muita supervisão e muita interação para manter o trabalho na direção certa. Conforme fui me acostumando com essas ferramentas — entendendo como conversar com elas, quanto contexto fornecer e quando intervir —, a pergunta principal começou a mudar. Já não era apenas como a IA poderia me ajudar a escrever código, mas quanto do meu fluxo de desenvolvimento eu poderia delegar sem perder controle ou qualidade.
Minhas primeiras tentativas de orquestração
Já escrevi sobre meu primeiro projeto de orquestração com subagentes . O desenho era razoavelmente sólido, embora ainda houvesse muito a melhorar, mas era difícil obter resultados consistentes. O agente principal nem sempre coordenava os subagentes de forma confiável. Por exemplo, depois de iniciar um subagente, às vezes continuava fazendo trabalho sem relação com a tarefa, em vez de aguardar o resultado delegado. Em outros casos, consultava repetidamente o subagente ou começava a executar algo que já havia delegado. Isso gerava trabalho duplicado, uso desnecessário de contexto e comportamento imprevisível.
Não era apenas um problema de elaboração do prompt. Parte da dificuldade parecia vir de limitações no ambiente de execução do agente ou no comportamento do próprio modelo. Cheguei a abrir uma issue no repositório openai/codex documentando um desses casos.
O que mudou
Recentemente, porém, isso começou a mudar. No meu fluxo, a orquestração de subagentes do Codex ficou confiável o suficiente para que eu pudesse estruturar processos de desenvolvimento ao redor dela. O agente principal consegue delegar uma tarefa bem delimitada e esperar quando faz sentido, enquanto eu continuo interagindo com a conversa principal, inspecionando o que os subagentes fazem e redirecionando o trabalho quando necessário.
Pode parecer uma melhoria relativamente pequena, mas não acho que seja. Quando a delegação passa a ser confiável, o problema muda. Dá para pensar em quais tarefas devem ser delegadas, quais podem rodar em paralelo, quais dependem de resultados anteriores, de quanto contexto cada agente realmente precisa e de como o agente principal deve integrar tudo depois. Nesse ponto, o fluxo começa a se parecer muito mais com engenharia de software do que com simplesmente pedir a um modelo para “implementar esta funcionalidade”.
Planejamento antes da orquestração
É aqui que o planejamento se torna ainda mais importante. O fato de um agente poder iniciar vários subagentes não significa que deva fazer isso. Antes de delegar qualquer coisa, tento entender a funcionalidade e dividi-la em tarefas com limites claros, entregas esperadas, restrições relevantes e dependências conhecidas. Algumas tarefas devem ser sequenciais; outras podem acontecer em paralelo.
Um agente pode investigar uma parte desconhecida do código, outro trabalhar em testes e outro revisar uma implementação. O agente principal combina esses resultados na próxima etapa. O que importa não é a quantidade de agentes, mas se o trabalho foi decomposto corretamente.
O contexto do repositório também ganha muito valor nesse modelo. Boas instruções em AGENTS.md, documentação de arquitetura, convenções do projeto, skills reutilizáveis, testes, requisitos rigorosos de tipos e outras formas de contexto persistente dão aos próximos agentes uma base reutilizável. Sem ela, cada agente precisa redescobrir o projeto. Com ela, entram no repositório com uma compreensão muito melhor de como o sistema funciona e de como devem agir. Na prática, a qualidade da orquestração depende tanto do modelo e do ambiente de execução quanto da preparação do projeto para receber agentes.
IA não serve apenas para construir mais rápido
Também venho pensando em como medimos o valor da IA no desenvolvimento de software. A maioria das discussões se concentra em velocidade: quão rápido uma funcionalidade pode ser construída, quanto código um agente gera ou em quanto tempo algo pode ser entregue. Não acho que essa seja a parte mais interessante.
Antes de trabalhar assim, atuei profissionalmente em uma software house, onde entreguei milhares de commits em produção. Como muitas equipes com prazos reais de clientes, fazíamos concessões o tempo todo. Uma funcionalidade precisava entrar no ar, outra tarefa já estava esperando e o cliente precisava da mudança. Com isso, trabalhos que sabíamos que melhorariam o projeto acabavam adiados: mais testes automatizados, maior cobertura de integração, validação de casos de borda, refatorações profundas, documentação melhor ou simplesmente mais acabamento. Não era falta de importância. Era falta de tempo.
A IA muda o custo da qualidade
É aqui que vejo uma mudança importante. A IA reduz o custo de alguns trabalhos de engenharia que antes consumiam muito tempo do desenvolvedor. Um agente pode investigar casos de borda enquanto outro implementa. Um subagente pode ampliar testes sem obrigar o agente principal a carregar cada detalhe da implementação no contexto. Outro pode revisar uma mudança em relação aos requisitos originais ou investigar uma parte desconhecida do código antes de qualquer alteração.
Nada disso elimina a necessidade de julgamento de engenharia nem garante qualidade, mas torna certos trabalhos muito mais baratos de executar.
É também por isso que não me importo de passar horas ou até dias trabalhando com IA na mesma funcionalidade. Se o resultado tem arquitetura melhor, testes mais sólidos, menos casos de borda, documentação melhor e uma implementação mais bem acabada, o valor não está em terminar em vinte minutos. Está em conseguir distribuir o esforço de engenharia de outra forma. Para mim, a IA está se tornando menos uma forma de construir rápido e mais uma maneira de tornar viável construir com mais qualidade.
Quem já passou tempo suficiente desenvolvendo com agentes sabe que gerar algo que funciona está ficando relativamente fácil. Gerar algo consistente com a arquitetura existente, sustentável, bem testado, compreensível para outro desenvolvedor, alinhado aos requisitos e sem padrões genéricos de IA é outro problema.
Isso aparece muito no frontend, onde os agentes tendem a convergir para layouts e padrões visuais parecidos sem uma direção forte, mas o mesmo ocorre no backend. Eles podem introduzir abstrações desnecessárias, nomes inconsistentes, lógica duplicada, limites fracos ou soluções que funcionam tecnicamente, mas não se encaixam na arquitetura. Modelos melhores ajudam, mas o fluxo ao redor deles continua sendo tão importante quanto. Planejamento, contexto, limites de tarefas e revisão continuam importando.
Como isso funciona na prática
Tenho aplicado essas ideias ao construir meu projeto público TowelBooks e ao contribuir com outros projetos pelo meu GitHub . Boa parte desse trabalho foi feita com modelos de custo relativamente baixo, como o GPT-5.6 Luna, outro aspecto dessa mudança que acho interessante.
Fluxos com agentes não exigem necessariamente o modelo mais caro em cada etapa. Um modelo mais forte pode ajudar na arquitetura, no planejamento, no raciocínio difícil ou em problemas ambíguos. Já tarefas menores de implementação, investigação, testes e revisão muitas vezes podem ser delegadas a modelos mais baratos, desde que o trabalho esteja bem decomposto. Uma boa divisão de tarefas pode melhorar a confiabilidade e a eficiência de custos ao mesmo tempo.
Considerações finais
O que mais me interessa nessa direção não é um agente gerar uma aplicação inteira a partir de um prompt. É a possibilidade de criar um fluxo em que conseguimos decompor problemas de engenharia, delegar partes bem delimitadas, executar tarefas independentes em paralelo, preservar limites de contexto, revisar resultados intermediários e coordenar tudo por meio de um agente principal.
O desenvolvedor continua responsável pela arquitetura, pelas restrições, pelas concessões aceitáveis e pelo resultado final. Mas a quantidade de trabalho de engenharia que pode acontecer ao redor dessas decisões está aumentando rapidamente.
Talvez você tenha notado que mencionei bastante o Codex ao longo do artigo. É simplesmente porque ele se tornou minha principal ferramenta de desenvolvimento com IA. Tenho me impressionado com a rapidez da evolução da experiência com agentes. No meu fluxo, combinar modelos mais fortes para planejamento e raciocínio com modelos mais baratos para implementação e tarefas delegadas tornou o desenvolvimento com múltiplos agentes muito mais prático.
O mais interessante, porém, não é um modelo específico. É que as ferramentas ao redor deles finalmente estão ficando confiáveis o suficiente para transformar esses fluxos de experimentos em processos reais de desenvolvimento de software.