Cuando los LLMs generen miles de tokens por segundo, lo que importa no será el código

La semana pasada hice un experimento. Cogí un microservicio de logística que lleva muchos años en producción, un servicio que nadie quiere tocar porque el ingeniero que lo diseñó ya no está y la documentación es, siendo generosos, incompleta. Le pedí a un agente que lo regenerara desde cero usando solo los tests existentes y la especificación de contratos.

El agente generó código. Razonable, con fallos. Pero lo interesante fue lo que descubrí que faltaba. Los tests cubrían el camino feliz. Los contratos definían entradas y salidas, pero no las invariantes de negocio que el equipo había ido descubriendo durante años: las reglas de priorización en picos de demanda, los umbrales de reintento que alguien ajustó después de un incidente y nunca formalizó. Todo eso vivía en la cabeza de dos personas. No en ningún artefacto.

El agente pudo regenerar las células. Pero no tenía el ADN.

El informe DORA 2025 de Google confirma que esto no es anecdótico: la IA ya mejora la velocidad de entrega, pero sigue correlacionando con mayor inestabilidad. Su conclusión es brutal en su claridad: la IA no arregla un equipo, amplifica lo que ya hay. Equipos con buen ADN mejoran. Equipos con ADN incompleto se rompen más rápido.

La velocidad de inferencia de los LLMs va a convertir el código en material desechable y regenerable. Pero si no cambias tu modelo de trabajo, esa velocidad no te salva: te entierra. Lo que sobrevive no es la implementación, sino la información que permite reconstruirla. El futuro del ingeniero de software no es escribir código. Es escribir ADN.

Lo que viene (y por qué cambia todo)

Todo lo que acabo de describir ocurre hoy, con modelos que generan entre 50 y 200 tokens por segundo. Con latencias perceptibles. Con ventanas de contexto que aún se quedan cortas.

Pero lo que viene es otra cosa. En local, con hardware dedicado y modelos optimizados, ya se superan los 17.000 tokens por segundo. Los nuevos chips están empujando el coste por token hacia abajo a una velocidad brutal. Y estos números se van a democratizar, como se democratizó el compute, el storage y el bandwidth antes.

Piénsalo así. Hoy un agente tarda minutos en generar un módulo. Con miles de tokens por segundo, tarda segundos. Estamos hablando de que generar una implementación desde cero sea más rápido que leer la implementación existente para entender si está bien.

Las consecuencias ya se ven. Paul Ford ya hizo el ejercicio: proyectos que en 2021 costaban 350.000 dólares los construyó él solo en un fin de semana por 150 dólares con Claude Code. Y lo que yo veo en mis equipos es coherente: escribir código se está convirtiendo en la parte fácil. Lo difícil es saber qué escribir, por qué, y cómo saber si está bien.

Si regenerar es más barato que mantener, la estrategia racional no es cuidar el código. Es hacer que sea desechable por diseño. Y desplazar toda la inversión hacia lo que no es desechable: los contratos, los tests, las invariantes de negocio, las evaluaciones, los SLAs.

Apoyo a siete equipos en la división online de una de las mayores empresas de distribución de España. Y ya he visto lo que pasa cuando un equipo mete agentes sin haber mejorado sus tests ni sus contratos: un codebase más grande que entiende menos gente. Lo he visto más de una vez. A escala de millones de operaciones diarias, eso no es un problema teórico. Es un incidente esperando su turno.

Chad Fowler lo llama software regenerativo: sistemas diseñados para arder y renacer sin perder su identidad. Me gusta la metáfora del fénix, pero creo que hay una más precisa.

No escribas células. Escribe ADN.

Las células de tu cuerpo se reemplazan constantemente. Lo que persiste es la información que dice cómo reconstruirlas. El software está entrando en la misma dinámica: el código (las células) va a ser cada vez más barato de generar, de descartar y de regenerar. Lo que define la identidad del sistema es la información que permite reconstruirlo correctamente: los contratos, las evaluaciones, las invariantes de negocio, los mecanismos de feedback. Eso es el ADN de tu software.

En el modelo clásico, el código era el activo. Toda una industria (estimaciones, code reviews, sprints, retrospectivas) existe porque escribir código era caro y peligroso de reemplazar. En el modelo que viene, el código son células consumibles. Lo que importa es el ADN: la información verificable que permite que la regeneración produzca un organismo sano y no un tumor.

Porque eso es lo que pasa cuando generas código sin ADN. Es mutación sin selección natural. Más código, más rápido, sin mecanismo que distinga lo correcto de lo incorrecto. Y la mutación acelerada sin selección no produce evolución. Produce enfermedad. Eso es exactamente lo que muestran los datos DORA: más velocidad, más inestabilidad.

Vuelvo a mi experimento. ¿Por qué el agente no pudo regenerar el servicio de forma fiable? No por limitaciones del modelo. Sino porque el ADN estaba incompleto. No había contratos que dijeran "en picos de demanda, la priorización sigue estas reglas, no estas otras". Todo eso lo sabía el equipo. Nada de eso estaba escrito de forma que una máquina (o un ingeniero nuevo) pudiera usarlo.

Después de ese experimento, empecé a hacer un ejercicio que llamo "el test de la regeneración": si mañana tuviera que regenerar este servicio desde cero, ¿qué porcentaje del comportamiento correcto sobreviviría solo con los artefactos que tengo? Sin contar lo que sabe la gente.

Las tres capas del ADN

He empezado a pensar en el ADN de un sistema como algo con estructura. No es un bloque monolítico. Son tres capas de expresión, cada una con una función distinta (y cada una conecta con una capa de verificación diferente):

Lo que el sistema hace. Tests de comportamiento, contratos de API, specs de entrada/salida. Es el ADN que se expresa siempre, en cada regeneración. La capa que más equipos tienen razonablemente cubierta.

Cómo lo hace bien. Límites de rendimiento, estándares de resiliencia, políticas de reintentos, umbrales de degradación graceful. Es el ADN que se expresa bajo condiciones específicas: cuando hay carga, cuando falla un servicio downstream, cuando el sistema opera en los bordes. Aquí es donde la mayoría flaquean.

En mi experimento, esto fue exactamente lo que falló: había una regla de reintentos ajustada manualmente después de un incidente. La convertí en un test de propiedad parametrizado. Tardé una tarde. Esa tarde valió más que semanas de código generado, porque ahora esa regla sobrevive a cualquier regeneración. Eso es engrosar el ADN.

Por qué lo hace así. Las decisiones de negocio que condicionan el diseño. Los acuerdos entre equipos que no están en ningún ADR. Las heurísticas que alguien aprendió después de un incidente a las tres de la mañana. Es el ADN regulador: no codifica comportamiento directamente, pero determina cuándo y cómo se expresan las otras capas. Es la capa más valiosa y la más invisible. Es la que Plumbline, un experimento open-source de verificación, intenta hacer explícita y verificable.

No voy a fingir que tengo esto resuelto. Llevo meses dándole vueltas y lo que tengo son más preguntas que respuestas. Pero las preguntas me parecen las correctas.

Y alguien dirá: "esto suena a waterfall disfrazado". No. No estoy proponiendo secuenciar el ADN completo antes de empezar. Estoy proponiendo ser honesto sobre cuánto de lo que llamamos "conocimiento tácito" es genuinamente incodificable y cuánto es, simplemente, pereza de documentación. Esa regla de reintentos no era tácita. Era una decisión explícita que nadie se molestó en convertir en artefacto. En mi experiencia, la mayoría del conocimiento que los equipos consideran "tácito" es en realidad conocimiento explícito que nunca se formalizó. Lo genuinamente tácito existe, pero es una fracción menor de lo que nos gusta creer.

La pregunta que separa dos futuros

Hay dos caminos, y los dos están ocurriendo ahora mismo.

El primero: usar la IA para lo que yo llamo mecanografía glorificada: escribir código más rápido. Más código, más features, más velocidad. Mutación acelerada sin selección. Los datos DORA nos dicen cómo acaba: sistemas más frágiles, la ilusión de productividad sin los resultados.

El segundo: cambiar el modelo mental. Tratar el código como células descartables. Invertir en el ADN: evaluaciones, contratos, definiciones de sistema. Hacer que la regeneración produzca organismos sanos.

He mentorizado a muchos ingenieros, y lo que veo es que esta transición está redefiniendo qué significa ser senior. Los que siguen definiendo su valor por la calidad de su código se están encontrando con que un agente produce código comparable en una fracción del tiempo. Los que definen su valor por su capacidad de juzgar si un sistema es correcto, de formalizar invariantes que nadie ha escrito, de anticipar modos de fallo, esos están en una posición que se refuerza con cada mejora del modelo. Y para los juniors el camino no ha desaparecido, ha cambiado de eje: de "aprende a escribir código limpio" a "aprende a definir qué significa que un sistema funcione correctamente".

No me fío de este argumento como garantía. He estado equivocado antes sobre cómo iba a evolucionar esta industria, y es posible que lo esté ahora. Pero ya no es una reflexión teórica para mí. Es algo que estoy probando cada semana con mis equipos, y de momento los datos me dan la razón más que me la quitan.

Llevo años diciendo que el código es un medio, no un fin. Ahora esa idea tiene consecuencias concretas: si el código es un medio, trátalo como tal. Hazlo desechable. Invierte en lo que lo rodea, lo define y lo verifica. No escribas células. Escribe ADN.

Pregunta para ti: Haz el test de la regeneración con un servicio de tu equipo. Si mañana tuvieras que regenerar todo el código desde cero, con solo los tests y la documentación que tienes hoy, ¿qué porcentaje del comportamiento correcto sobreviviría? No el que crees. El que puedes demostrar.

Me encantaría saber qué número te sale.