O alinhamento entre produto e engenharia começa onde a decisão fica registrada
A confiança na IA não começa no modelo, começa no processo.
Décima primeira parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz. É o caso aplicado do artigo anterior, sobre calibrar a intensidade ao risco real.
Quantas vezes você já viu uma reunião de alinhamento entre produto e engenharia terminar em consenso na sala, e, três sprints depois, cada lado jurar que “não foi isso que ficou combinado”? Quantas vezes esse desalinhamento não nasceu de má vontade de ninguém, mas do simples fato de que ninguém mais sabia, ao certo, onde estava escrita a versão que valia?
Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.
Esta série já descreveu, peça por peça, guardrails permanentes, prova em vez de crença, ADRs em lote e uma forma de calibrar quanto rigor cada projeto merece. O que ainda não descrevi é que essas mesmas peças resolvem um problema bem mais antigo do que IA: o de visão de produto e visão técnica divergindo silenciosamente, e o de documentação que jura dizer a verdade mas já não corresponde a nada que o código realmente faz.
Produto e engenharia não divergem por falta de reunião: divergem por falta de um lugar comum para a verdade
Toda reunião de alinhamento produz a sensação de consenso enquanto as pessoas ainda estão na sala, ouvindo as mesmas palavras, com o mesmo contexto fresco na cabeça. O problema nunca foi o momento da reunião. É o depois.
Cada lado sai com sua própria versão mental do que foi combinado, e essa versão começa a divergir da do outro lado no instante em que os dois voltam para seus respectivos contextos (produto trabalhando no roadmap, engenharia no código), sem nenhum artefato comum para consultar quando a memória de cada um começar a divergir.
Um ADR não resolve isso por ser um documento técnico. Resolve por ser o único artefato que sobrevive à reunião carregando o trade-off inteiro: não só a decisão, mas o porquê, as alternativas descartadas e, sobretudo, a restrição que motivou a escolha, seja ela técnica ou de produto.
Um exemplo real, de um dos oito projetos que venho analisando ao longo desta série: uma auditoria encontrou uma condição no algoritmo central do sistema mais ampla do que a documentação (a versão voltada para quem usa o software) descrevia.
Corrigir a documentação para refletir o comportamento real era trivial. Mudar o algoritmo para que ele se comportasse como a documentação prometia seria uma mudança de comportamento com um custo real por trás: a ferramenta de simulação usada para validar o algoritmo original não modelava a distinção necessária para validar essa mudança com segurança. Implementá-la de verdade significaria estender a ferramenta primeiro, não apenas ajustar uma linha de código.
Sem um lugar para registrar isso, essa decisão vira exatamente o tipo de desalinhamento que abre este texto: quem só olha a documentação corrigida assume que o comportamento antigo foi resolvido; quem só olha o código sabe que não foi. Duas verdades parciais, cada uma convicta de estar certa.
O ADR existe precisamente para eliminar essa divergência, registrando, no mesmo lugar, que o comportamento correto foi documentado agora, e que a mudança de algoritmo foi deliberadamente adiada como uma questão de design em aberto, com o custo que a justifica. Não é a mesma coisa que um defeito escondido debaixo do tapete. A diferença entre as duas coisas é inteiramente uma questão de onde, e com que honestidade, essa decisão fica registrada.
Nunca escrever o que ainda não foi provado
O artigo sobre ADRs em lote já tratou de como uma revisão de documentação serve para encontrar discrepâncias entre o que o código faz e o que o texto afirma. Existe uma disciplina complementar, mais estreita: nunca deixar essa discrepância nascer em primeiro lugar, na única situação em que ela é totalmente evitável: quando a própria pessoa (ou agente) que escreve o texto tem controle sobre a ordem em que escreve e mede.
Numa auditoria com múltiplas frentes, isso apareceu de um jeito concreto: um número de benchmark, escrito na documentação logo após um commit, se revelou desatualizado, medido antes do código final da rodada estar de fato pronto. Aconteceu duas vezes na mesma auditoria antes de virar regra. A resposta não foi confiar menos nos números, foi adotar uma disciplina explícita de sequenciamento: todo o código primeiro, rebuild limpo, uma única medição real, e só então a documentação é escrita.
Essa é exatamente a mesma régua do benchmark como teste de hipótese, aplicada um passo antes: se a conclusão só pode ser válida depois de uma medição limpa, escrever a conclusão antes de medir, mesmo que a intenção seja corrigir depois, já é aceitar como verdade algo que ainda não foi provado.
O que muda quando o colaborador de longo prazo é um agente de IA é a urgência disso: um agente que lê um número desatualizado não sabe que ele é provisório, e trabalha a partir dele como se fosse fato corrente.
Benchmark não é métrica de performance: é teste de hipótese
Aqui está o ponto que mais me fez repensar como uso a palavra “benchmark”. Na maioria das equipes, benchmark significa uma coisa: quão rápido, quanto throughput, quanta memória. Uma métrica de performance, isolada, medida uma vez, citada como prova de que uma otimização funcionou.
Mas o mesmo protocolo vermelho-então-verde que descrevi para prova em vez de crença (declarar o que se espera provar antes de medir, medir de forma que o resultado possa genuinamente contradizer a expectativa, só então aceitar a conclusão) se aplica a qualquer decisão que faça uma alegação testável. Não só “esse código é mais rápido”. Também “essa mudança de arquitetura reduz incidentes”, “esse trade-off vale o custo de complexidade que adiciona”, “esse comportamento é raro o suficiente para não justificar a correção agora”.
A avaliação de custo mencionada acima (sobre estender a ferramenta de simulação antes de poder validar com segurança uma mudança no algoritmo central) não foi só uma estimativa técnica. Foi, na prática, um benchmark de uma hipótese: “essa mudança de comportamento é segura de implementar sem o investimento adicional?”
A resposta, avaliada com a ferramenta real disponível, foi não. Essa resposta é o que sustenta a decisão de adiar a mudança como questão de design, em vez de forçá-la sem a validação adequada. Sem tratar essa pergunta como algo que precisa ser genuinamente testável antes de aceitar a resposta, a decisão teria sido só uma opinião com aparência de rigor.
Isso vale igualmente para hipóteses do lado de produto. Uma alegação como “essa mudança reduz o atrito de onboarding” ou “esse fluxo reduz abandono” merece o mesmo tratamento que um benchmark de performance: uma hipótese declarada antes de medir, um critério que definiria a hipótese como falsa, uma medição única e limpa, e só então uma conclusão.
A alternativa (aceitar a alegação porque soa plausível, ou porque a pessoa que a fez é sênior o suficiente para não ser questionada) é exatamente o tipo de “parece corrigido” que o protocolo vermelho-então-verde existe para eliminar do código. Não há razão para tolerá-lo nas decisões que o código serve.
Como as peças da metodologia se conectam nisso
Guardrails permanentes tornam isso o padrão, não uma exceção que alguém precisa lembrar de pedir: qualquer trade-off relevante, técnico ou de produto, é declarado com opções e custos explícitos antes de ser aceito, nunca decidido silenciosamente por quem está mais perto do teclado.
O protocolo vermelho-então-verde é a régua em si: a exigência de que uma alegação, seja sobre um bug ou sobre uma hipótese de produto, precise de uma prova que poderia genuinamente falhar, não de uma afirmação convincente.
E ADRs são, literalmente, o lugar onde tudo isso converge: o artefato que sobrevive à reunião, carrega o trade-off inteiro e continua dizendo a verdade muito depois de todo mundo ter esquecido os detalhes da conversa que o originou.
Nenhuma dessas peças resolve visão de produto contra visão técnica, ou documentação desatualizada, ou benchmark raso, isoladamente. Juntas, removem a pergunta que causa os três problemas ao mesmo tempo: onde, exatamente, mora a verdade sobre o que foi decidido, por quê, e com que evidência.
O que eu levaria disso para outro projeto
Nunca trate uma decisão produto-vs-técnica como resolvida só porque a reunião terminou em consenso. Resolvida é quando existe um documento que sobrevive à reunião e que os dois lados podem consultar depois, sem depender da memória de ninguém.
Trate toda alegação escrita como algo a ser falseado, não como verdade herdada. Um documento que ninguém tenta contradizer não é confiável, é só não verificado ainda.
Antes de rodar qualquer benchmark, escreva a hipótese que ele testa e o que provaria que ela é falsa. Sem isso, o benchmark não mede uma decisão, só confirma o que você já queria acreditar.
Uma decisão de “não fazer”, documentada com o custo real por trás dela, vale mais do que uma correção apressada sem essa clareza. A diferença entre dívida técnica deliberada e defeito escondido é inteiramente uma questão de como, e onde, essa decisão fica registrada.
Conclusão
Volto à pergunta que abriu este texto: quantas vezes uma reunião terminou em consenso e, poucas semanas depois, virou dois times contando histórias diferentes sobre o que tinha sido combinado?
Na maioria dessas vezes, o problema nunca foi a reunião. Foi não existir, depois dela, nenhum lugar comum onde a verdade continuasse valendo.
As mesmas peças que uso para governar um agente de IA (guardrails, prova em vez de crença, ADRs) não foram desenhadas para resolver visão de produto contra visão técnica, documentação que envelhece mal, ou benchmark raso demais para sustentar uma decisão. Mas resolvem os três, porque os três nascem do mesmo vazio: a ausência de um lugar onde a verdade sobre uma decisão é escrita, testada e mantida honesta ao longo do tempo, em vez de reconstruída de memória, por pessoas diferentes, toda vez que alguém precisa dela.
No próximo artigo desta série, o mesmo guardrail de avaliar um padrão antes de adotar aparece numa última forma, talvez a mais inesperada: como uma versão de segurança psicológica construída de propósito, porque não nasce sozinha entre uma pessoa e uma ferramenta. Esse artigo também explora o que significa um colaborador que discorda com dados e se compromete de verdade depois.
Tenham um excelente dia!
Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.
Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.
Nesta série
- Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
- Disciplina em rajada: por que o rigor não nasce junto com o código
- O código duplicado que a IA cria enquanto parece produtiva
- As três práticas que nunca esperam gatilho
- Quem autorizou essa atualização de dependência? Pode ter sido sua IA
- Os quatro eventos de risco e a auditoria multi-frente
- Seu agente de IA resolve a issue de verdade, ou só parece resolver?
- ADRs em lote, e a regra da visibilidade
- IA no time não reduz o bus factor do seu projeto — pode aumentar
- Calibrando a intensidade ao risco real
- O alinhamento entre produto e engenharia começa onde a decisão fica registrada (este artigo)
- Segurança psicológica também vale para o time formado por você e sua IA
- Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca
