O não de um CTO ao hype precisa de teste, gatilho e registro, ou é só humor

A Bessemer Venture Partners mantém em seu site uma página chamada Anti-Portfolio. Ela lista sete empresas nas quais a firma disse não, cada uma com um relato curto da recusa, e a introdução afirma que a única coisa pior do que perder uma grande empresa é fingir que isso não aconteceu. O Google está na página. Em 1999 e 2000, uma amiga de faculdade do sócio David Cowan alugou a garagem de sua casa a dois estudantes de Stanford que construíam um buscador e tentou, duas vezes, apresentá-los a ele. Segundo a página, Cowan respondeu perguntando como poderia sair da casa dela sem chegar perto da garagem. Facebook (2004), Tesla (2006), Atlassian e Apple também aparecem. O sócio Byron Deeter recusou a Tesla por causa das margens negativas e, mesmo assim, pagou um depósito para reservar o carro.

As recusas de um líder de tecnologia não deixam uma página assim, e é daí que parto. Um CTO que diz não a uma tecnologia badalada não gera fatura nem incidente. A empresa faz outra coisa no lugar, e ninguém consegue comparar esse mundo com aquele em que a resposta teria sido sim. Meu argumento é que um não só é crível quando vem acompanhado de um procedimento: critérios escritos, um teste barato com prazo, um gatilho publicado que mudaria a resposta e um registro datado das recusas, revisado em intervalos fixos. O registro é a peça mais importante, porque as outras três se deterioram sem ele.

Uma recusa sem essas peças é uma preferência, por mais experiente que seja quem a sustenta. Um CTO que não sabe dizer qual evidência reverteria sua recusa deve esperar ser atropelado, e parte das vezes quem o atropela vai estar certo. Também acho que a taxa certa de reversão é maior que zero. Um líder cujas recusas nunca são revertidas provavelmente parou de testá-las.

Recusas erradas somem se ninguém as registra

O valor do Anti-Portfolio está sobretudo no registro, e as histórias individuais importam menos. Sobre a Atlassian, a Bessemer conta uma história que começa com um primeiro contato em 2006, passa por uma chance, em 2010, de investir a uma avaliação de cerca de US$ 400 milhões que o time achou cara, e termina com a oferta pública inicial de 2015, que a página descreve como a maior listagem de tecnologia da história da Austrália. O verbete do Facebook registra uma recusa em 2004, depois que um sócio ouviu de Eduardo Saverin que o Friendster estava acabado. Numa entrevista de julho de 2006 ao programa de rádio público Marketplace, Cowan disse que a firma não quer levar o crédito por seus acertos, e criticou os sites de firmas de venture capital que fazem as empresas do portfólio parecerem fadadas ao sucesso, já que a maior parte do mérito é dos fundadores e dos funcionários.

A página tem também um limite que importa para quem pensa em copiá-la. Ela lista os erros que ficaram famosos e nenhuma das recusas que se mostraram certas, de modo que não existe denominador, e o leitor não consegue calcular com que frequência a firma recusa algo bom. Sete entradas numa página poderiam descrever uma firma cautelosa demais ou uma com taxa comum de erros; a página não permite distinguir. O registro de um CTO precisa incluir todas as recusas, as banais também, ou mostrará apenas os arrependimentos que por acaso foram memoráveis.

Imagino que as recusas de tecnologia sejam mais difíceis de reconstruir do que as de investimento. Um não costuma ser dado por e-mail ou no corredor, com uma razão que parecia suficiente naquele dia. Meses depois, quando um concorrente lança algo parecido, o raciocínio original quase sempre se perdeu, e a organização lembra do resultado e fornece uma razão que combine com ele. Uma razão escrita no dia, junto com a evidência que a teria mudado, permite que um leitor futuro diferencie um mau julgamento de um azar.

Julgamentos de tecnologia recebem feedback devagar demais para confiar na convicção

Daniel Kahneman e Gary Klein passaram anos em lados opostos de um debate sobre a intuição de especialistas e, em 2009, publicaram na American Psychologist um artigo conjunto sobre o que os dois concordavam. A resposta deles para quando o instinto de um especialista merece confiança tem duas condições. O ambiente precisa conter pistas que prevejam os resultados de forma confiável, e a pessoa precisa ter tido a chance de aprender essas pistas, o que eles descrevem como prática prolongada com feedback ao mesmo tempo rápido e inequívoco. Bombeiros e enfermeiros cumprem as duas condições. Previsões de longo prazo sobre eventos políticos, dizem os autores, não cumprem: eles citam o estudo de Tetlock sobre previsões políticas de especialistas, em que pessoas com alta escolaridade não se saíram melhor que leitores de jornal sem treino. Kahneman acrescenta que analistas de ações, psicoterapeutas e analistas de inteligência podem receber bastante feedback em tarefas de curto prazo, o que sustenta a confiança deles, enquanto o feedback sobre seus julgamentos de longo prazo é atrasado, escasso e ambíguo, uma mistura que o artigo considera propícia ao excesso de confiança. O texto diz com todas as letras que a confiança subjetiva não é um indicador confiável de acerto.

As decisões de adoção de um CTO ficam num ponto desconfortável entre os dois casos. Saber se a plataforma de agentes de um fornecedor processa corretamente as faturas de uma empresa pode levar semanas. Saber se esse fornecedor sobrevive e se o mercado adota o padrão que ele escolheu são perguntas que se resolvem em anos, misturadas a uma dúzia de outras causas, e um CTO toma talvez um punhado de grandes decisões desse tipo por ano. São poucos ciclos de feedback para que uma intuição se forme.

A resposta prática tem duas partes. A primeira é converter o julgamento em perguntas com ciclos curtos de feedback. Perguntar se uma tecnologia vai importar é uma pergunta de ciclo longo; perguntar se ela resolve corretamente quarenta casos nossos em um mês é uma de ciclo curto. A segunda é atribuir uma probabilidade às apostas de ciclo longo que restarem e pontuá-las depois. É o hábito que Philip Tetlock e Dan Gardner descrevem em Superforecasting (2015), extraído de um torneio de previsão que a agência de pesquisa de inteligência dos Estados Unidos, a IARPA, começou a realizar em 2011, no qual previsões probabilísticas eram pontuadas pela regra do erro quadrático de Brier. Tomo desse trabalho o hábito de pontuar e nada além disso. O registro proposto neste ensaio é uma versão pequena e privada do mesmo exercício.

Os dois erros custam dinheiro, mas só um aparece no orçamento

A palestra Choose Boring Technology, de Dan McKinley, publicada como ensaio em 30 de março de 2015, faz o argumento habitual contra o sim errado. Toda empresa, diz ele, dispõe por bastante tempo de cerca de três fichas de inovação, e cada escolha não comprovada, como o MongoDB ou uma ferramenta de descoberta de serviços com menos de um ano, gasta uma. A despesa está sobretudo em operar a coisa: ele escreve que os custos de longo prazo de manter um sistema funcionando superam em muito o incômodo de construí-lo. McKinley não é um absolutista, porém. Ele escreve que às vezes se deve escolher tecnologia nova, e pede um relato por escrito do que é difícil demais na pilha atual antes de gastar uma ficha. A reversão da Klarna em 2025 com seu assistente de atendimento por IA, que um ensaio anterior deste site cobre, é o exemplo que eu usaria para o custo de um sim errado.

O não errado é mais difícil de precificar, e um dos motivos é que recusar uma ferramenta oficial raramente impede as pessoas de usá-la. O Work Trend Index 2024, da Microsoft e do LinkedIn, ouviu cerca de 31 mil trabalhadores do conhecimento em 31 mercados entre meados de fevereiro e o fim de março de 2024, com o trabalho de campo feito pela Edelman Data & Intelligence. Ele constatou que 78% das pessoas que usam IA no trabalho levam as próprias ferramentas. O número vem de autodeclaração, num relatório produzido pela Microsoft, que vende produtos de IA, e eu não apoiaria um orçamento no valor exato. A direção, porém, é plausível, e ela muda o que uma recusa faz: a demanda continua, e o uso se desloca para onde ninguém enxerga, longe do alcance das regras de dados que o CTO poderia fixar.

Saber se um sim tardio sai barato depende do tipo de tecnologia, e quero deixar claro que isto é um julgamento meu e não uma medição. Para infraestrutura, um sim tardio costuma ser barato. O produto amadurece, os preços caem e outras empresas descobrem as arestas antes. Um sim precoce errado é caro porque as migrações são lentas. Para capacidades cujo retorno vem de a organização aprender a usá-las, como fluxos de trabalho redesenhados ou a habilidade de uma equipe em avaliar a saída de um modelo, um sim tardio custa mais, porque esse aprendizado não se compra depois. O primeiro tipo de decisão merece uma barra alta, e o segundo, uma barra baixa. Um procedimento deve perguntar com qual dos dois está lidando antes de perguntar qualquer outra coisa.

Oito linhas numa página bastam para tornar uma recusa auditável

As oito linhas abaixo cabem numa página. Os números que aparecerem nelas são meus e servem de ilustração.

Declare a afirmação, quem a faz, quem decide e a data. "O agente do fornecedor X vai resolver um terço dos nossos chamados de primeiro nível" é uma afirmação; "agentes são o futuro" não é.
Escreva os critérios antes da demonstração: o resultado, a métrica, a linha de base do processo atual e a nota de corte. Assim a demonstração do fornecedor pode ser julgada contra um número fixado de antemão.
Rode o menor teste capaz de constranger a afirmação. Use no máximo quatro semanas, dados seus, uma linha de base humana nos mesmos casos e execuções repetidas de cada caso.
Limite de antemão o custo de um sim: o escopo, qual ficha de inovação ele gasta e o plano de saída se der errado.
Publique um gatilho para quem propôs: a evidência específica que reabre a questão, com data de reavaliação. Pode ser um preço, uma confiabilidade medida nos seus casos, o resultado em produção de uma empresa parecida ou uma mudança regulatória.
Registre sua probabilidade de que esta recusa pareça errada na data de revisão.
Lance a decisão no registro, com a data, a razão em uma linha, o resultado do teste, o gatilho e a data de revisão.
Revise o registro a cada trimestre, pontue as probabilidades e anote quais recusas foram revertidas.

Acredito que é nos itens 2 e 5 que as recusas mais falham. Sem nota de corte, o teste vira discussão depois do fato, e sem gatilho a recusa só pode ser reaberta recorrendo a alguém acima na hierarquia; suspeito que uma equipe obrigada a fazer isso para ser ouvida acabará deixando de propor. Um gatilho diz a quem propôs que a resposta é não até que apareça certa evidência nomeada, e essa pessoa pode ir produzi-la.

Um produto de agentes mostra por que o teste repete execuções e o gatilho expira

Pense na onda recente de produtos vendidos como agentes. A Gartner previu em junho de 2025 que mais de 40% dos projetos de IA agêntica seriam cancelados até o fim de 2027, e usou o termo agent washing para os fornecedores que rebatizam assistentes, scripts e chatbots; o comunicado em si devolveu um erro de acesso quando tentei abri-lo, então me apoio na cobertura da imprensa especializada. Uma previsão sobre uma categoria diz pouco sobre o único fornecedor que está diante de um CTO nesta semana, e um teste diz.

O teste precisa medir execuções repetidas e não uma boa demonstração. O benchmark τ-bench, de Shunyu Yao e colegas (arXiv, junho de 2024), definiu pass^k como a chance de um agente resolver a mesma tarefa de atendimento ao cliente em todas as k tentativas separadas. Seu melhor agente de 2024, o GPT-4o, resolveu cerca de 61% das tarefas de varejo numa única tentativa, mas caiu para algo em torno de 25% quando as oito tentativas tinham de ter sucesso. São números antigos, de um modelo mais velho, e modelos mais novos pontuam mais, por uma margem que não verifiquei. Um ensaio anterior deste site, sobre quando um fluxo de trabalho vence um agente, esmiúça a métrica; aqui só preciso da consequência dela para o registro.

Segue um exemplo inventado dessa consequência. Suponha que a demonstração de um fornecedor mostre um agente resolvendo um punhado de casos de suporte, e que os critérios escritos antes digam que 85% dos casos devem passar em todas as cinco de cinco execuções repetidas, sem falhas em reembolsos acima de um valor definido. O teste usa 40 casos da fila do mês passado, cada um rodado cinco vezes. Se o agente acerta 80% das execuções e todos os casos têm a mesma dificuldade, um caso passa nas cinco execuções cerca de 33% das vezes (0,8 elevado à quinta potência). Se, em vez disso, 20 casos são sempre resolvidos e os outros 20 são resolvidos em 60% das vezes, a média continua em 80%, mas cerca de 54% dos casos passam nas cinco. De qualquer modo, o agente não alcança a nota de corte, e a entrada do registro é curta: recusado nesta data por causa desta consistência medida, a ser reaberto quando o fornecedor mostrar 85% no nosso conjunto ou oferecer preço por resolução auditada. O fornecedor pode ler isso e saber como reverter a decisão a seu favor.

A evidência se move, então o gatilho precisa de prazo de validade. Os assistentes de código mostram com que rapidez isso acontece. O ensaio randomizado da METR com 16 desenvolvedores experientes de código aberto em 246 tarefas próprias, publicado em julho de 2025, mediu tarefas que levaram 19% mais tempo com IA, embora os desenvolvedores tivessem previsto um ganho de velocidade de 24%. Um CTO que recusou com base nessa evidência estava acompanhando os dados. Sete meses depois, a METR relatou um estudo de acompanhamento com 57 desenvolvedores, 10 deles já participantes do primeiro. As estimativas brutas pendiam para um ganho de velocidade (tarefas que levaram 18% menos tempo para os que voltavam e 4% menos para os novos), mas os intervalos de 95% iam de -38 a +9% e de -15 a +9%, de modo que ambos incluíam efeito nulo. A METR chamou o sinal de pouco confiável, em parte porque de 30% a 50% dos desenvolvedores pesquisados disseram ter deixado de enviar tarefas que não queriam fazer sem IA. Uma recusa baseada no resultado de 2025 precisava de data de reavaliação, e a reavaliação teria descoberto que o próprio instrumento de medida havia se degradado. Os dois fatos pertencem ao registro.

A objeção mais forte é que um CTO que recusa muito passa a ser o risco

Um líder com um procedimento para dizer não pode simplesmente ter uma forma mais respeitável de dizê-lo. Os incentivos empurram nessa direção, porque um sim errado é rastreável até uma pessoa, com fatura e plano de migração anexos, enquanto um não errado é difuso e aparece como o lançamento de um rival. Os erros custam algo, e o Anti-Portfolio é o registro deles. A máxima de que as pessoas superestimam o efeito de uma tecnologia no curto prazo e o subestimam no longo costuma ser chamada de lei de Amara, por causa do futurista Roy Amara, e serve de argumento para dizer que os céticos perdem com o tempo. A atribuição é mais frágil do que a máxima é popular. O Quote Investigator rastreia um dito parecido, sobre o que se pode fazer em um ano contra cinco ou dez, até o livro Libraries of the Future, de J. C. R. Licklider, de 1965, no qual ele a chama de máxima moderna e não reivindica a autoria; a primeira atribuição explícita a Amara que o site documenta é uma coletânea de 1989, What Futurists Believe. A frase é uma heurística que ninguém mediu, e eu não a chamaria de lei.

Uma segunda versão da objeção diz para seguir o ciclo. Se o hype acaba desabando num vale e depois se recupera, um CTO poderia esperar o vale e comprar barato. É o que propõe Mastering the Hype Cycle (2008), de Jackie Fenn e Mark Raskino, que estende um modelo que, segundo uma resenha de 2009 na Strategy & Leadership, Fenn desenhou pela primeira vez na Gartner em 1995. Ozgur Dedehayir e Martin Steinert testaram o modelo contra as próprias bases de dados de tecnologia da Gartner numa revisão de 2016 na Technological Forecasting and Social Change e relataram incongruências com os relatórios da Gartner; sugeriram que a ideia de dinâmica de hype poderia sobreviver dentro de outros modelos de ciclo de vida, mas não necessariamente o ciclo em si. Li apenas o resumo desse artigo e, com base nele, trato a espera pelo vale como uma regra de timing em que essa revisão não dá motivo para confiar.

Minha resposta à objeção é que o registro permite a um CTO descobrir se ela se aplica a ele. Suponha, num caso ilustrativo, que um CTO registre 12 recusas em um ano, cada uma com 20% de chance declarada de parecer errada na revisão. O número esperado de reversões é 2,4. Se as probabilidades declaradas fossem honestas, nenhuma reversão ocorreria em cerca de 7% das vezes (0,8 elevado à décima segunda potência), e seis ou mais ocorreriam em cerca de 2%. Um único ano sem reversões é, portanto, só um indício de que as recusas se tornaram permanentes ou de que nada está sendo testado, e um segundo ano igual seria mais difícil de explicar. Seis ou mais indicariam recusas confiantes demais. Nenhum dos resultados é um veredito, já que 12 casos são uma amostra pequena, mas ambos ficariam invisíveis sem o registro.

Duas outras medições merecem ficar ao lado da taxa de reversão. Uma é o número de testes rodados por trimestre: um CTO que não rodou nenhum é um obstáculo, qualquer que seja a qualidade do raciocínio. A outra é o tempo entre a proposta e a resposta, já que um não que leva seis meses chega depois que quem usa a ferramenta por conta própria já decidiu.

O registro tem também limites que não consigo remover. Ele guarda as recusas que alguém propôs e nada diz sobre as ideias que ninguém ousou levantar. Pesa todas as recusas igualmente, quando um único não errado sobre uma tecnologia decisiva pode custar mais do que cem corretos, e por isso cada entrada deveria trazer uma estimativa grosseira do ganho perdido se a recusa se provar errada. E um CTO que revisa o próprio registro está corrigindo o próprio trabalho. Entregar a revisão trimestral a um colega ou aos autores das ideias recusadas é barato, e é a parte do procedimento que eu menos gostaria de pular.

O Technology Radar da Thoughtworks, cuja edição de abril de 2026 (volume 34) tem 118 entradas, pela minha contagem das listas em sua página, mostra a versão institucional disso. Um Technology Advisory Board de cerca de 20 tecnólogos seniores debate cada candidato e lhe atribui um anel. O quarto anel, chamado Caution no site atual, é para coisas amplamente aceitas com as quais a Thoughtworks teve experiências ruins. Os volumes são públicos e datados, então qualquer pessoa pode olhar para trás e ver o que foi dito. Não encontrei nenhuma pontuação publicada das classificações passadas contra os resultados, e esse passo ausente é o que proponho para uma única empresa.

Um lugar concreto para começar é a trilha de e-mails dos últimos seis meses. Liste cada proposta que foi recusada ou adiada, escreva a razão a partir do que a conversa diz, atribua a cada uma uma probabilidade de parecer errada e ponha uma data de revisão na página. A primeira revisão, para um registro iniciado nesta semana, cai em 14 de janeiro de 2027.

Fontes

Bessemer Venture Partners. The Anti-Portfolio. bvp.com/anti-portfolio (acessado em outubro de 2026); e Marketplace, American Public Media (julho de 2006). Matéria sobre o anti-portfolio, entrevista com David Cowan. marketplace.org/story/2006/07/28/anti-portfolio.
Kahneman, D. e Klein, G. (2009). Conditions for Intuitive Expertise: A Failure to Disagree. American Psychologist 64(6), 515-526. DOI 10.1037/a0016755.
McKinley, D. (30 de março de 2015). Choose Boring Technology. mcfunley.com/choose-boring-technology.
Tetlock, P. E. e Gardner, D. (2015). Superforecasting: The Art and Science of Prediction. Crown. O torneio da IARPA e a pontuação de Brier são descritos em resumos secundários (entre eles o verbete da Wikipedia sobre o Good Judgment Project, que indica início em julho de 2011); não abri o livro.
Microsoft e LinkedIn (2024). 2024 Work Trend Index: AI at Work Is Here. Now Comes the Hard Part. Pesquisa com cerca de 31 mil trabalhadores em 31 mercados, realizada de 15 de fevereiro a 28 de março de 2024 pela Edelman Data & Intelligence.
Gartner (25 de junho de 2025). Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027. Comunicado de imprensa; detalhes tirados da cobertura da imprensa especializada (CRN India, de 25 de junho de 2025, e outras), porque o comunicado em si estava bloqueado quando tentei abri-lo.
Yao, S., Shinn, N., Razavi, P., Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
METR (10 de julho de 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study; e METR (24 de fevereiro de 2026). We are Changing our Developer Productivity Experiment Design, metr.org/blog/2026-02-24-uplift-update.
Quote Investigator (3 de janeiro de 2019, atualizado em 2024). People Tend To Overestimate What Can Be Done In One Year And To Underestimate What Can Be Done In Five Or Ten Years. quoteinvestigator.com/2019/01/03/estimate.
Fenn, J. e Raskino, M. (2008). Mastering the Hype Cycle: How to Choose the Right Innovation at the Right Time. Harvard Business Press; Davidson, A. (2009). A model for picking technology winners? Strategy & Leadership (resenha de Fenn e Raskino), DOI 10.1108/sl.2009.26137bae.001; Dedehayir, O. e Steinert, M. (2016). The hype cycle model: A review and future directions. Technological Forecasting and Social Change 108, 28-41. DOI 10.1016/j.techfore.2016.04.005.
Thoughtworks (abril de 2026). Technology Radar, volume 34, e o FAQ do Radar sobre anéis e o Technology Advisory Board. thoughtworks.com/radar.
Aritmética ilustrativa, inventada para este ensaio: 40 casos rodados 5 vezes com nota de corte de 85%; sucesso por execução de 80% com dificuldade igual (0,8^5 = 33%) ou com metade dos casos sempre resolvida e a outra metade resolvida em 60% das vezes (0,5 + 0,5 x 0,6^5 = 54%); 12 recusas, cada uma com 20% de chance de reversão (esperado 2,4; nenhuma reversão 6,9%; seis ou mais cerca de 1,9%; nenhuma reversão em dois anos seguidos sob as mesmas premissas, cerca de 0,5%).