Agentes de IA en desarrollo de software: qué hacen y cómo se integran al SDLC

Por Ignacio Muñoz Riquelme

Los copilotos demostraron que la IA puede acelerar tareas de desarrollo. Los agentes introducen una discusión distinta: qué ocurre cuando la IA deja de limitarse a sugerir y empieza a ejecutar trabajo dentro del SDLC.

Para mí, esa es la diferencia que importa.

Un agente puede recibir contexto del proyecto, utilizar herramientas y participar en tareas de arquitectura, desarrollo, QA o seguridad. Cuando varios agentes empiezan a intervenir en un mismo ciclo, ya no basta con medir cuánto código generan. Hay que decidir cómo se especializan, qué acceso reciben, cómo se coordinan y dónde sigue siendo necesaria una validación humana.

En ACL powered by DataArt este problema ya forma parte de iniciativas concretas. SPIREX® trabaja la orquestación de múltiples agentes bajo un mismo flujo, incorporando supervisión human-in-the-loop, trazabilidad y control.

A escala global, Artisyn integra agentes de IA, contexto unificado de proyecto y bases reutilizables a lo largo de diseño, desarrollo, testing y despliegue.

Eso cambia la pregunta. Ya no es solo “¿podemos usar IA para programar?”.

Es qué parte del proceso tiene sentido delegar y bajo qué condiciones.

¿Qué es un agente de IA en desarrollo de software?

Un agente de IA combina un modelo con contexto, herramientas y reglas de ejecución para completar una tarea con cierto grado de autonomía.

Dentro del SDLC puede, por ejemplo, recibir una historia de usuario, consultar documentación y código existente, analizar dependencias y preparar una propuesta técnica. Otro agente podría utilizar esa salida para generar pruebas o continuar una tarea específica.

La diferencia con un copiloto no está únicamente en la capacidad del modelo.

Un copiloto normalmente propone. Un agente puede continuar trabajando sobre la instrucción.

Esa capacidad de actuar es la que obliga a diseñar controles alrededor del modelo.

¿Qué diferencia a un agente de un asistente o copiloto?

No usaría “autónomo” como sinónimo automático de “mejor”.

Cuanta más autonomía recibe un agente, mayor es la superficie que tengo que gobernar.

Un copiloto puede sugerir una implementación y esperar la decisión del desarrollador. Un agente puede además consultar un repositorio, trabajar sobre artefactos, utilizar herramientas o ejecutar determinados pasos dentro de un flujo.

Para evaluar agentes de IA en el SDLC, yo miraría cuatro variables:

Contexto: qué información recibe.
Herramientas: a qué sistemas puede acceder.
Permisos: qué está autorizado a hacer.
Validación: cuándo una persona debe intervenir.

Ese diseño importa bastante más que simplemente conectar un LLM con varias herramientas.

¿Qué tareas puede ejecutar un agente en el SDLC?

Los agentes pueden intervenir en distintas etapas, pero no todas necesitan el mismo nivel de autonomía.

En requisitos pueden apoyar la revisión de historias, dependencias y criterios de aceptación.

En arquitectura pueden contrastar requerimientos con estándares técnicos y componentes existentes.

En desarrollo pueden generar o modificar código, preparar pruebas unitarias y apoyar revisiones.

En QA pueden transformar requisitos en casos de prueba, analizar resultados o identificar brechas de cobertura.

Y en seguridad pueden incorporar controles específicos dentro del flujo.

ACL ya viene trabajando esta lógica desde QA. En nuestro análisis sobre SDLC y QA con IA planteamos algo importante: si QA entra tarde o el input es deficiente, la IA no corrige el problema de fondo; puede simplemente acelerar un proceso que ya venía mal diseñado.

Con agentes, esa disciplina se vuelve todavía más relevante porque el sistema ya no solo genera contenido: puede utilizar ese resultado para continuar ejecutando trabajo.

Agentes especializados: arquitectura, desarrollo, QA y seguridad

Yo evitaría pensar en un único “superagente” encargado de todo el SDLC.

Cada función necesita información, herramientas y límites distintos.

Un agente de arquitectura necesita contexto técnico y restricciones de diseño. Desarrollo necesita repositorios, dependencias y convenciones. QA necesita requerimientos, criterios de aceptación y evidencia. Seguridad trabaja con políticas y controles distintos.

La especialización permite limitar contexto y permisos según la tarea.

Y aparece una pregunta más interesante:

¿qué ocurre cuando la salida de un agente se convierte en el input de otro?

Ahí empieza el problema de orquestación.

¿Por qué varios agentes necesitan orquestación?

Cuando varios agentes participan del mismo delivery, alguien tiene que definir el flujo.

Qué agente interviene, qué información recibe, qué herramientas puede usar, qué salida debe producir y en qué puntos una persona valida el resultado.

Eso es bastante distinto de conectar varias automatizaciones.

‍

SPIREX® aborda precisamente esa capa entre los agentes, los modelos y los sistemas de una organización. El framework conecta múltiples agentes bajo un flujo determinista e incorpora supervisión activa, human-in-the-loop y acciones trazables, reversibles y auditables.

La diferencia práctica es importante:

el objetivo no es conseguir que el agente haga más cosas, sino controlar qué puede hacer dentro del proceso.

Contexto, herramientas y permisos

Un agente puede utilizar un modelo potente y aun así producir una mala salida si trabaja con contexto incorrecto.

Por eso separaría tres decisiones.

Contexto: entregarle la información necesaria para cumplir su función.

Herramientas: definir qué repositorios, documentación, ambientes o servicios necesita utilizar.

Permisos: limitar las acciones que puede ejecutar.

Leer una especificación, modificar código y desplegar un cambio tienen perfiles de riesgo muy distintos. El nivel de autonomía debería reflejarlo.

La regla práctica es sencilla: un agente no necesita acceso a todo para hacer bien su trabajo.

¿Qué riesgos introduce la autonomía?

El problema no es únicamente que un agente pueda equivocarse. Un desarrollador también puede hacerlo.

La diferencia está en hasta dónde puede propagarse el error antes de que alguien lo revise.

Si una salida incorrecta alimenta automáticamente otra tarea, el impacto puede avanzar por varias etapas del ciclo.

Por eso pondría foco en:

privilegios mínimos;
puntos de validación humana;
trazabilidad;
capacidad de revertir acciones;
evidencia de ejecución.

SPIREX® incorpora precisamente esta lógica al plantear seguridad, estabilidad, auditoría y trazabilidad como parte de la ingeniería necesaria para llevar agentes desde una demo hacia operación real.

¿La IA agéntica realmente puede mejorar el delivery?

Ya existen casos que permiten mirar resultados más allá de la demo.

En el trabajo de DataArt con Girls Who Code, el equipo construyó una práctica AI-native alrededor de Claude Code. En tres meses, el lead time promedio de desarrollo se redujo aproximadamente de siete días a tres días y medio.

El dato es relevante, pero no lo interpretaría como una promesa universal.

Lo interesante es dónde aparece el resultado: no simplemente en entregar una herramienta de IA al desarrollador, sino en incorporarla al sistema de ingeniería, incluyendo desarrollo, revisión y QA.

Ese cambio de unidad de análisis es importante.

Ya no medimos solamente cuánto más rápido programa una persona.

Medimos qué ocurre con el delivery completo.

¿Cómo comenzar con agentes sin automatizar todo el SDLC?

No empezaría construyendo un SDLC autónomo.

Partiría con una tarea acotada, frecuente y fácil de validar.

Por ejemplo:

preparar historias desde una épica;
revisar criterios de aceptación;
generar casos de prueba;
apoyar una revisión de código;
preparar documentación técnica.

Después mediría tres variables:

tiempo, calidad de la salida e intervención humana necesaria.

Si el caso demuestra valor, recién ampliaría contexto, herramientas o autonomía.

Ese enfoque permite aprender con un radio de impacto controlado y evita construir una arquitectura multiagente antes de saber dónde existe valor real.

¿Cómo SPIREX® orquesta agentes dentro del ciclo de desarrollo?

SPIREX® parte de una necesidad concreta: poner ingeniería alrededor de los agentes.

En lugar de tratar arquitectura, desarrollo, QA o seguridad como automatizaciones aisladas, permite conectar múltiples agentes dentro de un mismo flujo, incorporar contexto y establecer puntos de supervisión sobre tareas críticas.

Artisyn lleva esa misma conversación al modelo global de delivery de DataArt. Combina agentes especializados, contexto unificado, fundamentos reutilizables y estándares de gobernanza a lo largo del diseño, desarrollo, testing y despliegue.

Para una organización que ya experimentó con copilotos, este es probablemente el siguiente problema relevante:

cómo incorporar más autonomía al SDLC sin perder control sobre la ingeniería.

De copilotos a un SDLC con agentes

Los agentes de IA en desarrollo de software pueden cambiar más que la velocidad con la que escribimos código.

También cambian cómo distribuimos contexto, trabajo y decisiones dentro del ciclo.

Por eso, antes de sumar autonomía, yo definiría cuatro cosas con precisión: qué tarea quiero delegar, qué necesita el agente para ejecutarla, qué puede modificar y quién valida el resultado.

Si estás evaluando ese recorrido, puedes profundizar primero en nuestra guía sobre desarrollo de software con IA.

Y si el desafío ya está en llevar agentes desde una prueba hacia un flujo real de ingeniería, SPIREX® muestra cómo estamos abordando la orquestación, el control y la integración dentro del SDLC.

Preguntas frecuentes sobre agentes de IA en desarrollo de software

¿Cuál es la diferencia entre un agente de IA y un copiloto de desarrollo?

Un copiloto normalmente asiste a una persona y espera una nueva instrucción para continuar. Un agente puede utilizar contexto y herramientas para ejecutar varios pasos de una tarea con cierto grado de autonomía.

La diferencia relevante no es solo qué modelo utiliza, sino qué capacidad tiene para actuar dentro del proceso.

¿En qué etapas del SDLC pueden utilizarse agentes de IA?

Pueden participar en requisitos, arquitectura, desarrollo, QA, seguridad, documentación y tareas relacionadas con DevOps.

El grado de autonomía no debería ser igual en todas las etapas. Depende del riesgo de la acción, los permisos necesarios y la facilidad para validar o revertir el resultado.

¿Qué necesita una empresa antes de incorporar agentes al desarrollo de software?

Como mínimo, debería definir contexto, herramientas, permisos y puntos de validación humana.

Cuando varios agentes participan del mismo proceso, también se necesita una capa de orquestación que defina cómo se relacionan entre ellos y cómo pasa el trabajo de una etapa a otra.

¿Conviene automatizar todo el SDLC con agentes de IA?

No necesariamente.

Un punto de partida más controlado es seleccionar una tarea concreta, repetitiva y fácil de validar, medir el resultado y aumentar autonomía solo cuando exista evidencia de valor.

Automatizar más etapas no es por sí mismo una señal de madurez.