Contexto Técnico
Estoy totalmente de acuerdo con la fórmula brainstorm → spec → plan → implementation. Cuando realizo una implementación de IA en el desarrollo real, casi nunca le pido a Claude que escriba la funcionalidad completa de una vez. En ese momento, el modelo aún no comprende los límites de la tarea y comienza a hacer suposiciones sobre la arquitectura por mí.
Primero, lo uso como un agregador de contexto. Le doy el objetivo de la funcionalidad, partes de la arquitectura actual, restricciones, contratos de API y puntos controvertidos, y le pido que me devuelva esta información de forma resumida: qué entendió, qué falta y dónde están los riesgos. Este paso por sí solo evita la mitad de las decisiones extrañas.
Luego, no paso directamente al código. Pido una especificación (spec): qué cambiamos exactamente, cuáles son los non-goals, los criterios de aceptación, los casos extremos y qué módulos se verán afectados. Si la especificación parece débil, una nueva sesión no ayudará, porque el problema no es la ventana de contexto, sino que la tarea aún no está completamente definida.
Después de eso, le pido que convierta la especificación en un plan. No un plan abstracto como "hacer el backend, luego el frontend", sino un desglose de ingeniería adecuado: orden de los pasos, dependencias, archivos, pruebas, migraciones y riesgos de rollback. Y solo entonces, a partir del plan, comienzo la implementación, generalmente en pequeñas partes.
A menudo abro una nueva sesión, pero no mágicamente "para generar código", sino para establecer una fase de trabajo limpia. En una nueva sesión, paso la especificación y el plan ya depurados y el contexto de código necesario. Esto es mucho mejor que arrastrar una larga conversación de ida y vuelta llena de ideas, refutaciones y callejones sin salida.
La delegación también funciona, pero no como un sustituto del pensamiento. Puedo pedirle a Claude que recopile por separado las incógnitas, que sugiera una estructura para la especificación o que revise el plan en busca de lagunas. Es decir, delego subtareas, no la responsabilidad de la solución de ingeniería.
Impacto en el Negocio y la Automatización
En la práctica, aquí hay tres ventajas. Primero: menos código inútil que luego hay que desechar. Segundo: es más fácil estimar los plazos porque el plan ya está desglosado en pasos reales. Tercero: es más fácil construir la automatización con IA en un equipo donde varias personas y asistentes trabajan en la misma funcionalidad.
Ganan los equipos que tienen un contexto costoso: sistemas heredados, integraciones, lógica no estándar. Pierden aquellos que todavía le piden al modelo "haz un sistema completo" con un solo prompt y luego se sorprenden de por qué todo se desmorona en la revisión.
En Nahornyi AI Lab, resuelvo precisamente este tipo de problemas para los clientes: descompongo el desarrollo caótico en un pipeline gestionable donde la AI automation acelera los lanzamientos en lugar de crear nuevos riesgos. Si sus funcionalidades se ahogan en el contexto, echemos un vistazo a su proceso y construyamos un esquema de AI integration que realmente elimine el trabajo manual redundante.