Cómo formar a tu equipo de desarrollo en IA en 6 semanas
DominicodeCada vez que entro a dar una formación de IA a un equipo de desarrollo, hago la misma pregunta antes de encender el proyector: ¿qué no le dejáis hacer a la IA?
Y casi siempre pasa lo mismo. Silencio. No un silencio incómodo: un silencio de gente que nunca se lo había planteado porque nadie se lo había preguntado.
Formar a tu equipo de desarrollo en IA no consiste en repartir licencias ni en enseñar a escribir prompts: consiste en acordar por escrito qué se delega a la IA, cómo se revisa lo que genera y quién responde cuando falla. Eso es justo lo que ese silencio deja al descubierto.
Al rato alguien contesta: "lo crítico lo revisamos bien". Pregunto qué es crítico. Salen tres definiciones distintas en la misma sala, y las tres personas llevan dos años trabajando en el mismo repositorio.
Ahí está el problema entero. No es que el equipo no sepa usar la herramienta. Es que cada uno decide por su cuenta dónde termina la máquina y dónde empieza él.
Comprar licencias no es formar a tu equipo de desarrollo en IA
El patrón se repite en casi todas las empresas que me llaman. Dirección aprueba las licencias, se manda un email de anuncio, se hace una demo de una hora, y a partir de ahí "el equipo ya usa IA".
Seis meses después sube la actividad. Más commits, más PRs, más líneas. Y nadie en esa organización sabe decir si el equipo va mejor o solo va más rápido cuesta abajo.
Los datos del sector cuentan esa misma historia. El informe DORA 2025 sobre desarrollo asistido por IA, con casi 5.000 profesionales encuestados, encontró que el 90% ya usa IA en su trabajo y más del 80% cree que le hace más productivo.
Pero un 30% reconoce tener poca o ninguna confianza en el código que esa IA genera. Trabajamos a diario con algo en lo que no confiamos.
La encuesta a desarrolladores de Stack Overflow 2025 afina el diagnóstico: la frustración número uno, citada por el 66%, son las soluciones "casi correctas, pero no del todo". Y hay más gente que desconfía de la precisión de estas herramientas (45,7%) que gente que confía (32,7%).
Lee eso otra vez con gorra de manager. El trabajo de tu equipo se ha desplazado a detectar lo casi-correcto. Eso no es una habilidad de herramienta. Es criterio.
La conclusión más incómoda del informe DORA cabe en una frase suya: "AI doesn't fix a team; it amplifies what's already there". La IA no arregla un equipo, magnifica lo que ya había. Un equipo con estándares claros se vuelve más rápido y más consistente. Un equipo sin criterio compartido genera incoherencia a mayor velocidad y con mejor presentación.
Por eso la adopción no es la competencia. El porcentaje de gente con la extensión instalada es una métrica de compras, no de ingeniería.
Qué es exactamente "la parte de criterio" (en operativa, no en filosofía)
Cuando digo criterio no hablo de sabiduría abstracta. Hablo de cuatro decisiones que alguien de tu equipo toma cada día, casi siempre sin acuerdo.
Uno: qué se delega y qué no. Las tareas con dependencias de estado y decisiones encadenadas necesitan supervisión constante; las independientes y verificables se pueden lanzar en paralelo sin drama. Desarrollé esa separación en cómo clasificar tareas con IA en desarrollo de software, y es el primer acuerdo que debería tener un equipo por escrito.
Dos: cómo se revisa código que no escribió un humano. Revisar el código de un compañero es revisar una intención que puedes preguntar. Revisar un diff generado es revisar una salida sin intención detrás. Menos estilo y naming, más "¿esto resuelve nuestro problema o uno parecido?".
Tres: quién firma lo que sale a producción. Autoría y responsabilidad se han separado, y muchos equipos no lo han asumido. El modelo no está de guardia a las tres de la mañana. Si no hay un nombre humano pegado a ese despliegue, no hay dueño.
Cuatro: qué haces cuando la propuesta funciona pero está mal. Este es el caso difícil. Pasa los tests, hace lo que pedía el ticket, y mete un patrón que dentro de cuatro meses te obliga a reescribir un módulo. Un dev con criterio lo rechaza aunque esté verde. Uno sin criterio lo mergea porque está verde.
| Decisión de criterio | Síntoma cuando falta |
|---|---|
| Qué se delega | Cada dev tiene su umbral y la base de código parece escrita por cinco equipos |
| Cómo se revisa | Aprobaciones rápidas en diffs de 400 líneas que nadie ha leído entero |
| Quién firma | Cuando algo rompe, la primera frase es "eso lo generó la IA" |
| Funciona pero está mal | Deuda técnica nueva cada sprint, sin ninguna decisión que la haya causado |
Lo que la IA se ha llevado es la parte mecánica; escribí sobre ese desplazamiento en lo que cambió de verdad en el desarrollo con IA. Lo que queda es esta lista. Y esta lista es justo la que nadie está formando.
El problema de los juniors: le has quitado su gimnasio
Delegar a la IA el trabajo de bajo valor elimina justo las tareas con las que un junior se hacía senior. Es la parte de la que menos se habla y la que más me preocupa.
El CRUD repetitivo, el test aburrido, el refactor pequeño, el bug tonto de dos horas: trabajo de bajo valor para la empresa y de altísimo valor para el que empezaba. Ahí aprendía un junior a leer un stack trace, a oler dónde rompe algo y a intuir por qué una decisión de ayer duele hoy.
Si delegas ese bloque entero, el junior no se convierte en senior. Se convierte en revisor de algo que no sabe evaluar. Y un revisor sin criterio aprueba con una seguridad que asusta.
No te digo que prohíbas la IA a los juniors: eso los deja fuera del mercado. Te digo que rediseñes por dónde entra el aprendizaje, con tres reglas que puedes implantar esta semana:
- Primero a mano, después con IA. Elige dos o tres categorías de tarea (tests de lógica de negocio, consultas a base de datos) donde el junior hace la primera implementación sin asistente. A partir de la segunda, con lo que quiera. El objetivo no es sufrir: es tener un modelo mental propio contra el que comparar. Esto va por confianza, y la que lo hace cumplir de verdad es la regla siguiente.
- Prohibido "no sé por qué funciona". Si no puede explicar el diff línea a línea en la revisión, no se mergea. Acótalo para que sobreviva al tercer mes: en los PRs que tocan lógica de negocio, y durante los primeros meses de cada junior. Un senior sentado en todos los PRs de todos los juniors no escala más allá de dos.
- PR saboteado semanal. Un senior coge un PR generado con IA, le planta un fallo real (una condición invertida, un
awaitque falta, un índice que se cae en la query nueva) y se lo pasa al junior. Tres condiciones para que esto no acabe siendo una novatada: el junior sabe que es un ejercicio y que hay un fallo, la rama vive fuera del flujo de merge para que nadie la apruebe por error, y al terminar se enseña el fallo aunque no lo haya encontrado. No se puntúa. Treinta minutos. Y una vez al mes se invierte: el junior sabotea y busca el senior. Es el ejercicio más barato y más eficaz que conozco para entrenar la mirada.
Las tres cuestan tiempo de las personas más caras del equipo — cuenta unas 2 horas de senior por junior y semana. Es el precio real de que dentro de dos años tengas seniors.
Y un cuarto movimiento que cambia el rol: que el junior escriba la especificación y la IA implemente. Deja de aprender tecleando y empieza a aprender decidiendo, que es donde está el valor ahora. Es la base de por qué el spec define hoy tu ventaja competitiva, y el método completo está en el libro de Spec-Driven Development.
Si buscas algo que darle a un junior para que recorra ese camino por su cuenta, el curso Construye con IA va justo de eso: de la idea al producto decidiendo, no tecleando.
Criterio compartido: el acuerdo que tu equipo debería tener escrito
Un equipo donde cada dev tiene su propio umbral de delegación no tiene un problema de talento. Tiene un problema de varianza.
Cinco personas razonables tomando cinco decisiones razonables distintas producen una base de código incoherente. Y eso no se detecta en el PR: se detecta seis meses después, cuando hay tres formas de hacer lo mismo y nadie sabe cuál es la buena.
La solución no es un curso. Es un documento de una página que el equipo redacta y firma. Un acuerdo de uso de IA es ese documento: fija, por categoría de tarea, qué se delega al modelo, con qué nivel de revisión y quién tiene que dar el visto bueno. Cabe en esto:
| Categoría | Regla | Quién aprueba |
|---|---|---|
| Qué se le pega al modelo | Nunca secretos, credenciales ni datos reales de cliente: sintéticos o anonimizados. Solo herramientas aprobadas por la empresa | Autor del PR |
| Scaffolding, boilerplate, migraciones sin cambio de esquema | Se delega completo | Autor del PR |
| Tests de lógica existente | Se delega, revisión normal. El test tiene que fallar al menos una vez antes de aprobarse | Autor del PR |
| Refactor que cruza módulos o toca una API pública | Se delega la implementación, el plan lo escribe un humano | Autor + un revisor |
| Auth, permisos, pagos, datos personales | Se puede generar, revisión obligatoria de dos personas | Owner del módulo |
| Cambios de esquema en producción | No se delega la decisión | Tech lead |
| Infra, pipelines de CI/CD y secretos | No se delega la decisión | Tech lead |
| Dependencias nuevas | La IA propone, un humano aprueba antes de que entre en el package.json |
Tech lead |
La fila de los tests es la que más gente se salta y la que más caro sale: un test generado certifica el comportamiento actual, bug incluido. Si rompes a mano lo que prueba y sigue en verde, ese test no vale nada.
Tres reglas al pie del documento que valen más que la tabla:
- Toda excepción se justifica en una línea dentro del PR. Una línea, no un ensayo.
- Quien abre el PR responde del código, lo haya escrito él o no. La tabla dice quién aprueba; la responsabilidad no se reparte.
- El acuerdo se revisa cada trimestre. Si crece a ocho páginas, nadie lo lee y deja de existir.
Métetelo en el repositorio, no en Confluence. En el CONTRIBUTING.md, en el CLAUDE.md o en el AGENTS.md, donde lo lean el equipo y los agentes. Y protege con CODEOWNERS las rutas críticas, pero acuérdate de activar en la rama principal la regla "Require review from Code Owners": sin esa casilla, CODEOWNERS sugiere revisores y no bloquea nada. Con la casilla puesta, el acuerdo deja de depender de la memoria de nadie un viernes a las siete.
Y si quieres el punto de partida, este es el bloque que pego yo en el repo:
# Acuerdo de uso de IA — v1
Revisión: cada trimestre. Si crece a 8 páginas, deja de existir.
| Categoría | Regla | Quién aprueba |
|---|---|---|
| Qué se le pega al modelo | Nunca secretos ni datos reales de cliente | Autor del PR |
| Scaffolding, boilerplate, migraciones sin cambio de esquema | Se delega completo | Autor del PR |
| Tests de lógica existente | Se delega. Debe fallar una vez antes de aprobarse | Autor del PR |
| Refactor que cruza módulos o toca API pública | El plan lo escribe un humano | Autor + revisor |
| Auth, permisos, pagos, datos personales | Revisión de dos personas | Owner del módulo |
| Cambios de esquema en producción | No se delega la decisión | Tech lead |
| Infra, CI/CD y secretos | No se delega la decisión | Tech lead |
| Dependencias nuevas | La IA propone, un humano aprueba | Tech lead |
1. Toda excepción se justifica en una línea dentro del PR.
2. Quien abre el PR responde del código, lo haya escrito él o no.
3. Nada se mergea si el autor no lo puede explicar línea a línea.
Facilitar esa redacción con el equipo delante —y que salga en una sesión, no en tres meses de hilo de Slack— es la mitad del trabajo de una formación en IA para equipos de desarrollo. El documento no vale por lo que dice: vale porque lo escribieron ellos.
Cómo medir si la formación en IA de tu equipo sirvió de algo
La formación funcionó si el equipo converge: si ante el mismo ticket da menos respuestas distintas que antes de empezar. Lo que no sirve es medir líneas de código o PRs mergeados — con IA esas dos suben aunque el equipo esté empeorando. Ya conté qué medir en un equipo que usa IA en lugar de eso.
Para evaluar la formación en concreto uso una medida que no vas a encontrar en ningún dashboard, porque me la inventé yo: la dispersión de criterio, es decir, cuántas respuestas distintas da tu equipo cuando le preguntas qué delegaría de un mismo ticket. Se mide así.
Coges cinco tickets reales del backlog y preguntas a cada dev, por escrito y en anónimo, si los delegaría enteros, en parte o nada. Anotas el reparto antes de empezar. Seis semanas después repites el ejercicio con cinco tickets distintos pero del mismo perfil: si repites los mismos, lo que mides es si se acuerdan del acuerdo que firmaron, no si tienen criterio.
Mira cuánta gente coincide en la opción mayoritaria de cada ticket. Si en la primera ronda el equipo se reparte entre las tres opciones y en la segunda ocho de cada diez coinciden, la formación funcionó. Si sigue repartido, has pagado una charla.
Un detalle que evita el autoengaño: mete entre los cinco un ticket que ya salió mal en producción por haberlo delegado. Ese te dice si el equipo converge hacia el criterio bueno o simplemente converge hacia el que habla más alto en las reuniones.
Añade tres indicadores de salud que ya deberías estar mirando: ciclos de revisión por PR, defectos que llegan a producción y tiempo de recuperación cuando algo rompe. El último es el más revelador, porque un equipo que no entiende el código que desplegó tarda muchísimo en arreglarlo.
Y una métrica que no debes usar jamás: porcentaje de código generado por IA. Es vanidad pura y encima incentiva justo lo contrario de lo que quieres.
Plan de 6 semanas para formar a tu equipo de desarrollo en IA
Nada de trimestres ni de planes estratégicos: esto empieza el lunes. Seis semanas, una o dos sesiones por semana, y cada semana cierra con un entregable — diagnóstico, borrador del acuerdo, acuerdo firmado en el repo y segunda medición de dispersión.
| Semana | Qué haces | Entregable |
|---|---|---|
| 1 | Diagnóstico, sin formación. Cada dev trae el PR más grande del último mes que se aprobó en menos de diez minutos, y se lee en voz alta en una sesión de 60 min. Se anotan de paso los términos donde el equipo no coincide | Foto real del punto de partida, glosario común y medición inicial de dispersión |
| 2-4 | Criterio en vivo. Dos sesiones semanales revisando PRs reales del repo, no ejemplos de juguete. Cada sesión añade una línea al acuerdo | Borrador del acuerdo de uso de IA |
| 3 | Arranca en paralelo la pista de juniors (primero a mano, PR saboteado) y sigue corriendo hasta el final | Rutina semanal instalada |
| 5 | Se cierra y se firma el acuerdo v1. Se mete en el repo y se cablea lo automatizable: bloquear PRs que tocan package.json sin aprobación del tech lead, límite de tamaño de diff, y el check de que la línea de justificación está en la descripción del PR |
Acuerdo v1 en producción |
| 6 | Segunda medición de dispersión y retro | Comparativa antes/después |
Coste total: entre 8 y 10 sesiones en seis semanas, alrededor de hora y media por persona y semana. Ese es el número que necesitas para venderlo hacia arriba.
Las semanas 2, 3 y 4 deciden el resultado. Es donde el equipo discute casos concretos con el código delante y donde salen los desacuerdos que llevaban meses enterrados. Si te saltas esa parte y das teoría, acabas con gente que recita buenas prácticas y sigue mergeando lo que no entiende.
Fíjate en que no hay ninguna semana de vocabulario. Si el 90% del equipo ya usa IA a diario, dedicar cinco días a explicar qué es una ventana de contexto es formación para un equipo que no tienes: los términos salen solos en la sesión de diagnóstico, y ahí se anotan.
Si prefieres no llevar esto tú solo, es exactamente el trabajo que hago con equipos internos: seis semanas, adaptadas al stack real y con el acuerdo saliendo de los PRs del propio repo. Así funciona una formación para tu equipo.
Por dónde empiezas el lunes
Reúne al equipo cuarenta y cinco minutos, pon tres tickets reales encima de la mesa y que cada uno diga qué delegaría de cada uno. No pidas opiniones generales: vas a ver la dispersión en directo, y ese reparto es tu punto de partida.
La herramienta se compra en una tarde. El criterio se acuerda, se escribe y se revisa. Esa diferencia es todo lo que separa a un equipo que usa IA de un equipo que la aprovecha.
Preguntas frecuentes
¿Cuánto tiempo necesita un equipo para formarse en IA de verdad?
Seis semanas para tener criterio compartido y un acuerdo escrito funcionando. La parte técnica pura son entre 8 y 24 horas según el nivel, pero sin las sesiones de revisión sobre código real el conocimiento no se convierte en práctica de equipo.
¿Sirve este plan para un equipo de 3 personas? ¿Y para 40?
Para 3 sí, comprimido: las semanas 2, 3 y 4 se hacen en dos. Por debajo de 3 el acuerdo no aporta gran cosa, porque no hay varianza que reducir.
Por encima de 15 no funciona en una sola sala: se hace por squad, cada uno redacta su acuerdo y luego se consolidan las reglas comunes en el repositorio raíz.
¿Debo prohibir la IA a los juniors hasta que tengan más nivel?
No, eso los deja fuera del mercado y además la usarán igual sin que te enteres. Lo que sí funciona es acotar dónde la usan: que hagan la primera implementación de ciertas categorías de tarea sin asistente, y que no mergeen nada que no sepan explicar línea a línea.
¿Quién es responsable si el código generado por IA rompe producción?
Quien abrió el pull request. La autoría del código y la responsabilidad sobre él se separaron, y la única forma de que un sistema siga funcionando es que la responsabilidad se quede pegada a un nombre humano. Escríbelo en el acuerdo del equipo antes de que ocurra el primer incidente.
¿Cómo justifico ante dirección invertir en formación si ya pagamos las licencias?
Con la diferencia entre adopción y resultado. La licencia demuestra que la gente usa la herramienta; no dice nada sobre defectos en producción, ciclos de revisión ni tiempo de recuperación. Lleva esos tres números a la reunión junto con la medición de dispersión de criterio y la conversación cambia de tono.
¿Qué hago si un dev senior se niega a usar IA?
Escúchale primero, porque su objeción suele ser de calidad y suele tener parte de razón. Después conviértelo en el dueño de la parte de revisión del acuerdo: la gente que desconfía escribe las mejores reglas de control, y así deja de ser un bloqueo para ser una garantía.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.