Un dólar por un millón de líneas
Una línea de código común ocupa unos diez tokens en un modelo de lenguaje. En el otoño de 2026, los modelos más baratos cobran unos 13 centavos de dólar por millón de tokens generados, así que un millón de líneas sale por más o menos un dólar. Un modelo al que se le puede confiar trabajo de verdad cuesta unas treinta veces más, que sigue siendo el precio de una cena para dos (capítulo “A Million Lines for a Dollar”).
Para comparar, en 1996 el software de vuelo del transbordador espacial tenía 420.000 líneas, y el equipo gastaba 35 millones de dólares al año en él. Son más de 80 dólares por línea, cada año, mientras el programa exista (mismo capítulo). La diferencia es de casi cien millones de veces, y el experimento “Escribir una línea y mantenerla” muestra adónde se va.
Líneas gastadas, no producidas
En 1988, Edsger Dijkstra propuso contar las líneas de código como gastadas y no como producidas, y señaló que la práctica habitual las anota en la columna equivocada del libro contable (mismo capítulo). Una vez escrita, la línea se vuelve una obligación. Alguien tiene que leerla cuando algo se rompe, hay que revisarla cada vez que cambia algo cerca, y puede chocar con líneas que su autor ni sabía que existían. Antes escribir era tan caro que se olvidaba el costo de mantener. Ahora escribir cuesta un dólar por millón de líneas, y mantener cuesta más o menos lo de siempre.
Ya en 1980, Manny Lehman formuló una ley: a medida que un programa cambia, su complejidad crece y su estructura se degrada, salvo que se invierta esfuerzo en mantener el orden. Los modelos tienden al desorden por una razón simple. Encontrar y reutilizar un fragmento existente es caro; escribir uno parecido desde cero es barato. GitClear, tras analizar 211 millones de líneas, contó en 2024 ocho veces más bloques duplicados, mientras la parte del código que se movía y reorganizaba bajó de un cuarto de los cambios en 2021 a menos de una décima (mismo capítulo). El informe DORA de 2024 relacionó un aumento del 25 % en el uso de IA con una caída del 1,5 % en la velocidad de entrega y del 7,2 % en la estabilidad (mismo capítulo).
Un cambio, siete eslabones
En 1986, Fred Brooks dividió las dificultades de la programación en accidentales, como traducir una idea a código, y esenciales, la complejidad del problema mismo. Los modelos casi eliminaron las primeras y, al mismo tiempo, empezaron a producir complejidad accidental a escala industrial (mismo capítulo). La complejidad esencial sigue en su lugar.
En el libro lo muestro con el sitio de un salón de manicura. A la clienta se le permite dar varios teléfonos, el agente lo resuelve en unos tres minutos, y el cambio toca el esquema de datos, la migración, la lógica, las conexiones con otros programas, los permisos, las pantallas y las pruebas. El agente tocó dos eslabones de siete (capítulo “Change One Thing Without Breaking Everything”). La cadena se puede recorrer en el experimento “Siete eslabones detrás de un teléfono”. El ingeniero de Google Hyrum Wright observó que, con suficientes usuarios, alguien dependerá de cualquier comportamiento observable de un programa, prometido o no (mismo capítulo).
La ilustración más cara llegó el 1 de agosto de 2012. Knight Capital reutilizó el interruptor de un código viejo llamado Power Peg, instaló la versión nueva en siete de ocho servidores y, en cuarenta y cinco minutos, el sistema envió al mercado más de cuatro millones de órdenes. La empresa perdió más de 460 millones de dólares (mismo capítulo). Puede vivirlo en el experimento “Los cuarenta y cinco minutos de Knight Capital”. De ahí la fórmula que considero central en todo el libro: escribir se volvió casi gratis, y no escribir lo que sobra se volvió una habilidad cara. Cómo se llega ahí por el vibe coding se explica en la respuesta sobre vibe coding.
