Las herramientas de programación con IA han cambiado una cosa de manera fundamental: el código ya no es el cuello de botella. Una tarea que tomaba dos días ahora toma dos horas. Una funcionalidad que requería una semana se termina en una tarde.
Pero esto es lo que nadie te advirtió: el razonamiento que debería acompañar ese código no escala con la velocidad. Solo el código lo hace.
Abre cualquier foro de internet sobre Claude Code, Cursor o herramientas similares y encontrarás la misma queja apareciendo en todas partes. La IA olvida el plan. El contexto se compacta, la sesión se reanuda, y la herramienta empieza a tomar decisiones que contradicen las que ya se tomaron dos horas antes. Implementa algo que fue explícitamente rechazado. Reporta éxito en una tarea que no cumplió la intención original.
Las soluciones improvisadas son todas variaciones del mismo parche desesperado: escribir el plan en un archivo, actualizarlo antes de la compactación, esperar que la IA lo lea al reanudar. Manual. Frágil. Y aun así perdiendo el por qué: el razonamiento, las restricciones, las alternativas que fueron consideradas y rechazadas antes de que se abriera el primer archivo.
Este no es un problema de herramientas esperando que la próxima versión del modelo lo resuelva. Es un problema estructural. Y los problemas estructurales tienen soluciones estructurales.
La solución a la que llegué, desde mi propia experiencia, es la que llamo el plan de implementación.
Qué es un plan de implementación
Un plan de implementación (IP, por sus siglas en inglés) es un documento que vive en tu repositorio, lleva un ID estable, y hace cuatro cosas que una especificación clásica no hace.
Captura el plan ordenado para ejecutar el trabajo, no solo el objetivo. Fase a fase, tarea a tarea, con criterios de salida por fase para que sepas exactamente cuándo avanzar y qué constituye terminado.
Incorpora el registro de decisiones de manera inline. Cuando hay que tomar una decisión no obvia, con dos enfoques válidos y ventajas y desventajas reales, las opciones, la evaluación y el razonamiento viven dentro del IP, no en un documento separado que se aleja del código que produjo.
Registra el resultado. Lo que realmente ocurrió cuando el trabajo se ejecutó. Bugs descubiertos. Decisiones revisadas. Pruebas que atraparon cosas que nadie previó. La preimagen y la posimagen en el mismo artefacto.
Y se mantiene vivo después de que el trabajo termina. El IP no se archiva. Cada IP recibe un identificador estable y secuencial cuando se crea (IP-001, IP-002, IP-003), y ese identificador es el ancla permanente al que apunta el resto del sistema. Así, cuando una decisión en IP-080 depende de una regla establecida en IP-050, IP-050 es la fuente oficial. No un blog post sobre la decisión. La decisión misma, con las pruebas que demuestran que se sostiene y las notas de cuando casi no lo hizo.
Un documento. Un ID. Especificación más plan más resultado más memoria.
Cómo se ve esto cuando funciona
Imagínate esto: estás dentro de una sesión, la herramienta está trabajando, y aparece una pregunta que ninguno de los archivos abiertos responde. ¿Puede una acción downstream leer la salida de un elemento específico dentro de una operación de fan-out?
La herramienta de implementación no adivinó. No generó una respuesta plausible desde cero. Investigó, encontró las reglas de alcance de señal establecidas en un IP anterior, y devolvió la respuesta directamente: las señales por elemento van al stream, no al registro. Las reglas de visibilidad de señal previenen la fuga entre límites. Esto ya está decidido.
El IP anterior nunca había sido referenciado en esa sesión. La herramienta llegó a un límite, reconoció que ese límite ya tenía respuesta, y aplicó la respuesta existente: las pruebas que lo demostraban, el Architecture Decision Record (ADR, por sus siglas en inglés) que evaluó las opciones, y las notas del resultado de cuando la implementación se ejecutó.
Esta es la distinción que importa: la memoria le gana a la generación cuando la respuesta ya existe, porque la memoria carga con todo el contexto detrás de esa respuesta (las pruebas, las alternativas, el razonamiento), mientras que una respuesta generada solo carga con su propia plausibilidad.
Un modo de plan en un agente de código puede generar una respuesta plausible a la pregunta de visibilidad de señal. Un sistema de IP le permite al agente recuperar la respuesta que ya estaba establecida. No son la misma operación y no producen la misma calidad de resultado.
Contexto incorporado en el código mismo
El IP no solo vive junto al código. Viaja con él.
Cada bloque significativo de código que existe por un IP lleva una referencia a él, un comentario de la forma // IP-042: signal scope rules, per-item outputs go to stream not registry. Ese comentario no es documentación. Es un puntero.
Cualquier ingeniero que lea ese archivo, humano o IA, puede seguir el puntero, abrir IP-042, y encontrar la decisión completa: qué se consideró, qué se rechazó, cómo son las pruebas, qué ocurrió cuando se ejecutó. El razonamiento no está en la cabeza de alguien. No está en un hilo de chat que se compactó. Está en un archivo, en control de versiones, a una referencia del código que produjo.
Esto es lo que hace que la secuencia se comporte como memoria. Un IP es una especificación con un plan y un resultado. Una secuencia numerada de IPs es un mapa del terreno: decisiones que reducen el espacio de soluciones para cada IP que sigue, restricciones que previenen toda una clase de diseños incorrectos, reglas que cualquier sesión nueva puede recuperar sin que tengas que reexplicarlas.
No solo estás construyendo tu aplicación. Estás escribiendo su historia. Y cuando tú (o el próximo ingeniero, o la próxima sesión de IA) necesites saber qué se hizo y por qué, el sistema ya está ahí para responder.
Cuándo escribir uno
No todo necesita un IP. Correcciones pequeñas, cambios aislados, actualizaciones triviales: omítelo.
Escribe un IP cuando el cambio afecta más de una capa del sistema, cuando la decisión involucra ventajas y desventajas que vale la pena registrar, cuando la implementación abarcará más de una sesión de IA, o cuando estás tomando una decisión que necesitarás explicar más adelante, a un humano o a una herramienta que no tiene memoria de la conversación donde la tomaste.
El umbral no es la complejidad. Es la consecuencia.
Empieza con uno. Escribe el enunciado del problema primero. Si no puedes plantearlo con claridad, no estás listo para entregárselo a una IA. Luego el diseño, las restricciones, las fases. Abre la sesión de código con el IP como contexto, no como algo añadido al final. Cierra las fases a medida que se completan. Referencia el IP desde el código que produce.
Después de algunos de estos, el formato se vuelve instinto. Después de suficientes, el código lleva su propio razonamiento, y cada sesión que abres hereda ese razonamiento automáticamente, sin que tengas que reexplicar lo que ya estaba decidido.
La restricción que mantiene la honestidad
Una regla hace que la secuencia sea confiable: no open gaps.
Cada bug descubierto durante la implementación se corrige antes de que el IP cierre. Cada pregunta arquitectónica se responde antes de escribir código. No diferido. No eludido. Respondido.
Si una corrección descarrilaría el IP actual, la respuesta no es diferirla. Abres un IP nuevo en ese momento. A esta velocidad de implementación, el contexto desaparece en un parpadeo, tanto para ti como para la IA. Usa el contexto mientras lo tienes. Si lo difieres, lo que se escriba después será una conjetura, no un registro.
Porque estás trabajando activamente desde el IP, la brecha es visible frente a ti, no enterrada en un backlog. No puedes cerrar un IP mientras finges que no viste el hueco. Y porque el IP permanece vivo después de cerrarse, un hueco que se cuela lo pagan todos los IP futuros que dependen de esa decisión.
La regla no es perfeccionismo. Es mantenimiento de la memoria. Una secuencia con brechas silenciosas no es memoria. Es un registro con páginas que faltan.
Las herramientas de programación con IA hicieron la implementación barata. Lo que no hicieron barato es el costo de implementar sin intención.
El sistema de IP es lo que evita que la velocidad de implementación deje atrás al razonamiento. El código que lleva su propio razonamiento es el código en el que se puede confiar: por el próximo ingeniero, por la próxima sesión de IA y por la versión de ti que lo abre seis meses después y necesita saber no solo qué hace, sino por qué existe.
