Garry Tan, el presidente de Y Combinator, confesó algo esta semana que casi nadie con su perfil admite en público.

En enero volvió a programar y construyó una aplicación en Rails. Más de 540 mil líneas, con las pruebas para vigilarlas. Estaba orgulloso. Y escribió que no debía estarlo.

La imagen que usó para describir lo que hizo es la que me dejó pensando toda la semana: construyó una fábrica Foxconn para un trabajador de IA. Barreras de seguridad, ciclos de reintento, validadores, una jaula de control atornillada encima de una inteligencia que ya podía hacer el trabajo, y mil cosas más que nadie le pidió.

Lo cuento porque reconozco a ese ingeniero. Lo reconozco porque fui ese ingeniero, en cinco épocas distintas. Y la tesis de este post es incómoda: durante décadas, más código fue más capacidad. Esa ecuación se acaba de invertir, y la mayoría seguimos construyendo como si no.

Durante 36 años, más código fue más poder

Llevo desde 1990 en esto, desde los quince años frente a un Commodore 64 con 64 KB de memoria que había que defender byte por byte. Y si algo aprendí en cada salto de la industria, fue una regla que nunca falló: la capacidad se mide en código. Más líneas, más funcionalidad, más poder. El ingeniero que escribía más, hacía más.

Esa regla fue correcta durante mucho tiempo. Cuando la memoria era cara, escribías código apretado para caber. Cuando el cómputo era caro, escribías código para racionarlo. Cuando los servicios eran caros de llamar, envolvías cada llamada en capas de software que la protegían. El instinto era siempre el mismo: el recurso valioso está del otro lado, así que construye alrededor para cuidarlo.

Tan se describe a sí mismo como un ingeniero de 2013 lanzado a 2026, construyendo de la única forma que sabía. Es una buena descripción, pero le falta la mitad. No es un ingeniero de 2013. Es el instinto de toda una carrera, el mío incluido, que dice que capacidad y líneas de código son la misma cosa. Ese instinto fue verdad durante 36 años. Lo que pasó es que dejó de serlo, y el cuerpo todavía no se entera.

Qué es una fábrica Foxconn de código

Tan hizo la cuenta de su propia aplicación, y vale la pena mirarla. De sus 540 mil líneas, unas 262 mil eran de aplicación. Las otras 276 mil eran pruebas para vigilar a esas 262 mil. El comité de auditoría era más grande que la empresa que auditaba.

¿Qué hacían esas 276 mil líneas? Sanitizadores revisando entradas que el modelo ya manejaba. Validadores revisando salidas que el modelo ya atrapaba. Ciclos de reintento envolviendo llamadas de las que el modelo se recupera solo. Tan lo dice con una frase que se siente en el estómago: cada una de esas líneas es una apuesta a que el trabajador va a fallar. Y él hizo esa apuesta cientos de miles de veces, contra un trabajador que cumplía.

Esto es lo nuevo, y es lo que casi nadie está viendo. El desperdicio de 2026 no es escribir muy poco código. Es escribir código defensivo alrededor de un modelo que no lo necesita, y llamarlo rigor de ingeniería. Camina por tu propia base de código y cuenta las líneas que existen solo porque no confiaste en el modelo. Vas a encontrar más de las que esperas.

Y no es solo código. Son los tableros que nadie abre el segundo lunes, las 33 tareas programadas que son 33 alarmas para un trabajador que ya llega temprano, los procesos de aprobación que duplican una revisión que el modelo ya hace. Toda esa infraestructura se siente como control. Casi siempre es una jaula.

El nuevo desperdicio no es escribir poco, es vigilar de más

La razón del cambio es económica, y es la parte que el instinto de 36 años no procesa. Antes el modelo era caro y el código barato, así que escribías mucho código para racionar al modelo, para llamarlo con cuidado y pocas veces. Hoy las dos mitades de esa ecuación se invirtieron. El modelo es barato, se abarata cada trimestre, y es lo bastante capaz como para escribir el código él mismo. Así que dejas de escribir código para vigilarlo. Lo instruyes en lenguaje natural y dejas que escriba el mínimo código que de verdad hace falta.

Tan le pone nombre a la unidad nueva: el skillpack. No es un prompt suelto, que se evapora. Es instrucción en markdown, más el código mínimo que necesita, más pruebas unitarias y de integración. Eso último es lo que importa. Las pruebas son lo que separa un skillpack del vibe coding: el vibe coding es una sensación sin cobertura, el skillpack tiene pruebas que lo dejan cambiar sin romperse. La instrucción vive en un lenguaje que puedes editar, no en lógica congelada el día que la escribiste.

Hace un mes escribí, desde otro ángulo, que el runtime se había vuelto un commodity y el moat (ventaja competitiva) era el flujo de trabajo que construías encima. Esto es el escalón siguiente, y es más incómodo: no se trata solo de que el moat subió. Se trata de que, mientras subía, tú probablemente seguiste atornillando barrotes. La pieza que ya escribí sobre que el código no es barato apuntaba a lo mismo desde la contabilidad: cada línea es un pasivo que alguien mantiene. La línea defensiva que no hacía falta es el pasivo más caro de todos, porque te cuesta escribirla, te cuesta mantenerla, y encima frena al trabajador que querías ayudar.

Lo que hacemos en IQ Source con esto

Cuando entramos a una operación que ya metió IA, la mitad de lo que se presenta como rigor resulta ser jaula. Validadores que repiten lo que el modelo ya hace. Tableros que nadie lee. Ciclos de reintento que esconden un prompt mal escrito en vez de arreglarlo. Todo eso se construyó con buena intención, y todo eso hay que mantenerlo para siempre.

El trabajo concreto es separar la baranda de la jaula. Una baranda sostiene peso: es la validación en el límite donde el dato entra al sistema, el control que evita que un agente borre algo que no se recupera, la prueba que protege una decisión de negocio de verdad. Una jaula solo da sensación de control: es la línea que existe porque alguien, en algún momento, no confió. AI Maestro es el discovery donde se hace esa distinción proceso por proceso, antes de seguir construyendo encima. Y Socio Tecnológico es el rol que mantiene esa decisión viva cuando el sistema ya corre en producción, porque la jaula vuelve a crecer sola si nadie la poda.

John Sjölander resumió la otra cara de esto en una sola línea sobre el texto de Tan: el recurso escaso pasó a ser la claridad, el gusto y el criterio, y el ingeniero que escribe menos código suele ser el que más construye. Es verdad, y es difícil de tragar para cualquiera que aprendió a medir su valor en líneas. Yo aprendí así. Tan aprendió así. La buena noticia es que el oficio no desaparece, se muda: del que escribe más al que sabe qué no escribir.

Así que antes de tu próxima revisión de arquitectura, hazte una sola pregunta sobre tu propio sistema. Si quitaras hoy todo el código que existe solo porque no confías en el modelo, ¿qué quedaría, y seguiría funcionando? Si la respuesta te incomoda, no construiste una aplicación. Construiste una fábrica de vigilancia alrededor de un trabajador que ya sabía hacer el trabajo.

Separa la baranda de la jaula en tu operación de IA