Um dólar por um milhão de linhas
Uma linha de código comum ocupa uns dez tokens num modelo de linguagem. No outono de 2026, os modelos mais baratos cobram cerca de 13 centavos de dólar por milhão de tokens gerados, então um milhão de linhas sai por mais ou menos um dólar. Um modelo a quem dá para confiar trabalho de verdade custa umas trinta vezes mais, o que ainda é o preço de um jantar a dois (capítulo “Um milhão de linhas por um dólar”).
Para comparar, em 1996 o software de voo do ônibus espacial tinha 420 mil linhas, e a equipe gastava 35 milhões de dólares por ano com ele. Dá mais de 80 dólares por linha, todo ano, enquanto o programa existir (mesmo capítulo). A diferença é de quase cem milhões de vezes, e o experimento “Escrever uma linha e mantê-la” mostra para onde ela vai.
Linhas gastas, não produzidas
Em 1988, Edsger Dijkstra sugeriu contar as linhas de código como gastas, e não como produzidas, e observou que a prática corrente as lança na coluna errada do livro-caixa (mesmo capítulo). Uma vez escrita, a linha vira uma obrigação. Alguém precisa lê-la quando algo quebra, ela precisa ser verificada a cada mudança por perto, e pode entrar em conflito com linhas que o autor nem sabia que existiam. Antes, escrever era tão caro que se esquecia o custo de manter. Agora escrever custa um dólar por milhão de linhas, e manter custa mais ou menos o que sempre custou.
Já em 1980, Manny Lehman formulou uma lei: à medida que um programa muda, a complexidade cresce e a estrutura se degrada, a menos que se gaste esforço para manter a ordem. Os modelos tendem à bagunça por um motivo simples. Achar e reaproveitar um trecho existente é caro; escrever um parecido do zero é barato. A GitClear, analisando 211 milhões de linhas, contou em 2024 oito vezes mais blocos duplicados, enquanto a parcela de código movido e reorganizado caiu de um quarto das mudanças em 2021 para menos de um décimo (mesmo capítulo). O relatório DORA de 2024 associou um aumento de 25% no uso de IA a uma queda de 1,5% na velocidade de entrega e de 7,2% na estabilidade (mesmo capítulo).
Uma mudança, sete elos
Em 1986, Fred Brooks dividiu as dificuldades da programação em acidentais, como traduzir uma ideia em código, e essenciais, a complexidade do próprio problema. Os modelos quase acabaram com as primeiras e, ao mesmo tempo, passaram a produzir complexidade acidental em escala industrial (mesmo capítulo). A complexidade essencial continuou onde estava.
No livro eu mostro isso no site de um salão de manicure. A cliente passa a poder informar vários telefones, o agente resolve em uns três minutos, e a mudança mexe no esquema de dados, na migração, na lógica, nas integrações com outros programas, nas permissões, nas telas e nos testes. O agente mexeu em dois elos de sete (capítulo “Mudar uma coisa sem quebrar tudo”). Dá para percorrer a cadeia no experimento “Sete elos por trás de um telefone”. O engenheiro do Google Hyrum Wright observou que, com usuários suficientes, alguém vai depender de qualquer comportamento observável do programa, prometido ou não (mesmo capítulo).
A ilustração mais cara veio em 1º de agosto de 2012. A Knight Capital reaproveitou a chave de um código antigo chamado Power Peg, instalou a versão nova em sete de oito servidores e, em quarenta e cinco minutos, o sistema mandou ao mercado mais de quatro milhões de ordens. A empresa perdeu mais de 460 milhões de dólares (mesmo capítulo). Dá para viver isso no experimento “Os quarenta e cinco minutos da Knight Capital”. Daí a fórmula que considero central no livro inteiro: escrever ficou quase de graça, e não escrever o que sobra virou uma habilidade cara. Como se chega lá pelo vibe coding está na resposta sobre vibe coding.
