La mayoría de los ingenieros que «usan IA» en realidad solo están chateando con ella. Le piden fragmentos de código, les funciona en local, lo pegan en el proyecto y rezan para que compile. Eso no es construcción de software. Eso es AI-TDA: mucho movimiento, pocas features despachadas. La diferencia entre un equipo que entrega y uno que solo experimenta está, en gran medida, en cómo formula sus instrucciones al modelo.
Chat vs. construcción de sistemas
Cuando chateas con una IA, el contexto es implícito, el formato es libre y los errores se corrigen en la siguiente vuelta. Cuando diriges una IA para construir software de producción, necesitas exactamente lo contrario: contexto explícito, formato estructurado y restricciones que eliminen ambigüedad desde el primer token. Un prompt de chat dice «hazme un endpoint REST». Un prompt de construcción dice qué framework, qué versión, qué contratos de entrada/salida, qué convenciones de error maneja el proyecto y en qué archivo debe vivir ese código.
Anatomía de un prompt productivo
Un Delivery Master en FAST Delivery estructura cada prompt en cuatro bloques:
- Contexto: stack actual, versiones, arquitectura relevante, decisiones previas que restringen el espacio de solución.
- Restricciones: qué no puede hacer la solución (no introducir dependencias nuevas, no romper compatibilidad).
- Formato de salida: si quieres un archivo completo, un diff, o solo la función. Sin esto, el modelo decide por ti.
- Requisitos de integración: cómo se conecta lo generado con el resto del sistema: interfaces, contratos, pruebas esperadas.
«Un prompt vago produce código que parece correcto. Un prompt estructurado produce código que es correcto dentro del sistema que ya existe.»
Los errores más comunes (y costosos)
El primer error es omitir el contexto y asumir que el modelo «sabe» de qué proyecto se trata. No lo sabe. El segundo es pedir resultados abiertos sin especificar las restricciones técnicas. El tercero es no validar el formato de salida antes de integrarlo. El cuarto es iterar sin checkpoint: diez turnos de corrección sin anclar el estado actual degrada la calidad de cada respuesta.
El Delivery Master como director de IA
En FAST Delivery, el Delivery Master mantiene un repositorio de plantillas de prompt probadas, define estándares de contexto que todo el equipo sigue y establece los checkpoints de validación. Este rol convierte la IA de herramienta caótica en infraestructura de entrega. La diferencia entre equipos que entregan una feature por semana y equipos que nunca terminan nada suele vivir en esas cuatro líneas de contexto que nadie escribe.