De escribir código a escribir empresas

Antes de 2025, construir software significaba escribir código. Abría su editor, escribía funciones, corregía errores, confirmaba cambios. El ciclo de retroalimentación era corto y el trabajo, profundamente manual. Si quería algo construido, lo construía usted mismo o se lo explicaba a otro ingeniero, que luego escribía el código por usted.

Ese mundo terminó. No de la manera que la gente predijo, con una IA que iría mordisqueando poco a poco los bordes de la productividad. Terminó en el sentido de que toda la definición de lo que significa "construir" se está reconstruyendo desde cero, una capa de abstracción a la vez, a un ritmo difícil de asimilar.

Si pensamos en capas de abstracción, cuento cinco:

1. Escribir código: una persona escribe cada línea
2. Describir cambios: una persona le indica al agente qué cambiar y revisa el resultado
3. Programación de harness: los agentes escriben el 100 % del código
4. La organización: objetivos, roles, intención. El código es invisible. Las personas son el directorio
5. Metaorganizaciones: construir muchas empresas, empresas que construyen empresas

Cada capa hace lo mismo: aleja a las personas de la implementación y las acerca a la intención. Cada una parece radical la primera vez que la encuentra y obvia en retrospectiva.

Recorrámoslas.

Capa 1: escribir código

Aquí empezamos la mayoría. Piensa en lo que tiene que ocurrir, lo traduce a código, lo ejecuta, lo depura, lo publica. Toda la carga creativa y mecánica recae sobre sus hombros.

Es a la vez el arquitecto y el albañil.

Gran parte de la historia de la ingeniería de software transcurre aquí. Décadas de herramientas, lenguajes, frameworks y prácticas, todos diseñados para acelerar este ciclo. Control de versiones, linters, sistemas de tipos, CI/CD. Todo creado para ayudar a las personas a escribir mejor código.

Pensábamos que esto era divertido.

Capa 2: describir cambios

Luego llegaron Claude Code, Codex y herramientas similares. De pronto podía describir lo que quería cambiar y un agente escribía el código por usted. No a la perfección, pero lo bastante bien como para que su trabajo pasara de escribir a revisar.

Aquí está hoy la mayoría de los ingenieros. Abre un ticket en Linear o un hilo de Slack, describe lo que quiere y el agente produce un diff. Usted lo revisa. Lo cuestiona. Lo guía. Quizá diga "no, use este patrón en su lugar" o "el manejo de errores debería funcionar distinto aquí". El agente itera y, finalmente, usted aprueba.

Antes

"Voy a escribir el middleware de autenticación, manejar los casos límite, agregar pruebas y enviar un PR."

Ahora

"Agregue un middleware de autenticación que valide tokens JWT. Maneje con elegancia los tokens vencidos. Cubra los casos límite en las pruebas."

Escribe código más rápido que nunca. Pero sigue muy involucrado a nivel de código. Sigue revisando diffs, sigue preocupándose por los patrones de arquitectura, sigue aportando criterio y gusto.

Siente, con razón, que estas cosas importan para que su producto tenga éxito.

El cambio clave aquí es sutil: ha pasado de escribir código a definir el trabajo.

Pero sigue mirando el código.

Capa 3: programación de harness

Algunos equipos han ido más lejos. El objetivo es que los agentes escriban el 100 % del código. No el 80 %, no "la mayor parte". Todo. Este enfoque se ha llamado Harness Programming o Harness Engineering, un término que OpenAI cristalizó en su relato detallado sobre la construcción de una base de código de un millón de líneas sin una sola línea escrita a mano.

En un experimento interno de cinco meses, un pequeño equipo de ingenieros guio a agentes de Codex a través de pull requests y flujos de CI. Los agentes escribieron todo: lógica de aplicación, pruebas, configuración de CI, documentación, observabilidad y herramientas. Las personas no escribieron nada de código. Su trabajo principal pasó a ser permitir que los agentes hicieran trabajo útil: diseñar las restricciones, codificar "principios de oro" en el repositorio y construir los ciclos de retroalimentación que mantenían a los agentes en rumbo.

En este modelo, ya no mira archivos ni diffs individuales. Mira Claude Code o Codex como su interfaz principal. Guía al agente con instrucciones de más alto nivel. Está dentro del ciclo y puede intervenir, pero su relación con el código real se vuelve indirecta.

La siguiente pregunta natural: si los agentes hacen todo el trabajo, ¿por qué sigue asignándolo manualmente? ¿Por qué sigue sentado en Claude Code, alimentando tareas una por una?

Una respuesta es Symphony, de OpenAI.

Se basa en las mismas ideas que el ciclo Ralph Wiggum y es, básicamente, un servicio de larga ejecución que lee tickets de Linear, crea un espacio de trabajo aislado para cada incidencia y ejecuta un agente de programación dentro de él. Lo apunta a un proyecto, le da unos cuantos agentes y empieza a procesar el backlog. Los agentes abren PRs, revisan el trabajo de los demás y hacen el merge cuando pasa el CI.

En esencia, Symphony sigue siendo Harness Engineering: parte del repositorio, se acota por ticket y se centra en la implementación. Pero automatiza la asignación. En lugar de que usted vigile cada sesión de agente, el sistema toma el trabajo y avanza con él. Lo notable del repositorio de Symphony es que casi no es una implementación de código. Es más bien una especificación, con una fuerte invitación a implementar su propia versión.

No les importa el código que lo ejecuta. Les importan las ideas.

La idea crítica aquí: las barreras de protección lo son todo. Cuanto más rígido sea sobre lo que los agentes pueden hacer, qué patrones siguen y qué reglas de linting y pruebas obedecen, mejor funciona. Sin límites estrictos, los agentes se desvían. Hacen lo suyo. Pierden el contacto con la realidad. Y entonces tiene un proyecto de refactorización entre manos. Reglas estrictas de linting, formato y pruebas, fácilmente accesibles para cada agente, son lo que mantiene todo el sistema anclado.

Esto también significa que es sorprendentemente difícil aplicarlo a un proyecto brownfield, porque los agentes necesitan esas barreras estrictas y los humanos tendemos a omitirlas.

Capa 4: la organización

La capa 4 es un gran salto.

En las capas 1 a 3, las personas siguen pensando en el código, aunque ya no lo escriban ni lo lean. Los tickets se acotan a la implementación. El trabajo se define en términos de repositorios, endpoints y módulos. La abstracción cambió, pero el modelo mental no.

En esta capa, deja de pensar en el código por completo. No solo deja de leerlo, sino que deja de acotar el trabajo en torno a él. En lugar de describir lo que el código debería hacer, describe lo que quiere que sea verdad. No "implementar un limitador de tasa en la API", sino "los usuarios nunca deberían poder sobrecargar el sistema". No un ticket, sino una intención.

Thomas Dohmke, quien fue CEO de GitHub hasta agosto de 2025, se fue para crear una nueva empresa llamada Entire con USD 60 millones en financiamiento semilla. Su tesis: GitHub se creó para la colaboración entre personas en torno al código, pero en un mundo donde las máquinas son las principales productoras de código, el código en sí ya no es el artefacto más importante. Lo que importa es el razonamiento, las especificaciones y la intención que lo produjeron. Como él mismo dijo, avanzamos hacia "una abstracción mucho más alta, que son las especificaciones, el razonamiento, los registros de sesión, la intención, los resultados".

Nunca especificamos el código. Especificamos cómo nos gustaría que se viera el mundo. Si algo no encaja, lo vemos a nivel de aplicación y creamos nuevo trabajo. Nunca tocamos el código.

Pero capturar la intención no es solo un cambio de herramientas. Es un cambio organizacional. Cuando deja de pensar en el código, empieza a pensar en roles, responsabilidades, objetivos y rendición de cuentas. ¿Quién define lo que debe ser el producto? ¿Quién decide las prioridades? ¿Quién revisa los resultados? Son preguntas organizacionales, no de ingeniería.

La estructura natural que surge se parece a una empresa. Usted fija un objetivo de alto nivel: "construir el mejor boilerplate serverless de Python para AWS de código abierto". Nombra a un agente CEO, le da la misión y la visión, y lo deja ejecutar. El CEO contrata a un ingeniero fundador. El ingeniero contrata a perfiles junior. El CEO incorpora a un product manager y a un especialista en marketing. Empiezan a construir en público, a escribir publicaciones de blog, a entregar código y a iterar según la retroalimentación.

Herramientas como Paperclip lo hacen concreto: usted define una empresa con un organigrama, asigna roles a los agentes, fija objetivos y presupuestos, y deja que el organismo funcione.

Usted actúa como el directorio: aprueba contrataciones, revisa la estrategia y anula decisiones cuando es necesario.

Estas organizaciones no son estáticas.

Aprenden. Descubren qué funcionó y qué no. Se adaptan. Quizá en algún momento el CEO decide que el equipo necesita más gente, o que alguien tiene un bajo desempeño y debe ser reemplazado. Así funcionan las organizaciones reales. La estructura está viva.

Como humanos, operamos como un directorio. Todavía podemos guiar. Hay cosas que requieren nuestra aprobación y podemos darle instrucciones al CEO en cualquier momento.

"Creo que deberías enfocarte en esta oportunidad."

"Despide a esta persona."

"La estrategia es incorrecta; cambia de rumbo."

El CEO recibe la instrucción y la delega al resto de la organización.

Nunca volvemos a gestionar elementos de trabajo individuales.

Capa 5: metaorganizaciones

Y aquí es donde se dispara.

Si puede construir una organización y supervisarla como directorio, puede construir diez. Puede tener empresas que construyen empresas. Empresas que construyen plantillas para otras empresas. Un portafolio de organizaciones autónomas, cada una con su propia misión, su propio agente CEO, cada una creciendo y adaptándose.

Un directorio puede supervisar muchas empresas. Al fin y al cabo, eso es lo que hacen los directorios.

Esta es la capa que menos entendemos. Tenemos los primitivos, y herramientas como Paperclip ya admiten varias empresas en un solo despliegue con aislamiento completo de datos. El concepto de plantillas de empresa descargables, estructuras organizacionales prediseñadas que se pueden importar y ejecutar, está en la hoja de ruta.

Pero ¿qué pasa cuando una organización puede crear nuevas organizaciones para resolver subproblemas? ¿Cuando una empresa puede crear una filial, dotarla de agentes, darle un presupuesto y una misión, y dejarla funcionar? ¿Cuando la propia metaorganización empieza a tomar decisiones sobre qué empresas financiar, cuáles cerrar y cuáles fusionar?

Todavía no lo sabemos. Esta es la frontera.

El ritmo

Entre 2010 y 2016, la comunidad de JavaScript atravesó un período que a veces se llama las guerras de frameworks. React, Angular, Ember, Backbone, Vue: cada uno ganando popularidad, cada uno luchando por el dominio. Fue una época volátil. Había que aprender un framework nuevo cada año, a veces cada pocos meses. Meta, Google y equipos más pequeños competían por definir el futuro del desarrollo frontend.

Esa guerra duró unos seis años.

El ritmo del cambio

Cronología de las capas de IA:

• Ene 2026: se lanza OpenClaw. Se convierte en el estándar para ejecutar agentes dedicados. El proyecto de más rápido ascenso en la historia de GitHub.
• Feb 2026: OpenAI adquiere OpenClaw.
• Feb 2026: OpenAI publica Harness Engineering. Un millón de líneas de código, ninguna escrita a mano.
• Feb 2026: Entire se lanza. El ex CEO de GitHub apuesta USD 60 millones a que la intención, y no el código, es el nuevo primitivo.
• Mar 2026: Symphony se lanza. Asignación automática de tickets a agentes mediante Linear.
• Mar 2026: Paperclip se lanza. Agentes CEO, organigramas, presupuestos, gobernanza. Empresas como organismos.

Comparación

1. Guerras de JS: ~6 años
2. Capas de IA: ~semanas

Todo lo que he descrito, desde OpenClaw hasta Harness Engineering, pasando por Symphony y Paperclip, se lanzó en el lapso de unas pocas semanas.

Y esto es lo que ocurre con las capas de abstracción: a medida que sube, aumenta la velocidad de iteración. Si los agentes ya pueden construir empresas que a su vez suben por la capa de abstracción, el progreso se acumula. Cada capa acelera el descubrimiento de la siguiente.

Crea o no en la singularidad, en la AGI o en cualquiera de las grandes narrativas, es importante reconocer que esto no se está desarrollando en una escala de años.

Se está desarrollando en semanas y meses.

Qué significa para nosotros

Habrá un pequeño grupo de personas que se beneficiarán primero. Eso ocurre con todo cambio tecnológico. Pero no creo en la subclase permanente. Creo que todos tendrán espacio para prosperar en este nuevo mundo, sin importar cuándo o dónde eligieron participar, o incluso si eligen no hacerlo.

Mi esperanza es que los humanos podamos concentrarnos en lo que nos hace humanos. El trabajo creativo. El tiempo con amigos y familia. Las relaciones y experiencias que realmente importan. Si los agentes hacen la mayor parte de la implementación, quizá el trabajo y el dinero dejen de ser los marcadores de estatus que han sido.

Nos toca ser el directorio, no los albañiles.

Veamos cómo resulta.