Programación con IA en equipos: reglas que ayudan

Qué dice la investigación

No esperes automáticamente un gran salto. En un estudio aleatorizado de METR de 2025, desarrolladores experimentados de código abierto tardaron cerca de un 19 % más con IA en tareas de proyectos conocidos, y aun así creían ir más rápido. La muestra era pequeña, las herramientas evolucionan deprisa y la propia METR considera ahora que el panorama ha cambiado.

La lección para tu equipo no es que «la IA no aporta nada», sino que sentirse más rápido no es una prueba. Mídelo.

Regla 1: Aclara primero los datos

¿Qué herramientas se permiten y con qué contrato?
¿Se usa el código para entrenar? Comprueba el ajuste de tu plan, no la página publicitaria.
¿Qué nunca debe ir en un prompt: datos de clientes, credenciales, código ajeno bajo confidencialidad?
Si tratas datos personales en la UE, también hay que aclarar el encargo de tratamiento.

Si no hay herramientas permitidas, la gente usa alguna igualmente, solo que sin que lo sepas.

Regla 2: El autor sigue siendo el responsable

Quien abre la pull request la ha entendido y puede explicarla. «Lo escribió la IA» no es un motivo. Esta sola regla evita muchos problemas.

Regla 3: Cambios pequeños

La IA facilita generar mil líneas, y los revisores tienden a aprobar porque no pueden leerlo todo. Limita el tamaño de los cambios. La revisión se convierte en el cuello de botella, y ahí se decide la calidad.

Regla 4: Primero pruebas e integración continua

Los agentes funcionan bien si pueden comprobar sus resultados: pruebas, linters, comprobación de tipos, análisis de seguridad. Sin estas barreras, solo gestionas errores más rápidos. Exige también una prueba que falle antes de arreglar un error. Si no, los modelos cambian la prueba hasta que pase.

Regla 5: Escribe las reglas del proyecto para el modelo

Guarda en el repositorio un archivo con convenciones, comandos, decisiones de arquitectura y prohibiciones. La mayoría de las herramientas lo leen automáticamente. Ahorra correcciones y da a todos las mismas instrucciones.

Dónde suele ayudar la IA y dónde menos

Suele ir bien	Más arriesgado
Entender código ajeno	Autenticación y permisos
Pruebas, migraciones, código repetitivo	Pagos y criptografía
Prototipos desechables	Grandes cambios sin pruebas
Depuración con registros claros	Bibliotecas desconocidas sin revisar

Agentes, con cuidado

Los agentes que ejecutan comandos necesitan límites: sin acceso a datos de producción, sin credenciales duraderas y con los cambios pasando por la revisión normal. El contenido de la web o de los tickets puede incluir instrucciones ocultas. Trátalo como datos no fiables.

Cómo medir el beneficio

Las líneas de código no sirven como medida. Son mejores:

El tiempo desde la tarea hasta producción
La tasa de fallos y reversiones tras el despliegue
La duración y el tamaño de las revisiones
La opinión del equipo sobre la mantenibilidad a los pocos meses

Mide antes de la implantación para tener una referencia. Empieza con un equipo y un periodo limitado, no con todos a la vez.

No olvides a los perfiles júnior

Quien deja que la IA resuelva cada tarea no aprende a revisar, algo imprescindible más adelante. Planifica tareas que se resuelvan primero sin ayuda y haz que justifiquen las sugerencias de la IA en la revisión.

Para apps ya creadas, ayuda la lista antes del lanzamiento. Si quieres apoyo en la implantación: programación con IA con tob-apps.

Introducir la programación con IA en un equipo