Hace 9 meses, desde el cliente con el que estoy colaborando actualmente y cómo he leído que ha pasado en tantos otros sitios, se nos lanzó un mensaje muy genérico: «usad la IA«. Así que se nos dió una licencia de GitHub Copilot sin mucho más contexto, sin formación y sin estrategia. Solo la herramienta y la instrucción.
Lo que vino después fue uno de los procesos de aprendizaje más intensos, caóticos y divertidos de mi carrera.
Los primeros pasos: útil, pero con matices
Al principio el escepticismo era generalizado. Los primeros modelos hacían su función, pero había que entender bien qué podías pedirles y qué no.
El día a día dejaba patrones claros. Las tareas grandes eran un problema, cuando la petición tenía demasiado alcance, el modelo se iba por las ramas y perdía el hilo de lo que se pedía realmente. Las planificaciones dejaban mucho que desear y muchas veces se enrocaba en una solución que no era ni mucho menos la más óptima. Y cuando se atascaba con un enfoque que no funcionaba no lo abandonaba, lo intentaba una y otra vez con soluciones a cada cual más disparatada, llegaba al punto de tener que cerrar la sesión y empezar desde 0 con otro enfoque.
Sin embargo, con tareas pequeñas, acotadas y bien contextualizadas era otra historia. Cuando le dabas trabajo bien masticado, con referencias claras y contexto preciso, el resultado era bueno y te ahorraba mucho tiempo.
La IA era útil. Pero era una utilidad frágil. Muy dependiente de cómo preguntabas, de cuánto la acotabas y de si tenías la paciencia de pedirle justo lo que te podría ofrecer.
Y entonces llegó Claude Opus.
No recuerdo exactamente la tarea, pero sí recuerdo la sensación: por fin era posible trasladar lo que se tenía en la cabeza sin tener que simplificarlo. El razonamiento era otro nivel. Y el desarrollo, sinceramente, lo hacía mejor que cualquiera de nosotros. Era como hacer trampas. Ahí se entendió de verdad lo que la IA podía llegar a ser; y también que el modelo que usas lo cambia todo.
Eso, más adelante, sería clave para entender por qué no puedes usar el mismo modelo para todo.
Cuando el QA interior entra en acción
Al poco tiempo de usar la IA, empezó a detectarse un patrón familiar. Cada respuesta dependía de demasiados factores no controlados:
- La IA alucina. Si no le indicas explícitamente que siga las buenas prácticas del proyecto, no las sigue.
- Si dos personas del equipo la usan sin un enfoque común, cada desarrollo es de su padre y de su madre.
- Sin estandarización, la IA amplifica la variabilidad en lugar de reducirla.
Estaba claro: hacía falta mecanismos que ayudaran a hacer el uso de la IA lo más determinista posible. La pregunta era cómo.
Los coworking de qualtio: donde todo cogió forma
En qualtio nos juntamos una vez al mes en coworkings donde ponemos en común todo lo que estamos viendo, probando y aprendiendo. Simplemente talento con ganas de compartir y de hacer las cosas bien.
Con el auge de la IA, era la comidilla del coworking, comentábamos para qué la usábamos, qué problemas teníamos, a cuáles nos estábamos enfrentando y, entre otras cosas, lo impresionados que estábamos, y que nos íbamos a quedar sin trabajo. En ese punto algunos compañeros ya estaban explorando skills, agentes y herramientas de estandarización. La conversación central era exactamente la que se necesitaba: cómo hacer que la IA se comporte de forma predecible y consistente en un equipo de ingeniería.
Ahí empezó la segunda fase.
Construyendo los primeros agentes
El enfoque que adoptamos fue claro: dotar a cada agente de una parte concreta del proceso de desarrollo de software.
El primer agente estaba orientado a QA: automatización de pruebas con Playwright usando el CLI y MCP de Playwright. Esto me permitió entender cómo se construye y gestiona un agente desde cero. El segundo fue más ambicioso; un agente refinador para Product Owners que, con el MCP de Atlassian, descargaba información adicional de Jira y Confluence, ayudaba al PO a redactar criterios de aceptación y, al terminar, subía la Historia de Usuario actualizada a Jira y almacenaba el conocimiento funcional en un RAG que agilizaba su proceso de búsqueda. Cada PO que lo usaba estaba alimentando un sistema que hacía cada vez más inteligente al agente.
Al ir viendo el valor de los agentes, los siguientes pasos se fueron definiendo solos: orquestación para tareas más complejas y agentes cada vez más especializados en el proceso de desarrollo. Con esta idea en mente, los equipos de backend y frontend se construyeron sus propios agentes para desarrollo con Spring Boot o Angular, pruebas unitarias, etc.
El patrón era sólido: un agente, una responsabilidad, un estándar.
La orquestación: poner a prueba la apuesta
Cuando tienes un ecosistema de agentes funcionando, el siguiente reto aparece solo: ¿cómo los conectas? En los siguientes coworkings se evaluaron muchas opciones: GentleAI, Spec-Kit, BMAD, LangGraph, sobre todo enfoques basados en SDD. Había alternativas interesantes, pero ninguna encajaba del todo con la realidad del proyecto en el que estaba. Necesitábamos algo concreto que en aquel momento ninguna ofrecía sobre Copilot: asignar un modelo distinto a cada agente del flujo.
Con la orquestación se buscaba abordar tareas complejas desde principio a fin pasando por todas las etapas del desarrollo de software de la manera más eficiente posible y ajustando los recursos al máximo. Pero el cambio de facturación de Copilot hizo que se le diera más importancia, porque acababa de convertir una intuición de diseño en una necesidad de negocio: eficientar al máximo el uso de los modelos. Y aquí es donde nuestra apuesta de meses atrás encajó como una pieza de puzzle. Si cada agente tiene una única responsabilidad, cada agente puede correr con el modelo más barato que la resuelva. La granularidad que habíamos buscado por criterio resultó ser, además, la palanca de coste.
Para confirmarlo, hice una PoC: un pequeño orquestador propio usando el SDK de Copilot, con flujos de trabajo basados en SDD y configurables mediante YAML. Un sistema donde cada agente del flujo tiene asignado el modelo más adecuado para su función:
- El agente que descubre el repositorio utiliza un modelo de bajo coste.
- El agente que planifica las tareas usa un modelo superior, porque aquí el razonamiento importa.
- Los agentes de desarrollo trabajan con el modelo adecuado para su complejidad.
- Los agentes de pruebas cierran el ciclo con modelos más asequibles.
No buscaba ser un producto. Buscaba responder una pregunta: ¿merece la pena asignar modelos por fase? La respuesta fue un sí rotundo, y nos sirvió para estandarizar criterios de coste y calidad que seguimos usando hoy.
Tomar la decisión correcta antes de que el problema llegue
Tiempo después, ya se puede trabajar de esta manera con Copilot y con otras herramientas y la PoC dejó de ser necesaria. Pero lo importante nunca fue la herramienta. Fue que, cuando llegó el cambio de facturación que podría haber sido un problema, nos pilló con los deberes hechos: un ecosistema de agentes pequeños, especializados y baratos de operar.
No acertamos por suerte. Acertamos porque desde el principio elegimos el camino de la especialización, la estandarización y la gobernanza; y esas decisiones, tomadas con criterio mucho antes de que la facturación las pusiera a prueba, son las que nos dejaron exactamente donde teníamos que estar.
La rueda no para
Nueve meses después, lo que está claro es que esto no se detiene. Cada semana aparece algo nuevo: modelos, herramientas, enfoques … y es imposible estar en todo. Pero hay algo que sí se puede controlar: la forma en que lo adoptas.
En qualtio lo hemos hecho siempre con una mirada crítica, pensando en la estandarización, la optimización y la gobernanza. Los coworkings mensuales son la prueba de que cuando hay talento que comparte lo que sabe y tiene vocación de hacer las cosas bien, el aprendizaje colectivo va mucho más rápido que el individual.
El cambio en el modelo de facturación de Copilot podría haber sido un problema. Pero tras nueve meses de trabajo, de coworkings y de tomar siempre las decisiones correctas, nos habían dejado exactamente donde teníamos que estar. El tiempo nos dio la razón: cuando construyes bien desde el principio, los imprevistos se convierten en oportunidades.
¿Estás viviendo una evolución parecida en tu equipo? Nos encantaría leerlo en los comentarios.
