A mentira do "10x developer": o mito nasceu em 1968 e a IA só escancarou o erro
Durante décadas a indústria venerou uma figura quase mítica: o 10x developer. O programador lendário que, sozinho, produziria dez vezes mais que um dev comum. Empresas caçavam esse unicórnio, devs se mataram de estudar pra virar um, e o Reddit/HN/Twitter da vida gastaram milhares de threads discutindo se ele existia.
Quase ninguém parou pra checar a única coisa que importava: de onde saiu esse número?
Fui atrás. E a história é mais furada do que eu imaginava.
A origem: 12 pessoas, 1968, condições não comparáveis
O "10x" não nasceu num tweet motivacional. Ele vem de um estudo de 1968 — Sackman, Erikson e Grant, "Exploratory experimental studies comparing online and offline programming performance". Os autores compararam programadores resolvendo tarefas e encontraram diferenças de até ~20:1 no tempo entre o melhor e o pior participante em algumas métricas.
O problema está nos detalhes que quase nunca são citados junto:
A amostra tinha 12 programadores. Doze.
O objetivo do estudo nem era medir variação entre indivíduos — era comparar programação online (terminal interativo) versus offline (batch, cartão perfurado). A variação individual foi um subproduto.
Ou seja: parte dos participantes trabalhava em condições tecnológicas completamente diferentes das outras, e essa diferença acabou lida como se fosse "talento".
Uma das maiores discrepâncias saiu de comparar alguém em terminal interativo com alguém em batch — que é comparar coisas diferentes e chamar de mesma tarefa.
Fred Brooks referenciou variações de produtividade em The Mythical Man-Month. Steve McConnell defendeu o conceito em textos influentes. O folclore pegou carona nesses nomes de peso e virou dogma. Anos depois, Laurent Bossavit dedicou um capítulo inteiro do The Leprechauns of Software Engineering a rastrear a corrente de citações e mostrar como um dado frágil de 1968 foi sendo repassado de autor em autor até virar "fato consolidado" que ninguém mais checava.
Repare no padrão, porque ele é o ponto central: meio século de indústria se organizando em torno de um número extraído de 12 pessoas em condições não comparáveis — e ninguém verificou, porque o mito era conveniente. Ele entregava um herói fácil de idolatrar e uma métrica fácil de perseguir.
O que o mito media
O "10x" sempre foi medido pela lente da execução: linhas escritas, features entregues, bugs resolvidos, velocidade pura de produzir código.
E faz todo sentido que tenha sido assim. Uma indústria obcecada por output idolatra quem tem mais output. Commit é contável. Feature é demonstrável. Velocity cabe num dashboard e num relatório pra diretoria. O mito sobreviveu não porque era verdadeiro, mas porque era fácil de medir.
O detalhe é que essa métrica acabou de ser comoditizada.
Existe agora um executor que, em digitação de código, é ordens de magnitude acima de qualquer 10x: não dorme, não negocia salário, não pede home office e custa centavos por hora. Gera em minutos o boilerplate que o "10x" mais lendário levaria uma tarde pra escrever.
Se o jogo é produzir código rápido, faz tempo que o ser humano deixou de ser competitivo — e o primeiro a sentir isso é justamente quem construiu a identidade profissional inteira em cima de "eu entrego mais rápido que os outros". Ele apostou a carreira na única habilidade que a máquina replicou primeiro.
O que o mito escondia
Aqui está a parte que 20 anos de carreira me ensinaram na prática — programo desde os 11 e hoje lidero um time de devs:
O dev mais valioso de um time raramente era o que produzia mais código.
Era o que impedia o código errado de ser escrito. O que fazia na reunião a pergunta que economizava três meses de trabalho do time. O que percebia que a feature pedida não resolvia o problema real do cliente. O que sabia dizer "isso aqui a gente não deveria construir" antes de a sprint inteira ser gasta nisso.
Esse impacto nunca apareceu em métrica. Ele aparece nos lugares onde ninguém mede:
No projeto que não fracassou.
No retrabalho que não aconteceu.
Na decisão de arquitetura que evitou seis meses de dívida técnica.
Na oportunidade que foi vista a tempo.
É invisível pra métrica de execução — e é exatamente onde mora o valor difícil de substituir. A ironia é dura: passamos décadas medindo dev pela única dimensão em que ele um dia seria substituível, e ignorando a dimensão em que ele é insubstituível.
O novo múltiplo (e onde eu preciso ser honesto sobre a IA)
Aqui é onde a maioria dos textos sobre o tema descarrila, então vou tomar cuidado.
Não estou dizendo que a IA substitui dev. Estou dizendo o contrário. A IA amplifica execução de forma quase infinita, e isso joga todo o peso pro lado que ela não resolve: decidir o que construir, saber o que não construir, e — criticamente — revisar o que ela cospe.
Porque o código gerado por IA continua sendo, com frequência, medíocre ou sutilmente errado. Alucina API que não existe, ignora edge case, escreve algo que passa no happy path e quebra em produção. Quem não tem fundamento pra ler, questionar e corrigir esse output não está usando IA — está sendo pilotado por ela. Os fundamentos (arquitetura, performance, banco, segurança) não ficaram obsoletos. Eles ficaram pré-requisito: são o que te mantém no controle da ferramenta em vez de refém dela.
O que mudou é que fundamento deixou de ser o teto e virou o piso. Necessário, não mais suficiente sozinho.
O múltiplo que ainda importa mudou de natureza. Não é quem escreve 10x mais código. É quem toma a decisão certa que vale dez entregas erradas. Um executor amplificado por IA rodando em cima de uma decisão errada produz desastre em escala industrial — mais rápido e mais barato do que nunca. O mesmo executor em cima de uma decisão certa produz o que antes exigia um time. A IA não eliminou o multiplicador humano. Ela mudou o que está sendo multiplicado.
Na prática, isso mudou até como eu contrato. Código virou condição de entrada, não diferencial. O que decide hoje é leitura de negócio, comunicação, juízo diante de requisito ruim e iniciativa. Execução eu resolvo com IA. Decisão, só com gente. Eu chamo de "PowerDev" o dev que orquestra em vez de só executar — mas o nome é o de menos; o que importa é a mudança de eixo.
A parte democrática (que o mito antigo nunca teve)
O 10x da execução era vendido como dom. Ou você nascia com "o cérebro certo", ou passava a carreira correndo atrás — um clube fechado e, convenhamos, meio arrogante.
O 10x da decisão se constrói. Leitura de negócio se aprende. Critério se desenvolve errando, revisando, perguntando. Comunicação se treina. Você não precisa ser um gênio raro pra ser 10x nesse novo eixo. Precisa de algo mais barato e, ao mesmo tempo, mais difícil: parar de competir na métrica que a máquina já venceu.
O 10x developer não foi morto pela IA. Ela só revelou que aquilo media a coisa errada desde 1968.
Não escrevi isso como verdade fechada — escrevi como leitura de quem está do lado de dentro e pode estar errado em alguns pontos. Então queria discussão de verdade:
"10x" alguma vez foi métrica útil, ou sempre foi papo de gestor pra justificar folha de pagamento?
Na prática de vocês, a IA mudou mais a execução ou o tipo de skill que passou a valer numa contratação?
Quem já viu de perto: o dev que "só" fazia a pergunta certa na reunião era reconhecido nas avaliações, ou passava batido porque não dava pra medir?
E o contraponto honesto: tem gente aqui que acha que "decisão > execução" é só uma forma elegante de desvalorizar quem domina a técnica? Me convençam do contrário.