Nos últimos meses, muito se falou sobre IA nos times de produto e engenharia. Na prática, porém, o avanço dessas ferramentas expõe um problema mais estrutural do que técnico: a falta de clareza sobre onde a IA realmente gera valor.
O movimento de “colocar IA em tudo” fez muita gente pular direto para a automação antes de entender o próprio fluxo, resultando em entusiasmo com pouco retorno.
O que eu quero trazer aqui são aprendizados práticos do uso de agentes em diferentes pontos do desenvolvimento, e o que isso revelou sobre gargalos, maturidade e governança.
Diagnóstico antes da automação
A IA costuma ser vista como uma forma de acelerar a entrega, mas se o processo for ruim, ela só amplifica ineficiências, ruído e retrabalho.
Uma das maneiras mais eficientes de fazer esse diagnóstico é usando o Value Stream Mapping (VSM). Ele permite enxergar o fluxo completo de valor, mostrando não apenas o que cada pessoa faz, mas como o trabalho realmente se move pelo sistema.
Quando você mapeia o processo dessa forma, começam a aparecer pontos que normalmente ficam escondidos, como:
• onde estão os gargalos
• onde o trabalho se acumula sem necessidade
• onde existem dependências mal resolvidas
• quais etapas poderiam ser simplificadas ou automatizadas sem afetar a qualidade
O VSM também revela um tipo de problema que costuma passar despercebido: muitas falhas não vêm da execução em si, mas de decisões que não estão explícitas. Em quase todo mapa existe um trecho em que o avanço depende de interpretação, alinhamento de intenção ou definição de critérios que variam entre as pessoas.
Esses pontos não aparecem como etapas formais no fluxo, mas são exatamente onde o processo perde previsibilidade e onde pequenas variações individuais geram efeitos grandes.
É nesse contexto que o Human in the Loop (HITL) passa a fazer sentido de forma prática. Ele é frequentemente entendido apenas como uma camada de revisão, alguém validando o que a IA produziu, e é justamente aí que surge o equívoco.
Quando você analisa o fluxo com mais cuidado, percebe que a necessidade real não é revisar o resultado da automação depois que ele acontece, e sim evitar que a automação trabalhe em cima de decisões implícitas ou pouco claras.
O papel humano aqui é estabilizar essas zonas de interpretação, deixando explícitos os critérios, limites e escolhas que orientam o trabalho. Isso evita que a IA precise adivinhar intenções ou completar lacunas com suposições próprias.
Onde está a vantagem competitiva
A verdadeira vantagem competitiva em IA está em como a organização estrutura seu processo.
Em todo experimento que fiz, ficou claro que o impacto da IA depende desses quatro eixos:
É essa base que define se a IA vai realmente gerar valor ou só adicionar complexidade.
Ferramentas de diagnóstico
Pra entender se o processo está realmente preparado pra receber IA, é preciso traduzir esse diagnóstico em algo concreto. Algumas ferramentas ajudam a avaliar o fluxo e podem servir como ponto de partida:
1. Value Stream Mapping (VSM)
O VSM é uma técnica que ajuda a visualizar o caminho completo de uma entrega, da ideia até o valor em produção. Ele mostra:
quanto tempo o item leva pra atravessar o fluxo (lead time)
quanto desse tempo é de execução real (process time)
onde estão os gargalos e esperas que reduzem a velocidade
Com isso, o time deixa de agir por percepção e passa a decidir com base em dados.
A principal função do VSM é revelar onde vale a pena intervir, e é aqui que ele se conecta com IA. A IA acelera o que você mandar ela acelerar, e assim, o risco acaba sendo acelerar a parte errada do sistema.
Pra evitar isso, o VSM pode ser usado de forma prática, em cinco passos:
Mapeie o fluxo completo de entrega, do início ao fim
Identifique onde acontecem os handoffs e as traduções entre áreas
Meça o tempo ativo e o tempo de espera em cada etapa
Marque os pontos de retrabalho ou desperdício
Localize o gargalo que mais impacta o lead time total
Depois de mapear, use essas informações pra identificar:
onde o trabalho acumula sem necessidade
quais etapas podem ser simplificadas ou automatizadas
o que realmente limita a entrega de valor
2. Matriz de Diagnóstico
A Matriz ajuda a entender onde vale a pena começar. Ela organiza as iniciativas em dois eixos pra mostrar o que pode ser feito agora e o que precisa de mais estrutura antes de avançar.
O objetivo é simples: priorizar o que faz diferença e evitar esforço em iniciativas que trazem pouco retorno.
Na prática, use a matriz em três passos:
Defina os critérios que fazem sentido pro seu contexto (complexidade técnica, velocidade, impacto, custo etc.);
Posicione cada iniciativa cruzando impacto e viabilidade;
Use o resultado pra guiar a ordem e a estratégia de implementação.
Essa leitura mostra onde estão os quick wins e quais frentes exigem maturidade maior antes de aplicar IA.
3. Checklist de Prontidão de IA
Antes de avançar em qualquer iniciativa de IA dentro de um fluxo de SDD, é importante entender se a operação tem os fundamentos necessários para que esses esforços realmente funcionem.
Para ajudar nisso, preparei uma Checklist de Prontidão de IA voltado a Spec Driven Development. A ideia é ser um instrumento rápido você a construir um racional claro sobre onde o processo está sólido e onde ainda existem riscos estruturais
O material está disponível aqui
Casos práticos e aprendizados
Depois de aplicar essas ferramentas em diferentes contextos, alguns padrões começaram a aparecer. Cada case deixou claro na prática, onde houve progresso, onde houve atrito e o que aprendemos com isso.
Case 1: Um sistema bom não salva processo ruim
Em um dos testes, criamos um sistema de agentes para cobrir todo o fluxo, da ideação ao deploy. A intenção era reduzir o esforço operacional, mas as especificações estavam frágeis e o resultado foi o oposto: mais ruído, retrabalho e documentação desnecessária. A lição aqui foi clara: se o upstream não tem estrutura, a IA só replica as falhas do processo.
Case 2: Foco em criar valor através de IA
Em outro experimento, optamos por focar na especificação e deixar o time de produto responsável por estruturar o upstream. Essa mudança deixou o processo mais consciente e a entrega mais previsível. O ganho não veio apenas em tempo, mas em qualidade e aprendizado sobre o próprio fluxo. A IA funcionou melhor porque havia clareza do que ela precisava resolver.
Case 3: Nem sempre IA é a resposta
Ao mapear o fluxo de ponta a ponta, percebemos que o gargalo não era técnico, e sim estrutural: ausência de padrões, arquitetura e governança. Em vez de insistir em automação, corrigimos as bases, e isso gerou ganhos mais consistentes, inclusive para projetos futuros de IA. Às vezes, a melhor decisão é pausar o entusiasmo e fortalecer o processo.
No fim, tudo volta ao processo
No fim, o ponto é simples: antes de discutir automação, vale revisar o fluxo atual com calma. Mapear, medir, achar onde o trabalho de fato para.
A partir disso, separar o que é problema de processo do que pode ser acelerado com IA. Se tiver clareza desses dois lados, dá para decidir onde a automação faz sentido e onde não faz.
O próximo passo é repetir esse diagnóstico sempre que o fluxo mudar.