Como diagnosticar onde aplicar IA em Produto e Tech
Saindo do piloto automático da automação e indo para a engenharia de impacto com IA
Muita empresa começou a usar IA acelerando o que já existia. Gerando código mais rápido, automatizando etapas pontuais, resolvendo o que parecia mais fácil. Mas em times de produto, nem sempre o que dá pra acelerar é o que realmente precisa ser resolvido. Já vi várias vezes a IA só ampliar o acúmulo porque o gargalo estava em outro lugar.
Esse texto é um compilado do que tem funcionado por aqui pra sair desse modo automático. Falo sobre como a gente tem usado alguns frameworks para entender o fluxo como um todo e aplicar IA onde realmente muda o ritmo da entrega.
A mudança de foco: do código para a intenção
Não é só uma mudança de tecnologia. É uma mudança na forma como a gente constrói produto. Com IA, o foco sai da escrita do código em si e vai pra clareza da intenção. A linguagem natural começa a ocupar um espaço que antes era só do código.
Isso muda o papel de Produto, Design e Engenharia. A responsabilidade passa a ser definir bem o que precisa ser entregue, por que aquilo importa e como saber se deu certo.
Um paper recente sobre Structured Agentic Software Engineering (SASE) ajuda a dar nome pra esse momento. Os autores dizem que a engenharia de software está passando por um salto. Saindo do uso da IA só como apoio, o que eles chamam de SE 2.0, e entrando numa nova fase, com times formados por humanos e agentes trabalhando juntos, o SE 3.0.
Ferramentas como Codex, Claude Code e Gemini já conseguem criar, testar e até submeter código sozinhas. Mas ainda existe uma lacuna grande entre velocidade e confiabilidade. O código sai rápido, mas muitas vezes não está pronto pra ser integrado. Dá retrabalho, traz regressões e não é fácil de auditar.
O SASE surge tentando resolver esse problema. Como organizar a colaboração entre humanos e agentes de um jeito que o resultado final seja confiável, auditável e que escale bem.
A tese central propõe uma reconfiguração total da engenharia de software baseada em duas modalidades complementares:
SE for Humans (SE4H) → os humanos deixam de ser executores de código e passam a ser “mentores de agentes”, responsáveis por intenção, supervisão e decisão.
SE for Agents (SE4A) → os agentes ganham ambientes estruturados para executar tarefas com autonomia previsível, chamando humanos apenas quando enfrentam ambiguidade ou trade-offs críticos.
O SASE introduz dois ambientes de trabalho distintos:
ACE – Agent Command Environment: o “centro de comando” do humano. Permite criar briefings, revisar entregas, acompanhar custo computacional e mentorizar múltiplos agentes simultaneamente. Ali o humano atua como estrategista e curador.
AEE – Agent Execution Environment: o “chão de fábrica” dos agentes. Fornece um ambiente otimizado para execução: alta paralelização, baixo overhead, ferramentas nativas para busca semântica, depuração e análise de logs.
A interação entre ACE e AEE ocorre via artefatos estruturados, não mais por conversas soltas de chat. O ciclo se formaliza em uma “conversa versionada” com rastreabilidade total.
Se você quiser se aprofundar nessa visão, o paper completo oferece detalhes arquiteturais e exemplos de implementação que valem a leitura.
Spec First: quando a especificação vira a fundação da construção
Se o primeiro ponto é sobre mudança de foco de “código” para “intenção”, aqui falamos sobre como operar essa mudança com disciplina. A abordagem central: Spec First.
Em essência: enquanto a IA fornece o motor para executar tarefas operacionais, a Spec First fornece o mapa que orienta e controla essa execução digital. Permite que a construção de software seja mais modular, escalável, previsível.
A grande mudança: em vez de o código ser o centro (o que tornava a especificação um documento temporário), a especificação se torna a fundação viva do projeto, e o código se torna apenas um output gerado a partir dessa intenção clara.
A própria OpenAI já constrói seus produtos adotando essa mudança. A empresa mantém um documento conhecido como Model Spec, público e versionado, que é atualizado a cada novo modelo e detalha:
O comportamento dos modelos
Quais são as intenções, limites e valores
A forma como você interage com eles
Ao invés de detalhar exaustivamente o código interno dos modelos, a OpenAI foca em como ocorre a interação entre o humano e a linguagem natural. O código e o comportamento dos sistemas são vistos como expressões dessa especificação viva.
Em um texto anterior, comentamos como a especificação pode reduzir a fragmentação de informação e dar mais previsibilidade ao trabalho entre humanos e agentes. A partir dessa hipótese, fizemos o Product Spec, um documento único que reúne o contexto de produto, as regras de negócio e os padrões técnicos em um formato que pode ser consumido tanto por pessoas quanto por IA.
O objetivo não era criar mais uma documentação, mas reduzir dependências de conhecimento disperso e permitir que humanos e agentes trabalhassem a partir das mesmas referências.
Durante o teste, a IA fez a síntese inicial do material e o time realizou a curadoria e validação. O ganho não foi de automação, mas de coerência: menos retrabalho, menos ruído e mais clareza sobre o que cada parte do sistema deveria fazer. Também disponibilizamos o template de Product Spec como referência para quem quiser reproduzir essa abordagem.
Por onde começar para escalar o impacto da IA?
O verdadeiro impacto da IA em Produto e Tecnologia não vem da simples introdução de ferramentas. Ele surge a partir da revisão do funcionamento sistêmico da operação como um todo.
Antes de aplicar IA, entenda o todo. E como fazer isso?
Organizações funcionam como sistemas. E, em sistemas, o desempenho geral depende das conexões entre as partes, não do desempenho isolado de cada uma.
A função da IA deve ser analisada dentro do contexto do fluxo completo. O foco precisa estar em identificar e resolver a principal restrição que limita a entrega de valor.
Por aqui, usamos duas metodologias que se complementam para ajudar nesse ponto:
Theory of Constraints
A Theory of Constraints (Teoria das Restrições), criada por Eliyahu Goldratt, parte de uma ideia simples: todo sistema tem um gargalo que limita o desempenho do conjunto. Melhorar qualquer parte que não seja esse gargalo não acelera o fluxo; só gera acúmulo e desperdício.
No contexto de Produto e Engenharia, isso significa que acelerar a codificação com IA pode não mudar nada se o verdadeiro gargalo estiver em outro ponto: definição de requisitos, revisão de código, testes, deploy ou até na tomada de decisão do time.
A TOC propõe um processo contínuo em cinco etapas:
Identificar a restrição do sistema
Antes de implementar IA, mapeie o fluxo completo: da concepção da feature até a entrega em produção. Onde o trabalho para? Onde surgem os maiores atrasos?
O foco não é a velocidade de cada etapa isolada, e sim o lead time total, ou seja, quanto tempo uma ideia leva para virar valor real em produção.Explorar a restrição
Depois de identificar o gargalo, o primeiro passo não é aumentar capacidade, e sim eliminar desperdícios.
Se o problema está no code review, reduza interrupções, defina janelas dedicadas, diminua o tamanho dos PRs e automatize verificações básicas.
A IA pode entrar aqui de forma cirúrgica, não para acelerar tudo, mas para proteger e potencializar o ponto crítico.Subordinar o restante do sistema ao gargalo
Ajuste o fluxo ao ritmo da restrição.
Se o code review processa dez PRs por semana, não adianta gerar vinte.
O excesso cria fila, trocas de contexto e retrabalho.
Usar IA para acelerar a escrita de código nesse cenário só piora a situação, ampliando o acúmulo.Elevar a restrição
Só depois de otimizar o uso do gargalo faz sentido aumentar sua capacidade.
É nesse ponto que a IA pode destravar o fluxo: agents realizando code review automatizado, gerando especificações estruturadas ou criando ambientes de teste paralelos.
Se as etapas anteriores não forem seguidas, o gargalo apenas muda de lugar e o investimento se perde.Voltar ao início
Cada vez que um gargalo é resolvido, outro aparece.
A TOC é um processo de melhoria contínua, não um projeto com começo e fim.
O foco precisa estar no throughput do sistema como um todo: quantas features de valor chegam em produção, e não em quão rápido cada parte isolada parece trabalhar.
VSM (Value Stream Mapping)
O Value Stream Mapping é uma técnica usada para visualizar e analisar o fluxo de trabalho completo de um processo, desde o início (ideia ou demanda) até a entrega final de valor ao cliente.
Origem e propósito
O VSM nasceu no Lean Manufacturing, dentro do Sistema Toyota de Produção, como uma ferramenta para enxergar desperdícios e otimizar processos. A ideia central é tornar visível o que acontece “entre as etapas”, como filas, esperas, retrabalho e aprovações, e não apenas o trabalho produtivo em si.
Em times de Produto e Engenharia, o VSM permite mapear o caminho de uma feature desde a concepção até o deploy em produção, mostrando:
Quanto tempo o item permanece em cada etapa (Lead Time)
Quanto tempo ele é realmente trabalhado (Process Time)
Onde estão os gargalos, handoffs e esperas que reduzem a velocidade de entrega
Isso ajuda a identificar restrições do sistema, priorizar melhorias e alinhar times de produto e engenharia em torno do fluxo real de valor, e não apenas da eficiência local de cada etapa.
Resultado esperado
Um mapa VSM bem feito revela:
Onde o trabalho acumula sem necessidade
Quais etapas podem ser automatizadas ou simplificadas
Como reduzir o tempo de ciclo e aumentar a previsibilidade da entrega
Lean Enterprise (O’Reilly) por Jez Humble, Joanne Molesky e Barry O’Reilly, 2014
Em resumo, o Value Stream Mapping transforma o “sentimento” de onde estão os problemas em dados visuais e objetivos, servindo como base para a melhoria contínua e para o diagnóstico de onde a IA (ou qualquer outra otimização) deve ser aplicada primeiro.
A combinação de VSM (visão do fluxo) e TOC (foco na restrição) permite que a organização tenha uma visão global de onde deve atacar para maximizar o desempenho.
IA acelera o que você mandar ela acelerar. O problema é que a maioria acelera a parte errada do sistema.
Antes de implementar qualquer coisa, responda três perguntas com dados reais: quanto tempo uma feature leva do início ao fim? Quanto desse tempo é trabalho efetivo e quanto é espera? Onde está o maior acúmulo de trabalho parado?
Use VSM para mapear isso. Use TOC para focar no gargalo. Só depois avalie onde IA faz sentido. Se o gargalo é code review, IA em coding piora a situação. Se o gargalo é especificação, IA em testes é irrelevante. Se o gargalo é decisão de negócio, IA em engenharia é secundária.
Comece pequeno. Um squad, um tipo de trabalho, quatro semanas. Meça impacto no lead time total, não só na etapa que você tocou. Se funcionou, expanda. Se não funcionou, pivote. Mas não escale sem validar.