Resolvemos uma discussão de design a três refusando discutir

Três engenheiros, três designs para a mesma camada de memória de agent, e três explicações de por que os outros dois estavam errados. Um queria um log plano que o agent relê a cada turno. Um queria um vector store que recupera por similaridade. Um queria uma pequena tabela estruturada na qual o agent escreve fatos à mão. Cada um conseguia defender sua escolha por vinte minutos sem se repetir. Nenhum deles conseguia prová-la.

Tínhamos uma reunião no calendário para resolver isso. Cancelamos a reunião.

Rode as três specs contra cenários idênticos e deixe os números dobrarem duas delas.

Este post é sobre o que aconteceu quando paramos de tratar uma discordância de design como um debate para vencer e começamos a tratá-la como uma medição que ainda não tínhamos feito, e por que esse único movimento mudou como tomamos toda decisão load-bearing agora.

A versão ingênua: discuta até alguém desistir

A forma padrão de um time resolver uma discussão de design é discutir. Você reserva uma sala, põe as três opções num whiteboard, e deixa o caso mais forte vencer.

Parece rigoroso. Não é.

O que de fato decide a sala raramente é o design. É quem é mais sênior, quem é mais fluente, quem tem mais paciência para uma reunião longa, e quem por acaso enquadrou a pergunta primeiro. O vector store soa sofisticado, então ganha o benefício da dúvida. O log plano soa primitivo, então tem que lutar ladeira acima, mesmo que, para esta workload, primitivo seja exatamente o certo. A pessoa que consegue desenhar o diagrama mais limpo vence, e um diagrama limpo é uma medida de desenho, não da coisa que o diagrama descreve.

E aqui está a falha sob a falha: mesmo quando a sala concorda, ninguém aprendeu nada. Você escolheu a opção que argumentou melhor. Você ainda não sabe como nenhuma delas se comporta sob carga, como elas degradam quando o contexto do agent enche, o que custam por conversa, ou qual silenciosamente derruba um fato que o usuário mencionou quarenta turnos atrás. Você trocou uma pergunta real, qual design de fato funciona aqui, por uma mais barata: quem fez o melhor caso numa sala. Essas não são a mesma pergunta, e confundi-las é como times shipam a opção mais articulada em vez da melhor.

As decisões de design mais caras são tomadas assim constantemente. Não porque engenheiros são preguiçosos, porque a alternativa parece lenta, e discutir parece progresso.

O movimento: pare de discutir, comece a medir

Então fizemos a coisa que parecia mais lenta e era mais rápida. Recusamos discutir.

Rode as três specs contra cenários idênticos e deixe os números dobrarem duas delas.

A ideia-chave é simples. Uma discordância de design quase nunca é uma discordância sobre valores, todos naquela sala queriam a mesma coisa: um agent que lembra os fatos certos, barato, sem cair. Era uma discordância sobre previsões. Cada engenheiro estava prevendo como seu design se comportaria numa workload que nenhum deles tinha rodado ainda. Uma previsão que você não consegue testar é só um palpite fortemente defendido, e três palpites fortemente defendidos não somam uma decisão. Somam uma reunião.

A correção não é achar um arguidor melhor. É transformar as previsões em algo que você consegue checar.

Então em vez de um time escolher um vencedor num whiteboard, os três designs foram construídos, pequenos, só o suficiente para rodar, e os três foram apontados para o exato mesmo conjunto de cenários. Mesmas conversas. Mesmos fatos para lembrar. Mesmas perguntas de recall, quarenta turnos depois. Mesma medição de custo, latência, e se o fato de fato voltou. A discussão não foi resolvida. Ela foi dissolvida, porque uma vez que os três designs rodaram o mesmo desafio, dois deles visivelmente caíram e não restou nada para discutir.

O whiteboard pergunta qual design soa melhor. O conjunto de cenários pergunta qual design se saiu melhor. Só a segunda pergunta tem uma resposta em que você pode confiar numa terça-feira em que todos estão cansados.

Por que cenários idênticos são o truque inteiro

Há uma versão mais fraca disto que parece igual e não funciona, e vale encenar, porque é a que a maioria dos times busca quando tenta “testar primeiro”.

A versão fraca: cada engenheiro vai e faz benchmark do seu próprio design. O autor do vector store o roda nas queries que favorecem retrieval. O autor do log plano o testa em conversas curtas onde reler tudo é de graça. O autor da tabela estruturada escolhe os casos onde os fatos são limpos e bem-tipados. Todos voltam com números verdes. O design de todo mundo “venceu” no teste que ele desenhou. Você agora transformou três opiniões em três benchmarks, o que é pior, porque um benchmark vestindo um número parece evidência mesmo quando é só o mesmo viés com uma casa decimal.

Uma medição só resolve uma discussão se todos os lados enfrentam o teste idêntico. No instante em que cada design é avaliado no seu próprio terreno de casa, você está de volta a discutir, só que com gráficos.

Um benchmark que você escreveu para fazer seu design parecer bom não é uma medição. É uma opinião com barras de erro.

Então a disciplina é sem glamour e absoluta. Um conjunto de cenários, escrito antes de qualquer design ser favorecido, por alguém que não está tentando vencer. Os mesmos casos hostis para os três: a conversa que roda longa o suficiente para estourar o contexto, o fato mencionado uma vez e necessário muito mais tarde, os fatos quase-duplicados que uma busca por similaridade confunde, o usuário que se corrige e espera que a correção fixe. Todo design encontra todo caso. Ninguém avalia a própria lição de casa.

Essa única restrição, cenários idênticos, escritos por uma mão desinteressada, é o que converte um debate numa decisão. Tire-a, e você não tem um bake-off. Você tem três engenheiros cada um fazendo demo no laptop onde funciona.

O que os números fizeram que a reunião não conseguiu

Quando os três designs rodaram o mesmo desafio, dois deles caíram por conta própria, não porque alguém os argumentou para baixo, mas porque os cenários mostraram algo que nenhum diagrama conseguia.

Vou manter os detalhes ilustrativos, porque a forma é a lição, não os dígitos. Digamos que o log plano relembrava quase tudo mas custava mais por conversa a cada turno, porque reler o histórico inteiro está bem no turno cinco e é ruinoso no turno cinquenta. Digamos que o vector store era barato e rápido mas confundia os fatos quase-duplicados, quando um usuário mencionava duas coisas similares, ele às vezes retornava a errada, e “às vezes retorna o fato errado” é um jeito silencioso de perder a confiança de um usuário. Digamos que a tabela estruturada se aguentou em ambos: ela lembrava o fato corrigido, não confundia os duplicados, e seu custo se manteve plano conforme a conversa crescia, porque ela só anotava o que importava.

Nada disso era visível do whiteboard. Tudo isso era óbvio dos cenários. A confusão do vector store não era uma falha que alguém conseguiria argumentar em existência numa reunião, ela só apareceu quando uma conversa real lhe deu dois fatos que ele não conseguia distinguir. A curva de custo do log plano não era um número que alguém tinha na sala, ela só apareceu quando um cenário rodou longo o suficiente para dobrá-la. A medição não escolheu o design que soava melhor. Ela escolheu o que se comportou melhor nos casos que importam, e os outros dois caíram sem uma única voz erguida.

Aqui está o que é fácil de perder: o vencedor poderia ter perdido. Esse é o ponto. Se a tabela estruturada tivesse silenciosamente derrubado o fato corrigido, o mesmo desafio teria dobrado ela, e teríamos shipado o vector store com a consciência limpa. O método não tem um favorito. Ele só recusa deixar o argumento mais fluente substituir o mais testado. Rode as três specs contra cenários idênticos, e os números dobram duas delas, e você nunca tem que levar para o lado pessoal que a sua foi uma das duas.

Por que isto é mais barato, não mais lento

A objeção se escreve sozinha: construir três designs é mais trabalho que escolher um. Claro que é. Fizemos mesmo assim, e economizou tempo, o que só soa como um paradoxo até você precificar a alternativa.

Uma decisão de design tomada por discussão não é de graça. É cara num atraso. Você escolhe a opção que argumentou melhor, você a constrói de verdade, e então, semanas depois, na frente de uma workload real, você descobre a coisa que um cenário teria mostrado numa tarde. Agora o custo não é uma reunião. É um rewrite, mais tudo que foi construído em cima da fundação errada, mais a credibilidade que você gasta explicando por que a escolha sofisticada não deu certo. A conta de uma decisão de design ruim é sempre paga depois, com juros, e os juros são a parte que ninguém orça.

O bake-off paga a conta cedo e pequena. Três implementações descartáveis e um conjunto honesto de cenários custam alguns dias. Uma escolha de design load-bearing que acaba errada custa um trimestre. Pagamos os poucos dias de propósito, do mesmo jeito que você preferiria gastar uma hora numa medição do terreno a reconstruir uma casa numa fundação errada por trinta centímetros.

Medir três designs parece mais lento que escolher um. Reconstruir o errado é o que de fato é lento.

E há um retorno composto que a reunião nunca te dá. Depois do bake-off, você não tem só uma decisão, você tem a razão, anotada, reproduzível, com os cenários anexados. Quando alguém perguntar seis meses depois por que o agent usa uma tabela estruturada, a resposta não é “discutimos e foi nisso que aterrissamos”. É “aqui estão os casos, aqui está como cada design se comportou, rode você mesmo”. Uma decisão que você consegue re-rodar é uma decisão que não tem que ser re-discutida toda vez que um novo engenheiro entra e acha a escolha surpreendente.

Quando você ainda tem que discutir

Quero ser honesto sobre a borda, porque um método que afirma resolver tudo está vendendo alguma coisa.

Nem toda decisão tem um cenário que você consegue escrever. Algumas escolhas são sobre valores, ou estratégia, ou uma aposta em para onde o mundo vai, e você não consegue medir até elas, porque os dados ainda não existem. Se construir para o cliente que você tem ou o cliente que você quer não é um bake-off. Essas decisões continuam humanas, e deveriam.

Mas a armadilha é chamar uma pergunta mensurável de não-mensurável para poder continuar discutindo-a. A maioria das brigas de design do tipo “a gente só tem que tomar uma decisão de julgamento” não são decisões de julgamento de jeito nenhum. São previsões sobre comportamento, fantasiadas de gosto, defendidas numa reunião porque medir parecia trabalho demais. A disciplina é saber a diferença: se há um cenário que mudaria a opinião de alguém, você não tem um debate. Você tem um experimento que ainda não rodou, e a reunião é só procrastinação com lanches.

A virada

Os três engenheiros que não conseguiam concordar ainda estão no time, e nenhum deles perdeu uma discussão naquele dia, porque não havia uma para perder. Essa é a parte que importa mais que a camada de memória.

Quando uma decisão se reduz a quem argumentou melhor, alguém sai tendo perdido, e carrega isso. A próxima briga de design fica um pouco mais pessoal, um pouco mais sobre estar certo do que estar correto, porque da última vez estar certo é o que foi recompensado. Mas quando os cenários decidem, ninguém perde para ninguém. O autor do vector store não foi superado na conversa por um colega, ele foi superado na medição por uma workload, e isso é uma coisa que você consegue dar de ombros e aprender em vez de ressentir. O método tirou o ego da sala tirando a sala da decisão. O que resta são três engenheiros que confiam um pouco mais na próxima decisão, porque viram que a decisão é tomada pelo trabalho, não pela voz mais alta com som de correta nela.

Essa é a coisa silenciosa que um bake-off compra que nenhum diagrama compra. Não só o design certo, um time que não tem que vencer um ao outro para chegar nele.

---

É isso que estamos construindo na Apollo Space: um jeito de trabalhar onde as decisões mais difíceis são resolvidas pelo que de fato acontece, não por quem explica melhor, para que a pessoa mais esperta da sala nunca tenha que ser a que mais fala. Se você já assistiu o design que soava melhor vencer o melhor, você já sabe por que preferiríamos rodar os cenários a ter a reunião.