Nota del editor: Mientras cada vez más personas debaten '¿La IA reemplazará a los programadores?', el presidente de YC, Garry Tan, plantea en realidad otra pregunta: si la IA ya es capaz de realizar la mayor parte del trabajo de programación, ¿por qué seguimos gestionándola como gestionamos el software tradicional?

A principios de este año, Garry Tan pasó varios meses escribiendo un proyecto llamado Garry's List utilizando Rails y un Agente de IA, que alcanzó las 540 mil líneas de código. Una vez finalizado el proyecto, llegó a una conclusión aparentemente contradictoria: esas 540 mil líneas de código en sí mismas no son lo importante; lo verdaderamente valioso fue el GStack, un nuevo marco de desarrollo construido en torno a flujos de trabajo de Agentes de IA, que se cristalizó durante el proceso de desarrollo.

En su opinión, en los últimos años la industria del software ha desarrollado una inercia colectiva: los desarrolladores añaden constantemente pruebas, validadores, mecanismos de reintento, tareas en segundo plano y toda clase de lógica de control, envolviendo al modelo en capas. Este enfoque tenía sentido en una época en la que los modelos eran caros y sus capacidades limitadas, pero cuando los LLM ya son capaces de realizar gran parte del trabajo de forma autónoma, estos sistemas se asemejan más a construir una 'fábrica de Foxconn' para un trabajador superinteligente: imponer una gran cantidad de reglas y procesos para restringir a una entidad inteligente que ya es competente.

A medida que el coste de los modelos disminuye rápidamente y sus capacidades continúan mejorando, el foco del desarrollo de software quizás esté cambiando de 'escribir más código' a 'diseñar más capacidades'. El autor propone construir "skill packs" (paquetes de habilidades, módulos de capacidad reutilizables y testables) usando Markdown, permitiendo que el Agente genere automáticamente código, pruebas y sistemas de evaluación, convirtiendo flujos de trabajo complejos en activos de capacidad compuestos y reutilizables. Incluso muestra un ejemplo: lo que antes era un trabajo de revisión para un hackathon que llevaba días, ahora puede ser completado por un Agente en cuestión de minutos.

En cierto sentido, este artículo no trata sobre programación, sino sobre el fin de la lógica de la industrialización del software. Cuando el código deja de ser el recurso más escaso, la ventaja competitiva central de los ingenieros también comienza a cambiar: en lugar de escribir más código, juzgar qué vale la pena construir, cómo definir los problemas y cómo cristalizar la experiencia en capacidades reutilizables se está volviendo más importante. La conclusión final del autor es: los mejores ingenieros del futuro pueden no ser los que escriben más código, sino los que escriben menos, pero son capaces de liberar la mayor inteligencia.

A continuación, el texto original:

En enero de este año, volví a programar y creé Garry's List. El código en Rails más las pruebas para constreñirlo suman más de 500 mil líneas.

En su momento, me sentí muy orgulloso de ello. Pero no debería. Lo verdaderamente digno de orgullo no era esa aplicación, sino la forma de trabajar que fui descubriendo al construirla. GStack, mi forma de programar con Agentes, creció precisamente durante la creación de Garry's List. Más tarde lo hice open source. Ahora está entre los 100 proyectos open source más destacados (con más 'stars') en la historia de GitHub, alcanzando unas 105 mil estrellas en menos de tres meses.

Esas 500 mil líneas de código eran el 'producto'. Ese modo de trabajo era el 'subproducto'. Y lo verdaderamente importante, es ese subproducto.

Entonces, ¿qué son esencialmente 540 mil líneas de código construidas alrededor de un LLM?

Son una fábrica de Foxconn. Una fábrica construida para un trabajador de IA altamente inteligente. Un trabajador que ni siquiera necesita ser supervisado de cerca, pero para el que la construimos igualmente.

Hay que ponerse cubrezapatos para entrar. Levantarse a las 6 de la mañana. Hacer gimnasia colectiva. Pararse día tras día en la misma línea de montaje. Una vida tan difícil que cada edificio alto necesita redes de seguridad porque... esa no es una vida que uno quiera vivir. Cada prueba, cada barandilla de protección, cada ciclo de reintento, es otro centímetro de jaula atornillada sobre este trabajador. Y este trabajador podría haber completado este trabajo por sí mismo, e incluso mil cosas más que ni siquiera habías imaginado.

Tanto los humanos como los Agentes tienen un potencial infinito, pero la lógica de la fábrica de Foxconn es extraer intelecto y trabajo de vidas que podrían ser hermosas. Podrían hacer este trabajo, incluso mil veces más, si tan solo les permitiéramos hacerlo.

Yo construí una de esas fábricas. Casi todo el mundo lo está haciendo hoy. Y ahora quiero decirte: deja de hacerlo.

El viajero en el tiempo

Lo que realmente demostré con 539 mil líneas de código, es que puedo fingir perfectamente ser un viajero en el tiempo.

Un ingeniero Web 2.0 de 2013, que era la última vez que realmente me consideré un ingeniero de software, arrojado al 2026, con herramientas modernas en sus manos, pero que aún construye software de la única manera que conoce: más código. Siempre más código.

Las herramientas han cambiado, pero mi instinto no.

El ingeniero de 2013 cree en lo más profundo que: capacidad es igual a líneas de código. Esta creencia fue cierta durante las últimas décadas, hasta hoy.

Si me das Codex o Claude Code, puedo hacer el trabajo de 100 o incluso 1000 ingenieros. Pero sigue siendo el mismo mapa, solo que con un motor más rápido, conduciendo a toda velocidad hacia un destino que ahora es incorrecto.

Esta es precisamente la posición en la que se encuentran casi todos los constructores de IA en la actualidad. Han mejorado sus herramientas, pero conservan el modelo mental de 2013.

Esta trampa no parece una trampa, porque el código sí funciona. Garry's List sí se lanzó. Ese mes, sentí que estaba experimentando la etapa más productiva de mi vida.

Pero era una productividad al servicio de una idea obsoleta.

Los LLM solían ser caros, así que tuvimos que 'domesticarlos'

La vieja economía hasta alrededor de 2025 era: las llamadas a LLM son caras, y el código es barato.

Así que escribías código para ahorrar llamadas al modelo, para restringirlo, domesticarlo, invocarlo con cuidado. La arquitectura de entonces era: envolver unas pocas y preciadas llamadas al modelo con mucho software.

Pero ambos lados de esta ecuación se han invertido.

Los modelos se están abaratando, y cada trimestre son más baratos. Al mismo tiempo, los modelos son lo suficientemente inteligentes; la relación valor-coste ha dado la vuelta. Los modelos también pueden escribir código utilizable.

Así que ya no necesitas escribir código para 'vigilar' al modelo. Puedes decirle al modelo en lenguaje natural qué hacer, y luego dejar que genere solo el código mínimo realmente necesario.

Esto es "software just-in-time" (software de generación instantánea), y estamos entrando en su edad de oro.

La forma del artefacto de software también ha cambiado radicalmente. Esa aplicación Rails eran 540 mil líneas de código que yo escribí y poseía, más las pruebas para supervisarla. Su sustituto es un Agente construido con Markdown y una pequeña cantidad de código, de una fracción del tamaño.

Misma capacidad. Más fácil de leer. Más fácil de mantener. Y mucho más flexible. Porque el comportamiento reside en instrucciones que puedes editar en lenguaje natural, no congelado en código lógico que escribiste un día.

Solíamos escribir código para cuidar de algo, pero ahora ese algo es más inteligente que ese código.

Dentro de la fábrica Foxconn: incluso con las redes de seguridad instaladas

Si has estado escribiendo código últimamente, es probable que hayas estado construyendo este tipo de fábrica sin darte cuenta.

Puedes adentrarte en tu base de código y contar cuántas líneas existen solo porque no confías en que el modelo pueda hacer su trabajo. En mi base de código, había aproximadamente 262 mil líneas de código de aplicación, y unas 276 mil líneas de pruebas para supervisarlo. El comité de auditoría era más grande que la propia empresa.

Algunos limpiadores revisan entradas que el modelo podría haber procesado. Algunos validadores revisan salidas que el modelo podría haber detectado. Algunos bucles de reintento envuelven llamadas al modelo, cuando el modelo ya podría recuperarse por sí solo. Cada línea de ese código es una apuesta: este trabajador fallará.

Tú también has hecho apuestas similares. Todos lo hemos hecho.

127 tareas en segundo plano, 33 de ellas programadas. Esto no es capacidad, son 33 alarmas configuradas para un trabajador LLM que ahora suele llegar puntual.

En aquellos días en que construía la 'fábrica Foxconn', Claude y yo escribimos un archivo de 1778 líneas. Su único propósito era cuestionar los hechos proporcionados por el modelo.

Descomponía cada afirmación hecha por el modelo, la enviaba en paralelo a cinco fuentes diferentes para verificación, y luego la puntuaba. Las afirmaciones simples pasaban primero por un umbral de triaje ligero, para evitar que todo pasara por el flujo completo. Si la primera ronda no daba resultados, se reintentaba. Y luego había planes de respaldo para los planes de respaldo.

En un episodio de Rick and Morty, Rick construye un pequeño robot en la mesa del desayuno. El robot se activa, mira hacia arriba y pregunta: ¿Cuál es mi propósito? Rick dice: Pasas la mantequilla. El robot empuja el platillo de mantequilla, mira sus manos y dice: Oh, Dios mío. Y luego se queda sentado allí. Ese robot también tenía un potencial infinito. Fue construido para pasar la mantequilla. Mis 276 mil líneas de pruebas son ese platillo de mantequilla.

Cuando construyes software con el método de 'fábrica Foxconn' estilo 2023, estás construyendo una jaula. Si no tienes cuidado, tú mismo te conviertes en el guardián de esta prisión de Agentes de IA.

Ahora Markdown es el programa

Cuando digo Markdown, no me refiero a un prompt.

Un prompt es efímero. Escribes una frase, obtienes un resultado, y luego se evapora.

Me refiero a construir. Es construcción versionada, testeable y reutilizable.

Markdown es la capa de instrucción: intención, habilidades, juicio, y especificaciones sobre cómo se debe realizar el trabajo. TypeScript es solo una fina capa de lógica determinista. Se encarga únicamente de las pocas cosas que realmente deben hacerse con código: E/S, y aquellas partes que absolutamente no pueden alucinar.

Lo más importante, debes probar el Markdown como pruebas el código.

En mi sistema, este ciclo requiere solo una palabra: "skillify it" (conviértelo en habilidad).

Primero hago que algo funcione junto con el Agente, hasta que lo logra. Luego digo: "skillify it". Entonces el Agente escribe:

Las especificaciones de la habilidad en Markdown;

El código mínimo que necesita;

Pruebas unitarias para ese código;

Una evaluación LLM de la habilidad;

Pruebas de integración que cubren la habilidad y el código;

Un "resolver" (resolutor) para que el Agente invoque automáticamente esta habilidad en escenarios relevantes;

Y una evaluación para ese resolutor en sí mismo.

Todo este conjunto es un "skill pack" (paquete de habilidades). Es una unidad de capacidad reutilizable que se compone continuamente.

Lo verdaderamente mágico son las pruebas: la cobertura de la habilidad le permite evolucionar sin romperse. Esta es la diferencia con el "vibe coding" (programar por vibra/instinto). El "vibe coding" es solo sensación, un "skill pack" tiene pruebas.

Recién estamos empezando a explorar en tiempo real los primitivos sistémicos de la ingeniería de Agentes, como inventar la pila, el montón, los registros y la arquitectura de Von Neumann en los primeros días de la CPU.

Creo que el "skill pack" es uno de esos primitivos. El "harness" (marco de ejecución) es otro.

La mayoría de la gente aún no se da cuenta, porque todavía miden el software por líneas de código.

Realmente puedes construir cosas locas

Este no es un argumento de juguete.

Lo que este Agente puede hacer ya supera a esa aplicación Rails de 500 mil líneas, y el código nuevo añadido es solo una fracción.

Pongamos un ejemplo concreto: la revisión de un hackathon.

Un sábado hace dos semanas, organizamos un hackathon de GStack/GBrain, con 85 proyectos presentados. Subí el Google Drive con todos los proyectos y dije: Empieza.

El Agente analizó la calidad del código de cada repositorio, realizó una investigación profunda de cada participante, vio y capturó pantallazos de cada video demo, puntuó las interfaces y clasificó a los 85 equipos. Finalmente, me dijo cuáles eran las 5 aplicaciones más notables del lote.

Revisar un hackathon, que solía ser un trabajo arduo de varios días, ahora se convirtió en algo de unos 30 minutos.

Yo no escribí código. Dejé que OpenClaw hiciera la tarea, yo me encargué de guiarlo. Cuando terminó, dije: skillify it.

Así se convirtió en un tarball que cualquiera puede reutilizar para siempre, aplicable a cualquier hoja de cálculo de hackathon.

Ahora digo "skillify" casi todos los días. Ya tengo más de 350 skill packs. Casi cualquier tarea que necesito manejar, tanto personal como profesionalmente, ahora mi Agente puede hacerla.

Este es un ejemplo de la inversión.

En el pasado, una capacidad así habría sido un proyecto de software real: necesitaba rastreadores web, canalizaciones de puntuación, procesamiento de video, módulos de investigación, sistemas de clasificación. Ahora, se convierte en Markdown más un poco de código, construido por un Agente en una tarde, y reutilizable por todos.

Por cierto, el ganador de ese hackathon sí escribió un código que finalmente pulí y fusioné en la rama main. Ahora GStack puede probar aplicaciones iOS tanto en simulador como en dispositivos reales, y esta funcionalidad completa la hizo una persona en menos de 8 horas durante el hackathon.

Tokenmaxxing (Maximización de Tokens)

Hay un boleto de entrada aquí, pero casi nadie quiere pagarlo: debes estar dispuesto a gastar dinero en tokens.

Peter Steinberger creó OpenClaw, mi 'harness' favorito. Él ha dicho que estaría dispuesto a gastar alrededor de 1 millón de dólares al año en tokens.

La mayoría de la gente retrocede ante esa cifra. Pero no deberían, porque aquí está el oro: si estás dispuesto a hacerlo, puedes vivir en 2028. Y a los demás les llevará años ponerse al día.

Esta es también la razón por la que OpenAI decidió ofrecer 2 millones de dólares en créditos de tokens a cada empresa de YC, en forma de SAFE sin límite (uncapped).

Cuando puedes convertir inteligencia cruda en tokens, y luego convertir tokens en resultados realmente utilizables por los usuarios, que resuelven necesidades reales y por los que los usuarios están dispuestos a pagar, sucede algo mágico.

Si eres un fundador, deberías maximizar esta capacidad. Por eso insisto tanto en "skillify", porque es un método que realmente produce buenos resultados.

En una era pasada, siempre pensábamos que las llamadas a LLM eran demasiado caras, que teníamos que racionarlas. Siempre estuvimos racionando, es decir, distribuyéndolas con cuentagotas.

Pero ahora, es precisamente este instinto el que está frenando a la gente.

Si estás dispuesto a hacer 'tokenmax', a dejar que el Agente consuma tokens libremente y funcione continuamente, obtienes una ventaja de pionero similar a los primeros días de internet en 1994, solo que el coste esta vez se paga en tokens.

Esto mantendrá fuera al 99,99% o más de las organizaciones que aún están contando los centavos de un recurso cuyo precio se está derrumbando, entregando la ventaja de liderazgo a los pocos que realmente lo entienden.

Por decenas de miles de dólares al año, o incluso menos para algunos, puedes operar hoy de la manera en que el mundo entero tendrá que operar dentro de unos años.

Puedes vivir en 2026 como si fuera 2028. Esta inversión anticipada vale la pena. Porque 10.000 dólares en tokens hoy pueden costar 1.000 dólares el próximo año, 100 dólares al año siguiente, y tal vez 10 dólares para finales de 2028.

Si le dijeras a cualquier emprendedor en la historia: puedes invertir un capital de seis cifras para entrar dos o tres años antes en el futuro, y mantener esa ventaja durante años, de 100 fundadores cualificados, 100 aceptarían el trato.

Lo único que se interpone es ese instinto de 2013: te dice que las llamadas al modelo son demasiado caras, no puedes usarlas libremente.

Pero ya no son caras. Esa es la vieja economía. La inversión ya ha ocurrido.

Esalen, no Foxconn

Si 540 mil líneas de código de control son construir una fábrica Foxconn para el trabajador, entonces la solución es construir lo opuesto.

Hay un lugar en los acantilados de Big Sur llamado Esalen. La gente va allí para ser desarmada, remodelada, soltar sus armaduras y regresar siendo más ellos mismos.

Sin líneas de montaje. Sin capataces. Sin silbatos a las 6 de la mañana. Es libertad, no control.

Construye algo así.

Construye un lugar como YC: donde te ayudamos a crear empresas, resolver problemas reales, encontrar el ajuste producto-mercado.

Construye lugares que liberen a los trabajadores, sean estos humanos o IA.

Este es el núcleo de todo.

Haz cosas que liberen a los Agentes. Haz empresas que liberen el potencial humano.

En el trabajo del conocimiento, la fábrica es el modo de fracaso. El verdadero objetivo es crear instituciones que liberen a las personas. Ahora, ese objetivo también apunta a los Agentes.

OpenClaw es como un Ferrari al que debes traer tus propias herramientas. El modelo es el motor, no el coche completo. Todavía estamos en el momento Apple I, soldando placas de prototipos.

Se lanzó de forma tosca. Todavía tienes que terminarlo tú mismo.

Mi GBrain de código abierto, el motor de recuperación y los skill packs, aún no son productos completos listos para usar.

Algunos dicen que OpenClaw no es seguro. No entienden que su poder reside precisamente en la libertad. No te apresures a atornillar barandillas de seguridad a algo en lo que confías, hasta que realmente tengas un problema. El hecho de que tengas herramientas en tus manos es precisamente la prueba de que aún no está encerrado en una jaula.

Los sistemas de control son refinados porque el control requiere un control total, es decir, la fábrica Foxconn. Los sistemas libres son toscos porque confían en que tú los terminarás.

Debes elegir cuál de los dos estás construyendo. Y luego mirar hacia atrás para ver cuánto código has escrito.

¿Qué significa todo esto en realidad?

540 mil líneas de código Rails fueron mi prueba de que aún puedo jugar al máximo nivel en el juego antiguo.

Pero ese nivel pertenece al Web 2.0, a hace diez años.

Puedo jugar tan bien como antes, incluso puedo ser un ingeniero 1000x. Pero lo que hice fue construir fábricas Foxconn. Código antiguo. Juego antiguo.

Y el nuevo juego, sencillamente no se juega con líneas de código.

El resultado es que mis 'haters' tenían razón. Si están leyendo esto, amigos anónimos, les saludo.

Cuando puedes convertir la intención directamente en sistemas ejecutables, testeables y reutilizables, el cuello de botella ya no es cuánto puedes construir, sino qué es lo que realmente quieres, y si vale la pena construirlo.

Los recursos escasos se convierten en claridad, buen gusto y criterio.

El ingeniero que escribe menos código, a menudo es el que construye más cosas.

Yo escribí 540 mil líneas de código para aprender esto. Tú no tienes que repetir el camino.