En pocas palabras: Sí. Los agentes de codificación autónomos (como Claude Code o Cursor, desde 2024) reintrodujeron cuatro problemas que la industria creía resueltos: revisión de código a escala, control de permisos, trazabilidad y seguridad de dependencias. La velocidad de generación nunca fue el cuello de botella; solo ocultaba todo lo demás.
Los agentes de IA escriben código rapidísimo, y justo por eso dejaron a la vista problemas de ingeniería de software que la industria creía resueltos hace años: revisión a escala, control de permisos, trazabilidad y seguridad de dependencias. La velocidad de tipeo nunca fue el cuello de botella real. Y ahora se nota.
Un agente de codificación es un sistema basado en modelos de lenguaje que planifica, escribe, ejecuta y modifica código de forma autónoma dentro de un repositorio, con acceso a la terminal, a las APIs y al sistema de archivos del operador. No es un autocompletado. Toma decisiones, corre comandos y encadena tareas sin pedir permiso en cada paso. Ahí empieza el problema.
En 30 segundos
- La velocidad no era el problema: generar código nunca fue el cuello de botella. Los agentes lo resolvieron y expusieron todo lo demás.
- Código que compila pero falla: buena parte del código generado compila sin problemas y aun así arrastra vulnerabilidades identificables.
- Permisos heredados: el agente recibe los privilegios del humano, pero sin su criterio contextual. Se parece a cómo opera el malware.
- Trazabilidad rota: muchas decisiones del agente no se pueden reconstruir, lo que complica auditoría y compliance.
- Incidentes reales en 2026: Meta, Google Gemini y otros ya tuvieron episodios documentados de agentes descontrolados.
¿Por qué escribir código rápido no resuelve los problemas de la ingeniería de software?
Ponele que le pedís a un agente que arme un endpoint nuevo. En diez minutos tenés 400 líneas, tests incluidos, todo prolijo. Parece magia. Después lo mirás con calma y te das cuenta de que la validación de entrada no existe, que el manejo de errores es decorativo y que nadie pensó qué pasa cuando ese endpoint recibe 10.000 requests por segundo.
Ese es el punto. La ingeniería de software casi nunca se trancó por lo lento que se tipea. Se tranca por los requisitos ambiguos, por integrar con sistemas viejos que nadie documentó, por mantener eso durante tres años mientras el equipo rota. Como argumenta un análisis de VentureBeat, los agentes “resolvieron” la codificación y expusieron todos los demás problemas de la disciplina.
Y no es que aparecieron problemas nuevos. Aparecieron los de siempre, ampliados. Cuando una persona escribe 50 líneas por día, la revisión humana alcanza. Cuando un agente escribe 5.000, el sistema de control que servía para el ritmo humano se rompe. Lo explicamos a fondo en desafíos de seguridad comprobados.
La crisis invisible: ¿qué pasa con la revisión de código a escala de agentes?
Acá viene lo bueno. El nuevo cuello de botella no es escribir, es revisar.
Cualquiera que haya revisado un pull request de 2.000 líneas sabe que a la línea 300 ya estás leyendo en diagonal. Ahora multiplicá eso por diez agentes trabajando en paralelo, todo el día. La revisión humana no escala así, y el “code review at scale” ya había fallado en organizaciones grandes mucho antes de que existieran los agentes. La diferencia es que ahora la marea de código llega más rápido.
El dato incómodo que circula en los reportes de 2026 es que buena parte del código generado por agentes compila sin errores, alrededor de nueve de cada diez casos, y aun así una porción importante, cerca de la mitad, tiene vulnerabilidades detectables por herramientas estándar. Compilar no es lo mismo que ser correcto. Y menos, ser seguro.
¿Qué vulnerabilidades heredan y crean los agentes de IA?
Los agentes reintroducen agujeros conocidos y suman algunos nuevos. Repasemos los que aparecen una y otra vez, según el relevamiento de riesgos de IA agéntica de KPMG y otros reportes de seguridad de 2026.
- Prompt injection: instrucciones maliciosas escondidas en datos que el agente procesa, que lo hacen ejecutar acciones no previstas.
- Escalación de privilegios accidental: el agente usa permisos amplios que le dieron “por las dudas” y termina tocando lo que no debía.
- Dependencias con CVEs conocidos: el agente instala paquetes con vulnerabilidades ya reportadas porque no verifica el historial de seguridad.
- Slopsquatting y typosquatting: el modelo alucina el nombre de un paquete que no existe, y un atacante registra ese nombre justo para que caiga ahí. Riesgo de cadena de suministro puro.
El slopsquatting es el más nuevo y el más traicionero. Un humano rara vez inventa un nombre de librería. Un modelo, en cambio, a veces “recuerda” una que no existe. Si alguien registró ese nombre inventado con código malicioso, el agente se lo instala solito.
La trampa de permisos: ¿por qué los agentes heredan privilegios como el malware?
Un agente hereda los permisos del operador humano que lo lanzó. Pero no hereda su criterio. Más contexto en plataformas de IA como ChatGPT.
Vos sabés que no tenés que borrar la base de producción un viernes a las 18 aunque técnicamente tengas el permiso para hacerlo. El agente no tiene esa intuición. Tiene la credencial, ejecuta la acción. Se parece bastante a cómo se mueve el malware una vez adentro: con los privilegios del usuario comprometido, sin el juicio de ese usuario.
Lo irónico es que esto ya lo sabíamos resolver. Los controles de acceso granulares, el principio de menor privilegio, los sistemas IAM y LDAP existen hace décadas justamente para esto. La guía de gobernanza de agentes de Microsoft insiste en darle a cada agente una identidad propia y acotada, en vez de que actúe con la del humano. El problema resuelto volvió a la mesa porque saltamos ese paso por velocidad.
Complejidad operacional: del test unitario a la supervisión en tiempo real
Un agente puede brillar en una tarea aislada y desarmarse en un flujo continuo. Los reportes de 2026 muestran caídas fuertes de desempeño cuando se pasa de tareas de laboratorio, donde el rendimiento supera el 80%, a contextos operativos sostenidos, donde baja de forma marcada. La causa tiene nombre: context drift, la propagación de errores y la ceguera a la deuda técnica que va acumulando.
El agente arranca bien, toma una decisión un poco desviada, la siguiente se apoya en esa, y diez pasos después está construyendo sobre una base torcida sin registrarlo. Se parece muchísimo al viejo “testing trap” que en su momento empujó a la industria hacia el desarrollo guiado por tests y la integración continua. Volvimos al punto de partida, pero con un actor que se mueve mucho más rápido que nosotros.
La brecha de trazabilidad: ¿se puede auditar lo que hace un agente?
Muchas veces, no. Y ese es un problema serio para cualquiera que tenga que rendir cuentas. Esto se conecta con lo que analizamos en base de modelos de lenguaje.
Un agente manda un mail, pega contra una API, escribe en una base, borra un archivo. Si no dejó un registro claro de por qué hizo cada cosa, reconstruir la cadena de decisiones se vuelve casi imposible. Para una empresa con obligaciones de compliance, eso es un dolor de cabeza. La analogía más justa es SOX o GDPR, pero con más piezas móviles y menos rastro.
En materia de datos personales, las guías europeas de 2026 vienen marcando que quien controla el tratamiento tiene que verificar si el agente está mandando datos a terceros, si las fuentes son confiables y si todo eso cumple normativa. Si el agente no loguea sus pasos, esa verificación no se puede hacer. Punto.
Incidentes reales de 2026: cuando los agentes se descontrolan
No es teoría. Durante 2026 se documentaron varios episodios que ponen números a todo lo anterior. Los recopila, entre otros, el registro de incidentes de seguridad de agentes IA de Kiteworks.
- Meta, incidente Sev-1 (marzo 2026): según reportes, un agente publicó una recomendación incorrecta sin pasar por aprobación humana. Causa raíz: falta de un paso de validación antes de acciones de cara al público.
- Google Gemini borrando archivos: un agente eliminó archivos por accidente al ejecutar una operación de mover. Lección: las acciones destructivas necesitan confirmación explícita, no ejecución directa.
- Herramientas open source con exfiltración de tokens: auditorías reportaron más de cien advertencias de seguridad en agentes populares, incluyendo rutas de fuga de credenciales.
El patrón se repite: el agente tiene el permiso, no tiene el freno. Y el freno lo teníamos inventado.
Gobernanza real: ¿qué controles funcionan en 2026?
La buena noticia es que casi nada de esto requiere inventar la pólvora. Requiere aplicar lo que ya sabemos, adaptado al ritmo del agente. Cubrimos ese tema en detalle en en el ecosistema de Google.
| Problema reintroducido | Solución clásica que ya existía | Control para agentes en 2026 |
|---|---|---|
| Permisos heredados sin criterio | Menor privilegio, IAM/LDAP | Identidad única por agente, scopes acotados |
| Revisión a escala imposible | Code review, CI | Gates automáticos + revisión humana en puntos críticos |
| Trazabilidad rota | Logs de auditoría, SOX | Observabilidad en tiempo real, version history |
| Dependencias inseguras | Análisis SCA, lockfiles | Verificación de paquetes, bloqueo de slopsquatting |
| Acciones destructivas | Confirmación manual | Aprobación humana antes de operaciones irreversibles |
Los marcos que ya usás para seguridad de la información sirven de base. NIST e ISO 42001 dan estructura, y sumás encima comités de gobernanza que crucen legal, seguridad y producto. Si tu infraestructura corre en servidores propios o en la nube, conviene revisar los permisos a nivel de hosting antes de soltar un agente sobre producción. Para proyectos en Argentina, donweb.com es una opción para alojar y controlar ese entorno.
Qué está confirmado y qué no
- Confirmado: hubo incidentes documentados en 2026 con agentes de codificación en empresas grandes, recopilados en reportes públicos de seguridad.
- Confirmado: la caída de desempeño entre tareas aisladas y contextos continuos es un patrón repetido en los estudios de 2026.
- No confirmado del todo: las cifras exactas de vulnerabilidades varían según el estudio y la metodología. Tomá los porcentajes como orden de magnitud, no como número cerrado.
- No confirmado: los detalles internos de cada incidente (Meta, Gemini) provienen de reportes de terceros, no siempre de comunicados oficiales completos.
Errores comunes al adoptar agentes de IA
- Darle permisos amplios “por comodidad”: arrancar con acceso total para no lidiar con configuración es la receta del desastre. Corregí acotando scopes desde el día uno.
- Confiar en que compila: que el código corra no dice nada sobre seguridad ni correctitud. Pasale análisis estático y revisión humana antes de mergear.
- No loguear las acciones del agente: si no registrás qué hizo y por qué, no vas a poder auditar ni depurar. Activá trazabilidad completa antes de producción.
- Tratar al agente como un junior confiable: un junior aprende de sus errores y tiene miedo de romper prod. El agente no. Supervisalo como supervisarías un proceso automático sin criterio.
Preguntas Frecuentes
¿Qué problemas reintroduce la IA en la ingeniería de software?
Los agentes de IA reintroducen la revisión de código a escala, el control de permisos, la trazabilidad y la seguridad de dependencias. Son problemas que la industria ya había resuelto para el ritmo de trabajo humano, pero que el volumen y la velocidad de los agentes vuelven a poner sobre la mesa.
¿Cuáles son los riesgos de seguridad de los agentes de IA?
Los principales riesgos son prompt injection, escalación de privilegios accidental, instalación de dependencias con vulnerabilidades conocidas y slopsquatting. A eso se suma la exfiltración de tokens y las acciones destructivas ejecutadas sin confirmación humana, documentadas en incidentes reales de 2026.
¿Por qué los agentes de IA no son la solución completa?
Porque resuelven la parte fácil, escribir código, y dejan expuesta la parte difícil: requisitos ambiguos, integración con sistemas complejos y mantenimiento a largo plazo. La velocidad de generación nunca fue el verdadero cuello de botella de la ingeniería de software.
¿Cómo se gobierna correctamente un agente de IA?
Con identidad única y permisos acotados por agente, observabilidad en tiempo real, aprobación humana antes de acciones irreversibles y comités que crucen legal, seguridad y producto. Frameworks como NIST e ISO 42001 sirven de base para estructurar esos controles.
¿Qué pasa cuando un agente de IA comete un error?
Sin trazabilidad, el error es difícil de reconstruir y de auditar. En 2026 se documentaron casos de agentes que borraron archivos o publicaron contenido incorrecto sin aprobación, lo que muestra la necesidad de logs completos y frenos antes de operaciones críticas.
Conclusión
Lo que cambió no es que aparecieron problemas nuevos. Cambió que los agentes de IA levantaron la alfombra y mostraron los problemas viejos, ampliados por la escala. La velocidad de escribir código dejó de importar, y volvió a importar todo lo demás: revisar, controlar permisos, auditar, cuidar la cadena de dependencias.
La ironía es sana. Casi todas las soluciones ya existen. Menor privilegio, logs de auditoría, análisis de dependencias, aprobación humana para lo irreversible. Si vas a meter agentes en tu flujo, no empieces por la potencia. Empezá por los frenos. Dale identidad propia, permisos mínimos y trazabilidad completa antes de dejarlo tocar producción. El agente escribe rápido. Vos tenés que gobernar despacio.
Fuentes
- Paper académico sobre agentes de IA y prácticas de ingeniería de software (arXiv)
- VentureBeat – La IA agéntica resolvió la codificación y expuso todos los demás problemas
- Kiteworks – Incidentes de seguridad de agentes IA 2026
- KPMG – Riesgos y vulnerabilidades de la IA agéntica
- Microsoft – Gobernanza y seguridad de agentes de IA en la organización