Seu agente de IA lê o código. Ele não conhece o seu produto.

Um agente de IA abre o repositório do seu produto em segundos. Lê cada arquivo, entende cada dependência, mapeia cada função. Em minutos, sabe mais sobre a sua base de código do que qualquer engenheiro recém-contratado saberia em três meses.

E ainda assim entrega uma tela genérica.

O botão está no lugar errado. O tom da mensagem de erro não soa como a sua marca. A hierarquia visual ignora a decisão que o time de produto tomou há oito meses, depois de três rodadas de pesquisa com clientes. O componente é tecnicamente correto e institucionalmente estranho.

A equipe do TLDR DESIGN chamou isso de lacuna de contexto de produto, e o diagnóstico é preciso: agentes leem sintaxe; produtos são feitos de julgamento. A maior parte do julgamento que define um produto nunca foi para o código.

O código é a menor parte do produto

Pense no que realmente distingue um produto maduro de uma implementação qualquer. Voz. Princípios de design. Decisões arquitetônicas que parecem arbitrárias até você conhecer os três experimentos que antecederam. Hierarquia de mensagens. Trade-offs que foram discutidos, escolhidos e abandonados. A razão pela qual o onboarding tem exatamente quatro passos e não cinco.

Nada disso está no repositório.

Está em decks de 2023 que ninguém abre. Em threads do Slack arquivadas. Em anotações do Figma que só a designer sênior sabe interpretar. Em calls de pesquisa gravadas e nunca transcritas. Em uma conversa de corredor que aconteceu antes da pandemia. Na cabeça da pessoa que acabou de sair para outra empresa.

Esse é o patrimônio intelectual do produto. E ele é invisível para o agente.

Não é falha de modelo; é falha de contexto

Quando o agente produz um resultado genérico, o reflexo é atualizar o prompt. Melhorar o system message. Dar mais exemplos no few-shot. Essa é a resposta errada para um problema que não é de prompt.

Prompts resolvem contexto de curto prazo. O que está faltando é contexto institucional: o julgamento versionado, autorizado e consumível que define o que o produto é e o que ele recusa ser. Isso não vive em um prompt. Vive em um sistema de registro que alguém precisa manter.

Como exploramos em De Conhecimento Tribal a Inteligência Governada, a Meta resolveu o mesmo problema no debugging codificando o conhecimento tribal em analisadores testáveis e versionados. A analogia se aplica aqui quase termo a termo. Troque “debugging” por “produto” e o diagnóstico permanece: conhecimento que importa, preso em formatos que máquinas não conseguem ler, eventualmente evaporando com a rotatividade.

Agentes de IA só expõem esse problema mais rápido. Eles trabalham na velocidade do código, mas dependem da velocidade do contexto. E o contexto está congelado em formatos humanos.

A pergunta que mede a lacuna

Aqui está a pergunta que poucos times de produto fazem, e que todos deveriam estar fazendo:

Quanto do julgamento do seu produto existe em forma consumível por um agente?

Não é retórica. É uma métrica.

Pegue as dez últimas decisões de produto que a sua equipe tomou. Para cada uma, pergunte:

A decisão está escrita em algum lugar que um agente pode ler?
O racional está registrado, ou só o resultado?
As alternativas rejeitadas estão documentadas?
A voz da marca tem um arquivo de referência, ou vive na cabeça do copywriter sênior?
O sistema de design tem princípios escritos, ou só componentes renderizados?
As decisões de pesquisa com clientes estão em um formato que não seja um PDF de 47 páginas?

Se a maioria das respostas for “não”, você não tem um problema de IA. Você tem um problema de governança que a IA acabou de tornar visível.

Contexto autorizado vs. contexto recuperado

Vale separar duas coisas que tendem a ser confundidas.

Contexto recuperado é o que o agente puxa de um RAG, de uma busca semântica no Confluence, do histórico de conversas. É dinâmico, oportunístico, e tão bom quanto a qualidade da fonte. Funciona para perguntas factuais e falha para decisões.

Contexto autorizado é diferente. É curado, versionado, revisado por alguém com autoridade para falar pelo produto. Tem dono, changelog e critério de aceite. Não é o que “parece ser verdade sobre o produto”. É o que o produto assume como verdade até que alguém autorizado mude.

A maioria das empresas está tentando resolver a lacuna de produto jogando mais contexto recuperado no agente. Isso melhora as respostas triviais e piora as importantes. Porque para decisões que moldam o produto, recuperar não basta. Alguém precisa ter escrito.

Isso é o que separa uma equipe que vai escalar agentes com segurança de uma equipe que vai gastar os próximos três anos corrigindo output genérico.

Os dois riscos da codificação excessiva

A tentação inversa é codificar tudo. Transformar cada intuição em regra, cada escolha em documento, cada ritual em arquivo. Também está errado.

Dois riscos:

Primeiro: contexto de produto apodrece. Voz evolui, clientes mudam, princípios que fizeram sentido em 2024 precisam ser revisados em 2026. Um snapshot imutável se torna dívida silenciosa. Governança de contexto precisa incluir o mecanismo de atualização, não só o registro inicial.

Segundo: nem tudo deveria ser codificado. Valores, trade-offs éticos, decisões que envolvem dignidade do cliente: essas permanecem territórios humanos. Transformar julgamento moral em rulebook é o caminho mais curto para um produto que segue a regra e perde a pessoa.

A pergunta correta não é “como codifico tudo”. É “qual é o conjunto mínimo viável de contexto institucional que um agente precisa para não entregar output genérico?”. O resto contínua humano.

Onde isso cai no seu organograma

Essa é a parte incômoda.

Contexto de produto não tem dono claro. Design acha que é de produto. Produto acha que é de design. Engenharia assume que alguém mais está cuidando. Pesquisa documenta, mas ninguém consome. Marketing mantém a voz, mas só para canais externos.

Como argumentamos em Empresa como Código, a resposta não é inventar um novo time. É tratar o sistema de registro do julgamento como infraestrutura compartilhada, com os mesmos critérios que você aplicaria a qualquer repositório crítico: versionamento, revisão, changelog, responsabilidade designada.

A empresa que resolve isso primeiro não ganha porque tem um agente melhor. Ganha porque tem um produto cujo julgamento escala no ritmo que a IA agora exige.

O que fazer na segunda-feira

Três perguntas práticas para a sua equipe está semana:

Qual é o sistema de registro do julgamento do nosso produto? Se a resposta for “a cabeça do fulano”, você já sabe o trabalho.
Qual é o formato mínimo que um agente consegue ler? Markdown versionado tende a funcionar melhor que qualquer ferramenta sofisticada que ninguém atualiza.
Quem é o dono desse sistema? Governança sem dono é teatro.

A IA não criou esse problema. Apenas removeu a opção de ignorá-lo.

Fontes

TLDR DESIGN. “Your AI Agent Can Read Your Codebase. It Doesn’t Know Your Product.” Abril 2026.

Ajudamos equipes a fechar a lacuna entre código e julgamento de produto: contato@victorino.com.br | www.victorino.com.br