Si estás comparando un taller de dos días con un acompañamiento de varias semanas para que tu equipo trabaje con agentes de código, lo más probable es que estés comparando precios. Es la comparación equivocada.
La idea que defiende este insight: un taller enseña qué hace la herramienta; lo que cambia la entrega de un equipo es cómo escribe lo que hay que construir, cómo revisa lo que produce el agente y dónde decide una persona. Eso no se aprende en un aula, se instala trabajando. Por eso la pregunta útil no es cuánto cuesta el taller, sino qué queda en el equipo al cabo de tres meses.
Para qué sirve un taller (y para qué no)
Un taller no es una pérdida de tiempo. Sirve para que todo el equipo vea lo mismo, comparta un vocabulario y pierda el miedo a probar. Lo que no puede hacer en dos días es cambiar hábitos que se construyen con decisiones repetidas sobre código real: qué se pide al agente, contra qué se compara lo que devuelve y quién lo aprueba. La tabla es nuestra:
| Cabe en un taller | Solo se instala trabajando |
|---|---|
| Qué hace el agente y cómo se le pide algo | Escribir la especificación de una tarea real antes de pedir el código |
| Ejemplos preparados para aprender | Los casos del propio código del equipo, que no siempre salen bien |
| Buenas prácticas de revisión en general | Revisar cada cambio contra unos criterios de aceptación acordados antes |
| Un vocabulario común | Un contexto escrito en el repositorio (convenciones, decisiones, límites) que el equipo mantiene |
| Entusiasmo el lunes siguiente | Alguien a quien preguntar cuando el agente se equivoca en la tercera semana |
Elaboración de onext
Lo que dice la evidencia, y lo que no
No conocemos un estudio que mida cuánto tarda un equipo de desarrollo en cambiar su forma de trabajar con agentes. Hay señales sueltas que apuntan en la misma dirección.
La primera es de DORA, el programa de investigación sobre equipos de software de Google Cloud. Su informe de 2025 sobre el desarrollo asistido por IA dice que el papel principal de la IA es el de un amplificador, que magnifica las fortalezas y las debilidades que la organización ya tenía, y que los mayores retornos no vienen de las herramientas, sino del sistema organizativo que hay debajo. Si lo que se amplifica es el método del equipo, el método es lo que hay que trabajar.
Su modelo de capacidades para equipos con IA va en la misma línea. Las siete capacidades que identifica incluyen una postura clara y comunicada sobre el uso de la IA, prácticas sólidas de control de versiones y trabajar en lotes pequeños. Nuestra lectura: son prácticas de equipo, no contenidos de un curso. Se tienen o no se tienen en el día a día.
La tercera es una mención de pasada, pero significativa: la página del informe de DORA sobre el retorno de la IA en desarrollo, actualizada el 22 de abril de 2026, habla de gestionar la «caída de productividad» inicial de un despliegue nuevo. No dice cuánto dura ni cuánto cae. Dice que existe, y eso ya basta para no esperar resultados el lunes después del taller.
La cifra que más circula sobre el tiempo de adopción es de Microsoft: según una encuesta a 1.300 usuarios de Microsoft 365 Copilot, a las 11 semanas la mayoría dice que la herramienta mejora su trabajo, y Microsoft recomienda animar a la gente a seguir usándola hasta entonces porque crear hábitos nuevos lleva tiempo.
Riesgo El dato de las 11 semanas es una encuesta de percepción publicada por el propio fabricante en marzo de 2024, entre usuarios de Microsoft 365 Copilot (incluidos empleados de Microsoft) con al menos tres semanas de uso. No son desarrolladores ni agentes de código. Lo citamos solo como señal de orden de magnitud: semanas, no días.
Y luego está lo obvio, que también tiene evidencia: lo que no se practica se olvida. Jaap Murre y Joeri Dros replicaron en 2015 la curva del olvido de Ebbinghaus, con un solo sujeto que aprendía listas y las reaprendía al cabo de minutos, horas o días. Es un experimento de memoria y no dice nada sobre equipos de software; lo usamos solo para recordar que un taller sin práctica posterior se olvida.
Al comparar formatos, la pregunta útil no es cuánto cuesta el taller, sino qué queda en el equipo al cabo de tres meses.
Qué se instala trabajando
El centro del método es escribir antes de pedir. Con Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, lo que tiene que cumplir un cambio se escribe antes del código, y el agente trabaja contra eso. Lo explicamos en Spec-Driven Development con IA. Las plantillas para empezar están al alcance de cualquiera; lo que no viene en la plantilla es el método del propio equipo, y ese método se ajusta tarea a tarea.
Lo mismo pasa con la revisión. Revisar contra unos criterios escritos antes es más rápido que leer un cambio entero e intentar adivinar qué se quería, pero solo se consigue cuando el equipo lo ha hecho decenas de veces. Cuando no se hace, la ganancia del agente se queda esperando en la revisión, como contamos en más código, la misma entrega. Y sin ese método, lo que sube es la velocidad, no la estabilidad: con IA tu equipo entrega más rápido, pero no más estable.
La tercera parte del método es la red: control de versiones, pruebas y una forma clara de deshacer lo que haga el agente, que conviene tener antes de dar el agente al equipo. Y la última, una persona que decide donde hay riesgo. Ninguna de estas partes se aprende mirando; todas se aprenden equivocándose con algo que importa y corrigiéndolo con ayuda.
Cómo se hace sin parar las entregas
La objeción habitual a un acompañamiento de semanas es que el equipo no puede parar. No hace falta parar las entregas: el Quick-start trabaja con un equipo piloto, sobre trabajo real ya planificado y en paralelo a su sprint. Se trabaja sobre algo que había que entregar igualmente.
Empezar por un equipo concreto tiene una ventaja más. El uso de los agentes de código se extiende sobre todo entre compañeros, y con él viaja la forma de usarlos, como vimos en los agentes de código no se adoptan por decreto, se contagian. Un equipo piloto que trabaja con método y a la vista es lo que luego copian los demás.
La prueba de los tres meses
Sea cual sea el formato que elijas, a los tres meses se puede comprobar si el método se ha quedado en el equipo. No hace falta encuesta; basta con mirar el repositorio y una reunión de revisión:
- Los cambios del agente nacen de una especificación escrita antes del código, no de una petición en el chat que nadie más ha leído.
- La revisión compara el cambio con unos criterios de aceptación; no se limita a leerlo y dejar comentarios.
- El contexto del equipo (convenciones, decisiones, límites del agente) está escrito en el repositorio y alguien lo mantiene.
Si a los tres meses no se ve ninguna de las tres cosas, el equipo aprendió la herramienta, pero no cambió el método. Qué indicadores de entrega mirar además está en KPIs de equipos de desarrollo con IA.
Empieza con un taller, sigue con el método. Si quieres dar el primer paso, tienes el taller online de SDD de onext.
Si quieres ver con alguien de fuera qué le haría falta a tu equipo, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development.
Preguntas frecuentes
¿Sirve un taller de IA para un equipo de desarrollo?
Sirve para empezar: el equipo ve qué hace la herramienta, comparte un vocabulario y pierde el miedo a probarla. Lo que no cambia en dos días es cómo entrega el equipo: cómo escribe lo que hay que construir, cómo revisa lo que produce el agente y dónde decide una persona. Eso se instala con el trabajo real del equipo.
¿Cuánto tarda un equipo de desarrollo en adoptar la IA?
No conocemos una cifra fiable para equipos de desarrollo. La que más circula, las 11 semanas de Microsoft, es una encuesta de percepción a usuarios de Microsoft 365 Copilot publicada por el propio fabricante. DORA, por su parte, habla de una caída de productividad inicial al desplegar la IA, sin decir cuánto dura. Microsoft habla de semanas y DORA no da plazo; ninguna de las dos habla de días.
¿Qué diferencia hay entre formar en una herramienta y cambiar el método del equipo?
Formar en la herramienta enseña qué puede hacer el agente. Cambiar el método es decidir cómo trabaja el equipo con él: especificaciones escritas antes del código, criterios contra los que se revisa, cambios pequeños y una persona que decide donde hay riesgo. Lo primero cabe en un aula; lo segundo solo se comprueba con trabajo que llega a producción.
¿Hay que parar las entregas para implantar un método nuevo con IA?
No hace falta parar las entregas: el Quick-start trabaja con un equipo piloto, sobre trabajo real ya planificado y en paralelo a su sprint. Es la diferencia con un taller: se trabaja sobre algo que el equipo tenía que entregar igualmente.
¿Qué conviene preguntar antes de contratar un taller o un acompañamiento de IA?
Una sola pregunta ordena la comparación: qué quedará en el equipo y en su repositorio dentro de tres meses. Si la respuesta es el material del curso, es formación. Si son especificaciones, criterios de revisión y un contexto escrito que el equipo mantiene, es método.
¿Qué se puede comprobar a los tres meses para saber si el método se ha instalado?
Tres cosas que se ven sin encuesta: si los cambios del agente nacen de una especificación escrita antes, si la revisión compara el cambio con unos criterios y no solo lo lee, y si el contexto del equipo (convenciones, decisiones, límites) está escrito en el repositorio y alguien lo mantiene.
Fuentes
- DORA, «State of AI-assisted Software Development 2025» (la página solo indica el año), consultado el 25 de octubre de 2026.
- Kevin M. Storer y Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de septiembre de 2025.
- DORA, «ROI of AI-assisted Software Development report», página actualizada el 22 de abril de 2026.
- Microsoft WorkLab, «AI Data Drop: The 11-by-11 Tipping Point», 19 de marzo de 2024 (encuesta a 1.300 usuarios de Microsoft 365 Copilot).
- Jaap M. J. Murre y Joeri Dros, «Replication and Analysis of Ebbinghaus' Forgetting Curve», PLOS ONE, 6 de julio de 2015.
- Las citas de fuentes en inglés están traducidas por onext. La tabla, la prueba de los tres meses y la lectura de las capacidades de DORA como prácticas de equipo son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →