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.

No necesitas entender backpropagation para trabajar con IA generativa, pero sí necesitas entender por qué miente con tanta seguridad. Los equipos de producto que integran LLMs sin ese conocimiento básico terminan diseñando flujos que amplifican exactamente los fallos más peligrosos del modelo. Este artículo cubre lo mínimo indispensable que un Product Owner y su equipo deben saber antes de tomar cualquier decisión de diseño con un modelo de lenguaje.

Cómo funciona un LLM (lo que importa para producto)

Un modelo de lenguaje predice el siguiente token más probable dado todo el contexto anterior. No busca en una base de datos, no razona paso a paso por defecto, no tiene memoria entre sesiones a menos que se le provea explícitamente. La ventana de contexto es la cantidad de texto que el modelo puede «ver» a la vez. Todo lo que está fuera de esa ventana no existe para él. Diseñar un flujo que asuma memoria ilimitada es diseñar un flujo que se rompe en producción.

Alucinaciones, temperatura y confianza sin fundamento

Las alucinaciones no son bugs: son el comportamiento esperado de un sistema que predice texto plausible sin verificar hechos. La temperatura controla cuánta aleatoriedad se inyecta: temperatura cero produce respuestas más deterministas; temperaturas altas producen respuestas más creativas pero menos confiables. Para workflows de producto que requieren precisión, la temperatura debe ser baja y el output verificable por el sistema.

«Un LLM no sabe lo que no sabe. Por eso el diseño del workflow importa más que la capacidad del modelo.»

Qué puede y qué no puede hacer la IA de forma confiable

Los LLMs son excepcionalmente buenos en transformación de texto con estructura conocida: resumir, reformatear, clasificar, generar borradores bajo plantillas rígidas. Son poco confiables para aritmética exacta, razonamiento causal complejo y hechos factuales sin fuente en el contexto.

Diseñar workflows que aprovechen las fortalezas

La clave es insertar la IA donde su output es verificable y el coste del error es recuperable. Define siempre: ¿qué pasa cuando el modelo se equivoca? Si la respuesta es «nada, el usuario lo detecta», el flujo es frágil. En FAST Delivery, el PO define estos criterios de fallo antes de que el Delivery Master empiece a construir. El conocimiento mínimo sobre LLMs no hace ingenieros de ML a los POs; los hace responsables de las decisiones que toman.

La IA ya no es el futuro del software. Es el presente. Y la pregunta que separa a los equipos que avanzan de los que se quedan atrás no es “¿usamos IA?” — es “¿la estamos usando con disciplina o estamos improvisando?”

Para responder esa pregunta honestamente, primero hay que entender qué es exactamente lo que estás usando. Porque hay mucha confusión alrededor del término LLM — y esa confusión lleva a malas decisiones de equipo y peores resultados.

Qué es un LLM, sin rodeos

LLM significa Large Language Model — modelo de lenguaje grande. Son sistemas entrenados con cantidades masivas de texto (libros, código, artículos, documentación, conversaciones) para aprender a predecir cuál es la siguiente palabra más probable dado un contexto.

Eso es todo. No entienden. No razonan de la misma forma que tú. No tienen intenciones. Son máquinas de predicción estadística extremadamente sofisticadas que, gracias a su escala, producen resultados que parecen razonados.

Claude, GPT-4, Gemini, Llama — todos son LLMs con distintas arquitecturas, tamaños y datos de entrenamiento. Tienen habilidades distintas, pero el principio es el mismo: dado un contexto, predice lo que sigue.

Un LLM no sabe si el código que generó va a funcionar en producción. Sabe que ese tipo de código usualmente va junto a ese tipo de problema. La diferencia importa — y cambia cómo debes usarlo.

Cómo cambia el desarrollo de software

Antes de los LLMs, escribir código era el cuello de botella. Podías tener la idea clara, el diseño definido, los criterios de aceptación precisos — y aun así tardabas semanas en tener algo funcionando.

Los LLMs eliminaron ese cuello de botella. Hoy, con herramientas como Cursor, Claude Code o GitHub Copilot, un ingeniero senior puede generar en minutos lo que antes le tomaba días: scaffolding, lógica de negocio, tests, documentación. Estudios de GitHub muestran que los desarrolladores que usan Copilot completan tareas hasta un 55% más rápido.

Pero eso es solo la mitad de la historia.

El problema: velocidad sin disciplina

Aquí está lo que nadie te dice en los artículos de hype: la velocidad sin disciplina no produce más software — produce más caos.

Lo que vemos en equipos que adoptan IA sin estructura es lo que llamamos AI-TDA: Trastorno por Déficit de Atención inducido por IA. Los síntomas son conocidos:

• Cada desarrollador prompting en su propio contexto, sin coordinación.
• Código generado que nadie revisa con criterio real.
• Features “casi listas” que nunca llegan a producción.
• Deuda técnica que crece más rápido que antes, porque generar código ahora es trivial.
• Sprints que terminan con el 70% del trabajo iniciado y el 0% desplegado.

La paradoja es cruel: la herramienta que prometía acelerar el delivery lo está frenando, porque el equipo tiene más código en progreso pero menos features terminadas y en manos del usuario.

El problema no es la IA. El problema es que la IA amplifica lo que ya existía: si el proceso era disciplinado, la IA lo hace más rápido. Si el proceso era caótico, la IA produce caos más rápido.

La disciplina que falta: construcción dirigida

La solución no es usar menos IA — es usarla diferente. Específicamente: con un ingeniero senior que dirige la generación de código en vez de simplemente prompting al azar.

La diferencia entre “pedirle a la IA que escriba código” y “dirigir la construcción con IA” es la misma que existe entre darle un pincel a alguien que nunca pintó y contratar a un pintor que usa pinceles mejores. El resultado es completamente distinto.

Esto es lo que define el rol del Delivery Master en el método FAST Delivery:

• Contexto deliberado: El Delivery Master define el contexto antes de cada sesión de construcción. No “hazme un login” — “construye autenticación JWT con estos endpoints, estas validaciones, integrado a este ORM, con estos casos de error.”
• Revisión con criterio: Todo código generado pasa por revisión. La IA puede generar código que compila pero que introduce vulnerabilidades, viola convenciones o crea deuda técnica invisible.
• Decisiones de arquitectura reservadas para el humano: Qué va en el servidor, cómo se estructura la base de datos, qué librerías se usan — esas decisiones no se delegan. Se toman con criterio y se ejecutan con IA.

El resultado: una feature completa, probada y desplegada en producción cada viernes. No código generado — software funcionando.

Conclusión práctica

Los LLMs son la herramienta de desarrollo de software más poderosa que ha existido. No hay debate ahí.

Pero una herramienta poderosa en manos indisciplinadas produce resultados impredecibles. Y en software, lo impredecible tiene un costo concreto: releases retrasados, calidad degradada, equipos frustrados y clientes que pierden confianza.

La ventaja competitiva en los próximos años no va al equipo que use más IA. Va al equipo que la use con más disciplina — al que tenga un proceso claro de definición antes de construir, que revise con criterio lo que la IA genera, y que cierre cada semana con un incremento real en producción.

La IA cambia todo en el desarrollo de software. Pero solo para los equipos que la usan con un método.