Voltar

Com a prosa de graça, o memorando que merece aprovação diz o que faria o autor mudar de ideia

·20 min de leitura

A página 191 do relatório do Columbia Accident Investigation Board, publicado em agosto de 2003, reproduz um slide de apresentação e uma crítica a ele. O slide veio de um briefing da Debris Assessment Team à Mission Evaluation Room da NASA sobre o que a espuma que atingiu a asa da Columbia poderia ter feito aos ladrilhos do escudo térmico. Tem um título e tópicos aninhados que criam seis níveis de hierarquia, e a crítica conta onze frases simples nele. O título diz que uma revisão dos dados de teste indica conservadorismo, expressão que se refere à escolha dos modelos de teste e nada diz sobre o dano previsto. O fato que mais importava, o de que uma das estimativas do detrito era 640 vezes maior que os dados usados para calibrar o modelo de dano, aparece só no pé do slide. Uma análise posterior, acrescentou o Board, chegou a 400 vezes. Por qualquer dos dois números, essa comparação pertencia ao título.

A alegação do Board é mais estreita do que culpar o slide pela perda do ônibus espacial. Em vários pontos da investigação, ele se surpreendeu ao receber slides onde esperava relatórios técnicos, e leu o hábito como ilustração de uma comunicação técnica problemática na NASA. A cópia anotada impressa no relatório acrescenta que os altos dirigentes da agência, para quem os relatórios dos engenheiros eram escritos, ficaram satisfeitos de que a Columbia não corria perigo, e ninguém tentou examinar a ameaça mais a fundo. Ninguém sabe dizer o que um memorando de seis páginas teria feito naquela sala. O que a página mostra é uma decisão sobre olhar ou não com mais atenção para a asa, tomada por dirigentes que se deram por satisfeitos com relatórios de engenharia do tipo que esse slide exemplifica, um slide que enterrou o próprio fato mais importante.

Meu argumento é que um documento escrito de decisão cumpre duas tarefas fáceis de confundir. Ele obriga o autor a assumir uma posição, e deixa um registro que outras pessoas podem auditar depois que os envolvidos tiverem seguido em frente. Esses documentos costumam ser julgados pela qualidade da leitura, um indicador barato e imperfeito da primeira tarefa. Os modelos de linguagem reduziram a quase zero o custo da prosa fluente, o indicador deixou de funcionar, e os revisores precisam pedir as partes de uma decisão que um prompt não fornece: o que foi escolhido, o que foi rejeitado, que evidência sustenta a escolha e que observação faria o autor mudar de ideia. Defendo isso para decisões caras de reverter. Para as pequenas, acho que está errado, e volto a esse limite mais adiante.

O slide da Columbia enterrou a própria manchete

A seção do Board sobre o slide se chama "Engineering by Viewgraphs", e a falha que ela descreve é de prioridade. Num slide, a informação é hierarquizada pela posição e pelo recuo, e essa hierarquia pode contradizer a engenharia. A palavra vagamente quantitativa "significant" ou "significantly" aparece cinco vezes no slide, aponta o relatório, com sentidos que vão de detectável num caso de calibração irrelevante até dano suficiente para matar todos. Já a unidade de volume aparece escrita de três maneiras diferentes. Edward Tufte, cuja análise o relatório reproduz, propôs outro título: a revisão dos dados de teste indica que dois modelos são irrelevantes.

O mesmo capítulo compara a NASA com o programa de segurança de submarinos da Marinha americana. No sistema da Marinha, observou o Board, as recomendações técnicas dos contratados são documentadas em correspondência formal escrita e revisada por pares, e apresentações em PowerPoint não são aceitas no lugar de um trabalho de equipe concluído. A diferença está no que precisa acontecer antes de uma recomendação andar. Num caso, o autor tem de terminar o raciocínio no papel e expô-lo a revisores. No outro, pelo modo como leio o contraste, a apresentação comprime o raciocínio, e todos na sala podem supor que outra pessoa guarda os detalhes.

Valem dois limites. Um acidente é um caso só, e um memorando também pode enterrar uma manchete, tanto quanto um slide. A observação do Board diz respeito ao formato, e não ao estilo da prosa, e a lição que tiro dela é sobre o que um artefato obriga o autor a declarar: um formato que não exige que se diga o que está sendo decidido e qual é a evidência mais importante deixa as duas coisas se perderem.

Escrever obriga o autor a se comprometer, e o registro sobrevive às pessoas

A primeira tarefa tem um enunciado compacto na abertura do Capítulo 1 do livro Specifying Systems, de Leslie Lamport, de 2002: "Writing is nature's way of letting you know how sloppy your thinking is", frase atribuída ali a Guindon. Em tradução minha, escrever é o jeito que a natureza tem de avisar o quanto o seu pensamento é desleixado. Lamport acrescenta que a matemática faz o mesmo com a escrita. Seu argumento a favor das especificações é prático: especificar um sistema ajuda a entendê-lo, e por isso compensa fazê-lo antes de construir o sistema.

A Amazon transformou isso numa rotina de gestão. Na carta aos acionistas de 2017, Jeff Bezos escreveu que a empresa não usa apresentações de slides e redige memorandos de seis páginas com estrutura narrativa, que todos leem em silêncio no início da reunião, no que ele chama de sala de estudos (study hall). Admite que a qualidade varia muito. Seu diagnóstico para os memorandos fracos é que os autores avaliam mal o tamanho do trabalho: um memorando do padrão que ele quer é reescrito, compartilhado com colegas, deixado de lado por um ou dois dias e editado de novo, e provavelmente leva uma semana ou mais. Um resumo de segunda mão do livro Working Backwards, de Colin Bryar e Bill Carr, descreve a leitura silenciosa como algo em torno de vinte minutos e diz que os textos de Tufte sobre slides influenciaram a decisão de abandoná-los. Não abri o livro, então trato esses dois detalhes como relatados e não verificados.

A segunda tarefa, o registro auditável, é onde a literatura de engenharia é mais específica. Michael Nygard propôs os registros de decisão de arquitetura em novembro de 2011, com um argumento sobre quem chega depois. Sem um registro do motivo de uma decisão, quem entra num projeto só pode aceitá-la às cegas ou revertê-la às cegas. A aceitação cega deixa a equipe com medo de mexer em qualquer coisa, e a reversão cega pode destruir uma propriedade que a decisão antiga protegia. O formato dele ocupa uma ou duas páginas, com título, contexto em linguagem neutra quanto a valores, a decisão na voz ativa começando com "Nós vamos" (We will), um status e todas as consequências, inclusive as negativas. Os números nunca são reutilizados, e uma decisão revertida continua arquivada, marcada como substituída, porque ainda é relevante saber que um dia ela foi a decisão. Nygard também escreve, entre parênteses, que bullets matam pessoas, até os do PowerPoint.

A descrição de Malte Ubl, de 2020, sobre os design docs no Google acrescenta o item que eu destacaria para os revisores. Além de contexto e objetivos, ele pede não-objetivos explícitos e uma seção de alternativas consideradas, que chama de uma das mais importantes do documento porque mostra por que o desenho escolhido supera os outros diante dos objetivos declarados. Ele também lista para que servem esses documentos: achar problemas de desenho enquanto as mudanças são baratas, construir consenso e formar uma memória organizacional. O GitLab aplica a mesma lógica ao processo da empresa. Seu handbook manda escrever a solução primeiro e anunciá-la depois, e guarda de propósito apenas 90 dias de histórico de chat, para que o chat não vire o lugar onde os projetos são geridos do início ao fim.

Essas fontes concordam quanto ao mecanismo, e não achei nenhuma que discorde, mas a concordância é mais fraca do que parece. São descrições feitas por praticantes de empresas que adotaram a prática e sobreviveram, e o relato de experiência do próprio Nygard cobre poucos meses em poucos projetos. As afirmações de eficiência do GitLab são a empresa descrevendo a si mesma. Não conheço nenhuma comparação controlada em que equipes parecidas tenham decidido com e sem registro escrito. O argumento se apoia no mecanismo, na conclusão sobre a Columbia e no fato simples de que uma decisão que ninguém registrou não pode ser auditada.

A fluência gratuita elimina o indicador em que os revisores se apoiavam

A prosa fluente custava esforço, e por isso carregava informação. Um leitor que encontrava um memorando claro, organizado e bem editado podia inferir que o autor tinha gasto tempo e provavelmente entendia o assunto. Essa inferência nunca foi confiável, mas era barata de fazer, e as organizações se apoiavam nela.

Há evidência direta de que esse indicador falha num ambiente vizinho. Anaïs Galdin e Jesse Silbert estudaram propostas de trabalho na plataforma de freelancers Freelancer.com, onde, antes de os modelos de linguagem se popularizarem, os contratantes mostravam grande disposição de pagar por candidaturas mais adaptadas à vaga. Depois da chegada dos modelos, essa disposição caiu muito, e na amostra posterior à adoção a taxa de contratação ficou estável ao longo de toda a faixa da medida de adaptação. No modelo estrutural dos autores, um mercado em que as candidaturas escritas não trazem informação sobre a habilidade contrata o quinto superior dos trabalhadores 19% menos vezes do que antes e o quinto inferior 14% mais. Esse último resultado vem de uma simulação, e um mercado de propostas curtas não é uma revisão de projeto. Ainda assim, acho que o mecanismo se transfere: um sinal que não custa nada para produzir deixa de separar o cuidadoso do descuidado.

A revisão por pares mostra a mesma mudança pelo lado do leitor. Weixin Liang e colegas estimaram que entre 6,5% e 16,9% do texto das revisões na ICLR 2024, NeurIPS 2023, CoRL 2023 e EMNLP 2023 poderiam ter sido substancialmente modificados por um modelo de linguagem, com proporções maiores nas revisões que declararam baixa confiança do revisor ou foram enviadas perto do prazo. Em 2026, os organizadores da ICML conduziram um experimento randomizado em que um grupo de revisores foi proibido de usar modelos de linguagem e outro teve o uso limitado permitido. Na pesquisa que se seguiu, 22,5% do grupo proibido disseram tê-los usado mesmo assim. Os organizadores não usaram detectores genéricos de texto de IA. Esconderam nos PDFs das submissões instruções que faziam um modelo incluir frases escolhidas na revisão, sinalizaram 795 revisões de 506 revisores, cerca de 1% de todas as revisões, e puseram uma pessoa para conferir cada caso. Reconhecem que o método provavelmente pegou só os descuidados. O experimento também constatou que a política atribuída ao revisor teve efeito quase nulo nas decisões finais e nas notas. Esse resultado nulo diz que as duas políticas eram difíceis de distinguir nos desfechos. Não diz se as revisões assistidas por modelos eram boas.

O ganho de produtividade também tem respaldo experimental. Num experimento pré-registrado com 453 profissionais com ensino superior, relatado por Shakked Noy e Whitney Zhang em 2023, o acesso ao ChatGPT reduziu em cerca de 40% o tempo gasto em tarefas de escrita específicas da ocupação e elevou em cerca de 18% as notas de qualidade dadas por avaliadores independentes, e a distância entre os trabalhadores diminuiu. Qualidade ali significa notas de avaliadores cegos que atuam nas mesmas ocupações, com três avaliadores por texto e, na versão preliminar que consegui abrir, uma concordância média entre eles de apenas 0,44 em correlação. As tarefas eram trabalhos curtos e autocontidos, de 20 a 30 minutos. Não encontrei nessa versão uma auditoria separada da exatidão factual, de modo que a qualidade no estudo é, em grande parte, o que um leitor informado percebe.

Isso muda a primeira tarefa de um documento de decisão. O benefício de escrever, o de obrigar o autor a pensar, depende de o autor ser quem se debate com as frases. Um modelo pode transformar uma ideia não resolvida numa narrativa com ar de resolvida enquanto o autor não resolve nada. O desleixo que a frase de Guindon diz que a escrita expõe agora pode ser encoberto pela ferramenta, e o artefato continua parecendo evidência do esforço que Bezos pede. Essa é uma inferência minha, e não achei estudo que a teste para memorandos ou design docs.

Os revisores devem pedir o que um prompt não consegue inventar

Um modelo escreve um relato persuasivo de quase qualquer decisão, de modo que a revisão tem de pedir coisas verificáveis e que vivem fora do documento. O roteiro que proponho tem cinco perguntas, e cada uma é uma ideia antiga das fontes acima, refeita para depender de um ponteiro para algo que o revisor possa abrir.

  1. O que exatamente está sendo decidido, numa frase que começa com "Nós vamos", e o que acontece por padrão se ninguém decidir?
  2. Que alternativas foram rejeitadas, quem propôs cada uma e o que cada uma tinha a seu favor?
  3. Qual é a evidência, de onde ela veio e quais partes foram observadas e quais foram inferidas?
  4. Que observação, medida como e até que data, faria o autor reverter a decisão?
  5. Quanto custa reverter, e quem paga se o autor estiver errado?

A pergunta 1 é a declaração de decisão de Nygard, com um teste anexado: se não dá para escrever a frase nessa forma, a decisão ainda não foi tomada. Com nomes acrescentados, a seção de alternativas de Ubl vira a pergunta 2, porque uma lista de alternativas que ninguém defendeu é o tipo de coisa que um modelo produz com facilidade. Na pergunta 3, observação e inferência ficam separadas, e foi essa a linha que o slide da Columbia borrou, já que o número de 640 vezes era uma estimativa posta num tópico ao lado dos números da base de testes com a qual foi comparada. Considero a pergunta 4 a mais importante. Quase todo plano contém uma frase como "vamos revisitar se as condições mudarem", e uma frase assim não compromete o autor com nada. Um número, um instrumento e uma data comprometem o autor com algo que um estranho pode conferir um ano depois. A pergunta 5 vem da exigência de Nygard de listar todas as consequências, somada à questão de quem arca com elas.

É a exigência do ponteiro que mais pesa. Toda resposta às perguntas 2, 3 e 4 deveria trazer o link de uma conversa, um ticket, um experimento executado ou uma pessoa nomeada que fez a objeção. Resposta sem ponteiro é uma afirmação, e o revisor deve tratá-la como tal. Um modelo consegue inventar uma alternativa plausível, mas não consegue fazer com que ela seja a que alguém de fato levantou numa reunião de fato, nem produzir um link que funcione para um experimento que nunca foi rodado.

Um registro de decisão com números inventados mostra o que o revisor pode atacar

Este exemplo é inventado para ilustração: a equipe, as pessoas e todos os números. Uma equipe que classifica notas fiscais de fornecedores paga por um modelo grande em cada documento. Um rascunho que responda às cinco perguntas poderia ser assim. Vamos enviar as notas dos 70% de fornecedores com formato de nota conhecido a um modelo menor e manter o modelo grande para o resto. O padrão, se ninguém decidir, é uma conta mensal que subiu de US$ 9.000 para US$ 18.000 em dois trimestres e continuará subindo com o volume. As alternativas rejeitadas são continuar só com o modelo grande, defendida por um colega de finanças em nome da simplicidade, e fazer fine-tuning do modelo menor, proposta por um engenheiro e descartada porque coletar dados rotulados levaria cerca de dois meses. A evidência vem de uma execução em paralelo, em modo sombra, de duas semanas com 1.200 notas, com link, em que o modelo menor coincidiu com o grande em 97,1% dos campos. Isso foi observado. A expectativa de que as notas de formato conhecido se comportem do mesmo jeito no próximo trimestre foi inferida. A decisão é revertida se, numa amostra semanal auditada de 400 notas, a taxa de erro passar de 3% por duas semanas seguidas, com uma primeira revisão em 15 de janeiro. Reverter custa cerca de um dia de configuração de roteamento, e a área financeira arca com o custo de qualquer nota lançada errada até que o erro seja pego.

Um revisor pode atacar cada linha disso. Pode perguntar se a execução em paralelo cobriu o pico de fim de mês, ou se o colega de finanças concorda que a objeção dele foi apresentada com justiça. Pode também conferir o gatilho com aritmética, o que fiz com a distribuição binomial. Se a taxa de erro verdadeira fosse exatamente 3%, uma amostra semanal de 400 notas mostraria 13 erros ou mais, o suficiente para parecer acima de 3%, em cerca de 42% das semanas, e portanto duas semanas assim seguidas forçariam uma revisão em aproximadamente 18% das janelas de duas semanas só por acaso. Se a taxa verdadeira fosse 4%, cerca de 66% das janelas de duas semanas disparariam a regra, e a 2% quase nenhuma. O limite é utilizável, mas o autor deve saber que ele é ruidoso, e um revisor que vê o número pode pedir uma amostra maior ou uma janela mais longa.

Um parágrafo fluente que dissesse "avaliamos várias abordagens e escolhemos a opção de melhor custo-benefício" não ofereceria nenhuma dessas pontas para puxar. As duas versões poderiam ser produzidas por um modelo em segundos. Só a primeira pode estar errada de um jeito que alguém consiga detectar e corrigir.

Escrever é caro, e algumas decisões pertencem à sala de reunião

A objeção mais forte é sobre preço. Ubl diz com todas as letras que design docs são custo adicional, que revisões podem ser uma armadilha perigosa de burocracia e que, se a solução não é ambígua, o documento vale pouco. O GitLab admite que o trabalho que começa pelo handbook leva mais tempo no início, porque é preciso decidir onde a mudança se encaixa e ajustá-la ao texto existente. Bezos estima uma semana ou mais para um bom memorando. Multiplique isso pelo número de decisões que uma equipe toma, some as perguntas de revisão acima, e o processo pode custar mais do que muitas das decisões valem. Aplicadas a cada escolha de biblioteca, cinco perguntas com ponteiros levariam mais tempo do que a própria escolha.

Uma segunda objeção diz respeito ao que as reuniões fazem. A prática da Amazon, tanto no relato de Bezos quanto no de segunda mão, combina o memorando com uma reunião: o documento é lido na sala e a discussão vem depois. Uma reunião deixa o desacordo aflorar na velocidade da conversa, transmite o que está em jogo de um jeito que a prosa achata e permite questionar o autor sem anotações. Essa última propriedade tem relação direta com o problema dos modelos. Um autor que não consegue responder a uma pergunta de acompanhamento sobre a quarta pergunta do roteiro revelou algo sobre o documento que nenhuma revisão do texto revelaria. Uma defesa oral expõe depressa uma posição escrita por outra mão, e nada na prática escrita a substitui.

Uma terceira objeção é que escrever mais barato é um ganho, e é. O resultado de Noy e Zhang sugere que a ferramenta ajuda mais os escritores mais fracos, e eu esperaria que ajudasse quem redige numa segunda língua, embora isso vá além do que o estudo mediu. Uma organização que recusa a ajuda dos modelos para preservar o esforço paga um preço real em acesso desigual à expressão clara.

Minha resposta é uma regra de triagem. Reserve o formato completo para as decisões que Nygard chama de arquiteturalmente significativas e que o teste de Ubl marca como ambíguas: difíceis de reverter, compartilhadas entre equipes ou apoiadas em evidência contestada. Para todo o resto, um parágrafo num ticket basta, e uma conversa serve. Permita a ajuda de modelos na redação, já que é barata, mas exija que quem assina responda pelas cinco respostas e consiga defendê-las ao vivo. A regra tem custo, e supõe que os revisores de fato vão clicar nos links, o que nenhuma política consegue garantir.

Nenhum estudo que encontrei testa se essas perguntas pegam memorandos fracos

Não encontrei um estudo em que revisores com uma lista de verificação desse tipo fossem comparados com revisores sem ela, sobre memorandos de qualidade conhecida, entre eles memorandos redigidos por modelos. As fontes acima sustentam as premissas: um formato pode esconder o fato central, e nos ambientes estudados o polimento do texto carrega menos informação do que carregava. Não mostram que as cinco perguntas pegam memorandos fracos melhor do que uma leitura atenta. O teste pode ser feito: pegar um arquivo de documentos de decisão cujos desfechos são conhecidos, retirar a autoria, fazer alguns revisores lerem pela qualidade e outros aplicarem as cinco perguntas com verificação dos ponteiros, e comparar quantos dos fracassos posteriores cada grupo sinalizou.

Uma equipe pode rodar uma versão pequena disso sem estudo nenhum. Pegue as três últimas decisões que seu grupo aprovou, peça ao autor de cada uma que responda às cinco perguntas e conte quantas das respostas às perguntas 2, 3 e 4 terminam em algo que um estranho possa abrir.

Fontes

  1. Columbia Accident Investigation Board (agosto de 2003). Report Volume I. NASA e Government Printing Office. Capítulo 7, seção 7.5, "Engineering by Viewgraphs" (p. 191, incluindo o slide anotado e a análise de Tufte) e a discussão de benchmarking entre NASA e Marinha (p. 182). https://s3.amazonaws.com/akamai.netstorage/anon.nasa-global/CAIB/CAIB_lowres_full.pdf
  2. Bezos, J. (carta de 2017). Amazon.com 2017 Letter to Shareholders, seção "Six-Page Narratives". https://www.aboutamazon.com/news/company-news/2017-letter-to-shareholders
  3. Bryar, C., Carr, B. (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin's Press. Citado apenas conforme resumido em Charterworks, "Book briefing: Working Backwards" (https://www.charterworks.com/book-briefing-working-backwards-by-colin-bryar-and-bill-carr/); não abri o livro.
  4. Nygard, M. (15 de novembro de 2011). Documenting Architecture Decisions. Blog da Cognitect. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions
  5. Ubl, M. (6 de julho de 2020). Design Docs at Google. Industrial Empathy. https://www.industrialempathy.com/posts/design-docs-at-google/
  6. GitLab. The importance of a handbook-first approach to communication, e Handbook Usage (a passagem sobre o custo de tempo inicial). The GitLab Handbook. https://handbook.gitlab.com/handbook/company/culture/all-remote/handbook-first/ e https://handbook.gitlab.com/handbook/about/handbook-usage/
  7. Lamport, L. (2002). Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley. Capítulo 1, "What Is a Specification?" https://lamport.azurewebsites.net/tla/book-02-08-08.pdf
  8. Galdin, A., Silbert, J. (11 de novembro de 2025). Making Talk Cheap: Generative AI and Labor Market Signaling. arXiv:2511.08785 (v1).
  9. Liang, W. et al. (2024). Monitoring AI-Modified Content at Scale: A Case Study on the Impact of ChatGPT on AI Conference Peer Reviews. Proceedings of the 41st International Conference on Machine Learning, PMLR 235; arXiv:2403.07183.
  10. Kim, S. S. Y. et al. (16 de setembro de 2026). Use and Effects of LLMs in Peer Review: A Randomized Experiment and Survey at ICML 2026. arXiv:2609.19420; e organizadores da ICML 2026 (18 de março de 2026), On Violations of LLM Review Policies. https://blog.icml.cc/2026/03/18/on-violations-of-llm-review-policies/
  11. Noy, S., Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 14 de julho de 2023, pp. 187-192. DOI 10.1126/science.adh2586. Os 453 participantes e os números de 40% e 18% vêm da versão publicada, conforme resumida pelo Stanford SCALE; os detalhes dos avaliadores vêm da versão preliminar de março de 2023 (444 participantes), https://economics.mit.edu/sites/default/files/inline-files/Noy_Zhang_1_0.pdf
  12. Registro de decisão ilustrativo: a equipe, as pessoas, os volumes de notas fiscais, os custos, os tamanhos de amostra, os limites de erro e as datas do exemplo trabalhado são inventados para este ensaio e não descrevem nenhuma equipe real. As probabilidades citadas para a auditoria de 400 notas (42% das semanas com taxa de erro verdadeira de 3%, cerca de 18% dos pares de semanas consecutivas, cerca de 66% dos pares consecutivos com taxa verdadeira de 4%) são cálculo binomial meu sobre esses dados inventados.