Cómo uso Codex como capa operativa de desarrollo en Enolisa

La IA no como chat, sino como sistema operativo de trabajo

Durante los últimos meses he ido cambiando mi forma de trabajar con IA. Al principio, como casi todo el mundo, el uso natural era preguntar, pedir una función, revisar un error o generar una pieza concreta de código. Eso ayuda, pero se queda corto cuando el proyecto empieza a tener varias capas: app móvil, backend, datos, analítica, notificaciones, documentación, producto, QA y decisiones de arquitectura.

En Enolisa he terminado usando Codex de una forma más parecida a una capa operativa de desarrollo que a un asistente puntual. No le pido simplemente “haz esto”. Intento que trabaje dentro de un marco: con contexto local, instrucciones persistentes, roles especializados, documentación viva, restricciones explícitas y verificación antes de cerrar cada cambio.

Para ponerlo en escala: el ecosistema de trabajo que uso alrededor de Enolisa está repartido en 12 repositorios principales, con una app móvil, servicios backend, funciones serverless, analítica, web, documentación y herramientas de soporte. Solo en la app principal mantengo 28 subagentes locales, más de 50 documentos técnicos vivos y varias skills específicas para flujos repetibles. No todos intervienen siempre, ni todos pueden escribir código. La gracia está justo en lo contrario: cada pieza tiene un ámbito y unas reglas.

La diferencia parece pequeña, pero cambia completamente el resultado. Un modelo sin contexto puede escribir código correcto en una pantalla. Un agente con contexto, límites y memoria documental puede ayudar a mover un producto real sin romper contratos internos, sin olvidar dependencias entre repositorios y sin convertir cada conversación en una explicación desde cero.

Este artículo no es una exposición completa de la infraestructura interna de Enolisa ni de sus reglas de negocio. Prefiero contar el método: cómo organizo el conocimiento para que la IA sea más útil, más controlable y más productiva.

---

El problema real: demasiados frentes para trabajar sin sistema

Enolisa no es solo una app Flutter. Alrededor hay Cloud Functions, Firebase, Firestore, SQLite local, servicios de IA, validación de compras, notificaciones push, analítica, contenido, web corporativa y herramientas internas.

También hay un negocio detrás. No trabajo solo sobre pantallas o endpoints: trabajo sobre decisiones de producto, costes de operación, límites de uso, monetización, experiencia de usuario, soporte, métricas y riesgo técnico. Una funcionalidad puede empezar como una hipótesis de negocio y terminar implicando app, backend, stores, datos, documentación y QA.

Cuando un proyecto crece así, el problema no es solo programar. El problema es mantener coherencia:

• saber qué servicio es dueño de cada responsabilidad;
• recordar qué contrato consume la app;
• validar que una Cloud Function no cambia una salida sin actualizar documentación;
• distinguir qué se puede automatizar y qué necesita confirmación manual;
• evitar que una mejora de producto rompa una regla de privacidad, sincronización o notificaciones;
• mantener una visión global sin tener todos los detalles en la cabeza todo el tiempo.

Ese es justo el tipo de contexto donde una IA mal gobernada puede acelerar el caos. Pero también es donde una IA bien gobernada multiplica la capacidad de ejecución.

La clave está en no tratar el prompt como una frase suelta, sino como una interfaz de trabajo entre la intención humana, el estado real del repositorio y las reglas operativas del proyecto.

---

Instrucciones locales: convertir conocimiento tácito en reglas explícitas

Una de las piezas más importantes de mi flujo es mantener instrucciones locales cerca del código. En vez de depender de mi memoria o de repetir contexto en cada conversación, el proyecto tiene ficheros de instrucciones y documentación que describen cómo debe comportarse un agente dentro del repositorio.

Ahí no meto secretos ni decisiones sensibles de negocio. Meto gobierno técnico:

• qué repositorios existen y cómo se relacionan;
• qué servicios son fuente de verdad para cada feature;
• qué comandos se pueden ejecutar para validar;
• cuándo hay que pedir confirmación;
• qué documentación debe actualizarse si cambia un contrato;
• qué áreas son de solo lectura;
• qué agentes especializados existen;
• qué tipo de cambios no deben hacerse de forma automática.

Esto parece documentación, pero en la práctica funciona como contexto ejecutable. El agente no tiene que descubrir desde cero que una función conecta con una pantalla concreta, que un contrato se documenta en otro repo o que un despliegue requiere confirmación explícita.

Para mí esta es una de las partes más importantes del trabajo con IA: hacer explícito lo que normalmente queda repartido entre memoria, conversaciones, notas sueltas y conocimiento tribal.

---

Subagentes: especialización sin perder ownership

Otra capa que uso son los subagentes. La idea no es lanzar agentes por lanzar, sino dividir trabajo cuando hay especialización real.

En un producto como Enolisa tiene sentido que existan perfiles operativos distintos:

• agentes para revisar internacionalización;
• agentes para formato y consistencia en Dart;
• agentes para pruebas;
• agentes para auditorías de contratos;
• agentes para inspección read-only de datos;
• agentes para áreas concretas como notificaciones, compras, sincronización o IA;
• agentes para comprobar documentación transversal.

Esto no significa que cada agente haga cambios libremente. De hecho, una parte importante del sistema es definir límites: lectura en paralelo, escritura controlada, despliegues siempre con confirmación y especial cuidado con cualquier cambio que afecte a usuarios reales.

El paralelismo es útil para tareas como leer documentación, comparar contratos, revisar logs, inspeccionar estructura o buscar inconsistencias. Pero cuando llega el momento de modificar código o cambiar comportamiento, el control vuelve a ser mucho más estricto.

La productividad no viene de delegarlo todo. Viene de saber qué se puede paralelizar, qué se debe serializar y qué decisiones siguen siendo responsabilidad humana.

---

Un ejemplo real: de decisión de negocio a sistema técnico

Un caso representativo, contado sin entrar en lógica sensible, fue el trabajo alrededor de una funcionalidad de escaneo con productos de uso tipo pack.

La pregunta inicial no era puramente técnica. No era “cómo implemento una compra” ni “cómo guardo un contador”. La pregunta real era más amplia:

• qué valor percibe el usuario;
• qué coste variable tiene cada uso;
• cómo se puede empaquetar sin romper la experiencia;
• qué ocurre si una compra se valida tarde;
• cómo se evitan inconsistencias entre app, backend y stores;
• qué métricas indican si el modelo funciona;
• qué casos deben bloquearse antes de afectar a usuarios reales.

Ese tipo de decisión cruza negocio, producto e ingeniería. Primero hay análisis de mercado y business case. Después aparece la arquitectura: contratos, estados, validaciones, recuperación ante errores y ownership de cada servicio. Luego llega la implementación: app, backend, integración con stores, persistencia, eventos y QA.

Ahí la IA no es “el programador”. Es una capa que me ayuda a mantener el mapa completo: un agente puede revisar contratos, otro puede mirar consistencia de UI, otro puede auditar documentación, otro puede validar tests o escenarios de error. Pero la decisión de negocio, el alcance y el criterio de salida siguen estando dirigidos por mí.

Ese es el punto que más valor me aporta: pasar de una hipótesis de producto a una entrega técnica sin perder el hilo entre negocio, arquitectura, desarrollo y validación.

---

Skills: encapsular formas de trabajar, no solo respuestas

Además de instrucciones y agentes, uso skills para empaquetar procedimientos concretos. Una skill no es simplemente un prompt bonito. Es una forma de decir: “cuando trabajes en este tipo de problema, sigue este flujo, mira estos archivos, aplica estas restricciones y valida de esta manera”.

Esto es especialmente útil en temas repetitivos pero delicados:

• diseño de interfaz siguiendo las convenciones del producto;
• renderizado de texto y problemas visuales;
• preparación de releases;
• revisión de documentación;
• flujos donde hay que consultar fuentes concretas antes de decidir.

La diferencia frente a improvisar es enorme. Cuando una práctica funciona, la convierto en una pieza reutilizable. Así reduzco variabilidad, evito explicaciones repetidas y hago que el agente tenga menos margen para inventar un camino alternativo que no encaja con el proyecto.

En la práctica, las skills son una forma de transformar experiencia acumulada en proceso.

---

Prompt engineering aplicado al día a día

Muchas veces se habla de prompt engineering como si consistiera en encontrar una frase mágica. Mi experiencia es casi la contraria. Los mejores resultados aparecen cuando el prompt tiene estructura operativa:

• objetivo claro;
• contexto suficiente;
• restricciones explícitas;
• archivos o rutas relevantes;
• definición de qué no se debe tocar;
• criterios de salida;
• comandos de validación esperados;
• nivel de autonomía permitido.

Un buen prompt no intenta impresionar al modelo. Intenta reducir ambigüedad.

Por ejemplo, no es lo mismo decir:

“Mejora esta feature.”

que decir:

“Revisa esta feature, identifica el contrato afectado, no cambies dependencias, no despliegues, actualiza documentación si cambias comportamiento y valida con los tests existentes.”

La segunda instrucción no solo pide una tarea. Define un marco de seguridad. Y cuando ese marco vive además en instrucciones persistentes del repo, el trabajo se vuelve mucho más repetible.

---

Documentación viva como memoria de producto

Uno de los errores más comunes al usar IA para programar es dejar que el resultado final sea solo código. Eso funciona para tareas aisladas, pero en un producto real crea deuda rápidamente.

En Enolisa intento que cada cambio importante deje rastro:

• contrato técnico actualizado;
• decisión documentada;
• rutas afectadas;
• criterios de validación;
• relación con otros módulos;
• limitaciones conocidas;
• próximos pasos si existen.

La documentación viva no es burocracia. Es memoria externa.

Cuando un agente entra semanas después en una zona del proyecto, puede leer el estado esperado, entender por qué se tomó una decisión y detectar si un cambio rompe algo. Eso permite que la IA no dependa únicamente del contexto conversacional del momento, que siempre es parcial.

Este punto me parece clave para cualquier equipo o profesional que quiera usar IA de verdad en desarrollo. El valor no está solo en generar más código. Está en construir un entorno donde el código, los contratos y las decisiones sigan alineados.

---

Control: la parte menos vistosa y más importante

Trabajar con IA de forma intensiva obliga a ser más disciplinado, no menos. Si un agente puede tocar muchos archivos rápido, también puede equivocarse rápido. Por eso mi flujo separa claramente análisis, edición, validación y acciones sensibles.

Hay reglas que para mí son básicas:

• no desplegar a producción sin confirmación explícita;
• no mutar datos reales salvo autorización muy concreta;
• no meter secretos en prompts ni documentación;
• no publicar lógica interna crítica;
• no aceptar cambios grandes sin verificación;
• no confundir “compila” con “está bien”;
• no usar la IA como excusa para dejar de entender el sistema.

La IA acelera mucho, pero el criterio técnico sigue siendo humano. El agente puede proponer, leer, comparar, implementar y validar. La responsabilidad de la dirección, el trade-off y la decisión final no desaparece.

---

El resultado: más superficie de trabajo sin perder coherencia

La consecuencia práctica de este enfoque es que una sola persona puede avanzar en muchas más capas sin trabajar de forma desordenada.

Puedo estar pensando en producto, escribir una especificación, revisar una Cloud Function, ajustar una pantalla Flutter, validar una métrica de analítica, preparar un artículo técnico y actualizar documentación de arquitectura dentro del mismo ciclo de trabajo.

En un ciclo real eso puede significar pasar por análisis competitivo, definición de modelo de monetización, diseño de experiencia, arquitectura backend, implementación móvil, validación de compras, observabilidad, QA funcional y documentación pública o interna. La IA acelera cada fase, pero sobre todo ayuda a conectarlas.

Eso no significa hacerlo todo a la vez ni hacerlo todo solo. Significa tener un sistema donde la IA ayuda a mantener continuidad entre frentes que antes quedaban demasiado separados.

Para mí, el perfil técnico que viene no es únicamente el que sabe programar una pieza aislada. Es el que sabe dirigir sistemas de trabajo completos: negocio, producto, arquitectura, implementación, validación, documentación y comunicación.

La IA no sustituye esa capacidad. La hace más visible.

---

Una forma distinta de medir productividad

La productividad con IA no debería medirse por cuántas líneas de código se generan en una tarde. Esa métrica es pobre.

Me parece más útil medir:

• cuánto contexto reutilizable se ha creado;
• cuántas decisiones quedan documentadas;
• cuánto se reduce el coste de volver a entrar en una feature;
• cuántos errores se detectan antes de producción;
• cuántas tareas paralelas se pueden investigar sin perder control;
• cuánto tarda una idea en convertirse en una especificación implementable.

Visto así, Codex no es solo una herramienta para escribir código. Es una capa de coordinación técnica.

Y cuando esa capa está apoyada en instrucciones locales, subagentes, skills y documentación viva, la IA deja de ser un atajo puntual y empieza a comportarse como una extensión real del proceso de ingeniería.