Hemos pasado de pedirle código a la IA y corregirlo después a diseñar el sistema que guía su comportamiento. Pedir a un asistente de programación que genere un componente suele devolver código limpio y funcional a primera vista, pero al inspeccionarlo aparecen problemas: introduce librerías de iconos que no usamos, ignora la estructura estricta de carpetas del proyecto o cifra valores de espaciado en lugar de usar la escala del sistema de diseño. El resultado habitual es un ir y venir constante con el modelo, refactorizaciones y correcciones arquitectónicas.
La raíz del problema no era tanto la calidad del código, sino la falta de contexto. La IA actúa como un desarrollador junior con buena sintaxis pero sin conocimiento de las convenciones locales, restricciones o intención del equipo. Mejorar prompts ayuda, pero lo que funcionó mejor fue un cambio estructural: tratar la interacción con la IA como un problema de diseño de sistema.
En lugar de usar la IA como una herramienta conversacional, la transformé en un motor programable y dentro del repositorio introduje gradualmente una estructura basada en ficheros que gobierna cómo se comporta la IA en distintas tareas. No aspira a ser inteligente por sí misma, sino a cargar contexto de forma explícita. Algunos protocolos están siempre disponibles y otros se activan solo cuando añaden valor, por ejemplo mediante señales como @plan o @deep-think. Con el tiempo esto evolucionó hacia un modelo de trabajo consistente.
El primer cambio fue crear un punto de entrada único que actúa como centralita. Los grandes prompts con muchas reglas no escalan: cuando las instrucciones se acumulan el comportamiento se vuelve difícil de razonar. En su lugar, reutilicé un fichero de convención como capa de enrutamiento. No contiene reglas detalladas, apunta a ellas. Por ejemplo, si el usuario invoca @plan se carga la guía de arquitectura; con @ui-perfect se cargan las reglas del sistema de diseño; con @test se habilitan los protocolos de QA. Los prompts pequeños se mantienen ligeros y las tareas complejas cargan contexto adicional de forma explícita, lo que reduce el comportamiento impredecible.
Para decisiones donde hay compensaciones uso un paso dedicado llamado @deep-think. En este modo el modelo debe examinar el problema a nivel de sistema, proponer varias aproximaciones y dejar claros riesgos y restricciones. Suelo estructurar el razonamiento con una rúbrica tipo semáforo: BLOCKER para conflictos claros, WARNING para opciones viables con trade-offs y OPTIMAL para soluciones alineadas y mantenibles. La clave no son las etiquetas sino la obligación de justificar las decisiones antes de implementar. Además, exijo que la IA busque en el código existente antes de proponer soluciones nuevas, lo que reduce duplicación y deriva arquitectónica.
Para funcionalidades grandes o de larga duración introduzco opcionalmente ficheros de gobernanza que fijan límites de arquitectura, convenciones de estilo y anti-patrones conocidos. Estos ficheros no están pensados para la documentación humana, sino para anclar el comportamiento de la IA. Son optativos: para trabajos pequeños o exploratorios los omito; la idea es apalancar el esfuerzo de forma medible, no añadir burocracia.
Otro ajuste útil fue separar planificación de ejecución. En lugar de pedir que la IA planifique y construya al mismo tiempo, divido el proceso en pasos. @plan produce un documento PLAN.md que describe ficheros afectados, flujo de datos de alto nivel, límites modulares, contratos y consideraciones de testeo sin generar código. Después de revisar y aceptar el plan, ejecuto @build, donde la IA trata el plan como especificación e implementa. Esta separación reduce cambios estructurales no deseados.
La precisión visual suele ser un área problemática cuando la IA genera UI. Para casos donde la exactitud importa uso un paso @ui-perfect: primero analizar layout y espaciados desde el diseño, mapear medidas a tokens del sistema de diseño y solo entonces implementar. Separar el análisis de la implementación mejora la consistencia cuando la fidelidad visual es crítica.
Un flujo típico de trabajo quedó así: ejecutar @plan y revisar PLAN.md, ejecutar @build tras la aprobación, validar comportamiento, ejecutar @ui-perfect si se necesita precisión visual, extraer preocupaciones y finalmente @test. El proceso no es complejo, pero gana predictibilidad: la toma de decisiones se aplica antes de generar código, no después corrigiendo.
En Q2BSTUDIO aplicamos este enfoque en nuestros proyectos de desarrollo de software a medida y aplicaciones a medida para garantizar que la IA aporte valor real sin introducir deriva técnica. Como empresa especializada en inteligencia artificial y servicios de software a medida combinamos esa disciplina de diseño con experiencia en ciberseguridad, servicios cloud aws y azure y servicios inteligencia de negocio. Si buscas integrar IA para empresas o crear agentes IA que funcionen dentro de reglas y gobernanza claras podemos ayudarte a definir esos sistemas y a implementarlos con prácticas de calidad.
Nuestros servicios cubren desde la creación de soluciones críticas con software a medida hasta plataformas inteligentes y seguras respaldadas por buenas prácticas de ciberseguridad y pruebas, además de despliegues en la nube con inteligencia artificial integrada. También trabajamos con inteligencia de negocio y Power BI para transformar datos en decisiones accionables. Este enfoque sistemático reduce la fricción entre automatización y arquitectura y permite escalar agentes IA y soluciones empresariales manteniendo coherencia, seguridad y valor de negocio.
El resultado no elimina la necesidad de juicio humano, pero cambia dónde se aplica: en definir el contexto y las reglas que guían la generación, en lugar de corregir salidas que no encajan. Esa inversión inicial en diseño de sistema es la que hace que la IA deje de ser una caja negra impredecible y pase a ser una componente fiable en el ciclo de vida del software.