Checklist para CTOs: cómo adoptar asistentes de código con IA sin perder calidad ni seguridad

Por Felipe Traina · 28/9/2026 · 7 min · liderazgo, ia, productividad, seguridad

En un ensayo controlado aleatorizado publicado por METR en julio de 2025, 16 desarrolladores experimentados de proyectos open source completaron 246 tareas en repositorios que conocían muy bien. Antes de empezar estimaban que la IA les iba a ahorrar 24% del tiempo; al terminar creían que les había ahorrado 20%. La medición mostró lo contrario: con herramientas de IA de principios de 2025, tardaron 19% más.

El estudio es un preprint, tiene una muestra chica y se refiere a herramientas que ya quedaron viejas, así que no sirve para concluir que la IA "no funciona". Lo que sí muestra es algo muy útil para quien lidera un equipo: la percepción de productividad y la productividad medida pueden ir en direcciones opuestas. Adoptar asistentes de código sin medir es apostar.

El informe DORA 2025 de Google Cloud, dedicado al desarrollo asistido por IA, llega a una conclusión complementaria: el rol principal de la IA es el de un amplificador, que magnifica las fortalezas y debilidades que la organización ya tenía. Con eso en mente, este es un checklist para adoptar asistentes y agentes de código de forma ordenada.

1. Datos y confidencialidad

Antes que la herramienta, la pregunta es qué código y qué datos van a salir de tu perímetro.

• Revisar los términos del proveedor: retención de datos, uso para entrenamiento, jurisdicción, residencia de datos disponible.
• Usar planes empresariales con garantías contractuales, no cuentas personales.
• Configurar exclusiones de contenido para archivos sensibles (secretos, datos de clientes, código regulado). Ojo con los límites: la documentación de GitHub Copilot, por ejemplo, aclara que el modo agente de Copilot Chat en los IDE no soporta la exclusión de contenido.
• Sacar los secretos del repositorio. Si un asistente puede leer el repo, puede leer el .env que alguien commiteó. Escaneo de secretos obligatorio en CI.
• Definir qué repos quedan fuera del uso de IA, si los hay, y comunicarlo por escrito.

2. Permisos de los agentes

Los asistentes que solo sugieren código y los agentes que ejecutan comandos son riesgos distintos. Para los agentes:

• Credenciales propias, acotadas y de vida corta. Nunca el token personal del desarrollador. Uno de los incidentes documentados por OpenAI en 2026 empezó con un modelo interno usando el token de un investigador que tenía permisos de escritura sobre un repo público ajeno a la tarea.
• Sandbox para la ejecución: contenedor o VM sin acceso a producción, con salida de red limitada (DNS incluido).
• Aprobación humana para acciones con efectos: push a ramas protegidas, cambios en CI, migraciones, despliegues.
• Protección de ramas y de la configuración de CI, incluidos los scripts que los workflows ejecutan, no solo los archivos de workflow.
• Instrucciones del proyecto versionadas (el archivo de reglas o instrucciones que use tu herramienta), revisadas como cualquier otro código.

Y una regla de base: el system prompt o el archivo de instrucciones no es un control de seguridad. Si el agente tiene el permiso, hay que asumir que en algún momento puede usarlo.

3. Revisión de código y calidad

El código generado se revisa con el mismo estándar que el escrito por una persona, y la responsabilidad es de quien lo integra.

• Autor responsable: quien abre el PR responde por el código, lo haya escrito o no.
• PRs chicos. La IA facilita generar mucho código; la revisión no escala al mismo ritmo. Un límite orientativo de tamaño de PR ayuda.
• Tests obligatorios para el código generado, idealmente escritos o revisados por una persona.
• Análisis estático y de seguridad en CI (linters, SAST, escaneo de dependencias), sin excepciones para código generado.
• Revisar dependencias nuevas. Un asistente puede sugerir paquetes que no existen o que no conviene usar. Toda dependencia nueva pasa por revisión.
• Etiquetar opcionalmente los PRs hechos mayormente por agentes, para poder medir su calidad por separado.

4. Métricas: medir antes y después

Sin una línea de base, cualquier conclusión es anecdótica. Y como mostró el estudio de METR, la percepción no alcanza.

• Tomar una línea de base antes del despliegue: las métricas DORA (tiempo de entrega de cambios, frecuencia de despliegue, tasa de fallas, tiempo de recuperación, tasa de retrabajo) más tiempos de revisión de PRs.
• Medir resultados, no actividad. "Líneas generadas" o "sugerencias aceptadas" no son productividad.
• Vigilar la estabilidad: si sube el volumen de cambios pero también la tasa de fallas o de retrabajo, la ganancia es ilusoria.
• Encuestas periódicas sobre experiencia del equipo, carga cognitiva y confianza en el código.
• Comparar por tipo de tarea. Es probable que el impacto sea distinto en código nuevo, mantenimiento de legacy, tests o documentación.

5. Piloto antes de la adopción masiva

• Empezar con un equipo piloto voluntario y un conjunto de casos de uso definidos.
• Definir de antemano los criterios de éxito del piloto (métricas y umbrales).
• Duración suficiente (varias semanas) para pasar la curva de aprendizaje.
• Retrospectiva documentada con qué funcionó, qué no y qué reglas hacen falta.

6. Formación y cultura

El informe DORA 2025 insiste en que el retorno viene más del sistema organizacional que de la herramienta.

• Formación práctica: cómo dar contexto, cómo verificar, cuándo no usar la herramienta.
• Espacio para juniors: si la IA hace todo el trabajo mecánico, ¿cómo aprenden los fundamentos? Definir prácticas explícitas (por ejemplo, explicar en el PR el código generado).
• Compartir aprendizajes: prompts, reglas de proyecto y errores comunes en un lugar común.
• Política escrita y corta de uso aceptable, con ejemplos concretos.

7. Costos y proveedores

• Presupuesto por usuario o por equipo, con alertas. Los agentes pueden consumir muchos tokens en tareas largas.
• Evitar el lock-in innecesario: preferir herramientas que permitan cambiar de modelo o de proveedor.
• Revisar el contrato cada trimestre: precios, modelos y condiciones cambian rápido.

Qué hacer con esto

Un plan de 30 días:

1. Semana 1: política de datos, elección de plan empresarial, exclusiones de contenido y escaneo de secretos.
2. Semana 2: línea de base de métricas DORA y tiempos de revisión; definición de criterios de éxito.
3. Semanas 3 y 4: piloto con un equipo, agentes en sandbox con credenciales propias y aprobación humana para acciones con efectos.
4. Día 30: retrospectiva, ajuste de reglas y decisión de ampliar o no.

La pregunta no es si adoptar asistentes de código, sino cómo hacerlo sin trasladar el costo a la revisión, a la seguridad o a la estabilidad.

¿Tu equipo midió el impacto real de los asistentes de código, o la evaluación se basa en la percepción de cada desarrollador?

Lecturas relacionadas

• Seguridad de la cadena de suministro en npm y PyPI: controles concretos después de Shai-Hulud: lockfiles, edad mínima de versiones, scripts de instalación y trusted publishing después de Shai-Hulud.
• OWASP Top 10 para aplicaciones con LLM (2025) explicado: prompt injection y cómo mitigarla: los 10 riesgos de OWASP para apps con LLM y un plan concreto contra prompt injection y exceso de agencia.
• Métricas DORA explicadas: las cinco métricas actuales, cómo medirlas y errores comunes: las cinco métricas actuales, cómo calcularlas y cómo usarlas sin convertirlas en metas.

Fuentes

• METR, Becker et al., "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (preprint, arXiv, julio de 2025): https://arxiv.org/abs/2507.09089
• DORA (Google Cloud), "State of AI-assisted Software Development" 2025: https://dora.dev/research/2025/dora-report/
• DORA, métricas de desempeño de entrega de software: https://dora.dev/guides/dora-metrics/
• GitHub Docs, "Excluding content from GitHub Copilot": https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot
• OpenAI Alignment, "Exposing a GitHub token in a public repository" (act. 25/09/2026): https://alignment.openai.com/misalignment-reports/exposing-a-github-token-in-a-public-repository/
• OWASP, LLM07:2025 System Prompt Leakage: https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/

← Volver al blog