Estudio sobre el impacto de la IA generativa: siete principios para el desarrollo de software agente

A la hora de aplicar el desarrollo de software basado en agentes, hay siete principios que marcan la diferencia:

1. Los ciclos cortos son mejores que los sprints largos: El desarrollo ágil clásico funciona en sprints de dos a tres semanas. Los equipos «agentes» establecen ciclos de dos a cuatro días a lo largo de todo el ciclo de vida del desarrollo de software: desde los requisitos, pasando por la implementación y las pruebas, hasta la revisión y la puesta en marcha. Esto supone una diferencia tanto cuantitativa como cualitativa. Los ciclos más cortos cambian la forma en que se toman las decisiones, cómo se detectan los errores y la rapidez con la que un equipo reacciona ante los cambios en los requisitos. Los agentes trabajan de forma continua, por la noche y los fines de semana. Los lanzamientos son más frecuentes y las iteraciones, más cortas. Quien ha trabajado alguna vez a este ritmo, no quiere volver atrás.

2. Diferentes funciones del ser humano y del agente: El error más común al empezar: tratar a los agentes de IA como si fueran desarrolladores muy rápidos. Los agentes no son desarrolladores junior a los que simplemente se les pueda dejar trabajar libremente en las tareas. Son instancias ejecutivas que necesitan unas pautas precisas para funcionar. El ser humano aporta el „por qué“ y el „qué“: principios de arquitectura, requisitos funcionales, criterios de calidad. El agente se encarga de la ejecución. Esto incluye: generar código, realizar pruebas, corregir errores y redactar documentación. Todo ello en bucles de retroalimentación continuos, sin que sea necesario iniciar manualmente cada paso.

3. La calidad de los datos de entrada determina el resultado: La «alucinación» no es un problema técnico que se resuelva con un modelo mejor, sino un problema de contexto. Los requisitos vagos para los agentes de IA proporcionan resultados vagos. Los artefactos estructurados, como las especificaciones claras, los principios de arquitectura y la documentación de contexto, no son una obligación molesta, sino el verdadero nivel de control. Un buen documento de especificaciones es más valioso en el desarrollo de agentes que mil líneas de código escrito a mano. Es la diferencia entre un agente que sabe lo que hace y otro que va a ciegas.

„La cuestión no es si las empresas actúan como agentes...»
no solo cómo van a trabajar, sino también la rapidez con la que van a
”Crear las condiciones necesarias para ello».”

Benedikt Bonnmann,
Miembro del consejo de administración,
Adesso

4. Automatización guiada en lugar de autonomía total: Uno de los malentendidos más arraigados es que los agentes programan por su cuenta, mientras que las personas se limitan a observar. Pero los agentes no actúan libremente, sino dentro de estructuras definidas por las personas. En la práctica, esto significa que los agentes altamente especializados, con un enfoque claramente delimitado y un contexto preciso, trabajan dentro de puntos de traspaso definidos explícitamente, controles de calidad automatizados y criterios de aceptación claros. El ser humano, en su calidad de instancia de control, se encarga de lo que requiere el criterio humano: decisiones de arquitectura, orientaciones estratégicas, aprobaciones finales… pero no la revisión línea por línea.

5. Gobernanza: una obligación, no una opción: El desarrollo basado en agentes plantea nuevas cuestiones a los responsables de cumplimiento normativo. ¿Qué modelos se pueden utilizar en cada proyecto? ¿Cómo se garantiza que no se incluya código con propiedad intelectual protegida en los datos de entrenamiento? ¿Quién asume los costes de los LLM y cómo se asignan a cada proyecto concreto? Son cuestiones que tienen solución, pero que deben resolverse antes de la primera implementación productiva, no después. Un acceso estandarizado y conforme a la legislación a los LLM, con una estructura de costes transparente y normas de gobernanza definidas, es la base para que el desarrollo basado en agentes pueda escalar.

6. El legado no es un obstáculo: La idea de que el desarrollo de software basado en agentes solo funciona en entornos totalmente nuevos es errónea. En la práctica se ha demostrado que las bases de código existentes, los sistemas consolidados y los equipos mixtos pueden integrarse en procesos basados en agentes. El requisito previo es una metodología diseñada específicamente para ello. El principio clave es el paralelismo. Los equipos clásicos y los de tipo «agente» trabajan en el mismo sistema, con puntos de traspaso claramente definidos y un mecanismo de coordinación como Kanban, que evita conflictos entre las diferentes frecuencias de ciclo. Un equipo clásico trabaja en sprints de dos semanas, mientras que un equipo basado en agentes, en el mismo proyecto, lo hace en ciclos de entre dos y cuatro días. No se trata de una mera teoría, sino de algo que ya se ha puesto a prueba en proyectos de clientes.

7. El software es solo el principio: Los principios del trabajo basado en agentes describen un modelo básico para la colaboración entre personas y sistemas autónomos, como la distribución clara de funciones, las aportaciones estructuradas, los ciclos cortos, la automatización guiada y la gobernanza por diseño. Los enfoques basados en agentes pueden aplicarse en todos aquellos ámbitos en los que los procesos sean iterativos, documentables y dividibles en pasos bien definidos. En el control de calidad, en el procesamiento de documentos y en el análisis automatizado. Y en procesos empresariales que las empresas siguen gestionando hoy en día de forma totalmente manual. No porque tenga sentido, sino porque hasta ahora no existía una alternativa viable.

Al directorio de socios: