💬 NLP

Simulating Students' Java Programming Errors with Large Language Models

Este artículo demuestra que los modelos de lenguaje extensos, particularmente Claude Sonnet 4, pueden simular eficazmente errores de programación en Java diversos y realistas de estudiantes, ofreciendo una alternativa escalable a la recopilación de entregas auténticas para la investigación educativa y los sistemas de tutoría inteligente.

Autores originales: Ali Keramati, Jie Cao, Iman Mohammadi, Mark Warschauer, Yang Shi

Publicado 2026-06-15

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Ali Keramati, Jie Cao, Iman Mohammadi, Mark Warschauer, Yang Shi

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 profesor intentando prepararte para una clase importante de programación. Sabes que tus alumnos cometerán errores, pero no puedes predecir exactamente cuáles serán esos errores hasta que realmente impartas la clase y recojas sus tareas. Este es un proceso lento y costoso.

Este artículo plantea una pregunta sencilla: ¿Podemos usar una IA superinteligente (un Modelo de Lenguaje Grande, o LLM) para que finja ser un estudiante confundido y genere esos errores por nosotros de antemano?

Aquí está el desglose de su experimento, explicado con analogías de la vida cotidiana.

El Objetivo: La prueba del "Estudiante Falso"

Los investigadores querían ver si una IA podía escribir código Java que pareciera escrito exactamente por un estudiante principiante, específicamente, código que tuviera errores lógicos.

Errores lógicos: Son como escribir una receta que dice "añadir sal al gusto" pero olvidar añadir la sal realmente. La computadora ejecuta el código, pero el resultado es incorrecto porque el razonamiento fue erróneo.
El Desafío: Si solo le pides a una IA que "escriba código", normalmente escribe código perfecto. Si le pides que "rompa el código", a menudo comete errores aleatorios y tontos (como poner una coma donde debería ir un punto) que los estudiantes reales no cometen realmente. El objetivo era hacer que la IA cometiera errores realistas.

El Experimento: La "Prueba del Gusto"

Los investigadores tomaron 37 problemas de programación diferentes de una clase real (CodeWorkout). Hicieron que cinco modelos de IA diferentes intentaran resolver estos problemas, pero utilizaron tres "estilos de instrucción" (prompts) diferentes para intentar forzar a la IA a cometer errores:

Orden Directa (IO): "Aquí está el problema, dame una respuesta incorrecta".
Pensar en Voz Alta (CoT): "Piensa en los pasos, decide dónde podrías fallar y luego escribe el código incorrecto".
Bucle de Autocorrección (Self-Refine): "Escribe una respuesta incorrecta, luego critícala, luego arréglala ligeramente para que sea un otro tipo de respuesta incorrecta".

Luego compararon los "errores falsos" de la IA contra 74,000 errores reales cometidos por estudiantes reales.

Las Dos Reglas Principales para un Falso Bueno

Para ser útil, los errores falsos de la IA tenían que pasar dos pruebas:

Diversidad (La Prueba de la Variedad): ¿Cometió la IA muchos tipos diferentes de errores, o simplemente repitió el mismo error una y otra vez? (Imagina a un chef intentando hacer 10 tipos diferentes de galletas quemadas. Si todas se ven exactamente iguales, eso no es muy diverso).
Alineación (La Prueba de la "Realidad"): ¿Se parecían los errores de la IA a algo que un humano realmente haría? (Si la IA escribe código que es incorrecto de una forma en la que un humano nunca pensaría, no es un buen simulador).

Lo Que Encontraron

1. La IA puede cometer errores, pero no todas las IA son iguales
Todos los modelos de IA pudieron generar una variedad de errores. Sin embargo, algunos fueron mejores que otros.

Gemini 2.5 Pro era como un artista caótico: hacía una enorme variedad de errores (alta diversidad), pero muchos de ellos eran extraños y no se parecían a los errores de estudiantes reales.
GPT-4o era como un estudiante cauteloso: cometía errores muy similares una y otra vez (baja diversidad).
Claude Sonnet 4 fue el "Punto Medio" (Goldilocks) del grupo. Encontró el mejor equilibrio. Hacía suficientes tipos diferentes de errores, pero también eran muy cercanos a lo que los estudiantes reales realmente escriben.

2. El truco de "Pensar en Voz Alta" ayudó
Cuando los investigadores le dijeron a la IA que "pensara paso a paso" antes de escribir el código (Cadena de Pensamiento o Chain-of-Thought), los errores se volvieron más realistas. Era como si la IA estuviera simulando el proceso de un estudiante confundiéndose, en lugar de simplemente romper el código de forma aleatoria.

3. El factor de "Dificultad"
Los investigadores observaron qué tan "difícil" era un problema (basándose en cuántas veces los estudiantes intentaron resolverlo).

Problemas Fáciles: La IA hizo un gran trabajo imitando a los estudiantes.
Problemas Difíciles: A medida que los problemas se volvían más difíciles, los errores de la IA se volvieron más diversos (intentaba muchos caminos erróneos diferentes), pero se volvieron menos parecidos a los de los estudiantes reales. Es como un actor novato tratando de interpretar una escena compleja; pueden intentar muchas interpretaciones diferentes, pero ninguna captura realmente el matiz de una actuación humana real.

4. La "Prueba de Degustación a Ciegas" (Expertos Humanos)
Los investigadores contrataron a expertos humanos para que examinaran una mezcla de código de estudiantes reales y código generado por IA. Los expertos no sabían cuál era cuál.

El Resultado: Los expertos fueron engañados el 83.7% de las veces. Pensaron que el código de la IA había sido escrito por un humano.
El Giro: Los expertos calificaron de hecho los errores de la IA como más plausibles (más realistas) que los errores de los estudiantes reales. ¿Por qué? Porque la IA cometía errores "limpios" (como un error clásico de libro de texto), mientras que los estudiantes reales suelen cometer errores desordenados y complicados con múltiples errores a la vez. La IA era como un estudiante confundido "idealizado", mientras que los estudiantes reales son más desordenados.

La Conclusión Final

Este artículo demuestra que la IA puede actuar como un "sustituto" de los estudiantes para generar errores de programación realistas.

Claude Sonnet 4 es actualmente el mejor "simulador de estudiante".
Los problemas más difíciles hacen que la IA sea más creativa pero menos precisa respecto al comportamiento humano real.
El Intercambio (Trade-off): Puedes tener una IA que cometa una gran variedad de errores, o una que cometa errores muy realistas, pero es difícil lograr ambas cosas perfectamente al mismo tiempo.

Los investigadores sugieren que esto es una herramienta poderosa para profesores y desarrolladores de software educativo. En lugar de esperar años para recolectar miles de errores de estudiantes reales para entrenar sus sistemas, pueden usar estos errores "falsos" para construir mejores herramientas de tutoría y ayudar a los profesores a anticipar dónde podrían estancarse los estudiantes.

Resumen Técnico: Simulación de Errores de Programación en Java de Estudiantes con Modelos de Lenguaje de Gran Escala

Planteamiento del Problema

Comprender los errores de los estudiantes es fundamental para la educación en programación, particularmente para identificar errores lógicos que revelan concepciones erróneas subyacentes y estrategias de razonamiento defectuosas. Sin embargo, obtener un conjunto representativo de errores auténticos de estudiantes para tareas recién diseñadas es lento y costoso, ya que requiere un despliegue extensivo en el aula y la acumulación de datos. Si bien los Modelos de Lenguaje de Gran Escala (LLM) ofrecen una vía escalable para simular comportamientos de aprendizaje, los enfoques actuales enfrentan una brecha crítica: el prompting general tiende a producir soluciones correctas, mientras que las estrategias de corrupción aleatoria producen errores artificiales carentes de valor pedagógico. El desafío central es la indistinguibilidad: generar errores que sean erróneos de las formas específicas en que un estudiante novato lo sería (reflejando una comprensión parcial y concepciones erróneas específicas) en lugar de ruido superficial. Además, la infraestructura de evaluación existente suele priorizar la corrección absoluta sobre la diversidad y la alineación de los patrones de error.

Metodología

El estudio aprovecha el conjunto de datos CodeWorkout, que comprende más de 74,000 entregas únicas de código Java de estudiantes a través de 37 problemas de programación introductoria recolectados de estudiantes de pregrado en Virginia Tech.

Diseño Experimental

Preparación de Datos: Los autores filtraron los registros originales para retener únicamente el código compilable pero incorrecto (errores lógicos), eliminando errores de sintaxis y entregas totalmente correctas. Los problemas se categorizaron en tres niveles de dificultad (struggling levels) (Bajo, Medio, Alto) basados en el volumen total de entregas de estudiantes por problema, sirviendo como un proxy de la dificultad de aprendizaje empírica.
Simulación de LLM: Se evaluaron cinco LLM: Google Gemini 2.5 Pro, OpenAI GPT-5, OpenAI GPT-4o, Anthropic Claude Sonnet 4, y xAI Grok Code Fast 1.
Estrategias de Prompting: Se probaron tres estrategias distintas para cada combinación de modelo/problema:
- Entrada-Salida (IO): Instrucción directa sin razonamiento intermedio.
- Cadena de Pensamiento (CoT): El modelo articula una justificación para un desliz lógico antes de generar el código.
- Autorrefinamiento Iterativo (Iterative Self-Refine): Un bucle iterativo donde un crítico proporciona retroalimentación y un refinador reescribe el código (hasta cuatro iteraciones).
Métricas de Evaluación:
- Diversidad (RQ1): Medida mediante la media de la distancia de edición de árbol Zhang–Shasha (ZSS) entre los códigos erróneos generados. Distancias mayores indican mayor variación estructural.
- Alineación (RQ2): Medida por la distancia de edición del vecino más cercano entre el código generado por el LLM y la entrega humana auténtica más cercana. Distancias menores indican una mayor fidelidad a los errores reales de los estudiantes.
- Validación Cualitativa: Un estudio de anotación experta a ciegas ( $N=401$ ) comparó errores sintéticos (Claude Sonnet 4 con Self-Refine) y errores auténticos. Los expertos calificaron la plausibilidad (escala Likert de 1 a 5), realizaron la atribución de fuente (prueba de Turing) y categorizaron los errores en ocho taxonomías de errores lógicos.

Resultados Clave

1. Diversidad (RQ1)

Todos los modelos demostraron la capacidad de generar código erróneo diverso, pero el rendimiento varió significativamente según el modelo y la estrategia.

Gemini 2.5 Pro y Claude Sonnet 4 exhibieron la mayor diversidad, con distancias de edición medias que a menudo superaban los 60, particularmente cuando se utilizaba el prompting CoT.
GPT-4o produjo los patrones de error más homogéneos (menos diversos) (distancias ~25–40).
Impacto del Prompting: Las estrategias modularon la diversidad de manera diferente; por ejemplo, Self-Refine redujo la diversidad en Claude Sonnet 4 pero la aumentó en otros contextos.

2. Alineación (RQ2)

La capacidad de imitar los errores auténticos de los estudiantes varió según el modelo, con un claro compromiso frente a la diversidad.

Claude Sonnet 4 logró el desempeño más equilibrado, manteniendo distancias de edición relativamente bajas (mejor caso: 16.35 con Self-Refine) en todas las estrategias, lo que indica una fuerte alineación con los errores humanos.
Grok Code Fast 1 logró la distancia mínima absoluta (16.22) con Self-Refine, pero mostró una alta varianza en otros prompts.
GPT-5 y Gemini 2.5 Pro mostraron una alineación deficiente, con distancias que a menudo superaban los 80, lo que sugiere que sus errores divergen significativamente de los patrones auténticos de los estudiantes.
Evaluación Humana: Los anotadores clasificaron erróneamente el 83.7% de las entregas generadas por LLM como escritas por humanos. Sorprendentemente, los errores generados por LLM recibieron una puntuación de plausibilidad significativamente mayor (4.27) que los errores auténticos (3.78). Esto se atribuye a que los LLM generan errores lógicos "limpios" y de propósito único (por ejemplo, Lógica de Condición, errores de Límite) que se asemejan a las concepciones erróneas de los libros de texto, mientras que el código auténtico de los estudiantes a menudo contenía errores difusos, de múltiples fallos o de nivel de estrategia que eran más difíciles de categorizar claramente.

3. El Nivel de Dificultad como Moderador (RQ3)

La dificultad de la tarea de programación (nivel de dificultad/struggling level) influyó tanto en la diversidad como en la alineación.

Diversidad: Los niveles de dificultad más altos provocaron salidas de error más diversas (heterogéneas) de los LLM, ya que los problemas más difíciles abren más rutas de falla.
Alineación: Por el contrario, a medida que el nivel de dificultad aumentaba, la alineación entre los errores generados por LLM y los auténticos disminuía (las distancias de edición aumentaban). Los modelos encontraron más difícil reproducir errores lógicos similares a los de los estudiantes en problemas de alta dificultad, divergiendo más del comportamiento auténtico.

Significado y Contribuciones

El artículo sostiene que los LLM pueden servir como proxies escalables para los estudiantes en la generación de errores lógicos, pero con compromisos específicos que deben gestionarse según el objetivo de la aplicación:

Simulación Equilibrada: Se identifica a Claude Sonnet 4 como el modelo más equilibrado, ofreciendo un compromiso entre la generación de patrones de error diversos y el mantenimiento de una alta fidelidad a los errores auténticos de los estudiantes.
Utilidad Pedagógica: El estudio valida que los errores sintéticos pueden ser funcionalmente indistinguibles de los auténticos para los expertos. Esto respalda la integración de datos sintéticos en:
- Sistemas de Tutoría Inteligente (ITS): Para entrenar sistemas en el diagnóstico de diversas concepciones erróneas sin depender únicamente de los escasos datos humanos.
- Agentes Enseñables (Teachable Agents): Para permitir que los estudiantes practiquen la depuración corrigiendo errores generados por IA, fomentando el aprendizaje vicario.
- Desarrollo Profesional Docente: Para exponer a los educadores a una variedad concentrada de concepciones erróneas anticipadas para una mejor planificación instructiva.
Consideraciones de Diseño: Los hallazgos resaltan un compromiso entre diversidad y fidelidad (diversity–fidelity trade-off). Los modelos fuertes en diversidad (por ejemplo, Gemini) pueden carecer de alineación, mientras que aquellos con alta alineación pueden ser menos diversos. Además, el "nivel de dificultad" de una tarea actúa como un doble moderador: aumenta la amplitud de los errores simulados pero reduce su representatividad del comportamiento estudiantil real.

Los autores conclen que, si bien los LLM ofrecen una vía prometedora para aumentar los datos de los estudiantes en la tecnología educativa, su uso requiere la selección cuidadosa de modelos y estrategias de prompting adaptadas a si el objetivo es la cobertura amplia de concepciones erróneas o la aproximación precisa de las distribuciones de error observadas en el aula.