Agentes de IA en el desarrollo de software: adoptar con gobernanza

Un asistente de IA espera a que le preguntes. A un agente de IA se le asigna un objetivo y actúa hasta que lo logra, o hasta que se queda atascado en el intento.

Esta diferencia es la frontera más importante en el desarrollo de la IA en la actualidad. Los agentes codificadores no sugieren fragmentos: toman una tarea, abren el repositorio, cambian archivos, ejecutan las pruebas, leen lo que falló, lo corrigen y abren una solicitud de extracción para su revisión.

La pregunta para quienes lideran no es si existe esta capacidad. Existe y funciona. La cuestión es cómo adoptarlo sin cambiar la productividad por el caos.

¿Qué es un agente de codificación en la práctica?

Un agente trabaja en bucle. Recibe una meta, planifica pasos, ejecuta una acción, observa el resultado y decide el siguiente paso. Repita esto hasta que lo complete o se dé por vencido.

Lo que diferencia al agente del asistente es la autonomía sobre las acciones. No se limita a escribir el código: ejecuta el comando, lee la salida del terminal, se da cuenta de que la prueba no funciona y vuelve a intentarlo. No estás atrapado en medio de cada iteración.

Esto le permite delegar tareas completas. "Migrar este servicio a la nueva versión de la biblioteca y garantizar que las pruebas pasen" deja de ser un script que ejecutas manualmente y se convierte en una solicitud que el agente cumple y tú revisas el resultado final.

Es poderoso. Y es precisamente porque es poderoso que necesita reglas.

Dónde actúan los agentes

Los agentes destacan en tareas bien definidas, verificables y tediosas. Cuanto más clara sea la definición de listo, mejor será el resultado.

Dan sus frutos al escribir pruebas para código existente, porque el criterio es objetivo: la prueba pasa o no, cubre o no. Resultan en refactorizaciones mecánicas que se repiten en docenas de archivos, el tipo de cambio que cansa a los humanos y los tienta a perder la atención. Resultan en migraciones de dependencias, actualizaciones de sintaxis y corrección de errores que aparecen en la compilación.

También se benefician de la exploración de bases desconocidas. Pedirle a un agente que determine cómo funciona una función o dónde se implementa una regla comercial ahorra horas de lectura. La fase de mantenimiento, siempre la más cara en sistemas de larga duración, es donde veo el mayor retorno con el menor riesgo.

El denominador común es simple: tarea con criterios de éxito verificables. Cuando hay una prueba que dice “funcionó”, el agente tiene orientación.

Otra característica de las tareas que realizan los agentes es la rápida retroalimentación. Cuando el agente ejecuta un comando y ve el resultado en segundos, lo itera y lo corrige por sí solo. Cuando la señal de éxito es lenta, vaga o solo aparece en producción, el bucle se rompe y el agente queda girando. Por eso vale la pena preparar el terreno: una base con buenas pruebas y una construcción rápida extrae mucho más valor de un agente que una base sin una red de seguridad, donde cada error sólo aparece tarde.

Donde fallan los agentes

Fracasan cuando los criterios de éxito son ambiguos o inexistentes. Decisiones arquitectónicas, elecciones de productos, compensaciones que dependen del contexto empresarial: nada de esto tiene una prueba que diga si es correcto, y el agente producirá algo plausible que podría ser completamente incorrecto para su caso.

Fracasan en tareas que requieren comprender el por qué, no sólo el cómo. Un agente refactoriza una función para que parezca más limpia y, en el camino, borra un identificador de borde que existía por una razón que no está escrita en ninguna parte.

Fracasan silenciosamente y ese es el riesgo más peligroso. El código vuelve a funcionar, las pruebas pasan, la solicitud de extracción parece impecable y la lógica es sutilmente defectuosa. La IA comete errores con confianza, y la confianza contamina a quienes revisan con prisa.

Y fallan a gran escala cuando se confía demasiado. Un agente que abre diez pull request al día genera diez reseñas de dudosa calidad para un humano que sigue siendo uno solo. Sin gobernanza, el cuello de botella migra al revisor exhausto.

Los datos que justifican la precaución

Vale la pena repetir el número que respalda esta postura. En la encuesta Stack Overflow de 2025, con más de 49.000 encuestados, la desconfianza en la precisión de las herramientas de IA supera la confianza, y solo una fracción muy pequeña, el 3%, confía firmemente en ellas.

Este escepticismo de los propios desarrolladores no es resistencia al cambio. Es la experiencia de quienes viven con la herramienta y han visto dónde tropieza. Un líder que adopta agentes necesita diseñar el proceso basándose en esta realidad, no en contra de ella.

Confiar poco y comprobar mucho no es falta de ambición. Es la única forma responsable de aprovechar al máximo lo que los agentes tienen para ofrecer.

Cómo adoptar con gobernanza

La gobernanza aquí no es burocracia, es el conjunto de reglas que permiten utilizar agentes de forma segura. Comienza por definir qué se puede delegar y qué no.

Delegar lo verificable y lo reversible. Tareas con pruebas claras, cambios aislados, trabajo que un pull request puede contener y revertir. No delegues las cosas irreversibles y críticas sin un humano a cargo: migración de base de datos a producción, cambios de configuración de seguridad, cambios que afecten a los datos de los clientes.

Mantener el agente dentro de los límites técnicos. Entornos aislados, permisos restringidos, sin acceso directo a producción, sin posibilidad de implementarlo solo. El agente propone, el humano decide lo que sale al aire. Para obtener detalles sobre cómo organizar esto, escribí sobre agentes de IA en entornos empresariales y sobre la gobernanza al adoptar estas herramientas en las empresas.

Trate cada solicitud de extracción de agente como una solicitud de extracción de alguien nuevo en el equipo: revisión obligatoria, sin excepción, con especial atención a la lógica y no solo a la sintaxis. Y medir los resultados. Si la tasa de defectos aumenta o la base se vuelve más difícil de mantener, el agente no está ayudando, incluso si parece productivo.

El humano como revisor responsable

La responsabilidad no es delegable. Cuando el código entra en producción, la persona que lo aprobó es quien responde, no la herramienta que lo generó.

Esto reposiciona al ingeniero. El valor deja de estar en escribir cada línea y pasa a definir bien la tarea, juzgar bien el resultado y tomar la decisión. Es un rol de mayor jerarquía, no menos, y requiere más discreción, no menos.

El revisor responsable es aquel que comprende el código hasta el punto de no estar de acuerdo con él. Quién nota el borde borrado, la suposición equivocada, el atajo peligroso. Un equipo que delega en agentes pero mantiene revisores sólidos gana velocidad sin perder el control. Un equipo que delega y relaja la revisión simplemente está subcontratando sus errores.

Si va a presentar agentes, comience con algo pequeño y verificable: elija una tarea con pruebas claras, deje que el agente la ejecute y revísela como si fuera el trabajo de un nuevo empleado. La gobernanza se construye antes de escalar, no después del primer incidente.

Fuente: Encuesta de desbordamiento de pila 2025.