Cómo hemos llegado a programar sin escribir código

Cada pocos meses aparece una palabra nueva y con ella la misma sensación: que hay una pila de conocimientos ahí fuera, ordenada y compartida por gente que llegó antes, y que uno se ha incorporado tarde. Primero había que aprender a escribir prompts. Después resultó que lo importante era el contexto. Luego las herramientas, los protocolos, las specs, las evals, el harness. Ahora la ingeniería agéntica.

La sensación de retraso es real. La pila no.

Lo que hay debajo de estos siete años es un patrón mucho más simple y bastante menos halagador. Cada etapa de este oficio se ha bautizado por lo que el humano dejaba de hacer: escribir la línea, escribir la frase, leer el diff, vigilar el proceso, escribir el código. Y ninguna se ha consolidado hasta que alguien, con retraso y a menudo a base de incidentes, escribió la lista de lo que había que empezar a hacer en su lugar. Esa segunda lista nunca sale en el anuncio, porque no vende nada.

Tiene además una propiedad que conviene decir pronto, porque explica todo lo demás: cada elemento de esa segunda lista es la reconstrucción manual de un control que antes venía incluido en el precio. Cuando escribir código costaba caro, ese coste hacía de control de calidad sin que nadie lo pidiera. Nadie generaba cuarenta ficheros que no pensaba leer, porque escribirlos dolía. Al eliminar el coste, eliminamos el control. Todo lo que hemos aprendido desde entonces —presupuestos de contexto, verificación ejecutable, límites de permisos, arneses, evals— es la factura de ese control, pagada a mano y en diferido.

Lo que viene es esa historia, ordenada por renuncias y no por años ni por productos.

El autocompletado no pedía nada a cambio

La primera etapa es la que casi nunca se cuenta porque no dio miedo a nadie.

Deep TabNine, en julio de 2019, fue el primer autocompletado neuronal de uso amplio: un GPT-2 afinado sobre código público que adivinaba el final de la línea. Su rival más visible era Kite, una empresa distinta y anterior —fundada en 2014, centrada en Python— que llevaba años vendiendo la misma promesa desde la nube. Entre los dos se repartían la categoría entera. GitHub Copilot entró en preview técnica el 29 de junio de 2021 y en disponibilidad general el 21 de junio de 2022, a diez dólares al mes, y en unos meses no quedaba categoría que repartirse: el 16 de noviembre de 2022, Kite cerraba y su fundador publicaba el post-mortem: medio millón de desarrolladores activos, ningún ingreso, y una conclusión —“los desarrolladores individuales no pagan por herramientas”— que Copilot llevaba cinco meses desmintiendo a diez dólares al mes.

Lo relevante de esos tres años es lo que no pasó. El autocompletado no exigía ninguna práctica nueva. Sugería, tú aceptabas o rechazabas, y el control de calidad seguía siendo exactamente el mismo de antes: leías la línea. Renunciabas a teclear, no a entender. La revisión se mantenía intacta porque el volumen no se movió: una sugerencia cabe en un vistazo.

Fue la única etapa gratis del oficio, y probablemente por eso quedó como el recuerdo de una edad de oro que nunca fue tal. Era barata porque era pequeña.

El chat trasladó el trabajo dentro de la ventana

ChatGPT en noviembre de 2022 y GPT-4 unos meses después cambiaron la unidad de trabajo. Ya no era la línea: era la función, el fichero, el error pegado desde la consola. Y con ella apareció el primer nombre de la serie, el prompt engineering, que prometía que el oficio consistía en encontrar la formulación correcta.

Duró poco como disciplina y merecía durar poco, pero dejó dos cosas. La primera, un rol: en junio de 2023 swyx publicó “The Rise of the AI Engineer” y le puso nombre a alguien que no era investigador de machine learning y tampoco era exactamente un desarrollador de siempre. La segunda, una pregunta bien planteada: en octubre de 2023 apareció SWE-bench, 2.294 problemas reales extraídos de issues y pull requests fusionadas de doce repositorios de Python. La pregunta ya no era si el modelo escribía código bonito. Era si podía resolver un problema real en un repositorio real.

La renuncia de esta etapa fue escribir el primer borrador. La contrapartida, que casi nadie formuló entonces, era leerlo entero antes de pegarlo. Todavía funcionaba, porque el copiar-y-pegar imponía un peaje de atención: para mover el código tenías que mirarlo.

El bucle fue el salto, y no lo dio el modelo

Entre 2023 y 2025 pasó lo único de esta historia que fue realmente un cambio de categoría, y ocurrió fuera del modelo.

ReAct, AutoGPT y BabyAGI fijaron la forma —pensar, actuar, observar, repetir— siendo, como productos, bastante malos. Devin, en 2024, empaquetó dentro de un entorno aislado las tres cosas que faltaban: una shell, un editor y un navegador. El salto no fue que el modelo escribiera mejor código. Fue que por fin podía ejecutar una acción, mirar el resultado y volver a intentarlo. Un modelo que se equivoca y no puede comprobarlo es un generador de texto. El mismo modelo con acceso a los tests es otra cosa.

En 2025 ese bucle bajó al terminal y se convirtió en producto de consumo. Claude Code, Codex CLI, Gemini CLI, OpenCode y el veterano aider, que llevaba en ello desde 2023: distintas marcas para la misma idea, con el desarrollador ya fuera del volante.

Aquí la renuncia fue la conducción. La contrapartida —diseñar el entorno donde el bucle se ejecuta, decidir qué puede hacer sin preguntar y cómo se deshace lo que haga mal— tardaría todavía un año en tener nombre. Ese año de desfase es donde se acumularon casi todos los incidentes que después se atribuyeron a los modelos.

Vibe coding no era una técnica, era una renuncia declarada

En febrero de 2025, Karpathy escribió aquello de entregarse del todo a las vibraciones, abrazar las exponenciales y olvidar que el código existe. Él mismo lo describió después como un tuit de ducha, pensado para proyectos de fin de semana.

El término se escapó, y se escapó de una manera muy concreta: pasó a nombrar indistintamente al prototipo desechable del sábado y al sistema en producción que alguien no revisó. Que Collins lo eligiera palabra del año 2025 mientras Merriam-Webster elegía slop resume aquel año mejor que cualquier análisis, y ninguno de los dos diccionarios lo hizo a propósito.

Conviene ser justo con el término, porque el desprecio posterior ha oscurecido lo que tenía de valioso. El vibe coding es la única etapa de esta lista que fue explícita sobre su renuncia. No prometía una disciplina nueva ni un rol mejor pagado: decía en voz alta que ibas a dejar de leer el código, y te dejaba decidir si eso era aceptable. Como técnica de prototipado acotado sigue siendo legítima y útil. El problema nunca fue la práctica; fue que no traía consigo ninguna frase sobre dónde estaba el límite, y el sector tardó un año en escribirla.

El contexto dejó de ser texto y pasó a ser presupuesto

El 19 de junio de 2025, Tobi Lütke propuso context engineering en lugar de prompt engineering y lo definió como el arte de proporcionar todo el contexto para que la tarea sea plausiblemente resoluble. Karpathy lo amplificó seis días después. En septiembre, Anthropic lo formalizó.

Ese documento es el primero de toda la serie que se lee como ingeniería y no como manifiesto, porque introduce la idea que ordena el resto: la ventana de contexto no es un almacén, es un presupuesto de atención. Cada token que metes compite con los demás. De ahí salen tres técnicas que hoy son estándar y que conviene saber nombrar: la compactación —resumir la conversación al llenarse la ventana y reiniciarla con el resumen, maximizando primero el recall y afinando después la precisión—, la toma de notas estructurada —memoria que vive fuera de la ventana— y las arquitecturas de subagentes, donde cada subagente quema decenas de miles de tokens en su propio contexto limpio y devuelve mil o dos mil de resumen. Y una cuarta que cambia el diseño de todo lo demás: la recuperación just-in-time, traer el contenido solo cuando hace falta usando identificadores ligeros —una ruta de fichero, una query— en vez de volcarlo por si acaso.

La renuncia fue escribir el prompt. La contrapartida es saber, en cada paso, qué hay dentro de la ventana, por qué está ahí y cuánto cuesta que esté. Es la primera vez en esta historia que la contrapartida es más difícil que la renuncia.

Estandarizamos los enchufes antes que la disciplina

Anthropic publicó el Model Context Protocol en noviembre de 2024. Zed publicó el Agent Client Protocol en agosto de 2025, para el otro eje del problema: no cómo habla el agente con las herramientas, sino cómo habla con el editor. En diciembre de 2025, tres competidores pusieron sus piezas bajo un techo común: Anthropic cedió MCP, OpenAI cedió AGENTS.md —la convención de llamar siempre igual al fichero donde un repositorio le explica sus reglas al agente— y Block cedió goose, su agente de programación de código abierto, que se ejecuta en la máquina del desarrollador, funciona con cualquier modelo y fue uno de los primeros en hablar MCP. Con esas tres donaciones se fundó, dentro de la Linux Foundation, la Agentic AI Foundation, con AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI como miembros platino. La nota de prensa daba dos cifras que dicen bastante: más de diez mil servidores MCP publicados y AGENTS.md adoptado por más de sesenta mil proyectos.

Es una velocidad de estandarización notable y merece el reconocimiento. Que en la misma donación quepan un protocolo, un nombre de fichero y un agente entero dice también lo poco asentado que estaba el vocabulario. Pero lo que conviene mirar es el orden.

Estandarizamos primero el enchufe —cómo se conecta un agente a una herramienta, a un editor, a otro agente— y solo después empezamos a discutir la disciplina: qué conviene enchufar, quién decide, qué pasa cuando la herramienta devuelve algo hostil, quién responde. Es el orden que le conviene a un ecosistema que necesita interoperar rápido. Es exactamente el orden inverso al que le conviene a alguien que está aprendiendo, porque conectar es trivial y decidir es donde está el oficio.

La factura de ese orden llegó puntual. En junio de 2025, Simon Willison había nombrado la trifecta letal: datos privados, contenido no confiable y un canal de salida. Cuando las tres coinciden en el mismo agente, un texto envenenado en cualquier fichero que lea basta para exfiltrar lo que tenga a mano, sin que exista un fallo en el código de nadie. En 2026 dejó de ser una advertencia y pasó a ser un catálogo de CVEs contra agentes de programación concretos, incluida al menos una en la que la salida del propio agente terminaba redefiniendo el límite de su sandbox.

Las especificaciones volvieron por la puerta de atrás

El movimiento spec-driven es la parte más irónica de esta historia, porque es un regreso disfrazado de novedad: cuando el código lo escribe una máquina, el sitio donde vive la intención humana vuelve a ser el documento previo. Lo que llevábamos veinte años tratando como burocracia se convirtió en el artefacto valioso.

La aportación que de verdad ordena el asunto no es una herramienta, es la taxonomía de Birgitta Böckeler, que separa tres niveles de ambición y evita casi todas las discusiones estériles. Spec-first: escribes una especificación buena, la usas para dirigir la tarea y la especificación puede morir con la feature; es el nivel de menor compromiso y captura casi toda la reducción de retrabajo. Spec-anchored: la especificación sobrevive a la tarea y la funcionalidad evoluciona a través de ella. Spec-as-source: la especificación es el artefacto que mantienes y el código es su compilado; sigue siendo una apuesta de investigación por mucho que se venda como inevitable.

Casi todo el mundo debería quedarse en el primero. Casi toda la literatura habla del tercero.

En paralelo maduró la otra mitad de la verificación, las evals, con dos aprendizajes que valen más que cualquier framework. El primero es que hay que evaluar la trayectoria y no solo el resultado: qué herramienta eligió, con qué argumentos, cuántos pasos redundantes dio, cómo se recuperó del error. El segundo está en la diferencia entre dos métricas que suenan parecidas y no lo son: pass@k mide si acierta al menos una vez en k intentos, y pass^k mide si acierta todas las veces. La segunda es la que describe producción. La primera es la que aparece en los anuncios.

El entorno tardó tres años en tener nombre

En febrero de 2026 el sector encontró la palabra que le faltaba desde 2023 —harness—, y la adoptó con una prisa que se explica mejor por el reparto de responsabilidad que por el hallazgo técnico. Del término, para lo que viene ahora, hacen falta dos piezas.

Una: el principio de trinquete de Mitchell Hashimoto. Cuando el agente se equivoca, no le regañas en el chat; cambias el entorno para que ese error concreto no pueda repetirse. Es la única forma conocida de que un entorno crezca por evidencia y no por superstición.

Dos: la distinción de Böckeler entre controles computacionales —linters, tipos, tests, hooks: deterministas, baratos, instantáneos— e inferenciales —otro agente revisando: caros, lentos y opinables—. La regla operativa es empujar lo computacional lo más a la izquierda posible y reservar lo inferencial para después.

La renuncia de esta etapa fue la vigilancia. La contrapartida es construir el entorno que vigila en tu lugar, y eso es trabajo de ingeniería con presupuesto propio, no una configuración.

La ingeniería agéntica es el nombre de la contrapartida

En 2026, Karpathy retiró su propio término y propuso agentic engineering. Su formulación es la mejor definición corta que existe del oficio actual: la disciplina profesional de coordinar agentes falibles preservando corrección, seguridad, gusto y mantenibilidad. Agéntica, porque el 99% del tiempo ya no escribes el código directamente, sino que orquestas a quien lo escribe y ejerces la supervisión. Ingeniería, para insistir en que ahí hay arte, ciencia y pericia.

Y una frase suya que ordena de un golpe todo lo anterior: el vibe coding sube el suelo; la ingeniería agéntica trata de extrapolar el techo.

Lo importante es la premisa de la que parte, que es la primera premisa honesta de toda la serie: el agente es falible y estocástico. No devuelve lo mismo dos veces. No sabe cuándo ha terminado. Todo lo que hemos ido acumulando en la segunda lista —presupuesto de contexto, verificación ejecutable, límites de permisos, arnés, evals, trayectorias— existe únicamente por esa premisa. Es, por fin, un nombre que describe la contrapartida en lugar de la renuncia.

El oficio es la segunda lista

Vista entera, esta historia se lee mal como progreso y bien como transferencia.

Cada etapa nos quitó una tarea y nos devolvió una responsabilidad más abstracta, más difícil de medir y peor pagada en atención: dejamos de teclear y empezamos a juzgar; dejamos de escribir prompts y empezamos a administrar presupuestos; dejamos de leer el código y empezamos a diseñar cómo se comprueba; dejamos de vigilar y empezamos a construir lo que vigila. En cada salto, lo que se anunciaba era la renuncia. Lo que había que aprender era la contrapartida, y llegaba con un año de retraso y algún incidente de por medio.

La buena noticia, si es que la hay, es que esa segunda lista es corta y se puede recorrer en orden. Ocho controles, ninguno de los cuales lleva el nombre de un producto.

No hay razón para pensar que la próxima palabra funcione distinto, ni que tarde mucho en llegar. Cuando aparezca, la pregunta útil no será qué deja de hacer el humano, porque eso vendrá en el titular. Será cuál es el control que desaparece con ella, y quién va a reconstruirlo.

Ese trabajo, el de reconstruir a mano lo que la lentitud nos regalaba, es todo el oficio. No es un peaje temporal que la próxima generación de modelos vaya a eliminar. Es lo que queda cuando se elimina todo lo demás.