Casi todos los equipos de ingeniería usan ya asistentes de programación con IA de alguna forma. En la Stack Overflow Developer Survey 2025, el 84% de los encuestados dijo que usa o piensa usar herramientas de IA en su proceso de desarrollo. Sin embargo, la misma encuesta muestra que hay más desarrolladores que desconfían de la precisión de estas herramientas que desarrolladores que confían en ella. Los responsables oyen "somos el doble de rápidos" de un ingeniero y "me hace perder el tiempo" de otro. Ambas cosas pueden ser ciertas. Este plan explica qué dicen realmente las evidencias, cómo desplegar asistentes sin crear un problema de seguridad o de calidad y cómo medir si la inversión compensa para tu equipo.

Qué dice la investigación (y qué no)

El debate sobre productividad está lleno de anécdotas. Merece la pena conocer algunos estudios porque miden algo concreto.

  • Tarea controlada, código nuevo. En un experimento aleatorizado, los desarrolladores con GitHub Copilot implementaron un servidor HTTP en JavaScript un 55,8% más rápido que el grupo de control (Peng et al., 2023). La tarea era pequeña, estaba bien especificada y partía de un repositorio vacío: el caso ideal para un asistente.
  • Desarrolladores con experiencia, código maduro. METR realizó un ensayo aleatorizado con 16 mantenedores open source experimentados que trabajaban en issues reales de repositorios que conocían bien. Con herramientas de IA permitidas tardaron un 19% más, mientras creían haber sido alrededor de un 20% más rápidos (METR, 2025; resumen).
  • Nivel organizativo. El informe DORA 2024 encontró que un aumento del 25% en la adopción de IA se asociaba a un descenso del 7,2% en la estabilidad de las entregas y del 1,5% en su ritmo, aunque las personas declaraban más productividad y satisfacción laboral (DORA 2024). La edición de 2025 presenta la IA como un amplificador: las buenas prácticas de ingeniería se refuerzan y las débiles quedan al descubierto (DORA 2025).

El patrón es coherente: los asistentes brillan en tareas bien acotadas con feedback rápido y tienen dificultades —o generan costes ocultos— cuando el contexto es grande, los requisitos son implícitos y la capacidad de revisión es el cuello de botella. Las mejoras de velocidad autodeclaradas no son una prueba fiable. Planifica el despliegue en torno a ese hecho.

Tres categorías de herramientas, tres perfiles de riesgo

"Asistente de IA" abarca ya productos muy distintos. Trátalos por separado en las políticas y en el presupuesto.

Categoría Ejemplos Qué hace Riesgo principal
Autocompletado en línea Copilot completions, Cursor Tab, JetBrains AI Sugiere las siguientes líneas mientras escribes Bugs sutiles aceptados sin leer
Chat en el IDE Copilot Chat, Cursor Chat, Claude en el IDE Explica código, redacta funciones, responde preguntas Respuestas erróneas dichas con seguridad sobre tu código
Herramientas agénticas Claude Code, Copilot coding agent, Codex, Cursor agent Lee el repositorio, edita muchos archivos, ejecuta comandos y tests Diffs grandes, acceso a la shell, exposición de secretos

Las herramientas agénticas aportan las mayores ganancias y conllevan el mayor riesgo, porque ejecutan comandos. Explico cómo trabajar con ellas de forma productiva en buenas prácticas de agentic coding.

Paso 1: decide qué problema estás resolviendo

"Licencia para todos" no es una estrategia. Elige dos o tres puntos de dolor concretos y evalúa las herramientas frente a ellos:

  • Incorporación: ingenieros nuevos que piden al asistente que les explique módulos, flujos de datos y convenciones.
  • Código repetitivo y de pegamento: DTOs, mappers, clientes de API, migraciones, configuración.
  • Tests: tests de caracterización para código heredado, casos límite extra para baterías existentes (consulta tests unitarios generados con IA).
  • Migraciones: actualizaciones de frameworks y APIs obsoletas en muchos archivos (consulta IA para modernizar código heredado).
  • Carga de revisión: un revisor de primera pasada que detecta los problemas evidentes antes de que mire una persona (consulta revisión de código con IA).

Ponlos por escrito. Se convertirán en tus criterios de evaluación y, más adelante, en tus métricas.

Antes de que el código salga del portátil de un desarrollador, responde por escrito a estas preguntas:

  1. Retención de datos y entrenamiento. ¿El proveedor entrena con tu código? ¿Cuánto tiempo conserva los prompts? Los planes business y enterprise de los grandes proveedores suelen excluir por defecto los datos del cliente del entrenamiento, pero comprueba las condiciones que firmas, no la página de marketing.
  2. Qué repositorios están permitidos. El código de clientes bajo NDA, los datos regulados, el material criptográfico y todo lo que contenga datos personales pueden necesitar una decisión aparte. Algunos clientes prohíben directamente el procesamiento por IA de terceros.
  3. Secretos. Los asistentes leen archivos .env, el historial de la shell y la configuración. Usa listas de denegación en los ajustes de la herramienta, guarda los secretos en un gestor en lugar de en archivos y ejecuta escaneo de secretos en cada push.
  4. Ejecución de comandos. Para las herramientas agénticas, decide qué comandos se ejecutan sin confirmación. Los comandos de solo lectura y los tests suelen estar bien; git push, los scripts de despliegue y los clientes de base de datos, no.
  5. Licencias del código generado. Activa los filtros de detección de duplicados o de referencia de código cuando el proveedor los ofrezca y mantén el escaneo de licencias habitual en CI.

Si operas en la UE, las herramientas de programación con IA suelen ser de riesgo mínimo según la Ley de IA, pero las normas de protección de datos siguen aplicándose a cualquier dato personal que haya en tu código o en tus logs. Mi guía de la Ley de IA de la UE y la guía de privacidad para aplicaciones LLM cubren los detalles.

Paso 3: haz un piloto con plazo y con grupo de control

Un piloto debe producir evidencias, no entusiasmo. Un diseño que funciona para equipos de 10 a 100 ingenieros:

  • Duración: 6–8 semanas. Las dos primeras son curva de aprendizaje; no juzgues los resultados ahí.
  • Participantes: una mezcla de niveles y de bases de código, incluido al menos un servicio heredado. Si solo participan voluntarios, los resultados saldrán sesgados al alza.
  • Línea base: recoge las mismas métricas durante 4–6 semanas antes del piloto, o mantén un grupo comparable sin la herramienta.
  • Formación: una sesión de 90 minutos sobre prompting, archivos de contexto y revisión de la salida de la IA. Los equipos que se saltan la formación sacan bastante menos partido a las herramientas.
  • Notas semanales: cada participante anota una tarea en la que la herramienta ayudó y otra en la que estorbó. Estas notas cualitativas suelen ser más útiles que los números.

Paso 4: mide resultados, no pulsaciones

Los paneles de los proveedores muestran la "tasa de aceptación" y las "líneas sugeridas". Son métricas de actividad; no dicen nada del valor. Usa un conjunto equilibrado:

Dimensión Métrica Fuente
Ritmo PRs fusionados por ingeniero y semana, lead time de los cambios Alojamiento Git, métricas DORA
Calidad Tasa de fallos por cambio, PRs revertidos, bugs por versión Gestor de incidencias, CI
Carga de revisión Tiempo hasta la primera revisión, tamaño del PR, rondas de revisión Alojamiento Git
Mantenibilidad Código duplicado, tendencia de la cobertura de tests Análisis estático
Experiencia del desarrollador Encuesta: tiempo de concentración, frustración, utilidad percibida Encuesta trimestral
Coste Licencias más gasto en API por ingeniero Facturación

Vigila de cerca el tamaño de los PRs. Los asistentes abaratan escribir código y encarecen revisarlo; si el tamaño medio del diff se duplica mientras el tiempo de revisión por PR se mantiene, alguien no está leyendo con atención. Los resultados de DORA sobre estabilidad apuntan exactamente a este mecanismo.

Paso 5: escribe una política de uso breve y aplicable

Las políticas largas se ignoran. Basta con una página:

# AI assistant policy (v1.2)

1. Approved tools: Claude Code, GitHub Copilot (business plan). Others need approval.
2. Allowed repos: all internal repos except `payments-core` and client repos marked `no-ai`.
3. You own every line you commit. "The AI wrote it" is not a review argument.
4. Never paste secrets, customer personal data or production dumps into prompts.
5. Agent tools: no auto-approval for push, deploy, DB or network commands.
6. PRs with significant AI-generated code must include tests and a short
   description of what was verified manually.
7. New dependencies suggested by AI must be checked to exist and be maintained.

La regla 7 no es paranoia: los LLM sugieren con frecuencia paquetes que no existen, y los atacantes registran esos nombres. Consulta seguridad del código generado por IA.

Paso 6: invierte en contexto, no solo en licencias

La mayor diferencia entre los equipos que sacan valor de los asistentes y los que no es cuánto contexto dan a la herramienta. Inversiones prácticas:

  • Archivos de instrucciones del repositorio (CLAUDE.md, AGENTS.md, .github/copilot-instructions.md) que describan los comandos de build, la arquitectura, las convenciones y las reglas de "nunca hagas esto" (documentación de memoria de Claude Code).
  • Comandos de test rápidos y fiables. Un agente que puede ejecutar make test en 30 segundos verifica su propio trabajo; uno que necesita un pipeline de 20 minutos adivina.
  • Notas de arquitectura y ADRs actualizados. Ayudan por igual a personas y a modelos.
  • Integraciones de herramientas mediante el Model Context Protocol para tickets, documentación y observabilidad, de modo que el asistente pueda leer el issue y los logs en lugar de depender de un copiar y pegar.

Estas inversiones son lo que significa el context engineering en un entorno de desarrollo.

Paso 7: ajusta el proceso de revisión

Cuando el código se abarata, la revisión se convierte en la restricción. Adáptate:

  • Mantén los PRs pequeños. Pide a los agentes que dividan el trabajo en commits revisables; rechaza "refactorizaciones con IA" de 2.000 líneas salvo que sean mecánicas y estén cubiertas por tests.
  • Exige evidencias. La descripción de un PR debe decir cómo se verificó el cambio: tests añadidos, comprobaciones manuales, capturas.
  • Usa la IA como revisor de primera pasada, no como el único. Detecta erratas, comprobaciones de null que faltan y nombres incoherentes; las personas se centran en el diseño y en la lógica de negocio.
  • Sigue las reversiones y hotfixes según su origen durante unos meses para ver si los cambios con mucha IA se comportan de forma distinta en producción.

Coste: qué presupuestar

Las licencias por puesto de las herramientas de autocompletado y chat son predecibles. Las herramientas agénticas que llaman a modelos mediante una API pueden ir de unos pocos dólares a cientos por ingeniero y mes según el uso. Fija presupuestos y alertas por usuario desde el primer día, revisa el gasto cada mes y aplica las mismas palancas que describo en optimización de costes de LLM, sobre todo la elección de modelo y el tamaño del contexto.

Como regla general, si una herramienta ahorra a un ingeniero de nivel medio dos horas al mes, ya ha pagado un puesto típico. Lo difícil no es la licencia; es asegurarse de que el tiempo ahorrado no se gaste después en depuración y revisión.

Modos de fallo habituales

  • Caída silenciosa de la calidad. Más código, menos tests, PRs más grandes. Detéctalo con las métricas anteriores.
  • Atrofia de habilidades en los perfiles junior. Los juniors que aceptan sugerencias que no saben explicar no aprenden. Emparéjalos con seniors y pídeles que expliquen el código generado por IA durante la revisión.
  • IA en la sombra. Si la herramienta aprobada está demasiado restringida, los ingenieros usan cuentas personales. Haz que el camino aprobado sea el más fácil.
  • Todo a través del agente. Algunas tareas —concurrencia delicada, código crítico para la seguridad, ajuste de rendimiento— se benefician de un pensamiento humano más lento. Deja que los ingenieros elijan.

Preguntas frecuentes

¿Qué herramienta deberíamos elegir? Prueba dos herramientas con las mismas tareas. Las diferencias entre equipos y bases de código son mayores que las diferencias en los benchmarks de los proveedores. Las CLI agénticas encajan con ingenieros cómodos en el terminal; las herramientas integradas en el IDE tienen una curva de aprendizaje más suave.

¿Los asistentes de IA nos permitirán contratar menos desarrolladores? Las evidencias hasta ahora respaldan un trabajo más rápido en tareas bien definidas, no la sustitución del criterio de ingeniería. La mayoría de los equipos usan la capacidad para reducir el backlog y la deuda técnica en lugar de la plantilla.

¿Cómo gestionamos el código de clientes? Pregunta al cliente. Incluye el uso de IA en el contrato o en la descripción del trabajo y mantén una etiqueta de exclusión por repositorio.

¿Necesitamos modelos propios? Rara vez, para programar. Los modelos self-hosted tienen sentido sobre todo cuando los datos no pueden salir de tu infraestructura; consulta LLM self-hosted para ver los compromisos.

¿Cuánto tardaremos en ver resultados? Cuenta con una curva de aprendizaje de 2–4 semanas y datos estables al cabo de unos dos meses.

Fuentes

  1. Stack Overflow. Developer Survey 2025: AI.
  2. Peng et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.
  3. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.
  4. Google Cloud DORA. Accelerate State of DevOps Report 2024.
  5. Google Cloud DORA. State of AI-assisted Software Development 2025.
  6. Anthropic. Claude Code: manage memory (CLAUDE.md).
  7. Anthropic. Claude Code best practices for agentic coding.