Qué aprender para programar con agentes, y en qué orden

Vuelta al cole. Si esta semana te has propuesto por fin aprender a programar con agentes y has buscado una ruta, te habrán devuelto una lista de veintitantos elementos con el nombre de un producto en cada uno. Este editor, aquel CLI, este protocolo, aquel orquestador, esta extensión que salió el mes pasado. Ordenadas de arriba abajo, con la promesa implícita de que quien las recorra sale al otro lado convertido en algo.

El problema de esas listas no es que estén mal. Es que caducan antes de que termines de recorrerlas.

Las herramientas de este campo tienen una vida media que no llega a los dieciocho meses: la mitad de los nombres propios de cualquier ruta publicada en 2024 hoy no existen, se llaman de otra forma o pertenecen a otra empresa. Lo que no ha caducado en siete años es otra cosa, mucho más aburrida y bastante más útil: la lista de controles que hay que reconstruir a mano. Porque cada nombre nuevo del oficio anunció una tarea que dejábamos de hacer, y detrás de cada una había un control que desaparecía con ella y que alguien tenía que volver a montar.

Esa lista sí se puede estudiar en orden. Son ocho niveles, cada uno con tres partes: qué dejas de hacer, qué empiezas a hacer y —lo que de verdad importa— cómo sabes que lo has superado.

La tercera parte es la que separa una guía de estudio de un temario, y no es un capricho de formato. En febrero de 2026, METR abandonó el rediseño de su experimento sobre productividad porque ya no consigue grupo de control: los desarrolladores se niegan a participar si implica trabajar sin agente, incluso cobrando, y muchos admitieron no enviar al estudio las tareas que temían tener que resolver a mano. Si un laboratorio con financiación y método no consigue medir si esto va más rápido, tu sensación de estar mejorando no vale nada. De ahí que cada nivel termine en algo que se pueda comprobar desde fuera.

Un aviso antes de empezar, este sí medido: la productividad baja antes de subir. DORA lo llama la curva J —curva de aprendizaje más sobrecarga de revisión— y explica por qué tanta gente abandona justo en el punto bajo, cuando ya ha invertido y todavía no ha cobrado.

Nivel 0. Leer código que no has escrito

Dejas de teclear código. Empiezas a evaluar prosa ajena en un lenguaje formal, que es una habilidad distinta de escribirla y que casi nadie ha entrenado en serio.

Suena elemental y es el nivel donde se atasca más gente, porque es invisible: nadie te dice que has aprobado. Es también el único nivel que no se puede saltar. Todo lo que viene después consiste en delegar la escritura, y delegar sin saber juzgar el resultado no es delegar, es firmar en blanco.

Criterio de salida: en un cambio generado que pasa los tests, encuentras algo que aun así hay que corregir, y sabes decir en una frase por qué. Si lo único que encuentras son cuestiones de estilo, todavía no estás leyendo.

Complemento: Spinellis trata la lectura de código ajeno como una técnica con ejercicios en Code Reading (2003). Es de mucho antes de todo esto y se ocupa solo de la parte que no ha cambiado, que es justo lo que aquí interesa.

Nivel 1. Vibe coding con perímetro

Dejas de leer el código. Empiezas a decidir de antemano dónde está permitido no leerlo.

El vibe coding es una herramienta legítima con un dominio de aplicación estrecho: prototipos, exploraciones, scripts que se ejecutan una vez, cosas cuyo fallo no cuesta nada. El nivel no consiste en aprender a hacerlo —no hay nada que aprender— sino en aprender a acotarlo. Lo peligroso no es el prototipo del sábado; es el lunes, cuando el prototipo entra en un repositorio que sí importa sin que nadie haya decidido que entraba.

Acotar suena abstracto hasta que se escribe. En un script de un solo uso o en una rama de exploración que no se va a fusionar, no leer el código está bien. En cualquier cosa que toque cobros, autenticación o migraciones, no lo está, porque ahí un error verosímil no rompe ningún test que tengas y se paga en dinero o en datos.

Criterio de salida: puedes escribir en una línea, para un repositorio concreto, dónde está permitido no leer el código generado y dónde no, y esa línea aguanta que un compañero la discuta.

Complemento: “Not all AI-assisted programming is vibe coding”, de Simon Willison, sirve sobre todo para discutir la frontera con un equipo sin que la conversación se convierta en una pelea de bandos.

Nivel 2. El bucle y la red de seguridad

Dejas de conducir. Empiezas a construir el sitio donde el agente puede equivocarse gratis.

Aquí no se estudia el agente, se estudia git. Ramas efímeras, commits pequeños, worktrees, contenedores, sandbox, permisos explícitos, deshacer barato. Un desarrollador con higiene de control de versiones puede dejar a un agente trabajar durante horas y perder, como mucho, tiempo de cómputo. Sin ella, cada ejecución es una apuesta sobre un árbol de trabajo que no puede reconstruir.

Es, con diferencia, el nivel con mejor retorno del itinerario, y casi ninguna hoja de ruta pública lo incluye, porque no contiene ninguna tecnología nueva. Y pesa más cuanto peor esté el repositorio: DORA mide que la eficacia sobre sistemas heredados complejos no llega a un tercio de la que se obtiene en trabajo nuevo, así que sobre una base antigua y enredada este nivel no es preparatorio, es la condición para que el resto sirva de algo.

Criterio de salida: puedes tirar a la basura una hora entera de trabajo de un agente sin perder nada tuyo y sin pensarlo dos veces.

Complemento: el capítulo de worktrees de Pro Git se lee en una tarde y es libre. No menciona agentes en ninguna página; ese es exactamente el motivo de que siga sirviendo.

Nivel 3. El contexto como presupuesto

Dejas de escribir prompts. Empiezas a administrar una ventana con recursos limitados.

Aquí entran las técnicas que el sector formalizó en 2025 y una disciplina: fichero de instrucciones corto —una checklist de piloto, no una guía de estilo—, compactación cuando toca, notas fuera de la ventana, subagentes para lo que ensucia mucho y devuelve poco, y recuperación just-in-time —traer el contenido por su ruta cuando hace falta— en lugar de volcados preventivos. Con una intuición contraria que cuesta adquirir: meter más contexto empeora el resultado a partir de un punto, y ese punto llega antes de lo que sugiere el tamaño de la ventana.

Criterio de salida: ante una ejecución que ha salido mal, tu primera hipótesis es qué había en el contexto en ese paso, no qué modelo estabas usando.

Complemento: el artículo de ingeniería de Anthropic sobre contexto, leído con la reserva que merece cualquier texto de parte interesada, es donde estas técnicas están descritas con más detalle.

Nivel 4. La verificación ejecutable

Dejas de comprobar a mano. Empiezas a convertir criterios de aceptación en comprobaciones que se ejecutan solas.

Es el nivel que absorbe el impuesto de verificación, y por eso es el centro de gravedad de todo el itinerario. Tiene dos caras. Antes: una especificación escrita, aunque sea corta y aunque muera con la feature —el nivel spec-first de la taxonomía de Böckeler basta para la inmensa mayoría de los equipos—. Después: tests, tipos, linters, hooks y, cuando la comprobación no se puede automatizar, un evaluador que no sea la misma instancia que hizo el trabajo, porque los agentes se aprueban a sí mismos con una generosidad notable.

Y una métrica que hay que interiorizar aquí y no después: lo que importa no es que acierte alguna vez, sino que acierte todas.

Criterio de salida: el agente no puede declararse ganador por su cuenta; algo externo a él tiene que estar de acuerdo.

Complemento: Specification by Example, de Gojko Adzic (2011), es la prehistoria de todo esto quince años antes de que hiciera falta. No habla de agentes, habla de cómo se convierte un criterio de aceptación en algo que se ejecuta, que es la mitad difícil del nivel.

Nivel 5. Las herramientas y su radio de daño

Dejas de ejecutar tú las acciones. Empiezas a decidir cuáles puede ejecutar el agente sin preguntar, y qué es lo peor que pasa con cada una.

Si el nivel 2 protegía tu trabajo, este protege todo lo que hay fuera del worktree: la red, las bases de datos, las credenciales, los remotos, el dinero. Lo técnico es la parte fácil —MCP para el eje agente-herramienta, ACP para el eje agente-editor, y la observación empírica de que diez herramientas bien delimitadas rinden más que cincuenta solapadas—. Lo difícil es el inventario de daños.

Y casi todo el daño real es accidental. Un force-push sobre una rama compartida. Una clave commiteada. Una migración corrida contra la base de datos equivocada porque la variable de entorno apuntaba a otro sitio. Nadie ha atacado nada: le concediste la capacidad y se equivocó, que es lo que hacen los sistemas estocásticos.

Encima de eso hay un segundo caso, menos frecuente y bastante peor, que conviene conocer aunque no te haya tocado todavía. La trifecta letal de Simon Willison —datos privados, contenido no confiable y un canal de salida— la reúne un agente de programación sin que nadie lo planee: tu repositorio y tus credenciales, el README de una dependencia o el texto de un issue que escribió cualquiera, y una shell con red. Mientras las tres coincidan no hay parche, solo separación. Las CVEs de 2026 contra agentes de programación concretos salieron exactamente de ahí.

Criterio de salida: puedes decir, de cada capacidad que tu agente tiene concedida sin preguntar, qué es lo peor que puede provocar equivocándose. Si para responder tienes que abrir la configuración, no la decidiste tú.

Complemento: Threat Modeling, de Adam Shostack, es de 2014 y va de sistemas atacados, no de sistemas que se equivocan. Sirve igual, porque la pregunta que enseña a hacerse —qué puede salir mal aquí, y cuánto cuesta— es la misma en los dos casos.

Nivel 6. El entorno como producto

Dejas de vigilar. Empiezas a construir lo que vigila.

Este es el nivel del harness, y su método cabe en una frase: ninguna regla entra en el entorno sin un fallo real detrás. El agente se equivoca, tú cambias el entorno, documentas a qué error responde el cambio. Lo demás es colocar los controles en el sitio correcto —lo determinista antes del commit, lo opinable después de integrar— y guardar las trayectorias, porque sin registro de lo que hizo el agente y por qué no estás haciendo ingeniería del entorno, estás haciendo cábalas sobre él.

Criterio de salida: tu tasa de fallo baja de forma medible sin haber cambiado de modelo.

Complemento: no hay libro terminado, y la razón dice más que cualquier recomendación. El único que se toma el harness en serio, Agentic Engineering at Scale de Chris Ford, lleva meses publicándose por capítulos en preventa y todavía no está entero. Mientras tanto, lo más sólido son las notas de Hashimoto y el trabajo de Böckeler, que son artículos.

Nivel 7. La flota, el coste y la firma

Dejas de trabajar con un agente. Empiezas a gestionar varios, y descubres que el recurso escaso ya no es la generación.

Cuando puedes lanzar cinco agentes en paralelo, el límite deja de ser cuántos cambios se producen y pasa a ser cuántos puedes revisar, integrar y sostener. Aquí el trabajo es de gestión y de contabilidad: paralelismo real con aislamiento real, una cola de revisión que no se atasque, y una métrica que sigue faltando en casi todas partes, el coste por cambio aceptado, que es lo único que convierte el consumo de tokens en una cifra interpretable.

Y una decisión que no es técnica y que no delega nadie por ti: qué no se automatiza. Qué cambio no sale sin que alguien lo mire. Quién firma.

Criterio de salida: mides, tienes un número, y ese número le importa a alguien más que a ti.

Complemento: Accelerate, de Forsgren, Humble y Kim, trata de medir entrega de software sin un solo agente de por medio. Se ha citado hasta el desgaste y aun así sigue siendo un buen sitio donde discutir qué número merece la pena tener, que es la pregunta de este nivel.

Lo que ninguna ruta pública incluye

Las listas del principio tienen una segunda trampa, peor que la caducidad y más cara: la mayoría enseña un temario de Python, asyncio, bases de datos vectoriales, RAG y frameworks de orquestación. Eso no es esto. Eso es construir agentes, que es un oficio distinto, con un mercado distinto y un perfil de contratación distinto. Lo que has leído aquí es desarrollar software con agentes.

Sobre esto segundo sí hay libros, aunque pocos y jóvenes. Kim y Yegge publicaron Vibe Coding en 2025, más manifiesto que manual y útil precisamente por eso cuando lo que hace falta es convencer a alguien; Osmani sacó Beyond Vibe Coding el mismo año, bastante más sobrio y con material complementario libre. Ninguno de los dos llega a los niveles altos de esta ruta, y no es un descuido suyo: el libro que se los toma en serio todavía se está escribiendo. Y conviene no confundir ese estante con el de al lado, el de AI Engineering de Chip Huyen, que es excelente y es de la otra profesión.

La confusión no es nueva: swyx ya separaba en 2023 al ingeniero de software potenciado por IA del ingeniero que construye productos con modelos, y advertía de que el primero acabaría siendo el suelo del mercado y no un diferenciador. Eso es exactamente lo que ha pasado. El rol de “AI engineer” se está desagregando en especialidades —arquitectura de sistemas agénticos, evaluación y gobernanza, optimización de inferencia, post-entrenamiento— y ninguna de ellas es la que necesitas para entregar una feature el jueves.

Hay además cuatro cosas que determinan el resultado y no aparecen en ningún temario porque no se venden bien. Leer diffs a volumen sin que se apague la atención, que es un problema de factores humanos documentado desde 1983 y no una cuestión de disciplina personal. Presupuestar, porque cada control que añades se paga en cómputo y la fiabilidad tiene precio. Saber qué no se delega. Y la más incómoda: cómo se forma a quien viene detrás, cuando la primera capa de tareas —la que servía para aprender a juzgar— es justo la que ha desaparecido.

El nivel ocho lo vas a escribir tú

Estos ocho niveles no describen una carrera que termine. Describen un método, y el método es lo único que sobrevive a la próxima palabra.

Porque va a haber otra. Antes de Navidad, probablemente, aparecerá un término nuevo con su ola de hilos, su informe corporativo y su hoja de ruta de veintitantos elementos, y anunciará —como todos los anteriores— una tarea más que el humano deja de hacer. Cuando llegue, la pregunta no es si hay que aprenderla. Es la misma que ordena esta lista entera: qué control desaparece con ella, quién lo reconstruye, y cómo se comprueba desde fuera que está reconstruido.

Si sabes responder a esas tres, el nivel ocho te lo escribes tú, y llegarás antes que la gente que esté esperando a que alguien publique el temario.