5 vieses que decidem sua stack antes do teste

Sobre os números deste texto. Os vieses e o mecanismo vêm do meu livro sobre psicologia aplicada à engenharia. As cenas de decisão que aparecem aqui são exemplos trabalhados para mostrar como cada viés opera, não medição de um projeto real de produção. Meça no seu contexto antes de aplicar qualquer número daqui.

Você abre o benchmark, roda hyperfine, coleta os p95, monta a tabela comparativa. Tudo parece racional. Só que se você repetir o exercício depois de treinar o olho para vieses cognitivos, descobre uma coisa desconfortável: na maioria das vezes, a decisão sobre qual stack usar já estava fechada antes do benchmark abrir. O benchmark só confirmou o que o cérebro já tinha escolhido.

Esse post é sobre os 5 vieses cognitivos que mais fecham a decisão de stack antes do teste rodar. Para cada um: como o viés opera na cena típica, o custo que ele cobra no médio prazo, e uma técnica concreta para desarmar.

Viés 1: efeito manada — “todo mundo usa”

Efeito manada é a tendência de julgar correto aquilo que muita gente adotou. Aplicado à seleção de stack: framework com 50 mil estrelas no GitHub versus framework com 500 estrelas, o primeiro parece “mais seguro” mesmo antes de você abrir a documentação.

A cena típica: você precisa escolher entre dois ORMs. Um tem 40 mil estrelas, releases semanais, comunidade grande no Discord. O outro tem 3 mil estrelas, mas foi feito por um time que resolveu exatamente o problema que você tem. Você abre o benchmark, mas dentro da cabeça a decisão já está encaminhada para o primeiro. O benchmark vai virar validação, não escolha.

O efeito manada não é irracional em si. Ferramenta com muita gente usando tem documentação rica, ecossistema maduro, mais gente para contratar depois. Vantagens reais. O problema é dar a essas vantagens peso maior do que todos os outros critérios juntos, sem se perguntar se elas realmente casam com o seu projeto.

Como desarmar: antes de abrir o benchmark, escreva a matriz de requisitos do seu projeto, com pesos. Performance p95, curva de aprendizado do time, custo de manutenção em 2 anos, custo de contratação, dívida técnica que vai gerar. “Popularidade” pode ser uma linha da matriz, mas nunca a única. Se depois de preencher a matriz o candidato de 3 mil estrelas ganha em 4 de 5 categorias, vá com ele. A ansiedade de “escolhi o menos popular” que sobra é o efeito manada tentando não morrer, e você tem a matriz para responder a ela em reunião de arquitetura.

Viés 2: efeito IKEA — “eu montei, então é bom”

Efeito IKEA é a tendência de superestimar o valor daquilo que você mesmo construiu. Montou o móvel do IKEA, gosta mais dele do que de um móvel pronto do mesmo nível. Em software: framework interno, script de build customizado, ferramenta que o time desenvolveu num hackathon.

Onde isso pega na seleção de stack:

Síndrome NIH (Not Invented Here). “Nossos requisitos são especiais, vamos construir uma coisa nossa.” Às vezes os requisitos realmente são especiais. Mas vale conferir se essa decisão não está sendo empurrada pelo viés de “vou gostar mais do que fiz do que de qualquer coisa comprada”.

Apego à stack legada. “Esse framework interno levou 5 anos para estabilizar, não vou trocar.” Os 5 anos já foram gastos, não voltam. A pergunta útil é: comparando o custo dos próximos 2 anos mantendo o interno com o custo de migrar para uma alternativa OSS madura, qual ganha? Muitas vezes o interno perde, mas o time protege ele porque montou.

Superestimar a ferramenta própria. O script de build customizado que só funciona porque o autor está no time. Se ele sair, quem mantém? Se a resposta for “ninguém sabe”, o valor real da ferramenta é bem menor do que a percepção interna diz.

Como desarmar: fazer o teste do “se escolhesse do zero hoje?”. Se o sistema atual não existisse e você fosse escolher hoje sem nenhum histórico, escolheria a mesma stack? Se a resposta for não, o que você tem é apego, não escolha técnica. E apego custa dinheiro em manutenção e contratação nos próximos anos.

Viés 3: custo afundado — “já investimos 3 meses”

Falácia do custo afundado é o fenômeno em que tempo, dinheiro e esforço já gastos prendem a decisão, impedindo o recuo racional.

Na seleção de stack, isso aparece em 3 formatos:

Adiar refatoração. “Descartar esse código é jogar fora 3 meses de trabalho.” Só que os 3 meses já se foram, não voltam. A comparação útil é: manter esse código por mais 12 meses custa quanto (bugs, complexidade, onboarding) versus reescrever custa quanto pontualmente e economiza quanto por ano depois?

Continuar migração falhando. Time começou uma migração de monolito para microserviços, gastou 6 meses, os primeiros serviços quebraram em produção 3 vezes, o resto do time está com medo de tocar. “Chegamos até aqui, mais um pouco e dá certo”. Quanto maior o investimento, mais difícil recuar. Em economia chamam isso de Falácia de Concorde: o avião supersônico continuou sendo desenvolvido depois de ficar claro que não teria sucesso comercial, justamente porque o investimento gigante virou inércia.

Manter funcionalidade ou biblioteca que ninguém usa. “Dá pena descartar.” O custo de manter tudo — atualizar dependências, resolver conflito de versão, treinar novo dev — é invisível na hora, mas se acumula.

Como desarmar: no quadro de decisão, riscar o passado. Duas colunas: “custo futuro se continuar” versus “custo futuro se mudar”. Se a segunda for menor, mudar. “Dá pena” é emoção humana natural, mas em decisão técnica precisa ficar de fora.

Viés 4: heurística da disponibilidade — “o último framework que vi”

Heurística da disponibilidade é a tendência de avaliar a probabilidade de algo pela facilidade com que você lembra de exemplos. Aplicado a stack: o framework mais recente que apareceu no seu feed de RSS, na conferência que você assistiu, no post que bombou no HackerNews, vira o próximo candidato natural.

A cena: você viu 3 posts em 2 semanas sobre uma stack nova. Um deles era um post técnico decente, os outros dois eram opiniões entusiasmadas de gente que ainda não colocou em produção. No próximo projeto, você “lembra” dessa stack como candidata forte. Alternativas mais antigas e maduras, que resolveriam o problema melhor, ficam em segundo plano porque não estão frescas na cabeça.

Isso tem um efeito colateral perverso na comunidade dev: ferramentas viram tendência não por serem melhores, mas por serem mais faladas. Você adota a tendência, sofre com a imaturidade dela por 6 meses, e quando descobre que a solução antiga já resolvia o problema, os 6 meses já foram.

Como desarmar: para cada candidato “novo” que você está considerando, obrigue a matriz a incluir pelo menos 2 candidatos maduros de 3+ anos que resolvem o mesmo problema. Muitas vezes o candidato novo vence mesmo assim (é bom mesmo), mas com frequência não desprezível um dos maduros vence, e você acabou de se poupar meses de dor.

Viés 5: hype cycle — “estamos no pico ou no vale?”

O Hype Cycle do Gartner descreve em 5 fases o amadurecimento de uma tecnologia. Em cada fase, um viés diferente predomina, e a decisão de “vamos adotar?” fica distorcida sem você perceber.

Pico da expectativa exagerada: efeito manada máximo. A ansiedade de “não ficar para trás” trava a avaliação racional. Você adota agora porque todo mundo está falando, não porque testou.

Vale da desilusão: viés de negatividade toma conta. A tecnologia começou a mostrar limites reais, e a comunidade dev, que ama drama, amplifica os problemas. Você abandona a stack no exato momento em que ela está sendo consertada.

Rampa de esclarecimento e platô de produtividade: finalmente uma avaliação serena é possível. Mas até chegar aqui, o custo afundado (não consegue descartar a stack adotada no pico) e o efeito IKEA (apego ao que custou implementar) já estão distorcendo o julgamento sobre o que fazer.

A conclusão prática: seleção de stack não é decisão única, é processo contínuo. A escolha certa em janeiro de 2025 pode precisar ser revista em setembro de 2026, e isso não é falha, é como o hype cycle funciona.

Como desarmar: para stacks adotadas há mais de 12 meses, agendar um review semestral. Não para trocar por padrão, mas para forçar a pergunta “se fôssemos escolher hoje, escolheríamos isso de novo?”. Conhecendo o hype cycle, você reconhece o vale da desilusão quando ele acontece e não abandona uma stack que só está passando pela fase feia natural do amadurecimento.

O padrão que os 5 têm em comum

Os 5 vieses acima têm uma coisa em comum: eles fecham a decisão antes de o benchmark abrir. O benchmark, quando finalmente roda, só valida a escolha que o cérebro já fez. Por isso “vamos rodar o benchmark antes” não protege sozinho.

O que protege é fazer o exercício antes do benchmark:

1. Escrever a matriz de requisitos com pesos, com o time inteiro na sala
2. Listar 3 candidatos por categoria, obrigatoriamente incluindo 1 candidato maduro de 3+ anos
3. Rodar o benchmark e preencher a matriz
4. Se o vencedor for o candidato que estava na sua cabeça desde o começo, se perguntar: “isso é validação real ou o meu viés de confirmação fez o resto do exercício se ajustar para fechar aqui?”

A pergunta 4 é a que dói. Faça ela mesmo assim.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews