💻 computer science

Can LLMs Produce Better Object-Oriented Designs than Human-Involved Development?

Este estudio compara la calidad del diseño orientado a objetos en proyectos Java pre-LLM, post-LLM y puramente LLM, encontrando que, aunque el código generado por LLM presenta una complejidad menor y menos olores de código, a menudo adolece de una simplificación excesiva y una separación de responsabilidades débil, lo que subraya la necesidad continua de la guía humana en la descomposición del diseño.

Autores originales: Zushuai Zhang, Elliott Wen, Ewan Tempero

Publicado 2026-05-20

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Zushuai Zhang, Elliott Wen, Ewan Tempero

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres un arquitecto maestro encargado de construir una casa compleja. Tienes tres equipos diferentes entre los que elegir para realizar la construcción:

La Vieja Guardia (PreIA): Constructores experimentados que nunca han utilizado un asistente informático. Dibujan sus propios planos y construyen todo a mano.
La Tripulación Híbrida (PostIA): Constructores experimentados que ahora cuentan con un potente asistente informático. Siguen dibujando los planos y tomando las grandes decisiones, pero permiten que la computadora les ayude a colocar ladrillos y cortar madera.
El Equipo de Robots (IA Pura): Un equipo de robots avanzados que toman una descripción verbal sencilla de la casa y construyen todo desde cero, de principio a fin, sin que un humano toque ninguna herramienta.

Este artículo plantea una pregunta sencilla: ¿Qué equipo construye la mejor casa? Específicamente, ¿el "Equipo de Robots" crea un diseño que sea tan bueno, o incluso mejor, que el de los equipos humanos?

El Experimento

Los investigadores organizaron un "desafío de construcción" utilizando un juego de mesa clásico llamado Kalah. Pidieron a tres grupos que desarrollaran un programa en Java para jugar a este juego:

Grupo 1 (PreIA): Estudiantes de 2021 (antes de que las herramientas de programación con IA fueran comunes).
Grupo 2 (PostIA): Estudiantes de 2024 (después de que las herramientas de IA se popularizaran).
Grupo 3 (IA Pura): La misma tarea asignada a tres modelos de IA de primer nivel, que generaron el código completamente por sí mismos.

No solo verificaron si el juego funcionaba; examinaron la calidad del diseño. Piensa en esto como verificar si la casa tiene una distribución lógica, si las habitaciones tienen el tamaño adecuado y si la fontanería no está enredada.

Lo que Descubrieron

1. El Equipo de Robots Construyó Casas "Más Pequeñas", Pero Eran Demasiado Simples

Los equipos de IA Pura (Robots) construyeron código que parecía muy limpio en la superficie.

La Buena Noticia: Su código tenía menos "olores" (malos hábitos como código desordenado) y parecía menos complejo en general. Era como una casa con muy pocas paredes y una planta muy abierta.
La Mala Noticia: Esta simplicidad era en realidad un problema. Los robots simplificaron en exceso el diseño. En lugar de construir habitaciones separadas para el "Jugador", el "Tablero" y los "Huecos" (los agujeros del juego), los robots a menudo aplastaron todo en una o dos habitaciones gigantes.
La Metáfora: Imagina una casa donde la cocina, el dormitorio y el baño son todos una sola habitación grande sin puertas. Es muy simple y fácil de limpiar (baja complejidad), pero es terrible para vivir porque no puedes separar tus actividades (mala "separación de responsabilidades"). Los robots pasaron por alto las importantes "abstracciones" (los conceptos distintos) que hacen que un sistema sea comprensible.

2. La Tripulación Híbrida (PostIA) Empezó a Actuar como Robots

Los estudiantes de 2024 (que utilizaron asistentes de IA) no construyeron tan "robóticamente" como el equipo de IA Pura, pero estaban más cerca de los robots que los estudiantes de 2021.

Sus diseños también se estaban volviendo un poco demasiado simples, omitiendo algunas de las "habitaciones" (conceptos) distintas que incluían los estudiantes de 2021.
Sin embargo, a diferencia de los robots, el código de la Tripulación Híbrida en realidad tenía más hábitos desordenados (olores de código) que los estudiantes de la vieja escuela. Parece que cuando los humanos intentan corregir o editar código generado por robots, a veces introducen nuevos desordenos localmente, incluso si la estructura general parece simple.

3. El "Prompt" Importa, Pero No es una Varita Mágica

Los investigadores intentaron dar a los robots instrucciones más específicas, como "Asegúrate de tener una clase separada para el Jugador y otra separada para el Tablero".

Resultado: Cuando las instrucciones eran más específicas, los robots hicieron un mejor trabajo creando "habitaciones" (conceptos) separadas.
Limitación: Incluso con las mejores instrucciones, los robots aún no lograron igualar la calidad de las casas diseñadas por humanos. Todavía tendían a simplificar en exceso.

La Gran Conclusión

Los robots son excelentes colocando ladrillos, pero los humanos siguen siendo necesarios para dibujar los planos.

El artículo concluye que, aunque la IA puede escribir código que funciona y parece limpio, lucha con la visión general del Diseño Orientado a Objetos. Tiende a agrupar todo para hacer las cosas "simples", lo que en realidad hace que el software sea más difícil de mantener más adelante porque se pierden las partes distintas del sistema.

IA Pura (Robots): Excelentes evitando pequeños errores, pero malos entendiendo la gran estructura.
PostIA (Humanos con IA): Empezando a perder algo de la profundidad estructural, y a veces haciendo el código más desordenado en el proceso.
La Lección: Si usas IA para escribir software, debes actuar como el arquitecto. Necesitas decirle a la IA exactamente cómo dividir el problema en partes distintas (descomposición) y de qué es responsable cada parte. Si solo dices "construye un juego", la IA construirá una versión desordenada y simplificada en exceso que parece limpia pero es difícil de arreglar más adelante.

Resumen Técnico: ¿Pueden los LLMs Producir Diseños Orientados a Objetos Mejores que el Desarrollo con Participación Humana?

Declaración del Problema

Aunque los Modelos de Lenguaje Grandes (LLM) son cada vez más capaces de generar código, su habilidad para producir un Diseño Orientado a Objetos (OOD) de alta calidad para proyectos multi-clase sigue siendo incierta. Investigaciones anteriores se han centrado principalmente en:

La corrección funcional a nivel de problema (métodos o clases individuales) en lugar de la arquitectura a nivel de proyecto.
Líneas base pre-LLM, sin tener en cuenta el impacto del desarrollo humano asistido por LLM (PostAI).
Artefactos de alto nivel (por ejemplo, diagramas UML) en lugar de la mantenibilidad y la calidad estructural del código implementado.

Este estudio aborda la brecha en la comprensión de cómo la calidad del OOD en proyectos generados de extremo a extremo por LLMs (PureAI) se compara con los proyectos con participación humana producidos antes (PreAI) y después (PostAI) de la adopción generalizada de LLMs.

Metodología

Los autores realizaron un estudio de caso comparativo utilizando una asignación de posgrado en Java: la implementación del juego de tablero Kalah. El estudio analizó 11 conjuntos de datos en tres condiciones de autoría:

PreAI (Con participación humana, Pre-LLM): 93 entregas de marzo de 2021, anteriores al lanzamiento público de los principales asistentes de codificación con LLM.
PostAI (Con participación humana, Post-LLM): 57 entregas de agosto de 2024, después de que las herramientas LLM se volvieran mainstream.
PureAI (Generado por LLM): Más de 810 ejecuciones de generación utilizando tres modelos contemporáneos (gpt-5.4, gemini-2.5-pro, gemini-3.1-pro-preview) en tres variantes de prompt que variaban en la especificidad de la guía de OOD (Ninguna, Amplia, Específica). Solo se conservaron las ejecuciones que superaron las 19 pruebas funcionales (tras hasta cinco iteraciones de reparación).

Métricas de Evaluación

El estudio empleó un marco de evaluación multidimensional:

Métricas OOD: 13 métricas que capturan características estructurales, incluyendo Métodos Ponderados por Clase (WMC), Acoplamiento entre Clases de Objetos (CBO), Falta de Cohesión en Métodos (LCOM), Profundidad del Árbol de Herencia (DIT), Número de Clases (#Cl) y Líneas de Código (LOC).
Densidad de Olores de Código: Densidad a nivel de proyecto de 30 tipos de olores detectados (11 a nivel de método, 19 a nivel de clase), normalizada por tamaño (KLOC).
Modelado de Dominio:
- Representación de Conceptos: Si seis conceptos clave del dominio (Tablero, Juego, Jugador, Hoyo, Casa, Almacén) fueron modelados explícitamente como clases.
- Cumplimiento en Tiempo de Ejecución: Si el número de objetos instanciados coincidía con los requisitos implícitos de los conceptos del dominio.

Análisis Estadístico

Las comparaciones utilizaron la prueba U de Mann–Whitney con el delta de Cliff ( $\delta$ ) para el tamaño del efecto en métricas no binarias, y pruebas de Chi-cuadrado/Fisher exactas con Razones de Probabilidad (OR) para métricas binarias. Los resultados se corrigieron para comparaciones múltiples utilizando el procedimiento de Benjamini–Hochberg.

Contribuciones Clave

Primera Análisis Comparativo: Este es el primer estudio que compara la calidad del OOD en las condiciones PreAI, PostAI y PureAI en un entorno a nivel de proyecto.
Evaluación Multidimensional: El estudio combina métricas cuantitativas de OOD, análisis de olores de código y modelado de dominio basado en requisitos para proporcionar una visión holística de la calidad del diseño.
Evidencia Empírica sobre la Sobre-simplificación: El documento proporciona evidencia de que, aunque el código generado por LLM a menudo parece "más limpio" (menor densidad de olores), esto frecuentemente se asocia con sobre-simplificación (falta de abstracciones, separación de responsabilidades más débil).
Perspectivas sobre las Tendencias PostAI: El estudio demuestra que los proyectos con participación humana en la era de los LLM (PostAI) exhiben tendencias de diseño más cercanas a PureAI (simplificación) que a PreAI, pero sin la misma reducción en los olores de código.

Resultados

RQ1: Diferencias entre PreAI, PostAI y PureAI

Simplicidad Estructural vs. Sobre-simplificación: Los proyectos PureAI generalmente exhiben menos clases, menor complejidad total, tamaño y acoplamiento en comparación con los proyectos humanos. Sin embargo, esta "simplicidad" se correlaciona con la sobre-simplificación:
- Mayor complejidad/acoplamiento promedio y máximo por clase (carga concentrada en menos clases).
- Menor cohesión (LCOM más alto), ya que clases individuales a menudo representan múltiples conceptos del dominio.
- Menos conceptos del dominio representados explícitamente (falta de abstracciones).
Olores de Código: Los proyectos PureAI muestran una densidad de olores de código significativamente menor (tanto a nivel de método como de clase) en comparación con los proyectos con participación humana.
Convergencia PostAI: Los proyectos PostAI están estadísticamente más cerca de PureAI que de PreAI en muchas métricas de OOD, mostrando tendencias similares hacia la simplificación y la falta de conceptos del dominio. Sin embargo, a diferencia de PureAI, los proyectos PostAI tienen una densidad de olores de código mayor que PreAI, particularmente a nivel de método.
Cumplimiento en Tiempo de Ejecución: Una vez que un concepto del dominio está representado, los proyectos PureAI generalmente tienen más probabilidades de cumplir en tiempo de ejecución que los proyectos humanos.

RQ2: Efecto de la Especificidad del Prompt en PureAI

Impacto de la Guía: Aumentar la especificidad del prompt (de Ninguna $\to$ $\to$ Amplia $\to$ $\to$ Específica) generalmente conduce a:
- Más clases y mayor complejidad/tamaño/acoplamiento total (alejándose de la sobre-simplificación).
- Menor complejidad/acoplamiento promedio y máximo por clase.
- Reducción de la densidad general y a nivel de método de olores de código.
- Mejora en la representación de conceptos del dominio (aunque los efectos varían según el modelo).
Limitaciones: Los prompts más específicos no cierran completamente la brecha con los proyectos con participación humana. Para algunos modelos (por ejemplo, O54), aumentar la especificidad de Amplia a Específica produce una mejora adicional limitada.

Significado e Implicaciones

El documento concluye que, aunque los LLMs pueden manejar eficazmente los detalles de implementación (produciendo código con menos olores y alto cumplimiento en tiempo de ejecución), luchan con la descomposición orientada a objetos y la asignación de responsabilidades sin una guía humana explícita.

Riesgo de Sobre-simplificación: Los proyectos PureAI a menudo parecen más simples y con menos "olores", pero esto enmascara una falta de abstracción adecuada y separación de responsabilidades, lo cual puede perjudicar la mantenibilidad a largo plazo.
Advertencia PostAI: La disponibilidad de herramientas LLM puede llevar a los desarrolladores humanos a producir diseños que imitan la sobre-simplificación de los LLM (conceptos faltantes) mientras introducen nuevos problemas locales (olores a nivel de método), potencialmente anulando las ganancias de productividad.
Necesidad de Humano en el Bucle: Una guía humana apropiada sobre la descomposición de alto nivel y el modelado de dominio sigue siendo crítica. Confiar únicamente en prompts genéricos o incluso específicos de OOD es insuficiente para lograr una calidad de diseño comparable a la humana.
Estrategia de Revisión: Las revisiones de código en entornos asistidos por LLM deben verificar explícitamente la falta de conceptos del dominio y estructuras sobre-simplificadas, en lugar de solo la corrección funcional o los olores de código locales.

El estudio sugiere que el uso más efectivo de los LLMs en OOD es aprovecharlos para la implementación dentro de una estructura definida por expertos humanos que comprenden el dominio y la arquitectura deseada.