Tu IA está inventando tu producto

Por qué el resultado varía tanto

Aquí está el mismo prompt, enviado al mismo modelo, con sesenta segundos de diferencia.

Prompt: "Escribe criterios de aceptación para un ticket: el usuario puede configurar los ajustes del proveedor de IA."

Primer intento — sin contexto adjunto: el resultado es una lista genérica. "El usuario puede seleccionar un proveedor de IA desde un desplegable. El usuario puede guardar los ajustes. El usuario ve un mensaje de confirmación." Podría ser cualquier producto, cualquier plataforma, cualquier década. No hay nada malo en ello. Tampoco hay nada útil.

Segundo intento — con contexto del producto adjunto: el resultado hace referencia a las páginas de administrador de Jira Cloud, los permisos del Forge resolver, la validación de claves API por proveedor (OpenAI, Anthropic, Google, Mistral, xAI), el comportamiento del ámbito de datos a nivel de organización frente a proyecto, y las acciones de escritura condicionadas por licencia. Especifica que los ajustes persisten mediante @forge/sql y que la interfaz usa componentes de Atlaskit con tokens xcss. Parece escrito por alguien que ha trabajado de verdad en esa base de código.

El modelo no cambió. La temperatura no cambió. Cambió la entrada. Esa brecha — entre genérico y concreto — es el tema central de este artículo.

Cuando los resultados de la IA parecen inconsistentes, el instinto es culpar al modelo: cambiar de proveedor, actualizar el tier, ajustar la temperatura. Casi siempre, esa es la palanca equivocada.

Cada prompt empieza de cero. El modelo no tiene memoria de tu producto, tus usuarios, tus restricciones ni tu conversación anterior, a menos que proporciones esa información explícitamente. "Escribe criterios de aceptación" significa algo completamente diferente para una app Jira nativa sobre Forge que sirve a equipos de ingeniería de diez a cien personas que para un rastreador de fitness móvil de consumo.

El modelo responde al mundo que le describes. Si no describes nada, inventa uno — y rara vez es el tuyo.

Por eso dos personas del mismo equipo pueden usar el mismo modelo y obtener resultados completamente distintos. No es habilidad. No es la estructura del prompt. Es si el modelo recibió suficiente realidad del producto para trabajar con ella.

Para el marco más amplio sobre por qué esto causa errores tan costosos en Jira, empieza por: La IA no arregla los equipos desalineados. Los esconde.

La solución no es mejor técnica de prompting. Es construir una capa de contexto reutilizable — una descripción compacta y honesta del mundo de tu producto — y adjuntarla antes de cada prompt. Se escribe una vez. Se reutiliza en todas partes. El modelo deja de adivinar y empieza a trabajar con las mismas restricciones que tu equipo.

Las cuatro capas

El contexto del producto no es un solo bloque de texto. Se descompone limpiamente en cuatro capas, cada una haciendo un trabajo diferente.

• Resumen del producto cubre qué hace el producto, para quién y qué resultados importan — verdad operativa, no copy de marketing. La diferencia importa. "Una herramienta de gestión de proyectos para equipos" podría describir cualquier cosa. "Just es un copiloto de IA nativo de Jira para equipos de producto e ingeniería en Jira Cloud. Tarea principal: convertir issues vagos de Jira en planes de ejecución estructurados — aclaraciones, planes paso a paso y escritura de vuelta en campos de Jira — sin salir del panel del issue. No es un chatbot. No es una herramienta independiente. Construido sobre Atlassian Forge." describe exactamente un producto.
• Audiencia cubre quiénes son los usuarios, qué necesitan, qué esperan y qué no saben.
• Lenguaje de diseño cubre patrones visuales, biblioteca de componentes, hábitos de interacción y las cosas que nunca se hacen.
• Stack y restricciones cubre frameworks reales, límites de runtime, integraciones y decisiones explícitamente prohibidas.

La versión mala de cada campo encaja con miles de productos. La buena encaja con exactamente uno. Ese es el test.

La audiencia es donde el contexto genérico se rompe

La audiencia suele ser el primer campo que los equipos simplifican demasiado. "Product managers y desarrolladores" suena razonable. También es demasiado vago para ayudar al modelo a tomar mejores decisiones.

Un campo de audiencia útil es específico sobre la composición del equipo, la familiaridad con la IA, las expectativas de confianza y lo que los usuarios no quieren. Para Just, eso significa PMs e ingenieros senior en equipos de Jira Cloud de 10 a 100 personas, con familiaridad moderada con la IA, que gestionan sus propias claves API y se preocupan más por un resultado fiable que por uno llamativo.

La línea "No para" importa igual. Decir que esto no es para equipos fuera de Jira Cloud ni para usuarios que quieren agentes completamente autónomos elimina categorías enteras de suposiciones erróneas antes de que aparezcan.

Es lo que hace que el contexto parezca fundamentado en lugar de decorativo. Al modelo no solo se le dice quién es el usuario. También se le explica en qué mundo opera ese usuario y qué tipos de flujos se sentirían incorrectos.

Extrae lo que ya existe

La mayoría de los equipos ya tienen las cuatro capas de contexto — simplemente están dispersas entre codebases, archivos de diseño, documentación y memoria del equipo, en lugar de en una forma que la IA pueda usar.

Desde tu repositorio: apunta un agente de código — Claude Code, Codex o similar — a tu codebase y pide un resumen en markdown que cubra propósito del producto, stack, límites de implementación y restricciones conocidas. Un repositorio bien estructurado produce un primer borrador usable en minutos.

Desde tus archivos de diseño: identifica el nombre de la biblioteca de componentes, tres a cinco patrones de interacción clave en los que se apoya tu producto, y tres cosas que la UI nunca hace. Los antipatrones importan tanto como los patrones.

Desde documentación existente: notas de onboarding, archivos README, briefs internos o contexto de marketing pueden contribuir fragmentos de resumen del producto y definición de audiencia. No tienen que ser perfectos para ser útiles.

Desde tu propia cabeza: si nada de lo anterior existe aún, abre un documento en blanco y escribe ahora mismo un párrafo por campo. Será imperfecto. El contexto imperfecto supera al contexto inexistente por mucho.

No necesitas documentación perfecta. Necesitas una descripción compacta y honesta del mundo en que vive tu producto.

Guárdalo una vez, reutilízalo en todas partes

El contexto solo da frutos si es reutilizable. Escribirlo una vez y pegarlo en una sola sesión ayuda a esa sesión. Hacerlo persistente ayuda a todas las sesiones.

• En Just, el panel de administrador tiene una sección dedicada para cada uno de estos cuatro campos de contexto — Resumen del Producto, Audiencia, Lenguaje de Diseño y Stack. Pega tu contenido en cada campo una vez por proyecto. Cada insight futuro, cada aclaración, cada plan y cada paso de ejecución en ese proyecto queda fundamentado automáticamente por este contexto.
• Si no usas Just, crea un único archivo context.md en la raíz de tu repositorio o en documentación compartida. Estrúcturalo con las mismas cuatro secciones. Pégalo al comienzo de cualquier sesión de IA — asistentes de código, herramientas de chat, generadores de documentos. El formato importa menos que el hábito: el contexto va primero, antes del prompt.

Trata tu capa de contexto como un documento vivo, no como un artefacto del día de lanzamiento. Revísalo cuando el producto cambie significativamente — una nueva integración, un cambio importante de audiencia, una migración de sistema de diseño. No lo revises cada sprint. Si tu resumen del producto cambia cada dos semanas, no es un resumen del producto — son notas de reunión.

El contexto no es ingeniería de prompts

El contexto del producto no es ingeniería de prompts. No es un truco, una plantilla ni un hack ingenioso. Es darle al modelo el mismo briefing que le darías a un contratista nuevo el primer día: aquí está lo que construimos, para quién, cómo debe verse y en qué funciona.

Los equipos que hacen esto una vez — y lo reutilizan de forma consistente — obtienen resultados que parecen venir de alguien que realmente entiende el producto. Porque en todo sentido funcional, así es. El modelo no se volvió más inteligente. Simplemente dejaste de pedirle que adivinara.