Can AI Agents Generate Microservices? How Far are We?

El estudio demuestra que, aunque los agentes de IA pueden generar microservicios funcionales con código de calidad y buena adherencia a contratos de API, la inconsistencia en la corrección y la necesidad de supervisión humana indican que la generación totalmente autónoma aún no es viable.

Lo esencial

Imagina que construir un sistema de software complejo (como una aplicación de banco o una plataforma de reservas de trenes) es como construir una ciudad moderna. En lugar de tener un solo edificio gigante, la ciudad está hecha de muchos barrios pequeños e independientes (estos son los "microservicios"). Cada barrio tiene su propia función: uno vende boletos, otro gestiona usuarios, otro procesa pagos. Para que la ciudad funcione, estos barrios deben hablar entre sí perfectamente, siguiendo reglas estrictas de cómo se conectan las calles (las "APIs").

El artículo que has compartido se pregunta: ¿Puede un "arquitecto robot" (una Inteligencia Artificial) diseñar y construir estos barrios por sí solo?

Aquí tienes la explicación de sus hallazgos, usando analogías sencillas:

1. El Experimento: Dos Escenarios de Construcción

Los investigadores probaron a tres "robots arquitectos" (Agentes de IA) en dos situaciones muy diferentes:

• Escenario A: La Renovación (Generación Incremental)

  • La analogía: Imagina que quieres añadir un nuevo barrio a una ciudad que ya existe y está habitada. El robot tiene que mirar las calles vecinas, respetar los códigos de construcción actuales y encajar su nuevo edificio sin romper nada.
  • El resultado: Fue más difícil de lo esperado. Cuando les dieron mucha información detallada sobre cómo era la ciudad, los robots se confundieron y construyeron cosas que no encajaban bien. Curiosamente, funcionaron mejor cuando solo se les dio una instrucción simple ("construye un barrio de pagos") y ellos mismos tuvieron que explorar la ciudad para entender las reglas.
  • Éxito: Aproximadamente 50-76% de las veces, el barrio nuevo funcionaba bien con el resto de la ciudad.

• Escenario B: El Terreno Vacío (Generación "Clean State")

  • La analogía: Imagina que tienes que construir un barrio desde cero en un desierto, basándote solo en un plano de requisitos (ej: "necesito un banco"). No hay edificios vecinos, no hay reglas preexistentes. El robot inventa todo.
  • El resultado: ¡Fue un éxito rotundo! Los robots construyeron barrios que funcionaban perfectamente entre sí (95-98% de éxito). Al no tener que encajar en una estructura rígida preexistente, fueron más creativos y cumplieron mejor las reglas de conexión.

2. La Calidad de la Construcción

• Edificios más simples: Los edificios que construyeron los robots eran, en general, más simples y menos complicados que los construidos por humanos. Esto es bueno (menos complejidad), pero a veces significa que les faltaron detalles de seguridad (como cerraduras extra o alarmas) que un humano pondría por defecto.
• El problema de la "memoria": Los robots funcionaron mucho mejor con proyectos de código abierto famosos (como "PiggyMetrics" o "Train-Ticket"). Es como si hubieran estudiado para un examen usando las mismas preguntas que salieron en el libro de texto. Cuando les dieron proyectos privados y nuevos (donde no habían estudiado antes), su rendimiento bajó. Esto sugiere que a veces "memorizan" en lugar de "razonar".

3. Velocidad y Costo (¿Cuánto cuesta contratar al robot?)

Aquí hay una gran diferencia entre los tres robots probados:

• El Lento y Caro: Un robot (Codex) tardó mucho más (promedio de 16 minutos por barrio) y a veces se quedaba "pensando" durante casi 2 horas. Fue el más costoso.
• El Rápido y Económico: Otro robot (Code Qwen) fue muy rápido (7 minutos) y muy barato.
• El Equilibrado: El tercero (Claude Code) fue rápido pero costoso, aunque escribía código muy conciso y eficiente.

Lección clave: No siempre "más texto" (código más largo) significa "mejor calidad". A veces, el robot que escribe menos palabras hace un trabajo más correcto.

4. Conclusión: ¿Estamos listos para dejar que los robots construyan ciudades?

La respuesta corta es: No del todo, pero estamos muy cerca.

• Lo bueno: Los robots pueden escribir código funcional, limpio y que cumple las reglas. Pueden ahorrar mucho tiempo a los humanos.
• Lo malo: A veces fallan en detalles críticos, especialmente cuando tienen que integrarse en sistemas existentes. A veces se "alucinan" o se confunden si les das demasiada información de golpe.
• El papel humano: Por ahora, el arquitecto humano es indispensable. No podemos simplemente darle la orden al robot y esperar. Necesitamos un humano que revise el plano, verifique que las conexiones sean seguras y que el robot no haya olvidado poner las cerraduras de seguridad.

En resumen: La IA es como un aprendiz de albañil muy talentoso y rápido. Puede levantar las paredes y poner los ladrillos perfectamente, pero todavía necesita un maestro de obra (humano) para asegurarse de que el edificio no se caiga y que encaje bien con el resto de la ciudad. Si intentamos dejar que construya todo solo sin supervisión, podríamos terminar con un barrio que no se conecta con las calles principales.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo de investigación en español, estructurado según los puntos solicitados:

Título: ¿Pueden los Agentes de IA Generar Microservicios? ¿Hasta dónde hemos llegado?

1. Problema y Contexto

La automatización de la generación de sistemas ejecutables a partir de descripciones de arquitectura es un objetivo central en la Ingeniería de Software. Aunque los Modelos de Lenguaje Grandes (LLM) han avanzado en la generación de código, su aplicación para generar microservicios completos con dependencias explícitas y contratos de API sigue siendo poco estudiada.

• El desafío: Los microservicios requieren no solo corrección lógica local, sino también una integración global estricta a través de contratos de API y patrones de interacción.
• La brecha: Existe una transición de LLMs pasivos a Agentes de IA (sistemas con capacidad de usar herramientas, memoria y refinamiento iterativo). Sin embargo, no se ha evaluado empíricamente si estos agentes pueden generar microservicios funcionales en diferentes escenarios de contexto (desde cero vs. en sistemas existentes) y cuál es la calidad del código resultante.

2. Metodología

El estudio empleó un diseño experimental riguroso para evaluar la capacidad de generación de microservicios:

• Datos y Proyectos: Se seleccionaron 4 proyectos (2 de código abierto: PiggyMetrics y Train-Ticket; 2 privados de estudiantes: TeamSync y Project Management). Se eliminaron 3 microservicios de cada proyecto para su regeneración, totalizando 144 implementaciones generadas.
• Agentes Evaluados: Se compararon 3 agentes de codificación líderes:
  1. Claude Code (Propietario).
  2. Codex (GPT-5, Propietario).
  3. Code Qwen (Open Source).
• Estrategias de Prompting (P1 vs. P2):
  • P1 (Mínimo contexto): Solo nombre del servicio y ruta de requisitos.
  • P2 (Contexto detallado): Nombre, requisitos y un resumen de implementación generado previamente.
• Escenarios de Generación:
  1. Generación Incremental: El código del servicio se elimina, pero el resto del sistema (APIs, dependencias, tests) permanece. Se evalúa con tests unitarios.
  2. Generación en Estado Limpio (Clean State): Se eliminan todas las trazas del servicio, incluyendo llamadas API externas. El agente debe inferir la arquitectura solo de los requisitos. Se evalúa con tests de integración.
• Métricas:
  • Corrección Funcional: Tasas de aprobación de tests (unitarios e integración).
  • Calidad de Código: Líneas de código (SLOC), Complejidad Ciclomática y Complejidad Cognitiva (medidas con SonarQube).
  • Eficiencia: Tiempo de generación, costo monetario y consumo de tokens.

3. Contribuciones Clave

• Primer estudio empírico sobre la generación de microservicios por agentes de IA en diferentes escenarios contextuales.
• Análisis comparativo de la eficiencia (tiempo, costo, tokens) entre agentes propietarios y de código abierto.
• Evaluación de la viabilidad de la generación "de cero" (clean state) frente a la generación incremental, revelando que la estrategia de evaluación (tipo de test) impacta drásticamente en los resultados percibidos.

4. Resultados Principales

A. Corrección Funcional (RQ1)

• Generación Incremental: El rendimiento fue moderado (50–76% de tasa de éxito en tests unitarios). Sorprendentemente, los prompts mínimos (P1) superaron a los detallados (P2). Los agentes con P2 tendieron a "anclarse" en el resumen y omitir detalles de implementación específicos (ej. convertidores de base de datos) que hubieran inferido explorando el código existente.
• Generación en Estado Limpio: Logró tasas de éxito mucho más altas (81–98% en tests de integración). Esto se debe a que los tests de integración son más flexibles con diferencias estructurales (nombres de paquetes, clases) siempre que el contrato de API se cumpla.
• Desempeño por Agente: Los agentes comerciales (Codex, Claude) superaron consistentemente a Code Qwen en escenarios incrementales. Sin embargo, Code Qwen mejoró drásticamente en estado limpio cuando se le proporcionó un resumen de implementación (P2).

B. Calidad del Código

• El código generado mostró menor complejidad (ciclomática y cognitiva) que las implementaciones humanas de referencia (baselines), manteniendo una longitud de código comparable.
• No hubo correlación entre la verbosidad del código (cantidad de tokens de salida) y la corrección funcional. Agentes como Claude Code generaron código muy conciso con alto rendimiento.

C. Eficiencia (RQ2)

• Tiempo: Claude Code y Code Qwen fueron rápidos (promedio ~7-8 min). Codex fue significativamente más lento (promedio 16.6 min) con casos atípicos extremos (hasta 104 minutos), lo que plantea riesgos de timeout en producción.
• Costo: Code Qwen fue la opción más económica ($2.98/servicio), seguida por Codex ($5.92) y Claude Code (~$13.28).
• Contaminación de Datos: Todos los agentes rindieron mejor en repositorios de código abierto populares (posiblemente memorizados) que en proyectos privados, indicando un sesgo en los datos de entrenamiento.

5. Significado y Conclusiones

• Viabilidad Parcial: Los agentes de IA pueden generar microservicios funcionales y con código mantenible, pero la corrección no es consistente y depende fuertemente del contexto y la estrategia de prompting.
• Necesidad de Supervisión Humana: La generación totalmente autónoma aún no es viable. Se requiere supervisión humana para garantizar el cumplimiento de los contratos de API y la coherencia arquitectónica, especialmente en sistemas existentes.
• Implicaciones Prácticas:
  • No existe una estrategia de prompt universal; debe determinarse empíricamente según el agente y el escenario (mínimo contexto para incremental, resumen para estado limpio).
  • Se deben establecer límites de tiempo estrictos para evitar bloqueos en flujos de trabajo.
  • Los resultados de benchmarks públicos pueden ser optimistas debido a la contaminación de datos; las evaluaciones en código propietario real son esenciales.
• Futuro: Se necesitan benchmarks específicos para arquitectura y marcos de colaboración humano-agente para definir puntos óptimos de intervención.

En resumen, la tecnología ha avanzado lo suficiente para ser una herramienta de apoyo potente en el desarrollo de microservicios, pero aún no alcanza la madurez para reemplazar al arquitecto o desarrollador humano en la toma de decisiones críticas de integración.