La mayoría del trabajo de producto asistido por IA falla. No porque los modelos sean malos, sino porque el proceso lo es.
La capacidad es real. Los PMs ahora pueden documentar sistemas complejos, sintetizar requisitos dispersos y generar especificaciones listas para desarrollo en horas en vez de semanas. Pero muchos equipos no están capturando ese valor. Se quedan atrapados en prompts de una sola pasada: preguntan al modelo, toman la salida y la mandan a construir.
Esta guía cubre técnicas para discovery de producto asistido por LLM. Si eres nuevo en estos flujos o quieres refinarlos, el foco es el mismo: patrones que realmente funcionan.
Una nota rápida sobre tooling: los LLM no trabajan aislados. Los patrones aquí asumen herramientas de IA con acceso a archivos, ya sea un IA-IDE como Cursor o Windsurf, Claude con cargas de archivos o ChatGPT con documentos adjuntos. El LLM aporta razonamiento; la herramienta aporta acceso al código, documentos y contexto. Sin ese andamiaje, la mayoría de lo que sigue no es posible.
Principios centrales
Antes de entrar al flujo, tres principios gobiernan todo.
El problema de verificación
Los LLM son muy buenos en este trabajo. Apunta un modelo frontier a un codebase, un conjunto de requisitos o una colección de mockups, y producirá documentos de especificación que suelen ser mayormente correctos. La arquitectura central, los flujos principales y los modelos de datos primarios quedan bien capturados. Con buen prompting, puedes llegar al 80-90% en una sola pasada.
Pero el porcentaje restánte importa.
Los puntos ciegos son sútiles: una ruta de archivo que no existe exactamente, un edge case que el modelo pasa por alto o una suposición que parecía razonable pero no coincide con la realidad. No son fallas de inteligencia; son el resultado inevitable de sintetizar sistemas complejos bajo incertidumbre. Toda especificación las tiene. La pregunta es si las encuentras antes o después de que empiece el desarrollo.
La solución: inicia una conversación nueva para verificar. En un chat nuevo, el modelo aborda tu documento en frío y puede usar subagentes para validar afirmaciones contra el material fuente, en vez de defender lo que generó antes.
Validación entre LLMs
Las conversaciones nuevas capturan puntos ciegos dentro de un modelo. La validación entre LLMs captura puntos ciegos entre modelos.
No mezcles feedback a ciegas. Vuelve a tu conversación original y preséntalo como "aporte de colegas". El LLM original, con el contexto completo de cómo se construyó el documento, puede evaluar qué es válido y qué no.
Dos o tres rondas suelen producir una salida estable. Terminas cuando el feedback se vuelve estilístico en vez de sustantivo.
El trabajo humano
Los LLM manejan generación. Tú manejas juicio.
Revisa, no apruebes automáticamente. Las especificaciones generadas por IA pueden verse pulidas y aun así estar sútilmente equivocadas. Lee con cuidado. Sigue la lógica.
Agrega conocimiento de dominio. Tú sabes cosas sobre el negocio, los usuarios y las restricciones que no aparecen en ningún documento. El LLM no puede saber que el VP de Ventas prometió a un cliente que una función trabajaría de una forma específica.
Toma decisiones. El LLM muestra opciones. Tú eliges dirección. ¿Solución rápida ahora o enfoque robusto desde el inicio? Esa es una decisión de producto, no técnica.
Cuestiona supuestos. Cuando el enfoque no se siente correcto, empuja. Tu intuición compara patrones con experiencia. A menudo está detectando algo real.
Estos principios, verificación fresca, validación entre modelos y juicio humano, aplican en cada fase.
El flujo
Con los principios establecidos, este es el flujo. Cada fase construye sobre la anterior y produce artefactos para la siguiente.
Fase 1: Documentar el estado actual
Todos quieren saltar a la nueva función, el rediseño o la migración. Pero no puedes planear a dónde vas sin saber dónde estás. Y "dónde estás" en un codebase maduro suele ser más complejo de lo que cualquiera recuerda.
Con el andamiaje correcto, los LLM son excelentes para arqueología de codebase. Pueden leer documentación, rastrear jerarquías de componentes, mapear flujos de datos y sacar a la luz deuda técnica que nadie ha discutido en años.
Genera el documento: apunta tu herramienta de IA al área que vas a cambiar. Sé específico: arquitectura, rutas de archivos, modelos de datos, endpoints de API, puntos de integración y limitaciones conocidas.
Luego verifica. Abre una conversación nueva, da acceso a los mismos archivos y haz que valide cada afirmación de la especificación recién creada. Las rutas deben existir. Las descripciones de componentes deben coincidir con las implementaciones.
Luego revisa tú. Es tu oportunidad de aprender el sistema que vas a cambiar. El conocimiento de dominio detecta errores que los LLM pasan por alto.
Resultado: un documento de estado actual que describe con precisión lo que existe hoy.
Fase 2: Documentar el estado propuesto
Los insumos de producto vienen en muchas formas: exports de Figma, PRDs escritos por comité, RFCs técnicos y hilos de Slack donde supuestamente se tomaron decisiones.
Los LLM pueden sintetizarlo todo, pero debes proporcionar los insumos y aplicar la lente correcta. Para mockups, pide análisis UI/UX: jerarquía de componentes, interacciónes, estados vacíos y errores. Para requisitos, piensa como analista de producto: flujos de usuario, reglas de negocio y criterios de éxito. Para RFCs, usa lente de arquitecto: límites del sistema, flujos de datos y contratos de API.
No solo resumas. Extrae estructura. ¿Qué componentes existen? ¿Qué datos necesitan? ¿Qué puede salir mal?
Cuestiona y aumenta antes de finalizar. Presiona las áreas vagas. Luego verifica en una conversación fresca contra los materiales originales.
Resultado: un documento de estado propuesto que captura intención de diseño y requisitos.
Fase 3: Crear la especificación técnica
Ahora une la brecha. Dale al LLM ambos documentos, estado actual y estado propuesto, y pídele sintetizar una especificación técnica.
Aquí el LLM demuestra su valor. Puede identificar qué necesita cambiar, qué puede quedarse, qué componentes nuevos se requieren y cómo se integran con los sistemas existentes. Cambios de arquitectura, modelos de datos, APIs, estrategias de migración: todo derivado del delta entre dónde estás y a dónde vas.
Este documento necesita el mayor escrutinio. Aplica validación entre LLMs aquí. Pasa la especificación por varios modelos, recopila feedback por separado, integra lo válido y repite hasta que el feedback se estabilice.
Resultado: una especificación técnica que describe cómo pasar del estado actual al propuesto.
Fase 4: Descomponer en trabajo
Con una especificación validada, pide al LLM descomponer el trabajo en elementos de backlog.
La estructura que funciona: Epic → Features → PBIs. Un Epic para la iniciativa, Features para grupos de capacidad y PBIs para unidades individuales que un desarrollador pueda completar.
Mantén el sizing simple. S/M/L según complejidad. Deja que el LLM proponga y ajusta con base en la velocidad de tu equipo.
Valida la descomposición. La revisión cruzada detecta dependencias circulares, tareas faltantes y estimaciones poco realistas. El breakdown impulsa la planificación; errores aquí crean sprints bloqueados.
Resultado: un backlog estructurado listo para desarrollo.
Desarrollar tu propio flujo
Empieza simple. No construyas un proceso elaborado antes de validar que algo funciona.
Agrega pasos de verificación cuando notes errores recurrentes. Documenta lo que funciona. Estandariza nombres y carpetas; la consistencia habilita automatización.
El metapatrón: usa el mismo enfoque iterativo y cargado de validación para mejorar tu proceso que usas para mejorar tus especificaciones.
Qué sigue
El trabajo de producto asistido por LLM todavía está temprano. Los patrones evolucionarán conforme mejoren los modelos. Pero los principios centrales permanecerán: verificación con conversaciones frescas, validación entre modelos y juicio humano donde importa el contexto de negocio.
Las ganancias de productividad son reales. Especificaciones que tomaban semanas ahora toman días. Especificaciones que solían ser superficiales ahora son completas. Edge cases se detectan en planeación en vez de QA.
Empieza a experimentar. El costo de probar es bajo. El costo de esperar es mayor.
Próximamente: los artefactos que impulsan agentes de IA, una mirada a los documentos que produce este flujo y cómo habilitan desarrollo asistido por IA con menos hand-holding.
Publicado originalmente en LinkedIn