Le pides a la IA una pantalla de login y te devuelve cuatrocientas líneas en dos minutos. ¿Y ahora qué? ¿Cómo sabes si eso funciona de verdad? ¿Cómo sabes si de paso ha tocado el formulario de pago, que sí iba bien? ¿Cuántas veces has dado a «aceptar» porque el código parecía correcto y tres días después no encuentras dónde se torció todo?
Da igual si programas desde hace quince años o si te has metido a esto hace tres meses porque querías montar tu propia herramienta interna. El cuello de botella ya no es escribir código: es revisarlo, probarlo y decidir qué entra en producción. Y ahí la improvisación se paga cara.
Lo que sigue es el ciclo completo: encargo, plan, implementación, revisión, montado como un proceso fijo que ejecutas siempre igual. Sin misticismos, sin promesas de multiplicar tu velocidad. Solo los pasos, dónde se guardan las reglas y qué permisos das a cada cosa.
Los prompts completos para crear workflows de programación con IA los encontrarás al final del artículo, listos para copiar.
Por qué en programación el workflow gana a la improvisación
Anthropic distingue dos cosas que la gente mezcla todo el rato. Un workflow son pasos que defines tú de antemano: la IA los recorre en el orden que le has marcado. Un agente es la IA decidiendo sobre la marcha qué hacer a continuación.
La regla práctica es sencilla: si puedes escribir los pasos, escríbelos y hazlo workflow. Sale más barato, más predecible y más fácil de depurar cuando algo falla.
Programar es, precisamente, uno de los sitios donde casi siempre puedes escribir los pasos. Recibes un encargo, decides cómo abordarlo, escribes el cambio, lo pruebas, alguien lo revisa y se publica. Ese circuito lleva décadas funcionando.
La IA no lo sustituye: se mete dentro, en cada casilla. Si te saltas casillas «porque la IA ya lo hace todo», lo que has hecho es quitar los controles de calidad justo cuando el volumen de código se ha multiplicado.
La otra regla que repiten tanto Anthropic como OpenAI: empieza por lo más simple que funcione y sube complejidad solo cuando eso falle. Aplicado aquí significa que no necesitas un enjambre de agentes para arreglar un bug de CSS. Necesitas un prompt bien escrito, un diff pequeño y una prueba.
Si quieres el marco general de cómo se arma un proceso repetible, lo tienes en la guía de cómo crear un workflow con IA; este artículo es la versión aplicada al código.
Y una aclaración para quien «vibe codea» sin ser programador: esto también va contigo. De hecho va más contigo, porque no tienes el instinto de mirar un diff y notar que algo huele raro. Tu red de seguridad tiene que ser el proceso, no la intuición.
El método: del encargo al código revisado en seis pasos
1. Escribe el encargo antes de abrir el editor
Casi todas las respuestas malas vienen de encargos malos. «Añade filtros a la tabla» no es un encargo: es un deseo. Un encargo dice qué campos se filtran, qué pasa cuando no hay resultados, si el filtro se guarda en la URL, qué no hay que tocar y cómo sabrás que está bien.
Redáctalo tú en cuatro líneas y deja que la IA lo convierta en una especificación con criterios de aceptación. El primer prompt de las tarjetas de abajo hace exactamente eso: te devuelve el encargo estructurado y, lo más útil, una lista de preguntas que no habías contestado. Si al leerlas piensas «pues no lo había pensado», acabas de ahorrarte una tarde.
2. Pon las reglas del proyecto en un fichero de instrucciones
Aquí es donde la mayoría se atasca, porque cada herramienta lee un sitio distinto:
- Claude Code lee
CLAUDE.md. No leeAGENTS.md. Si quieres un único fichero para todo el equipo, pon@AGENTS.mdcomo primera línea delCLAUDE.mdy listo. - Codex, Cursor y compañía leen
AGENTS.md. - Cursor además usa
.cursor/rules/*.mdc. Ojo con esto: un.mdplano en esa carpeta se ignora, tiene que ser.mdc. - ChatGPT y Claude en web: instrucciones del Proyecto. Gemini: instrucciones del Gem.
Dos criterios para no arruinarlo. El primero: menos de 200 líneas. Un fichero más largo no solo gasta más en cada consulta, es que además reduce el caso que le hacen a lo que has escrito.
El segundo, y es el que más gente ignora: lo que escribes ahí es contexto, no configuración obligatoria. «Nunca borres la base de datos» es una frase, no un candado. Lo que no puede pasar se impide con permisos, no con una línea en un markdown.
Reparto: los hechos permanentes van al fichero de instrucciones (stack, convenciones de nombres, comando para lanzar los tests, qué carpetas no se tocan). Los procedimientos de varios pasos —«cómo se crea una migración aquí», «cómo se publica una release»— van a una skill aparte, un documento que la IA carga solo cuando toca.
3. Pide plan, no código
Este es el paso que más devuelve por lo poco que cuesta. Antes de que se escriba una sola línea, pide un plan: qué ficheros va a tocar, en qué orden, qué decisiones ha tomado y qué se le queda fuera. Lo lees, discutes dos puntos, y entonces das luz verde.
Claude Code trae un modo plan pensado para esto: es un estado de solo lectura en el que puede explorar el repositorio y proponer la implementación, pero no escribe ni ejecuta nada hasta que apruebas.
En Codex el equivalente es arrancar en modo read-only y pedir el plan ahí. En herramientas de vibe coding sin modo plan, lo consigues igual: se lo pides en el prompt y le dices explícitamente que no genere código todavía.
Si no eres programador, el plan es tu momento de control. No necesitas entender cada fichero; necesitas ver si lo que ha entendido coincide con lo que pediste.
4. Implementa en trozos pequeños y con los permisos cerrados
Un cambio, un diff, una revisión. Si le encargas seis cosas de golpe y algo se rompe, no sabes cuál fue. Trabaja siempre sobre una rama, nunca directamente sobre la principal.
Y ahora los permisos, que es lo que de verdad te protege. En Codex el sandbox tiene tres modos documentados:
read-only: puede leer ficheros, pero no editar ni ejecutar comandos sin aprobación. Es el modo para revisar un pull request, explorar un repositorio recién clonado o preguntar sobre código que no quieres que se toque.workspace-write: puede leer, editar dentro del espacio de trabajo y ejecutar comandos rutinarios ahí dentro. Es la opción por defecto para el desarrollo del día a día.danger-full-access: elimina las restricciones de sistema de ficheros y de red. La propia documentación avisa de que solo debe usarse cuando quieres que el agente actúe con acceso total.
Aparte van las políticas de aprobación: untrusted (para antes de ejecutar comandos fuera del conjunto de confianza), on-request (trabaja solo dentro del sandbox y pide permiso cuando necesita salirse) y never (no se detiene a preguntar). Por defecto el sandbox también restringe el acceso a red.
¿Por qué el modo sin restricciones casi nunca merece la pena? Porque el beneficio es dejar de dar a «sí» cuatro veces por sesión, y el coste es que un comando mal generado puede tocar cualquier cosa de tu máquina, con red abierta. La documentación de OpenAI es explícita: combinar acceso total con la política never elimina todas las salvaguardas.
Si de verdad necesitas ese nivel de libertad, la respuesta correcta es un contenedor o una máquina aislada, no bajar el candado en tu portátil de trabajo. Y una línea que no se negocia: todo lo que envía, publica, cobra o borra debe requerir aprobación humana, en programación igual que en cualquier otro workflow.
5. Prueba antes de dar por bueno
«Compila» no es «funciona». «Se ve bien» tampoco. Antes de aceptar un cambio necesitas tres cosas: que pasen las pruebas automáticas que ya tenías, que haya prueba nueva para lo que acabas de añadir, y que tú abras la aplicación y hagas el camino del usuario a mano.
Si no tienes pruebas automáticas, este es el mejor sitio para empezar a tenerlas, y da igual tu nivel: pídele a la IA que escriba la prueba antes del cambio, no después. Si la escribe después, tiende a escribir una prueba que pasa con el código que acaba de generar, que es justo lo contrario de lo que quieres.
Para quien construye sin programar, la versión práctica es un guion de comprobación manual: cinco o seis pasos escritos, con el resultado esperado de cada uno, que repites igual en cada cambio. Es aburrido y funciona.
En crear apps sin programar está desarrollado el enfoque completo para ese perfil.
6. Cierra con revisión automatizada en el pull request
La última casilla. Cuando el cambio está en un pull request de GitHub, puedes pedir revisión escribiendo @codex review en un comentario. Codex reacciona con 👀 y publica la revisión en el pull request, como haría un compañero. También puedes activar revisión automática en los ajustes de Codex, y entonces revisa cada pull request nuevo sin que tengas que comentar nada.
Dos detalles que cambian mucho el resultado. Uno: Codex busca ficheros AGENTS.md en el repositorio y sigue las reglas de revisión que hayas escrito ahí, así que ese fichero del paso 2 te sirve también para esto. Dos: en GitHub solo señala incidencias P0 y P1, es decir, los riesgos de prioridad alta, para que los comentarios no se conviertan en ruido.
Puedes además dirigir el foco sin cambiar la configuración permanente, comentando algo como «@codex review buscando regresiones de seguridad». Detalles y ajustes actuales, en la documentación de la integración con GitHub.
Que quede claro: esto no sustituye a que un humano mire el cambio. Sustituye a la primera pasada, la que detecta lo evidente, para que la persona llegue descansada a lo que importa.
Errores comunes que se pagan caros
- Escribir prohibiciones en vez de poner permisos. Ya lo hemos dicho y lo repetimos porque es el error más caro: el fichero de instrucciones es contexto. Lo que no puede pasar se bloquea con el modo de sandbox, no con una frase en mayúsculas.
- El fichero de instrucciones de 600 líneas. Alguien empieza con veinte reglas sensatas y a los tres meses hay una sección de «cosas que nunca funcionan» con anécdotas de 2025. Gasta más y le hacen menos caso. Poda cada mes.
- Aceptar diffs sin leerlos. Si no entiendes un cambio, pide que te lo explique fichero a fichero antes de aprobar. «Explícame este diff como si no conociera el proyecto» es un prompt legítimo, no una rendición.
- Encargar seis cosas en el mismo mensaje. Cuando algo se rompe, no hay forma de saber cuál fue. Un cambio, un diff.
- Confundir «genera rápido» con «avanza rápido». El código que no has probado no está terminado; está pendiente.
- Trabajar sobre la rama principal. Sin rama no hay marcha atrás limpia. Es gratis y te salva una vez al mes.
- Meter secretos en el repositorio. Claves de API en un fichero de configuración que luego subes. Siempre variables de entorno y
.gitignore.
Herramientas: qué usa cada una y dónde van las instrucciones
| Herramienta | Para qué encaja | Fichero de instrucciones | Precio orientativo |
|---|---|---|---|
| Claude Code | Trabajo en terminal sobre un repositorio existente; modo plan antes de tocar nada | CLAUDE.md (con @AGENTS.md en la primera línea si unificas) | Dentro de Claude Pro, 20 $/mes; comprueba el plan y las condiciones actuales |
| Codex | Ciclo completo con sandbox por modos y revisión en el pull request | AGENTS.md | Ligado a la suscripción de ChatGPT; ChatGPT Plus, 20 $/mes. Comprueba condiciones |
| Cursor | Editor completo, para quien prefiere ver el código mientras se genera | AGENTS.md + .cursor/rules/*.mdc | Cursor Pro, 20 $/mes. Comprueba el precio actual |
| Lovable, Bolt, v0 | Vibe coding: de idea a aplicación funcionando sin abrir un editor | Instrucciones del proyecto dentro de la propia herramienta | Consulta la web de cada una |
| ChatGPT o Claude en web | Planificar, escribir el encargo, revisar un diff que pegas tú | Instrucciones del Proyecto | 20 $/mes cada uno; comprueba condiciones |
| Gemini | Segunda opinión sobre un plan o un diff | Instrucciones del Gem | Consulta su web |
Los precios cambian y los planes se reorganizan cada pocos meses, así que compruébalos en la web de cada herramienta antes de decidir. Y no acumules: con una para el trabajo diario y una para segundas opiniones vas sobrado.
💡 ¿Quieres esto ya resuelto?
No hace falta que escribas el prompt desde cero: la carta The Vibe Coder de Invokard son más de 3.000 palabras de instrucciones que convierten a la IA en tu compañero de desarrollo: te ayuda a elegir herramienta, escribir el encargo, revisar el diff antes de aceptarlo y recuperar el proyecto cuando algo se rompe, aunque no sepas programar. Es gratis.
¿Y si el próximo encargo ya lo lanzas con el proceso montado?
Ninguno de los seis pasos es difícil por separado. Lo difícil es acordarse de hacerlos todos cuando llevas dos horas metido en un problema y solo quieres que compile de una vez. Por eso el proceso se escribe: para que no dependa de tu memoria un martes a las siete de la tarde.
Empieza por lo mínimo. Un AGENTS.md corto, la costumbre de pedir plan antes que código, y los permisos en el modo que corresponde a lo que estás haciendo. Con eso solo ya cambia bastante. Cuando lo tengas rodado, añade la revisión automática en el pull request y las pruebas escritas antes del cambio. Ese es el orden: lo simple primero, complejidad solo cuando lo simple falle.
La lógica completa de montar un proceso que se repita solo la tienes en la guía sobre cómo crear un workflow con IA.
Aquí abajo tienes los cinco prompts que cubren el ciclo entero: el que convierte tu idea en un encargo con criterios de aceptación, el que te genera el fichero de instrucciones del proyecto sin pasarte de líneas, el que exige plan antes de tocar código, el que te traduce un diff aunque no programes y el que monta el plan de pruebas.
Cópialos, pégalos y ajústalos a tu proyecto. ¿Con cuál empiezas?
Preguntas frecuentes
No sé programar. ¿Puedo montar esto igualmente?
Sí, con dos adaptaciones. La primera: el paso del plan pasa a ser tu control principal, porque ahí compruebas si la IA ha entendido el encargo sin necesidad de leer código. La segunda: tu «prueba» es un guion de comprobación manual escrito, no una suite automática. Lo que no debes hacer es saltarte los permisos: cuanto menos sepas leer un diff, más importa que la herramienta no pueda tocar lo que no debe.
¿Un fichero de instrucciones o uno por herramienta?
Uno. Escribe AGENTS.md, que es el que leen Codex y Cursor, y en el CLAUDE.md pon @AGENTS.md como primera línea para que Claude Code lo cargue. Si usas Cursor con reglas específicas, esas van aparte en .cursor/rules/*.mdc, con esa extensión, porque un .md plano ahí no se lee.
¿Cuándo esto deja de ser workflow y necesito un agente?
Cuando no puedas escribir los pasos por adelantado. Corregir un bug reproducible con un mensaje de error concreto es workflow. «Averigua por qué la aplicación va lenta los martes» no lo es: hay que explorar, descartar y decidir sobre la marcha. Regla práctica: si puedes escribir los pasos, hazlo workflow. Y aun así, empieza por lo simple y sube complejidad solo cuando falle.
¿Merece la pena usar el modo sin restricciones alguna vez?
Casi nunca en tu máquina. El caso razonable es un entorno aislado y desechable, tipo contenedor, donde el peor escenario es que se rompa algo que puedes recrear en un minuto. En un portátil con acceso a repositorios de clientes, credenciales guardadas y red abierta, lo que ahorras en clics no compensa lo que arriesgas. Es una decisión de entorno, no de comodidad.
