Sua equipe usa IA. Mas ela já sabe trabalhar com IA?

Hoje em dia é bem comum ver um desenvolvedor abrindo o editor, digitando um prompt rápido e recebendo uma implementação pronta em questão de segundos.

Isso tem muito valor. Mas, para quem constrói produtos e lidera times de engenharia, a dor costuma ser outra. A pergunta que fica é: a equipe está realmente trabalhando melhor, ou só estamos gerando código mais rápido?

Em um projeto de verdade, lidamos com padrões de arquitetura, regras de negócio chatas, contratos de API e, principalmente, pessoas que vão ter que manter esse código amanhã. Se cada dev usa um agente isolado, com suas próprias instruções e um contexto pela metade, a gente corre o risco de acelerar a criação de um monstro cheio de partes incompatíveis.

Figura 1 — A diferença não está no número de ferramentas, mas no contexto compartilhado e nos critérios de entrega.

É exatamente para tentar resolver esse gargalo que tenho focado bastante em estruturar fluxos de orquestração na prática — e é um pouco desse aprendizado que quero compartilhar aqui.

Usar IA sozinho não é integrar IA no time

Quando falamos de IA hoje, o papo costuma ficar preso em qual modelo é mais inteligente ou quantas linhas de código o Copilot gerou. Essas métricas ajudam, claro, mas não dizem muito sobre o que acontece depois que o PR (Pull Request) é aberto.

Se olharmos para a pesquisa DORA 2025, do Google, a mensagem que levo dessa pesquisa é que a IA tende a amplificar forças e fragilidades já existentes nas organizações. Não dá para jogar uma ferramenta nova no time e esperar que ela consiga consertar falhas de comunicação ou processos ruins.

Antes de pensar em agentes, as perguntas básicas de engenharia continuam as mesmas. O que significa “tarefa concluída” por aqui? Onde registramos as decisões de arquitetura? Como garantimos que uma mudança não quebrou um contrato? Quem responde por esse deploy?

Se o seu time não tem essas respostas na ponta da língua, o agente de IA também não vai ter.

O bom e velho planejamento

Se a tarefa for corrigir um erro de digitação ou ajustar a cor de um botão, o agente pode ir lá e fazer direto. Criar processo em cima disso é só burocracia.

Mas pensa numa alteração no fluxo de checkout que bate no frontend, backend, banco e num serviço de terceiros. O agente pode sair escrevendo código na hora e entregar algo que compila. Mas ele viu todos os lugares que isso impacta? Ele sabe que existe uma restrição delicada de rollback naquele banco específico?

Planejar, nesse caso, não é criar burocracia. É reduzir incerteza antes de mexer no sistema.

Quando a mudança é complexa, eu gosto de quebrar em três passos lógicos: primeiro, entender o problema e as restrições; segundo, mapear as dependências e o que define o sucesso da tarefa; e só então ir para a execução e os testes. Se no meio do caminho a gente descobre que uma premissa estava errada, ajustamos o plano. Nada de seguir roteiro cego.

E a grande vantagem é que um plano bem escrito serve de base para o próximo agente (ou para o próximo dev), sem que ele precise ler todo o histórico do chat de novo.

Um modelo para cada etapa do fluxo?

Para tarefas menores, usar o mesmo modelo de ponta a ponta resolve muito bem a vida. O gargalo aparece quando a demanda exige investigar muito código, fazer alterações espalhadas e depois revisar tudo com lupa. Nesses cenários, dividir responsabilidades faz sentido:

• Para planejar: Você precisa de um agente bom de raciocínio. Ele vai ler o repositório, achar dependências, levantar riscos e montar um plano de ataque. O foco aqui não é gerar código, é entregar um plano claro e validável.
• Para executar: Aqui a IA recebe uma caixinha fechada: o contexto mastigado e o que ela precisa fazer. Se o contrato já estiver bem definido, um modelo mais rápido e econômico pode ser suficiente, desde que a entrega passe pelas verificações necessárias. Mas cuidado: se a tarefa exigir decisões difíceis de arquitetura no meio do caminho, o modelo “barato” vai acabar gerando retrabalho.
• Para revisar: Um agente diferente pode validar se o código gerado faz o que o plano pediu, se respeita a segurança e se passa nos testes. Vale lembrar que IA não substitui a revisão humana nem os testes automatizados (dois modelos diferentes podem alucinar e concordar no mesmo erro).
• Para documentar: Depois que tudo está rodando, um modelo pode ler o diff final e gerar a nota de versão ou atualizar um ADR. O segredo é documentar só o que foi entregue, e não o que foi planejado.

Figura 2 — A separação de responsabilidades só faz sentido quando melhora a qualidade, o tempo ou o bolso.

A regra de ouro aqui é escolher a capacidade certa para a complexidade do problema.

E onde entra o orquestrador?

Ter um monte de agentes rodando não quer dizer que você tem um processo. Alguém precisa gerenciar quem faz o que, controlar dependências, segurar a onda do custo (para a IA não ficar rodando em loop infinito) e validar critérios de sucesso.

É aí que brilha o orquestrador. E um detalhe importante: ele não precisa ser uma IA. Boa parte dessa coordenação pode ser código tradicional, determinístico mesmo.

Imagina um pipeline: levantamento, planejamento, execução, revisão, correção. Se a revisão de IA (ou o linter) achar um erro de sintaxe, o orquestrador manda a tarefa de volta para a execução sem precisar repensar o projeto do zero. Bateu no limite de orçamento da API? Ele pausa e chama um humano.

É só observar os padrões discutidos pela Anthropic no artigo Building Effective Agents. Fica bem claro que você só deve adicionar a complexidade de um sistema multiagente quando a tarefa realmente pede isso.

Trabalhando com “lanes” (trilhas de execução)

A gente costuma dividir funcionalidades maiores em trilhas (lanes): backend para cá, frontend para lá. O problema é que paralelizar o trabalho da IA só funciona se os contratos entre essas partes estiverem cravados.

Se a API ainda não está definida, botar dois agentes para escrever o front e o back ao mesmo tempo é pedir para dar conflito. Cada um vai assumir um contrato diferente, e as peças não vão se encaixar no final.

Figura 3 — Paralelismo de IA exige contratos muito claros e isolamento.

A mesma coisa vale para a parte operacional. A gente pode (e deve) ter uma trilha focada em observabilidade, segurança e deploy. Mas vale o lembrete: SRE (Engenharia de Confiabilidade) não é só um prompt bonito. Criar um agente chamado “SRE” não tira a responsabilidade operacional do time.

O foco de trabalhar com lanes é acelerar o que é seguro paralelizar, e não apenas ligar o máximo de instâncias possível.

Botar mais IA custa mais caro?

Pode apostar que sim. Cada agente a mais na jogada gasta contexto, consome tokens, faz chamadas de ferramenta e toma tempo. Montar um fluxo gigante cheio de agentes para uma tarefa banal sai mais caro e demora mais do que fazer direto.

Mas a conta também pode ser inversa. Ter um modelo mais barato focado só em arrumar testes, para que o modelo caro (e pesado) não precise ler o repositório inteiro de novo, economiza bastante.

Figura 4 — O que importa no fim do dia é quanto custa até a entrega estar validada, e não o valor do token na primeira resposta.

Na prática, eu gosto de olhar para quatro coisas: custo final, tempo até aprovar, quantidade de refação e qualidade do que foi entregue. Às vezes, um modelo rápido erra 5 vezes e fica mais caro do que rodar uma única vez no modelo mais potente que acerta de primeira.

O modelo certo não é necessariamente o mais barato ou o mais inteligente, mas sim o que resolve o problema sem você ter que refazer o trabalho.

Adequando a estratégia ao projeto

Projetos novos: explorar e depois consolidar

Quando estamos começando algo do zero, a IA é sensacional para criar protótipos rápidos e testar ideias. Mas eu evitaria a tentação de pedir o “sistema inteiro” sem antes ter definido requisitos mínimos e arquitetura básica.

Protótipo rodando não é arquitetura de produção. Use a IA para explorar, mas defina os limites antes de mandar ela escrever milhares de linhas.

Sistemas em produção: entenda antes de mexer

Se tem cliente usando, a regra número um é não quebrar o que já funciona. Aqui, o foco do agente muda: ele precisa achar onde a alteração vai bater, checar a cobertura de testes e levantar o risco de regressão. O planejamento serve para traçar a linha do que vai mudar e, principalmente, do que não pode ser tocado.

Código legado: cuidado com a reescrita mágica

Em sistemas antigos, a IA ajuda muito a mapear o que está acontecendo ali dentro e escrever testes de caracterização. Mas fuja da ideia de “reescrever tudo em Node/Go/Rust” só porque o agente consegue. A Thoughtworks e o Martin Fowler publicaram um material excelente sobre como modernizar legados com GenAI de forma incremental. Trocar de linguagem sem entender a regra de negócio que estava escondida ali é só arrumar um problema mais moderno.

Como colocar isso para rodar na sua equipe?

Eu definitivamente não começaria comprando um monte de licença cara e mandando o time “usar IA a partir de amanhã”.

Comece pequeno. Pegue uma tarefa real, mas que não vá derrubar a empresa se der errado. Passe o contexto, peça para a IA gerar um plano, deixe ela executar e revise muito bem o resultado.

Depois, faça a retrospectiva: Ajudou? Economizou tempo? O código ficou decente ou virou um espaguete? Precisava mesmo de vários agentes para resolver isso?

A partir daí, você vai ganhando confiança para dar mais autonomia para as ferramentas.

Onde estou aplicando isso

Esses padrões que estou descrevendo não são regras tiradas da cartola. É o que a gente tem apanhado para construir no dia a dia.

Faço parte da IAPro Community, um espaço bem legal que o Fernando Bolzan criou para a galera trocar experiências reais sobre IA. É de lá que nascem algumas iniciativas open source bem interessantes.

O Orquestrador Maestro, por exemplo, foi idealizado pelo Fernando. Eu acabei mergulhando de cabeça no projeto e ajudei bastante na evolução técnica até conseguirmos lançar a versão 1.0.

E puxando o gancho do que aprendi estruturando essas orquestrações, comecei o desenvolvimento do IAPro Nexus, que hoje segue evoluindo rápido graças à parceria e ao suporte do Fernando e do resto da comunidade.

Maestro: governança e evidência na prática

Com a chegada da versão 1.0, o Maestro ficou muito mais focado no fluxo real de engenharia. Ele seleciona skills de acordo com a intenção e complexidade da tarefa e procura limitar o contexto ao necessário. Isso reduz trabalho e leitura desnecessários, mas não substitui critérios de verificação nem garante respostas corretas. O custo efetivo ainda depende do modelo escolhido, das ferramentas acionadas e do retrabalho.

A ideia do Maestro não é matar o Claude Code ou o Copilot. Ele atua como uma camada de metodologia e governança, incorporando verificações e evidências ao ciclo antes de declarar uma conclusão. Isso complementa, mas não substitui, testes e revisão humana.

Nexus: gerenciando o ciclo de vida

Enquanto o Maestro cuida bem de quem está executando e comprovando o código, o Nexus olha para o andar de cima. Ele é um ambiente focado em organizar o ciclo de vida dos projetos de forma supervisionada.

Para dar nome aos bois e não perder o controle do que está rodando, nós estruturamos o Nexus em alguns pilares práticos: o Composer ajuda a transformar uma intenção em plano; o WorkPlan registra a estrutura, as decisões e dependências; o Flow apresenta o plano de forma visual e editável; e as Missions coordenam sua execução com agentes e verificações.

São dois projetos separados, mas que se encaixam muito bem. O Nexus está crescendo rápido e muita coisa ainda está em fase beta, mas ele já mostra na prática como a gente pode parar de tratar IA só como um “autocomplete vitaminado” e passar a usá-la de forma sistêmica e previsível.

No fim do dia, a gente ainda está fazendo engenharia

Sim, gerar código ficou absurdamente rápido. Mas gerar mais rápido não nos livra de ter que entender o negócio, planejar as mudanças, fazer revisão de arquitetura e manter o sistema de pé no longo prazo.

O próprio Martin Fowler chama isso de agentic engineering e faz questão de separar do vibe coding: o agente escreve o código, mas os humanos continuam olhando para ele, revisando e respondendo pelo que o software faz.

Curiosamente, quanto mais fácil é gerar um bloco de código, mais essencial se torna o desenvolvedor que sabe explicar o motivo daquele código existir.

Trazer IA para o time não é sobre virar “engenheiro de prompt”. É sobre criar um ambiente onde humanos e agentes colaboram com papéis claros, sem bagunçar a casa.

Conheça os projetos e participe

• Orquestrador Maestro — GitHub — projeto open source liderado por Fernando Bolzan com contribuições da comunidade.
• IAPro Nexus — GitHub — projeto open source focado na coordenação macro de agentes.
• IAPro Community — comunidade para troca de experiências e networking sobre IA.
• Fernando Bolzan — Instagram — idealizador do Maestro e incentivador da comunidade.

Se a sua empresa está quebrando a cabeça para sair do uso isolado de IA e montar uma esteira de engenharia mais madura, me chama. Você pode entrar em contato comigo pelo kiver.dev para batermos um papo sobre adoção, arquitetura de agentes e como treinar o time.

Engenharia além do código.

Referências

• Anthropic — Building Effective Agents (19/12/2024).
• Google — DORA 2025: State of AI-assisted Software Development (2025).
• Martin Fowler / Thoughtworks — Legacy Modernization Meets GenAI (24/09/2024).
• Martin Fowler — Agentic Engineering (21/05/2026).
• IAPro Community — Orquestrador Maestro.
• IAPro Community — Nexus.