Programación con agentes: escribir código se abarató, verificarlo no

Las herramientas y sus tres modos

En el IDE, el agente edita dentro de tu editor mientras lo observas. En la terminal, un agente de línea de comandos lee el repositorio, ejecuta comandos y pruebas y edita archivos. En la nube, asignas una tarea y recibes un pull request.

Dos formatos abiertos limitan la dependencia: AGENTS.md, un archivo Markdown de instrucciones para agentes lanzado en agosto de 2025 y adoptado por más de 60.000 proyectos de código abierto en diciembre, y MCP para herramientas y datos (ver MCP explicado).

Benchmarks: mira la versión y el arnés

SWE-bench Verified, el subconjunto validado por humanos que OpenAI publicó en agosto de 2024, era la cifra que citaba todo lanzamiento de código. En febrero de 2026 OpenAI dejó de reportarlo: el estado del arte solo había pasado de 74,9 % a 80,9 % en seis meses, una auditoría de 138 problemas difíciles encontró pruebas defectuosas en el 59,4 % y GPT-5.2 resolvió 31 tareas consideradas casi imposibles, señal de contaminación. Ya no aparece en las tablas de lanzamiento de Claude Opus 5.5 ni de GPT-6 Astra.

Sus sucesores son más difíciles y cambian más rápido. SWE-bench Pro (Scale AI, septiembre de 2025) reúne 1.865 tareas largas de 41 repositorios, pero su tabla pública aún no incluye los modelos de mediados de 2026. Terminal-Bench pasó de la versión 1.0 a la 4.0 en 15 meses; en la tabla oficial de la 4.0, GPT-6 Astra con Codex lidera con 58,2 %, por delante de Claude Fable 5.1 con Claude Code (57,9 %), mientras que el 66,4 % que Anthropic reporta para Opus 5.5 (ver nuestro análisis) todavía no figura. En la tabla de DeepSWE v1.1 de OpenAI, cinco modelos de tres proveedores quedan a menos de 7 puntos.

Así que nombra el modelo y el arnés, el software que ejecuta al agente; compara solo dentro de una misma versión, y prueba con tu código. Anthropic recomienda empezar las evaluaciones de agentes con 20 a 50 tareas sacadas de fallas reales: en código, issues cerrados de tus propios repositorios. El método está en nuestra guía de evaluación de LLM.

Qué encontraron los estudios de productividad

El estudio más riguroso sigue siendo el ensayo aleatorizado de METR, de julio de 2025: 16 desarrolladores experimentados de código abierto, 246 issues reales de unas dos horas cada uno, en repositorios maduros de más de un millón de líneas. Con IA permitida, sobre todo Cursor Pro con Claude 3.5 y 3.7 Sonnet, las tareas tomaron un 19 % más de tiempo. Los desarrolladores esperaban ir un 24 % más rápido y, al terminar, seguían creyendo que habían ganado un 20 %.

El seguimiento, iniciado en agosto de 2025 y publicado en febrero de 2026, estimó ahorros de tiempo del 18 % para quienes repetían y del 4 % para los nuevos participantes, pero ambos intervalos de confianza incluyen el cero. METR considera los datos poco fiables: entre el 30 % y el 50 % de los participantes se guardó tareas que no quería hacer sin IA, así que la ganancia real probablemente es mayor.

Las encuestas muestran la misma brecha. En DORA 2025 (casi 5.000 respuestas), el 90 % usa IA en el trabajo y más del 80 % dice ser más productivo, pero el 30 % confía poco o nada en el código generado, y la adopción va de la mano con más volumen de entregas pero menos estabilidad. En la encuesta 2025 de Stack Overflow, solo el 14,1 % usaba agentes de IA a diario.

Seguridad: el código de IA falla de formas conocidas

En 2025, Veracode probó más de 100 modelos en tareas de Java, Python, C# y JavaScript: el 45 % de las muestras introdujo una vulnerabilidad del OWASP Top 10, desde el 72 % en Java hasta el 38 % en Python. La calidad funcional mejoró; la seguridad no, sin importar el tamaño del modelo.

• Dependencias. Un modelo puede sugerir un paquete que no existe, y un atacante puede registrar ese nombre antes. Fija versiones, instala desde un registro interno o una lista de paquetes permitidos y haz de cada dependencia nueva una decisión humana (ver seguridad de la cadena de suministro de IA).
• Secretos. Un agente ve lo que ve su terminal. Dale credenciales de corta duración y alcance mínimo, nunca las de producción, y escanea secretos en cada pull request.
• Inyección de prompts. Un issue, una página web o un README pueden traer instrucciones que el agente sigue, y OpenAI ve poco probable que el problema se resuelva del todo algún día (ver prompt injection y agentes).
• Aislamiento. El aislamiento de archivos y red redujo un 84 % las solicitudes de permiso en Anthropic, lo que frena la aprobación automática. Anthropic también vio que cerca del 0,8 % de las acciones de agentes parecían irreversibles: pocas, pero no cero.

Nuestra recomendación: las mismas barreras de seguridad para todo pull request, humano o de agente, y un pentest web y de API externo antes de exponer una aplicación crítica.

Qué cambia dentro del equipo

Specs antes que prompts. Los agentes rinden mejor con una especificación corta: criterios de aceptación, archivos en alcance y lo que no debe cambiar. AWS construyó Kiro alrededor de esa idea, y el arnés de Anthropic para agentes de larga duración avanza una funcionalidad a la vez, después de ver agentes que intentaban todo de una vez, se daban por terminados antes de tiempo y dejaban funciones sin probar.

Pruebas como contrato. Un agente que escribe el código y las pruebas puede equivocarse en ambos de la misma forma. Las pruebas que definen el comportamiento deben escribirlas o aprobarlas personas, estar protegidas por code owners y nunca cambiar en el pull request que validan.

La revisión es el cuello de botella. Mantén los pull requests pequeños (una tarea, un pull request), pide evidencia al agente (salida de pruebas, capturas, lo que no hizo) y etiqueta el trabajo de agentes para medirlo aparte. Según Anthropic, con la experiencia la supervisión pasa de aprobar cada acción a monitorear el trabajo.

Checklist antes de activar agentes en segundo plano

1. Un AGENTS.md con los comandos de build, pruebas y lint, y las zonas vedadas.
2. Pruebas de aceptación en las rutas críticas, a cargo de personas.
3. Barreras de CI: pruebas, tipos, análisis estático y escaneo de secretos, dependencias y licencias.
4. Un tamaño máximo por pull request; un agente nunca fusiona su propio trabajo.
5. Credenciales de agente de corta duración y mínimo privilegio, separadas de las cuentas humanas.
6. Un sandbox con red restringida y una etiqueta en los commits de agentes.

Gobierno, licencias y propiedad intelectual en Colombia y Europa

Primero, la política. El modelo de capacidades de IA de DORA incluye una política de IA clara: qué herramientas, qué repositorios, qué datos y quién puede activar agentes en segundo plano. Sin ella, cada quien trae sus propias herramientas.

El código es un dato. Los repositorios guardan secretos empresariales y a veces datos personales. Elige planes que excluyan el entrenamiento con tu código, mantén los datos de producción lejos de los agentes y verifica dónde corre la inferencia. En Colombia, un proveedor que trata datos personales por tu cuenta necesita un contrato de transmisión, y las transferencias internacionales se rigen por el artículo 26 de la Ley 1581 de 2012. En la Unión Europea aplica el RGPD, y el artículo 4 reformado del AI Act (vigente desde el 27 de julio de 2026) pide a las empresas apoyar la alfabetización en IA de su personal.

Autoría y licencias. La Oficina de Derechos de Autor de EE. UU. concluyó en enero de 2025 que los prompts por sí solos no hacen protegible un resultado de IA: la protección exige autoría humana. Conserva la evidencia de la contribución humana (specs, revisiones, commits), lee los términos de propiedad intelectual de tu proveedor y escanea licencias, porque el código generado puede parecerse a código abierto existente.

Riesgo de proveedor. Las herramientas cambian de dueño (Cursor ahora es de SpaceX) y el acceso puede cambiar por razones políticas: una directiva de control de exportaciones de EE. UU. obligó a Anthropic a retirar Fable 5 a todos sus usuarios del 12 de junio al 1 de julio de 2026. Mantén las instrucciones en formatos abiertos, las herramientas en MCP y una segunda opción probada.

Un modelo operativo y las métricas que importan

Despliega por etapas. Empieza donde la especificación es clara y verificar es barato: bugs con una prueba que los reproduce, actualizaciones de dependencias, escritura de pruebas, documentación, migraciones mecánicas. Suma agentes en segundo plano cuando existan barreras y métricas, y deja la arquitectura, el código sensible y las migraciones de datos bajo control humano estrecho. A las 8 a 12 semanas, compara con la línea base y decide repositorio por repositorio.

Nuestra regla práctica cuando construimos software a la medida: el agente escribe; las pruebas y los revisores deciden. Para agentes más allá del código, lee agentes de IA en producción.