De la idea a la spec: cómo convierto intuiciones de producto en planes de trabajo con IA
El proceso que sigo en Enolisa para transformar ideas, feedback y problemas técnicos en documentos de trabajo detallados antes de desarrollar.
Antes de programar, construir el terreno
Una de las cosas que más ha cambiado en mi forma de desarrollar Enolisa es que cada vez programo menos “desde una idea en bruto”.
Antes, una mejora podía empezar con una intuición clara: “habría que mejorar esto”, “este flujo necesita otra vuelta”, “este sistema debería ser más robusto”, “este feedback de usuario apunta a un problema real”.
Con IA, la tentación inmediata es pedir código cuanto antes. Pero en features importantes hago justo lo contrario: uso la IA para retrasar la programación hasta que el problema está suficientemente entendido.
En mi caso, muchas mejoras pasan primero por una carpeta de trabajo previo, una zona donde voy acumulando análisis, borradores, TODOs, ADRs, benchmarks, investigaciones, hipótesis y planes de validación. No es documentación pública ni documentación final de arquitectura. Es un taller.
Ese taller no contiene solo tareas técnicas. También contiene análisis de oportunidad, comparativas de mercado, hipótesis de monetización, feedback de usuarios, riesgos de soporte, posibles modelos de producto y criterios para decidir si una idea merece convertirse en desarrollo. Para mí esa es una de las mayores diferencias: la IA no entra únicamente cuando toca programar, entra mucho antes, cuando todavía estoy decidiendo qué merece la pena construir.
Ahí una idea puede estar varios días madurando antes de convertirse en desarrollo. Y esa maduración cambia mucho la calidad del resultado.
La carpeta de futuras features como laboratorio
En Enolisa mantengo documentación de trabajo para futuras funcionalidades y evolutivos. Puede haber documentos sobre sincronización, rendimiento, feedback de usuarios, notificaciones, UI responsive, analítica, IA, escaneo, gestión de imágenes o mejoras de producto.
Lo importante no es la carpeta en sí. Lo importante es el patrón:
- capturar la idea antes de perderla;
- separar intuición de decisión;
- investigar antes de implementar;
- versionar el pensamiento cuando el problema cambia;
- dejar claros los riesgos;
- convertir una conversación en una spec;
- convertir una spec en plan de ejecución;
- convertir el plan en criterios de QA.
Hay documentos que empiezan siendo un TODO muy abierto y terminan en una especificación extensa. Otros pasan por varias versiones porque el primer planteamiento no era suficiente. También hay investigaciones que acaban descartando una solución. Eso no es trabajo perdido. Es coste de incertidumbre pagado antes de tocar producción.
Ejemplo: un producto de uso alrededor del escaneo
Un ejemplo real, explicado de forma deliberadamente abstracta, es el trabajo previo para convertir una capacidad técnica de escaneo en un producto empaquetable.
La forma rápida de plantearlo habría sido: “añadir packs de escaneo”. Pero esa frase no es una spec. Es una intuición.
Antes de escribir código, el documento de trabajo tenía que ordenar preguntas de negocio y de producto:
- qué problema resuelve realmente para el usuario;
- si el modelo encaja mejor como límite, pack, suscripción o combinación;
- qué coste operativo tiene cada uso;
- cómo se comunica el valor sin crear fricción;
- qué pasa con usuarios premium, usuarios nuevos o compras restauradas;
- qué métricas deben indicar si el producto funciona;
- qué casos pueden generar soporte o pérdida de confianza.
Después venía la traducción técnica:
- estados de entitlement;
- validación de compra;
- consumo y recuperación de saldo;
- sincronización entre app y backend;
- errores de red;
- trazabilidad;
- pantallas afectadas;
- eventos de analítica;
- pruebas manuales y automáticas.
La IA en este punto no sustituye la decisión. Me ayuda a no dejar ángulos sin revisar. Puede actuar como analista de mercado, product manager crítico, arquitecto backend, revisor de UX, QA o auditor de documentación. La clave es que cada rol mira el mismo problema desde una lente distinta.
El resultado no es solo una lista de tareas. Es un puente entre una decisión de negocio y una entrega técnica validable.
Iterar un documento durante días
Una buena spec rara vez sale en una sola conversación. Mi flujo suele ser iterativo.
Primero describo el problema con lenguaje natural: qué quiero conseguir, qué me preocupa, qué casos de usuario veo y qué restricciones existen. Después uso la IA para ordenar ese material: detectar huecos, separar objetivos de soluciones, proponer preguntas, identificar dependencias y señalar riesgos.
A partir de ahí empieza un ciclo:
- redactar una primera versión;
- contrastarla con el estado real del código o la documentación;
- pedir una revisión crítica;
- ampliar casos límite;
- ajustar alcance;
- dividir fases;
- definir validaciones;
- volver a leerlo como si fuera otra persona quien tuviera que implementarlo.
Ese ciclo puede durar días. Y no lo veo como lentitud. Lo veo como una forma de reducir improvisación.
Cuando el documento ya es sólido, el desarrollo cambia de naturaleza. El agente no tiene que inventar la feature sobre la marcha. Puede seguir un plan, comprobar decisiones, implementar por fases y validar contra criterios explícitos.
Qué debe tener una spec útil
Para que un documento de trabajo sirva de verdad, no basta con describir “lo que quiero”. Tiene que explicar el problema de forma operativa.
Una spec útil suele incluir:
- hipótesis de negocio;
- análisis de oportunidad;
- contexto funcional;
- motivación del cambio;
- objetivo principal;
- objetivos secundarios;
- cosas que quedan fuera de alcance;
- estado actual del sistema;
- restricciones técnicas;
- dependencias entre módulos;
- riesgos;
- fases de implementación;
- criterios de aceptación;
- escenarios de prueba;
- métricas de producto o negocio;
- impacto en documentación;
- posibles decisiones futuras.
En algunos casos añado también secciones de investigación, benchmark, análisis de feedback o ADRs. No todo necesita el mismo nivel de detalle. Una mejora pequeña no debe convertirse en una novela. Pero cuando el cambio toca arquitectura, datos, UX crítica o comportamiento cross-repo, el documento tiene que ser lo bastante preciso como para evitar malentendidos.
La IA ayuda mucho aquí porque puede actuar como revisor incómodo. Puede preguntar qué pasa si falla una dependencia, qué ocurre en un caso límite, qué parte no está especificada, qué validación falta o qué contrato habría que actualizar.
De conversación a requisitos
Una parte interesante de este proceso es que la entrada no siempre es técnica. A veces viene de una sensación de producto. A veces de feedback de usuario. A veces de una métrica. A veces de un bug extraño. A veces de una oportunidad detectada al comparar el producto con alternativas del mercado. A veces de una pregunta de negocio: si una funcionalidad tiene coste variable, si puede empaquetarse, si mejora retención o si abre una línea de monetización razonable.
El trabajo consiste en transformar esa entrada difusa en requisitos concretos.
Por ejemplo:
- una hipótesis de monetización puede convertirse en modelo de producto, restricciones, métricas y plan de validación;
- una queja de usuario puede convertirse en análisis de severidad, hipótesis técnica y caso de reproducción;
- una idea de mejora puede convertirse en fases de implementación;
- una intuición de UX puede convertirse en criterios de navegación y estados visuales;
- una deuda técnica puede convertirse en ADR;
- un riesgo de escalabilidad puede convertirse en plan de observabilidad;
- una feature ambiciosa puede dividirse en entregas pequeñas y validables.
Este paso es donde más se nota la diferencia entre usar IA como generador de texto y usarla como herramienta de pensamiento estructurado.
El objetivo no es que el modelo “tenga razón”. El objetivo es que ayude a hacer mejores preguntas antes de escribir código.
El documento como contrato de trabajo con el agente
Una vez que la spec está suficientemente madura, se convierte en contrato operativo.
Cuando empiezo el desarrollo, el documento sirve para decir:
- implementa esta fase, no todo el sistema;
- respeta estas restricciones;
- no cambies esta parte;
- valida estos escenarios;
- actualiza esta documentación;
- deja explícito lo que queda pendiente;
- no despliegues sin confirmación.
Esto cambia la relación con el agente. Ya no estoy conversando con una IA para ver qué sale. Estoy dirigiendo una ejecución sobre un plan.
El agente sigue pudiendo proponer alternativas, detectar problemas y sugerir ajustes. Pero la base ya no es una petición ambigua. La base es una especificación que ha pasado por análisis previo.
Para mí, esa es una de las diferencias más grandes entre “usar IA” y trabajar profesionalmente con IA.
QA diseñado desde el principio
Otra ventaja de escribir specs antes de implementar es que el QA deja de ser una fase improvisada al final.
Si el documento está bien escrito, ya contiene muchas preguntas de validación:
- qué escenarios deben funcionar;
- qué casos límite pueden romperse;
- qué pantallas hay que revisar;
- qué contratos deben mantenerse;
- qué datos no deben mutar;
- qué logs o métricas conviene observar;
- qué documentación se debe actualizar;
- qué pruebas manuales o automáticas tienen sentido.
Esto permite que el desarrollo y la validación estén conectados desde el inicio. El mismo documento que sirvió para pensar la feature sirve después para comprobar si se ha construido correctamente.
Además, cuando el proyecto tiene varios repositorios o servicios, esta trazabilidad se vuelve crítica. Una mejora aparentemente pequeña en la app puede depender de una Cloud Function, un esquema de Firestore, una regla de sincronización, una notificación push o un contrato con una API interna.
Sin una spec, esas conexiones se descubren tarde. Con una spec, se pueden poner encima de la mesa antes.
No todo debe exponerse al detalle
Hay un punto importante: documentar bien no significa publicar todo ni dar al modelo cualquier información sin filtro.
En mi flujo separo tres niveles:
- documentación privada de trabajo;
- documentación técnica interna;
- contenido público, como este blog.
En la documentación privada puedo trabajar con más detalle operativo. En la interna dejo contratos, decisiones y reglas necesarias para mantener el sistema. En lo público cuento arquitectura, método y aprendizajes, pero sin publicar lógica sensible, credenciales, reglas de negocio críticas ni datos reales.
Esta separación me permite aprovechar la IA sin convertir el conocimiento interno en una exposición innecesaria.
También obliga a escribir mejor. Si no puedes contar una idea sin revelar lo delicado, probablemente todavía no has separado bien método, implementación y ventaja competitiva.
El valor está en dirigir el proceso
La parte más interesante de trabajar así no es que la IA escriba más rápido. Eso ya lo sabemos.
El valor está en poder sostener más frentes con más orden:
- negocio;
- producto;
- arquitectura;
- implementación;
- documentación;
- QA;
- análisis de feedback;
- comunicación técnica;
- mejora continua.
El perfil técnico que va a destacar en los próximos años no será únicamente quien conozca una tecnología concreta. Será quien sepa convertir oportunidad de mercado en decisión de producto, decisión de producto en sistema, sistema en plan, plan en ejecución y ejecución en aprendizaje.
La IA amplifica muchísimo a quien tiene criterio para dirigirla. Pero también amplifica el desorden si no hay método.
Por eso dedico tiempo a las specs. Porque una buena especificación no es un trámite previo al desarrollo. Es el lugar donde se decide si el desarrollo va a ser una sucesión de parches o una construcción con sentido.
Una conclusión práctica
En Enolisa, muchas features empiezan como una conversación y terminan como un documento de trabajo exhaustivo. Ese documento después guía implementación, revisión, QA y documentación final.
Cuando la feature tiene componente de negocio, el documento también obliga a responder algo más importante: por qué existe, qué hipótesis valida, qué métrica debería mover y qué coste o riesgo introduce. Ese paso evita construir por inercia.
No siempre es el camino más corto en apariencia. Pero suele ser el camino que menos vueltas da.
Cuando la IA entra en ese proceso, deja de ser una herramienta para producir texto o código aislado. Se convierte en un copiloto de análisis, planificación, ejecución y validación.
Y ahí es donde, para mí, empieza realmente el cambio: no en pedirle a una IA que haga una tarea, sino en diseñar un sistema de trabajo donde la IA pueda aportar velocidad sin quitar control.