A pergunta mudou de “a IA escreve código mais rápido?” para “que parte do meu ciclo de entrega eu confio a um agente?”.

O copiloto já virou commodity

Nove em cada dez profissionais de software já usam alguma ferramenta de IA no trabalho diário (DORA, 2025). O copiloto no editor deixou de ser diferencial competitivo e virou linha de base. Se todo mundo tem, ele não decide mais nada sobre quem entrega melhor.

A conversa relevante para a liderança de engenharia não é mais qual copiloto adotar. É outra: quando a IA para de sugerir e começa a executar etapas inteiras do ciclo, quanto do seu processo de entrega você está disposto a delegar, e sob quais garantias.

Antes de responder isso, vale separar três coisas que costumam ser tratadas como sinônimo.

Copiloto, agente e multiagente não são a mesma coisa

O copiloto sugere enquanto você digita. Quem conduz o trabalho ainda é a pessoa, e a IA acelera trechos.

O agente recebe uma tarefa e a executa de ponta a ponta. Ele examina o repositório, monta um plano, altera arquivos, roda ferramentas, testa e devolve um resultado para revisão.

O sistema multiagente distribui uma tarefa complexa entre vários agentes com papéis distintos, que se coordenam para entregar algo que um agente sozinho não daria conta. Esse é o território que exploramos no artigo Multiagentes de IA, no recorte de negócio. Aqui o foco é o recorte de engenharia.

A diferença entre o segundo e o primeiro é o que muda tudo. Sugerir não carrega responsabilidade. Executar, sim.

Do sugerir ao agir: o ciclo plan-act-evaluate

Quando o agente executa, ele opera num laço fechado que a Microsoft descreve como plan, act, evaluate: planeja a ação, age no ambiente e avalia o resultado antes de seguir (Microsoft Azure, 2025). Isso o separa da automação tradicional, em que um script roda exatamente o que foi definido. O agente decide o caminho dentro dos limites que recebe.

Um exemplo concreto já em produção. O coding agent do GitHub recebe uma issue, trabalha dentro de um ambiente isolado, roda verificações de segurança e abre um pull request para revisão humana, passando pelo mesmo fluxo de qualquer código escrito por pessoa (GitHub, 2025). Cerca de 90% das empresas da Fortune 100 já usam Copilot de alguma forma (GitHub, 2025).

O mercado projeta que 33% das aplicações corporativas terão IA agentic embarcada até 2028, contra menos de 1% em 2024 (Gartner, 2025). A questão não é se agentes vão entrar no ciclo de desenvolvimento. É onde deixá-los entrar primeiro.

Onde o agente entra no ciclo: um mapa por etapa

Delegar “o desenvolvimento” a um agente é uma decisão vaga demais para ser boa. O ciclo tem etapas com maturidade, risco e reversibilidade muito diferentes. Um agente que erra na geração de testes custa barato de corrigir. Um agente que erra numa decisão de arquitetura contamina meses de trabalho.

O critério útil não é “posso automatizar?”. É “qual o custo de um erro aqui, e quão fácil é revertê-lo?”. Quanto mais barato e reversível o erro, mais autonomia o agente pode ter.

Um mapa rápido por etapa, do valor ao risco e ao nível de autonomia recomendável:

•  Discovery e requisitos. Valor: levantar contexto, resumir tickets, esboçar hipóteses. Risco: assumir requisito implícito como certo. Autonomia: assistido.

•  Arquitetura. Valor: propor alternativas e mapear impactos. Risco: decisão de design escondida no código gerado. Autonomia: humano decide.

•  Implementação. Valor: escrever features, corrigir bugs, refatorar. Risco: volume grande de código plausível, porém frágil. Autonomia: assistido a alto.

•  QA e testes. Valor: gerar testes e ampliar cobertura. Risco: testes que validam o comportamento errado. Autonomia: alto, com revisão.

•  Segurança. Valor: rodar scans e sinalizar exposições. Risco: introduzir a própria vulnerabilidade. Autonomia: humano decide.

•  Deploy. Valor: preparar pipeline e montar release. Risco: ação irreversível em produção. Autonomia: assistido.

•  Observabilidade e manutenção. Valor: detectar anomalia e análise de causa raiz. Risco: loop de correção sem supervisão. Autonomia: assistido.

O mapa não é uma verdade fixa. É um ponto de partida para a conversa que precede qualquer liberação de agente: nesta etapa, o erro é barato e reversível, ou caro e permanente?

O amplificador: velocidade sem sistema vira risco

O dado mais honesto sobre IA no desenvolvimento vem da própria DORA. A IA funciona como amplificador: onde há prática sólida e cultura saudável, ela fortalece; onde há fragilidade, ela amplia a instabilidade (DORA, 2025). Distribuir agentes numa engenharia frágil não corrige o gargalo. Acelera o problema.

Os números de segurança mostram o tamanho disso. Em junho de 2025, código gerado por IA já introduzia mais de 10 mil novos achados de segurança por mês nos repositórios analisados pela Apiiro, um crescimento de 10 vezes em relação a dezembro de 2024 (Apiiro, 2025). Nas empresas da Fortune 50, o estudo apontou 322% mais caminhos de escalação de privilégio e 153% mais falhas de design (Apiiro, 2025).

A leitura para o CTO é direta. Mais código não é mais entrega. A DORA reforça que o maior retorno da IA não vem da ferramenta, e sim do sistema organizacional em volta dela (DORA, 2025). O agente amplia a capacidade de produzir. Cabe à engenharia ampliar, na mesma medida, a capacidade de validar e conter.

O agente como novo contribuidor, e a pergunta que ninguém quer responder

Se o agente abre um pull request, ele age como um contribuidor. E contribuidor tem identidade, permissões e rastro. Tratar o agente como uma extensão anônima do desenvolvedor é abrir mão justamente do controle que o volume de código exige.

Na prática, isso significa três coisas. Identidade própria, para saber qual agente agiu. Permissões mínimas, para que ele acesse só o necessário à tarefa. Rastreabilidade, para reconstruir qual contexto ele recebeu, quais ferramentas usou e o que alterou. É o mesmo cuidado que se aplica a um prestador externo com acesso ao repositório.

Daí vem a pergunta de accountability que a liderança precisa responder antes de escalar: quando um pull request criado por agente entra em produção e quebra, quem responde pelo resultado? A resposta não pode ser “a IA”. Ela recai sobre quem revisou, quem aprovou e quem definiu os limites de atuação do agente. Governança de código gerado por IA começa por deixar isso explícito, no mesmo espírito de aplicar guardrails na prática antes de liberar autonomia (https://conteudo.maitha.com.br/guardrails-na-pratica/).

Como preparar a engenharia antes de soltar o agente

Gartner projeta que mais de 40% dos projetos de IA agentic serão cancelados até o fim de 2027, por custo, valor incerto ou controle de risco insuficiente (Gartner, 2025). O que separa quem captura valor de quem entra nessa estatística não é a escolha da ferramenta. É a preparação do ambiente que recebe o agente.

Três movimentos concretos para começar com critério:

•  Comece pelas etapas de erro barato. Geração de testes e correção de bugs pequenos dão retorno rápido e falham de forma reversível. Arquitetura e deploy ficam para depois, com o humano no comando.

•  Trate o agente como contribuidor desde o primeiro dia. Identidade, permissão mínima e rastro não são refinamento futuro. São pré-requisito para escalar sem perder controle.

•  Meça o sistema, não a velocidade. Se a única métrica for linhas ou PRs por dia, a IA vai otimizar exatamente o que não importa. Estabilidade, retrabalho e tempo de revisão contam a história real.

O movimento do pair programming para o agent supervision não elimina o papel da engenharia. Ele desloca esse papel do “escrever” para o “especificar, supervisionar e validar”. A liderança que trata isso como decisão de arquitetura, e não como escolha de ferramenta no dia a dia do time, é a que consegue transformar a organização de engenharia em vez de apenas acelerá-la.

Esse é o corredor que ajudamos a desenhar: onde delegar, com que garantias e sob qual governança. Se a sua engenharia está no ponto de decidir isso, vale mapear juntos por onde o agente entra primeiro, e o que precisa estar de pé antes.