Durante años, las herramientas de inteligencia artificial ayudaron a los desarrolladores a completar líneas, explicar errores y generar pequeñas funciones.

Los agentes de IA representan un cambio de escala.

Pueden explorar un repositorio, localizar archivos relacionados, modificar diferentes partes del sistema, ejecutar comandos, crear pruebas, corregir fallos y abrir una pull request para su revisión.

En lugar de sugerir la siguiente línea, reciben una tarea.

“Implementa esta funcionalidad.”

“Actualiza esta dependencia.”

“Investiga por qué están fallando las pruebas.”

“Corrige esta vulnerabilidad.”

El desarrollador deja de pedir solamente una respuesta y comienza a delegar una secuencia de acciones.

Esto crea una promesa poderosa:

producir más software con menos tiempo de ejecución humana.

Pero también crea un riesgo proporcional.

Un agente capaz de trabajar en decenas de archivos puede acelerar una buena decisión.

Y puede propagar una mala decisión con la misma eficiencia.

Por eso, la pregunta no es únicamente si los agentes aumentan la productividad.

La pregunta correcta es:

¿Aumentan nuestra capacidad para entregar software sostenible o solamente adelantan el momento en el que tendremos que pagar por la velocidad?

Un agente no es simplemente un autocompletado mejorado

Los asistentes tradicionales trabajan cerca del desarrollador.

Sugieren una línea.

Completan una función.

Explican un fragmento.

El profesional continúa conduciendo prácticamente todos los pasos.

Los agentes reciben más autonomía.

Pueden decidir qué archivos deben leer, qué comandos necesitan ejecutar y qué modificaciones son necesarias para completar una tarea.

En plataformas como GitHub, los agentes ya pueden trabajar en entornos propios, explorar un repositorio, ejecutar pruebas, modificar código en ramas específicas y crear pull requests para revisión humana. La documentación oficial de GitHub Copilot describe estas capacidades y advierte que este tipo de agente tiene acceso al código, puede realizar cambios y requiere controles de permisos, trazabilidad, revisión y seguridad.

La diferencia puede parecer pequeña cuando se describe en una presentación comercial.

En la práctica, es enorme.

Una mala sugerencia afecta a una línea hasta que alguien la acepta.

Una tarea mal delegada puede afectar a decenas de archivos antes de que alguien perciba que la interpretación inicial era incorrecta.

El agente amplía la unidad de trabajo.

Como consecuencia, amplía la unidad del error.

La productividad es real

Sería un error tratar las ganancias como una ilusión.

Los agentes pueden ejecutar tareas repetitivas, crear estructuras iniciales, actualizar dependencias, escribir pruebas, corregir problemas sencillos e investigar partes de un sistema con enorme rapidez.

También pueden reducir las interrupciones.

En lugar de abandonar una tarea importante para realizar una modificación mecánica, el desarrollador puede delegar el trabajo, acompañar el resultado y mantener su atención en decisiones más complejas.

El informe DORA de 2025 encontró uso de IA entre aproximadamente el 90% de los profesionales tecnológicos encuestados. Más del 80% percibió mejoras de productividad.

Pero la conclusión principal fue más importante que esos porcentajes: la IA funciona como un amplificador.

Amplía las buenas prácticas de las organizaciones maduras y también amplía los problemas de las organizaciones desorganizadas.

Esto significa que un agente incorporado a un equipo con buenas pruebas, una arquitectura comprensible, documentación adecuada y procesos eficaces de revisión puede aumentar considerablemente la capacidad de entrega.

El mismo agente, colocado en una base de código confusa, sin pruebas ni criterios claros, puede limitarse a producir confusión con mayor rapidez.

La herramienta no sustituye la madurez de la ingeniería.

Multiplica sus efectos.

Producir más no significa entregar mejor

Muchas empresas miden el impacto de la IA mediante indicadores sencillos:

más código producido;

más pull requests abiertas;

más tareas completadas;

menos tiempo entre el comienzo y el final de una implementación.

Esos números pueden demostrar actividad.

No demuestran necesariamente valor.

Un equipo puede aumentar el número de pull requests y, al mismo tiempo, aumentar el retrabajo.

Puede completar tareas con mayor rapidez y provocar más incidentes.

Puede producir más código y hacer que el sistema sea más difícil de mantener.

Puede ahorrar dos horas durante la implementación y gastar dos días investigando una consecuencia inesperada.

La productividad en ingeniería de software no es la cantidad de código que entra en el repositorio.

Es la capacidad de transformar una necesidad en una solución confiable, manteniendo un costo sostenible a lo largo del tiempo.

El código representa solamente el inicio de ese costo.

Después de crearlo, debe ser comprendido, probado, operado, corregido, actualizado y eventualmente eliminado.

Un agente hace que la creación sea más barata.

No garantiza que el resto del ciclo también se vuelva más barato.

Deuda técnica a gran velocidad

La deuda técnica no significa simplemente código malo.

Aparece cuando una decisión facilita la entrega en el presente, pero crea un costo adicional para el futuro.

En ocasiones, la decisión es consciente.

El equipo sabe que está utilizando una solución temporal para cumplir un plazo y pretende revisarla después.

El problema es la deuda invisible.

La solución parece correcta.

Las pruebas pasan.

La pull request se aprueba.

Pero el agente introdujo duplicaciones, dependencias innecesarias, abstracciones inconsistentes, tratamientos incompletos de errores o decisiones que no encajan con el resto de la arquitectura.

Un preprint publicado en marzo de 2026 analizó 304.362 commits identificados como producidos por cinco asistentes de IA en 6.275 repositorios.

Los investigadores encontraron 484.606 problemas atribuidos a las modificaciones analizadas. Los olores de código representaron el 89,1% del total. En todas las herramientas evaluadas, más del 15% de los commits introdujo al menos un problema, y el 24,2% de los problemas analizados todavía existía en la versión más reciente del repositorio correspondiente.

Como se trata de un preprint basado en análisis estático y métodos de identificación de código producido por IA, los resultados no deben interpretarse como una medición definitiva de todos los usos de agentes. Aun así, muestran un riesgo plausible: una parte del costo introducido por el código generado no se corrige rápidamente y puede permanecer en la base.

El agente acelera la entrega.

Cuando los controles no evolucionan a la misma velocidad, también acelera la acumulación.

El código incorrecto no es el único problema

La deuda más peligrosa puede no aparecer en una herramienta de análisis estático.

Aparece cuando el sistema contiene código que funciona, pero que pocas personas comprenden.

Imaginemos que un agente modifica quince archivos para implementar una nueva regla.

Las pruebas pasan.

La funcionalidad funciona.

El desarrollador revisa rápidamente las diferencias y las aprueba.

Meses después, la regla necesita cambiar.

El equipo descubre que nadie comprendió por completo por qué se tomaron determinadas decisiones.

El código existe.

El conocimiento que debería acompañarlo no.

Este fenómeno está siendo descrito como deuda de comprensión o deuda de conocimiento.

Un estudio cualitativo de 2026, basado en 621 diarios reflexivos de 207 estudiantes, identificó patrones como la aceptación del código de IA como una caja negra, la incompatibilidad de contexto, la dependencia de la herramienta y la omisión de la verificación. Los autores definen la deuda de comprensión como la distancia creciente entre lo que un equipo sabe sobre su base de código y lo que necesita saber para mantenerla correctamente.

Como el estudio acompañó a estudiantes y no a equipos profesionales, sus resultados no deben generalizarse directamente a toda la industria. Aun así, el mecanismo descrito es relevante: la dependencia de la herramienta puede reducir el esfuerzo de comprensión independiente y crear deuda de conocimiento incluso cuando el código continúa siendo técnicamente aceptable.

El equipo no necesita únicamente poseer el software.

Necesita poseer la comprensión del software.

El agente conoce patrones, no conoce tu historia

Una base de código está formada por algo más que archivos.

Posee decisiones antiguas.

Restricciones que no aparecen en la documentación.

Dependencias mantenidas por razones específicas.

Soluciones aparentemente extrañas que existen para evitar problemas ya enfrentados.

Acuerdos entre equipos.

Exigencias jurídicas.

Limitaciones operativas.

Clientes que dependen de comportamientos no documentados.

El agente trabaja con el contexto al que puede acceder.

Cuando ese contexto es incompleto, llena los espacios mediante patrones generales.

El resultado puede ser técnicamente razonable y localmente incorrecto.

Puede crear una nueva abstracción sin percibir que la empresa ya tiene otra para la misma finalidad.

Puede sustituir un comportamiento extraño por una solución más elegante y reintroducir un fallo antiguo.

Puede seleccionar una biblioteca popular incompatible con restricciones internas.

Puede crear una arquitectura adecuada para una empresa hipotética, pero excesiva para el equipo real.

Cuanto peor sea la documentación de una organización, mayor será la distancia entre el sistema verdadero y el sistema que el agente cree estar modificando.

El problema no es que la IA no posea un contexto infinito.

Es que muchas empresas nunca organizaron el contexto que sus propios profesionales necesitaban.

El código casi correcto es especialmente peligroso

Un error evidente suele identificarse rápidamente.

El sistema no compila.

La prueba falla.

La aplicación no se inicia.

El código casi correcto es más peligroso.

Funciona durante la demostración.

Supera los escenarios esperados.

Parece coherente durante una revisión superficial.

Pero falla ante una condición poco frecuente, un volumen mayor, un permiso diferente o una integración que no se mencionó en la tarea.

Este tipo de error no interrumpe la entrega.

Llega a producción.

Los agentes son especialmente eficientes al crear soluciones plausibles.

Pero la plausibilidad no es lo mismo que la corrección.

Un agente puede proponer con confianza una biblioteca inexistente, interpretar incorrectamente un requisito o modificar un comportamiento que necesitaba conservar la compatibilidad.

Cuanto más convincente parezca la respuesta, mayor será la tentación de reducir la revisión.

Precisamente en ese momento, la revisión resulta más necesaria.

Una mayor autonomía exige más seguridad

Cuando un modelo solamente sugiere texto, su poder es limitado.

Cuando recibe acceso a archivos, terminales, dependencias, servicios y credenciales, puede realizar acciones.

Esta capacidad crea riesgos que van más allá de la calidad del código.

El OWASP Top 10 para aplicaciones con LLM describe la agencia excesiva como una combinación de funcionalidad excesiva, permisos excesivos o autonomía excesiva.

Un agente puede ejecutar una acción perjudicial como consecuencia de una respuesta incorrecta, una instrucción ambigua o una inyección de prompt encontrada en contenido externo.

Por eso, los agentes no deberían recibir automáticamente todos los permisos de la persona que los utiliza.

El principio debe ser el mismo aplicado a cualquier sistema:

el menor acceso necesario para completar la tarea.

La documentación de GitHub sobre riesgos y mitigaciones describe algunas de las protecciones aplicadas a su agente: restricciones a ramas específicas, revisión humana antes de la fusión, limitación de credenciales, controles sobre la ejecución de workflows, análisis con CodeQL, verificación de dependencias y detección de secretos. También reconoce los riesgos de inyección, fuga de información y generación de código incorrecto.

Estas protecciones demuestran algo importante.

Incluso quienes desarrollan los agentes no consideran seguro tratarlos como profesionales autónomos sin límites.

La revisión humana no puede convertirse en una ceremonia

Muchas herramientas afirman mantener al ser humano dentro del proceso.

Pero existe una diferencia entre que una persona esté presente y que ejerza un control real.

Una pull request con tres archivos puede revisarse cuidadosamente.

Una pull request con cincuenta archivos, cientos de modificaciones y explicaciones extensas aumenta la carga cognitiva.

El desarrollador puede comenzar a buscar únicamente señales evidentes de error.

¿Pasaron las pruebas?

¿Compila el código?

¿Parece coherente la descripción?

Entonces lo aprueba.

En este escenario, la revisión humana existe formalmente.

En la práctica, el agente se convierte en la principal autoridad sobre la modificación.

Revisar código generado por IA exige disciplina adicional, no menos disciplina.

Las modificaciones deben ser pequeñas.

La intención debe estar clara.

Las decisiones importantes necesitan explicarse.

Las pruebas deben cubrir comportamientos, no únicamente líneas.

El revisor debe ser capaz de describir lo que cambió sin depender del resumen producido por el propio agente.

De lo contrario, la persona no está revisando.

Solamente está autorizando.

El agente también puede generar las pruebas incorrectas

Una estrategia habitual consiste en pedir al agente que implemente la funcionalidad y escriba las pruebas.

Esto parece eficiente.

Pero crea un problema de independencia.

La misma interpretación equivocada puede aparecer en la implementación y en las pruebas.

Si el agente interpretó incorrectamente el requisito, puede producir un sistema y un conjunto de pruebas perfectamente coherentes con el mismo error.

Todo queda en verde.

El problema continúa sin resolverse.

Por eso, los criterios de aceptación no deberían surgir solamente después de generar el código.

Deben existir antes.

Las pruebas de comportamiento crítico deben derivarse de las necesidades del usuario, los riesgos y las reglas del negocio.

En sistemas sensibles también son necesarios diferentes mecanismos de verificación:

pruebas automatizadas;

análisis estático;

verificación de dependencias;

revisión de seguridad;

pruebas de integración;

observabilidad;

validación humana.

Ninguna técnica aislada ofrece suficiente confianza.

No todas las tareas deberían delegarse de la misma manera

Los agentes funcionan mejor cuando la tarea tiene límites claros.

Actualizar una dependencia específica.

Añadir pruebas para un comportamiento conocido.

Corregir un error reproducible.

Migrar una API bien documentada.

Modificar una interfaz siguiendo un patrón existente.

En estos casos existen criterios objetivos para evaluar el resultado.

El riesgo aumenta cuando la tarea es ambigua.

“Mejora la arquitectura.”

“Optimiza el sistema.”

“Corrige los problemas de seguridad.”

“Moderniza este módulo.”

“Haz que el código sea más limpio.”

Estas solicitudes exigen decisiones relacionadas con prioridades, compatibilidad, costes, riesgos y contexto organizativo.

Un agente puede producir modificaciones impresionantes.

Pero no posee necesariamente la autoridad ni el conocimiento para decidir qué compromisos debería asumir la empresa.

Cuanto más amplia sea la tarea, menor debería ser la autonomía inicial.

La calidad de la especificación determina el radio del error

Delegar a un agente no elimina la necesidad de especificar.

La aumenta.

Una instrucción ambigua dirigida a una persona genera una conversación.

La persona pregunta.

Negocia.

Percibe contradicciones.

Una instrucción ambigua dirigida a un agente puede generar cientos de líneas antes de que la ambigüedad resulte visible.

Por eso, una buena tarea necesita describir:

el problema que debe resolverse;

el comportamiento esperado;

aquello que no debe modificarse;

las restricciones técnicas;

los riesgos conocidos;

las pruebas necesarias;

los límites de la actuación.

Cuanto mayor sea la autonomía, más claros deben ser los límites.

Los prompts no sustituyen las especificaciones.

Solamente son una nueva interfaz para ellas.

Cómo utilizar agentes sin acelerar la deuda

La respuesta no es impedir su uso.

Es construir un sistema de trabajo en el que la velocidad y el control crezcan juntos.

El primer principio es limitar la tarea.

Los agentes deberían comenzar con modificaciones pequeñas, reversibles y fáciles de validar.

El segundo es limitar los permisos.

Un agente no necesita acceso irrestricto al entorno de producción, a todos los repositorios ni a todos los secretos para modificar una función.

El tercero es definir los criterios antes de la ejecución.

¿Qué significa completar la tarea?

¿Qué comportamientos deben conservarse?

¿Qué pruebas necesitan pasar?

El cuarto es preservar una revisión humana real.

Quien aprueba debe comprender la modificación y asumir la responsabilidad por ella.

El quinto es automatizar la verificación.

Las pruebas, el análisis estático, la verificación de dependencias, la detección de secretos y las políticas arquitectónicas necesitan ejecutarse de manera consistente.

El sexto es mantener la trazabilidad.

Debe ser posible identificar qué produjo el agente, quién solicitó la modificación, qué instrucciones se proporcionaron y qué verificaciones se realizaron.

El séptimo es medir las consecuencias, no el volumen.

El tiempo de ciclo importa.

Pero también importan el retrabajo, los fallos, las vulnerabilidades, el tiempo de revisión, la complejidad y el costo de mantenimiento.

El octavo es preservar el conocimiento.

Las decisiones relevantes deben documentarse, y los profesionales necesitan poder explicar el código que aprueban.

El mejor uso del agente no consiste en eliminar al desarrollador

Consiste en eliminar partes del trabajo que consumen tiempo sin exigir lo mejor del desarrollador.

Un agente puede preparar una modificación.

Investigar archivos relacionados.

Crear una primera versión.

Ejecutar verificaciones.

Señalar inconsistencias.

El profesional puede concentrar su atención en los requisitos, la arquitectura, los riesgos, la calidad y el impacto.

Esta combinación es más valiosa que intentar convertir al agente en un sustituto completo.

El agente aporta velocidad.

El desarrollador debe aportar contexto y criterio.

El agente explora alternativas.

El desarrollador decide qué compromisos son aceptables.

El agente produce.

El desarrollador responde por lo que entra en el sistema.

Cuando cada parte desempeña el papel adecuado, la productividad puede ser real.

Cuando la empresa utiliza al agente solamente para aumentar el volumen, la ganancia a corto plazo puede ocultar una factura creciente.

¿Productividad real o deuda técnica acelerada?

Existen ambas posibilidades.

Los agentes pueden reducir el trabajo repetitivo, acelerar investigaciones, ampliar la cobertura de pruebas y permitir que equipos pequeños realicen tareas antes inviables.

También pueden introducir código inconsistente, ampliar la superficie de ataque, ocultar decisiones y crear sistemas que nadie comprende por completo.

La diferencia no depende únicamente de la calidad del modelo.

Depende de la madurez del equipo que lo utiliza.

Una organización sin pruebas no se vuelve disciplinada porque adopte IA.

Una base de código sin arquitectura no se vuelve comprensible porque un agente pueda modificarla.

Un equipo sin revisión no se vuelve seguro porque la herramienta genere un resumen convincente.

La IA no resuelve automáticamente los problemas de ingeniería.

Permite producirlos a otra escala.

Los agentes no deberían evaluarse por la cantidad de código que pueden escribir.

Deberían evaluarse por la cantidad de trabajo sostenible que ayudan a completar.

La velocidad es una forma de productividad.

Poder continuar avanzando después de esa velocidad es otra.

Un agente puede entregar hoy aquello que un equipo habría necesitado una semana para producir.

La pregunta es quién comprenderá, mantendrá y corregirá esa entrega dentro de un año.

Cuando esa pregunta tiene una buena respuesta, existe productividad.

Cuando nadie puede responder, probablemente solamente estamos generando deuda con mayor rapidez.