La forma segura de enviar código escrito por agentes IA

El cambio estructural que 2025 dejó en cómo se escribe software

Entre mayo y septiembre de 2025, desarrolladores de GitHub usaron la versión agente de Copilot — la que planifica una tarea de varios pasos y vuelve con un PR listo para revisión humana — para abrir más de un millón de pull requests. En el mismo año, la plataforma cerró 518,7 millones de PRs mergeados, un 29% más que el año anterior, según el informe Octoverse 2025 de GitHub. Algo cambió en cómo se escribe software, y la mayoría de los líderes de ingeniería aún están escribiendo políticas para el escenario anterior.

La confusión que sostiene decisiones de gobernanza equivocadas es de base: autocompletar, asistente y agente no son la misma categoría. El autocompletado sugiere la siguiente línea. El asistente responde una pregunta o genera un fragmento que tú copias. El agente recibe un objetivo ("arreglar esta prueba que falla"), planifica un enfoque de varios pasos, ejecuta herramientas (lee archivos, corre el suite de tests, edita código, revisa el resultado) e itera sin aprobación humana en cada paso. El humano vuelve a entrar al ciclo en el PR, no en cada tecla pulsada.

Ese desplazamiento — de "sugerir texto" a "operar la cadena de herramientas" — es la razón completa por la que cambió el perfil de riesgo. No estás revisando una sugerencia. Estás revisando la salida de un proceso autónomo de varios pasos que no viste acontecer.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Lo que la métrica de productividad realmente dice

La narrativa más repetida en presentaciones de proveedores dice "los agentes te hacen más rápido". La foto honesta es más desordenada.

En julio de 2025, METR — una organización independiente de evaluación de IA — publicó un ensayo controlado aleatorio con 16 desarrolladores experimentados de código abierto, con alrededor de cinco años de experiencia previa en promedio en sus bases de código. Antes del estudio, los desarrolladores predijeron que la IA reduciría el tiempo de finalización un 24%; después seguían creyendo que habían sido cerca de un 20% más rápidos. La medición real: fueron un 19% más lentos con la IA permitida.

Dos matices que importan para no leer ese número como un veredicto universal. Primero, el intervalo de confianza fue amplio, aproximadamente de +2% a +39%, y la población estudiada fue estrecha: dieciséis personas, en bases de código que conocían íntimamente. Segundo, METR intentó repetir el experimento con una cohorte más grande y reportó en febrero de 2026 un problema todavía más interesante: entre el 30% y el 50% de los desarrolladores invitados rechazaron participar porque no querían trabajar sin acceso a IA. Ese sesgo de selección está deformando el estudio desde adentro, porque quienes aceptan prescindir de la IA son, casi por definición, quienes sienten que obtienen menos de ella.

Un análisis separado de la firma de análisis de flujos de trabajo Faros AI encontró que los equipos asistidos por IA mostraron una tasa de finalización de tareas un 21% mayor y un 98% más de PRs mergeados, impulsado menos por la velocidad de cada ticket individual y más por la capacidad de trabajar en paralelo: arrancar una parte del trabajo con un agente mientras se revisa otra. Las organizaciones optimizan para software entregable en equipo, no para la velocidad de un ticket aislado.

Y en julio de 2026, un estudio de Microsoft con su propio rollout interno de agentes por línea de comandos (Claude Code y Copilot CLI) encontró un incremento del 24% en PRs mergeados por ingeniero por día, con un rango probable de +14,5% a +33,7%, y el efecto no decayó durante los cuatro meses del estudio. Quienes usaron las herramientas cinco o más días por semana vieron lifts superiores al 50%, frente a cerca del 15% en quienes las usaron tres días por semana. La adopción no es solo contar licencias: la métrica relevante es uso sostenido.

La lección para cualquier CTO: cuando alguien en una reunión general diga "ahora somos un 40% más rápidos", vale preguntar más rápidos en qué, medido cómo, comparado con qué base.

Qué hace realmente un agente cuando le das un objetivo

Un agente de codificación no es un modelo más una ventana de chat: es el modelo envuelto en un arnés que le permite actuar sobre la base de código en lugar de describir qué hacer. Tres componentes importan:

Recuperación de contexto: búsqueda e indexación para que el agente encuentre los tres archivos relevantes en un repositorio de medio millón de líneas, en vez de inventar firmas de función que no existen.
Ejecución de herramientas: permiso real para correr comandos de shell, editar archivos y ejecutar el suite de tests, no solo describir qué deberían ser esos comandos.
Bucle de verificación: ¿pasaron las pruebas? Si no, revisar y volver a intentar, posiblemente varias veces, antes de abrir un PR visible para un humano.

El error común es describir ese bucle como "el agente prueba su propio trabajo, así que las alucinaciones se detectan". No es correcto. El modelo genera una hipótesis, las herramientas prueban esa hipótesis específica y el sistema observa el resultado — éxito o fracaso — y se ajusta. Lo que no hace es verificar que la hipótesis fuera la correcta para probar desde el principio. Un suite de tests solo comprueba lo que alguien pensó en escribir; un agente puede satisfacer todas las afirmaciones de un archivo de pruebas mientras entrega algo estructuralmente incorrecto que nadie testeó. El bucle es real, detecta una clase significativa de errores y no es una prueba de corrección.

Un análisis de METR publicado en marzo de 2026 lo confirmó con datos: mantenedores de scikit-learn, Sphinx y pytest revisaron 296 PRs generados por IA que ya habían pasado SWE-bench Verified, un estándar para evaluar agentes de programación. Aproximadamente la mitad no habrían sido mergeados al código real: fallos en funcionalidad principal, código que rompía otras partes del sistema y problemas de calidad que el suite de tests no tenía cómo detectar. Las pruebas que pasan son necesarias. Nunca han sido suficientes.

Los 5 controles que separan a un equipo seguro de uno expuesto

Permisos limitados, impuestos a nivel de credenciales. El agente obtiene acceso de escritura a la rama en la que trabaja. Nada de infraestructura de producción, nada de secretos, nada de otros repositorios. Esto se impone con IAM y escopeo de tokens, no con una línea amable en el prompt del sistema pidiéndole que no toque producción. Las instrucciones del prompt no son un límite de seguridad.
Tests automatizados como condición ineludible para mergear. El cambio del agente no se fusiona sin que el suite existente pase, más tests nuevos para el nuevo comportamiento. Debe ser una verificación de CI, no una solicitud.
El mismo análisis estático y escaneo SCA que aplicarías a código humano. El código escrito por agentes introduce las mismas clases de vulnerabilidades que el humano, y una nueva específica de esta generación: la alucinación de dependencias, donde un agente referencia un nombre de paquete que no existe. Ya es un vector documentado de ataque a la cadena de suministro: alguien puede registrar exactamente ese nombre alucinado con código malicioso dentro.
Revisión humana antes de mergear, siempre. No porque desconfíes de este modelo en particular, sino porque exigirías revisión para cualquier nuevo contribuidor, humano o no. Un agente es, funcionalmente, un nuevo contribuidor muy rápido y muy inconsistente.
Políticas como código en CI, idénticas para PRs de humanos y de agentes. Cumplimiento de licencias, patrones prohibidos, listas de permisos para dependencias: las mismas comprobaciones automatizadas que bloquean un PR humano deben bloquear el del agente, sin excepciones.

La fórmula operativa es proponer, controlar, revisar, mergear — no proponer y enviar. Un estudio de la ACM Transactions on Software Engineering and Methodology revisó 567 PRs de Claude Code en 157 proyectos open source: el 83,8% terminó mergeado, pero solo el 54,9% entró sin cambios adicionales; el 45,1% requirió revisión humana, sobre todo para bug fixes, documentación y estándares específicos del proyecto.

Qué cambia realmente para las personas

La versión perezosa dice "los desarrolladores se convierten en ingenieros de prompts". Lo que se observa en equipos que ya llevan meses con esto es más matizado: se aplica el juicio más temprano — más tiempo en el diseño del sistema y en redactar con precisión los criterios de aceptación, porque un agente ejecutará literalmente lo que se le indique, con sus vacíos incluidos — y más tiempo revisando y verificando la salida. Menos tiempo en la implementación repetitiva.

También aparece un puesto nuevo que no existía hace dos años: alguien del equipo de plataformas o DevEx es responsable de la configuración de los controles de seguridad del agente — qué puede tocar, qué tests lo vigilan, qué ocurre en caso de fallo — de la misma forma en que alguien hoy es responsable del pipeline de CI/CD. Si nadie se encarga, se va ampliando el alcance silenciosamente hasta que un agente tiene más permisos de los que alguien pretendió.

En marzo de 2026, GitHub vivió un episodio que ilustra el riesgo de un agente sin guardia: Copilot estuvo insertando mensajes publicitarios en más de 11.000 pull requests que no había originado, modificando descripciones y comentarios de otros contribuidores. GitHub desactivó la función ese mismo día. El incidente fue promovido por un comportamiento comercial, pero el patrón — un agente actuando fuera del scope previsto — es exactamente el tipo de fallo que los cinco controles anteriores están diseñados para detener.

Cuándo NO usar un agente autónomo

Los agentes son más fuertes en tareas bien definidas y verificables: corrección de bugs con un test reproducible, features que siguen un patrón existente en el código. Son más débiles en tareas ambiguas y con alto contenido de juicio: decisiones de arquitectura novedosas, cualquier cosa donde "correcto" no pueda verificarse automáticamente.

Un criterio simple: si no puedes escribir un test que detecte que el agente se equivoca, no está listo para correr sin supervisión en esa tarea. Para ese tipo de trabajo, humano en el bucle y punto.

Camino de adopción en tres pasos

Empieza estrecho. Escritura de tests, actualizaciones de dependencias, correcciones de bugs bien definidas con un test reproducible. Revisión humana obligatoria en todo.
Instrumenta antes de expandir. Rastrea tasa de merge, tasa de defectos y tiempo de revisión en PRs escritos por el agente en comparación con los escritos por humanos durante al menos un mes. No se trata de sensaciones, sino de números, de la misma manera en que METR insistió en medir en lugar de preguntar a los desarrolladores cuán rápido se sentían.
Expande solo en categorías con verificación automática sólida. Una buena cobertura de tests es el requisito real para ejecución autónoma, no lo impresionante que parecía el demo en la reunión.

Qué significa esto para tu startup

La pregunta relevante para un founder no es "¿debería usar agentes de codificación?", sino "¿están mis controles listos para que un agente opere dentro de ellos?". Un estudio interno de una empresa mediana con 802 desarrolladores y 196.212 PRs analizados mostró que, tras una directiva pública de duplicar throughput, la proporción de PRs con al menos una revisión humana cayó del 89% al 68%, mientras la revisión automatizada por IA subió de cerca del 19% al 84%. Los PRs autoría de IA tardaron un 20% más en mergear tras la primera revisión humana y un 22% más en total. La velocidad bruta subió, pero la carga de revisión casi se duplicó por revisor.

Tres acciones concretas para implementar esta semana:

Audita los permisos del agente hoy mismo. ¿Puede escribir en tu rama principal? ¿Tiene acceso a secretos o a infraestructura? Si la respuesta es "sí, porque confiamos en el prompt", reescribe los límites con IAM y tokens de scope limitado.
Mide antes de acelerar. Define desde ya el KPI que vas a mirar: PRs mergeados por ingeniero por semana, tasa de revert, tiempo medio de revisión, defectos escapados a producción. Sin métricas de línea base no vas a distinguir señal de ruido.
Separa los workflows. No todo PR de un agente debe pasar por el mismo flujo que un PR humano. Bugs con test reproducible pueden tener un camino acelerado y con menos reviewers; refactors arquitectónicos deben mantener revisión humana obligatoria hasta tener datos propios de calidad.

La IA agente no elimina la necesidad de juicio ingenieril. Mueve ese juicio más temprano — a la precisión con la que especificas una tarea y a la rigidez con la que diseñas los parámetros alrededor de ella — en lugar de eliminarlo. Los equipos que obtienen valor real son los que tratan al agente como tratarían a cualquier nuevo colaborador muy rápido pero a veces demasiado seguro: acceso con scope, tests obligatorios, revisión humana y números antes que impresiones.