Eran las 2:14 de la mañana cuando el agente decidió que la API de Stripe tenía un endpoint llamado customers.subscriptions.upgrade_with_proration.
No existe. Nunca existió.
Yo había ido por agua. Cuando volví, había cuarenta y siete minutos de trabajo construidos sobre ese endpoint inventado: tres archivos nuevos, una migración a Postgres, y un commit con el mensaje "feat: implement subscription upgrade flow". El loop de pruebas se había convertido en un loop de alucinaciones, donde cada 404 lo "arreglaba" inventando otro endpoint igual de ficticio. La IA se había metido en una madriguera de mentiras coherentes consigo mismas.
Ese sábado borré seiscientas líneas, cerré el laptop, y me fui a dormir furioso. No con el modelo. Conmigo.
Porque el modelo había hecho exactamente lo que yo le había pedido: "implementa el upgrade de suscripción". Sin contexto. Sin documentación. Sin un archivo que dijera "estos son los endpoints que existen de verdad". Lo había soltado en el bosque sin mapa y luego me indignaba porque había inventado un mapa.
El "vibe coding" no es el problema. Pretender que es ingeniería sí.
Hay una cosa que dice Matt Pocock que me persigue desde hace meses: el "Wrong Turn". Es ese momento exacto en el que el agente, por falta de una guía técnica clara, decide tomar el camino creativo en lugar del correcto. No es un ug. No es una limitación del modelo. Es lo que pasa cuando le pides a algo que no sabe el camino que avance de todos modos.
Y aquí va la parte que me cuesta admitir: yo era un vibe coder. Cargaba contexto a ojo, escribía prompts en lenguaje natural rezando para que el modelo "entendiera" la arquitectura, y cuando algo salía mal, culpaba al modelo. Defendía el flujo en Twitter. Le decía a colegas que la IA "casi" reemplazaba a un junior.
No es que estuviera mintiendo. Es que estaba teniendo suerte.
La diferencia entre el desarrollador que prospera con IA y el que produce basura técnica no es el modelo. No es ni siquiera el prompt. Es la cantidad de trabajo de ingeniería que está dispuesto a hacer antes de abrir el chat. Y cuando me senté a estructurar ese trabajo —en parte robándole ideas a Pocock, en parte aprendiendo a los golpes— terminé con siete fases que parecen mucho hasta que las ves funcionar.
Lo incómodo de esas siete fases es esto: no inventan nada. Son lo que hacíamos antes de que la moda nos convenciera de que podíamos saltárnoslas.
Tu research.md se pudre como el pescado
La primera fase útil es la Investigación. Suena obvia. Casi insultante. Pero el 80% de los desórdenes que vi en clientes el último año vienen de aquí: gente lanzando agentes a codear sin un research.md que les diga qué APIs existen de verdad, qué patrones usa el repo, qué decisiones difíciles ya están tomadas.
El research.md no es documentación. Es un caché temporal. Esa palabra —caché— me costó internalizarla. Significa que tiene fecha de caducidad.
Pocock lo llama "Research Rotting" y es brutalmente cierto. Un archivo de investigación escrito hace tres semanas, sobre una rama que ya cambió cuatro veces, es peor que no tener nada. El agente lo lee, lo cree, y se va al precipicio con confianza. Por eso ahora, en cada sprint, el research vive y muere con el sprint. Lo borramos. Lo reescribimos. Suena ineficiente. Es lo más eficiente que hago.
Lo segundo que aprendí, casi por accidente, es a prototipar en rutas descartables. Throwaway routes. Antes me lanzaba directo a integrar; ahora le pido al agente que monte una /playground/whatever aislada, que pruebo, que toco, y que tiro. El gusto humano —esa palabra que detesto pero no encuentro mejor— se aplica acá. Si la arquitectura se siente mal en el prototipo, no pasa al PRD. Punto.
Si no puedes defender el diseño ante un modelo, no estás listo
El PRD fue donde más resistencia interna sentí. Yo escribía PRDs hace años para una agencia donde trabajé entre 2019 y 2021, y los odiaba. Eran teatro corporativo. Decidí que con IA no los necesitaba.
Estaba equivocado.
Lo que cambió es la técnica. Ahora hago lo que llamo "PRD grilling": escribo el PRD y luego levanto un agente con un rol específico —algo así como "actúa como un staff engineer escéptico"— y le pido que me destroce el documento. Caso por caso. Edge por edge. Que cuestione cada decisión arquitectónica.
La primera vez que lo hice, el agente me preguntó qué pasaba si dos usuarios upgradeaban su suscripción en el mismo milisegundo. No lo había pensado. Pasé tres horas más en el PRD. Esas tres horas me ahorraron probablemente dos días de debugging después.
Si no puedes defender tu diseño contra un modelo entrenado para ser pedante, no estás listo para ejecutarlo. Esa frase me sonó pretenciosa la primera vez que la pensé. Sigue sonándome pretenciosa. También sigue siendo cierta.
El Kanban es lo que separa al gerente del programador monohilo
Del PRD salta al Kanban, y aquí es donde la mayoría de la gente que conozco se traba. Le dan al agente un plan secuencial gigante —"implementa todo el upgrade flow"— y se quejan de que pierde contexto a la mitad.
El truco es fragmentar con relaciones de bloqueo. Algo así:
#101: Definir esquema de DB para subscription_changes (BLOQUEA A #102)
#102: Endpoints POST /subscriptions/upgrade (BLOQUEA A #104)
#103: Componente UI <UpgradeModal /> (SIN BLOQUEOS)
#104: Integración frontend-backend del upgrade flow
La ventaja no es estética. Es estratégica. Mientras un agente trabaja en #101, levanto otro independiente para #103. Dos terminales, dos contextos, dos cabezas. Dejo de ser un programador monohilo y me convierto en algo más parecido a un tech lead de un equipo paralelo.
La primera vez que ejecuté tres agentes en paralelo y volví media hora después a ver que dos habían terminado y uno estaba esperando review, sentí algo que no había sentido en años. No era productividad. Era algo más raro. Era control.
La autonomía total es un espejismo (y los que la venden lo saben)
Después viene la ejecución AFK. Away From Keyboard. El "Ralph Loop". El agente toma los tickets desbloqueados y avanza solo, porque el contexto está cacheado y las instrucciones son nítidas.
Aquí es donde los influencers de IA te muestran el video de "mira, codeé una app entera mientras dormía". Y no es mentira. Pero tampoco es la historia completa.
La historia completa es que el QA final no es opcional. El humano hace el recorrido. El humano detecta que el modal está alineado mal por dos píxeles, que el copy en el botón dice "Confirmar" cuando debería decir "Pagar", que el rate limiting falla con el rol de admin. El agente puede generar un plan de pruebas. No puede tener gusto.
Tu rol cambia. Antes escribías código. Ahora juzgas código.
Lo curioso es que esto no es menos trabajo. Es trabajo distinto. Y para mucha gente que se hizo dev porque le gustaba escribir, es trabajo peor. He visto colegas brillantes deprimirse con este flujo, no porque no funcione, sino porque les quitó la parte que disfrutaban. No tengo respuesta para eso. Es una pérdida real.
Ahora la pregunta incómoda
Acá es donde se me cae el manifiesto.
Llevo dos meses con este flujo. Funciona. Lo defendería ante quien sea. Pero hay una pregunta que me corroe y no la he resuelto.
¿Esto que estoy haciendo es ingeniería con IA, o es solo ingeniería que finalmente me obligué a hacer bien?
Porque los PRDs existen hace cuarenta años. La investigación previa al código es un principio básico. El Kanban con dependencias claras es de los noventa. La idea de un humano juzgando código antes de mergearlo se llama code review y todos sabemos que deberíamos hacerlo más.
La IA no inventó nada de esto. Solo me castigó por no hacerlo.
Y eso me lleva al elefante que Pocock menciona de pasada y nadie quiere mirar: en este flujo de siete fases, ¿dónde está el code review como fase independiente? Lo metemos a la fuerza en el QA. Lo confundimos con la ejecución. Pero el code review de verdad —ese donde otro humano, no un agente, lee el diff y dice "esto está mal por estas razones"— no aparece. Y su ausencia me incomoda más cuanto más automatizo el resto.
Sospecho que las siete fases van a ser nueve. Sospecho que una de las nuevas va a ser un code review obligatorio entre dos humanos, justo antes del merge. Sospecho que en seis meses voy a leer este artículo y voy a pensar que era ingenuo.
Está bien.
Lo único que sé con certeza
Si abres Cursor o Claude Code mañana y empiezas a tirarle prompts sin un research.md, sin un PRD que defienda decisiones, sin tickets fragmentados, sin un QA con un humano mirando: vas a tener una mala tarde. Quizá no esta. Quizá la próxima. Pero va a llegar.
Y cuando llegue, el agente va a inventarte un endpoint que no existe a las 2:14 de la mañana, y vas a borrar seiscientas líneas, y vas a culpar al modelo.
No es el modelo.
Si necesitas una mano en tu desarrollo y escalar a un producto que venda
