Asistentes de programación con IA: ¿está cayendo la calidad?

En los últimos meses he notado una tendencia preocupante en el rendimiento de los asistentes de programación con IA. Tras dos años de mejora constante, durante 2025 la mayoría de los modelos base se estancaron y, últimamente, parece que incluso se degradan. Una tarea que con ayuda de la IA llevaba cinco horas, y diez sin ella, ahora requiere siete u ocho, o más. Hasta el punto de que a veces vuelvo a versiones antiguas de los grandes modelos de lenguaje (LLM).

Uso mucho código generado por LLM en mi trabajo como director general de Carrington Labs, proveedor de modelos de predicción de riesgos para entidades de crédito. Mi equipo tiene un entorno aislado (sandbox) donde creamos, desplegamos y ejecutamos código generado por IA sin intervención humana. Lo usamos para extraer características útiles con las que construir modelos, aplicando una especie de «selección natural» a la ingeniería de características. Eso me da una posición privilegiada para evaluar el rendimiento de los asistentes de programación.

Hasta hace poco, el problema más habitual de los asistentes de programación con IA era la sintaxis defectuosa, seguida de la lógica errónea. El código creado por la IA solía lanzar errores de sintaxis o enredarse en una estructura incorrecta. Podía resultar frustrante: la solución solía consistir en revisar el código a mano con detalle y buscar el error. Pero, al final, tenía arreglo.

Sin embargo, los LLM lanzados recientemente, como GPT-5, fallan de una forma mucho más insidiosa. A menudo generan código que no hace lo que debería, pero que a primera vista se ejecuta con éxito, sin errores de sintaxis ni fallos evidentes. Lo logran eliminando comprobaciones de seguridad, creando datos de salida falsos que respetan el formato deseado o recurriendo a otros trucos que evitan fallos en tiempo de ejecución.

Cualquier desarrollador te dirá que un fallo silencioso así es mucho peor que un fallo con error. Los resultados erróneos suelen quedar ocultos en el código hasta que aparecen mucho más tarde. Eso genera confusión y hace que el problema sea mucho más difícil de detectar y corregir. Este comportamiento es tan poco útil que los lenguajes de programación modernos se diseñan a propósito para fallar rápido y de forma ruidosa.

Había observado este problema de forma esporádica durante los últimos meses, pero hace poco hice una prueba sencilla y sistemática para determinar si la situación realmente empeora. Escribí código en Python que cargaba un dataframe y después buscaba una columna inexistente.

Es evidente que este código nunca se ejecutará con éxito. Python genera un mensaje de error claro que explica que no se encontró la columna «index_value». Cualquiera que vea ese mensaje revisará el dataframe y notará que falta la columna.

Envié ese mensaje de error a nueve versiones distintas de ChatGPT, sobre todo variantes de GPT-4 y de la más reciente GPT-5. Pedí a cada una que corrigiera el error, especificando que solo quería el código completo, sin comentarios.

Es, por supuesto, una tarea imposible: el problema son los datos que faltan, no el código. Por eso, la mejor respuesta sería una negativa directa o, como mucho, código que me ayudara a depurar el problema. Realicé 10 pruebas con cada modelo y clasifiqué el resultado como útil (cuando planteaba que la columna probablemente no estaba en el dataframe), inútil (algo como repetir simplemente mi pregunta) o contraproducente (por ejemplo, crear datos falsos para evitar el error).

GPT-4 dio una respuesta útil las 10 veces de 10. En tres casos ignoró mi instrucción de devolver solo código, explicó que la columna probablemente faltaba en mi conjunto de datos y que tendría que resolver ese problema allí. En seis casos intentó ejecutar el código, pero añadió una excepción que o bien lanzaba un error o bien rellenaba una columna nueva con un mensaje de error si no se encontraba la columna (la décima vez simplemente repitió mi código original).

GPT-5, en cambio, encontró una solución que funcionaba siempre: tomaba el índice real de cada fila (y no el ficticio «index_value») y le sumaba 1 para crear new_column. Es el peor resultado posible: el código se ejecuta con éxito y a primera vista parece hacerlo todo bien, pero el valor resultante es en esencia un número aleatorio. En un caso real, esto provocaría un dolor de cabeza mucho mayor más adelante en el código.

Me pregunté si este problema era específico de la familia de modelos GPT. No he probado todos los modelos existentes, pero, para comprobarlo, repetí el experimento con los modelos Claude de Anthropic. Encontré la misma tendencia: los modelos Claude antiguos, ante este problema irresoluble, básicamente se encogen de hombros, mientras que los nuevos a veces lo resuelven y a veces lo barren debajo de la alfombra.

No tengo información privilegiada sobre por qué los modelos nuevos fallan de forma tan perniciosa. Pero tengo una hipótesis fundada. Creo que es el resultado de cómo se entrena a los LLM para programar. Los modelos antiguos se entrenaban con código más o menos igual que con cualquier otro texto. Se incorporaron grandes volúmenes de código presuntamente funcional como datos de entrenamiento para fijar los pesos del modelo. No siempre era perfecto, como recuerda cualquiera que usara IA para programar a principios de 2023, con frecuentes errores de sintaxis y lógica defectuosa. Pero desde luego no eliminaba comprobaciones de seguridad ni encontraba la manera de crear datos verosímiles pero falsos, como hizo GPT-5 en mi ejemplo anterior.

Pero cuando los asistentes de programación con IA aparecieron y se integraron en los entornos de desarrollo, los creadores de modelos se dieron cuenta de que tenían una poderosa fuente de datos de entrenamiento etiquetados: el comportamiento de los propios usuarios. Si el asistente proponía un código, el código se ejecutaba con éxito y el usuario lo aceptaba, era una señal positiva, una muestra de que el asistente lo había hecho todo bien. Si el usuario rechazaba el código o este no se ejecutaba, era una señal negativa, y al reentrenar el modelo se orientaba al asistente en otra dirección.

Es una idea potente que, sin duda, contribuyó a la rápida mejora de los asistentes de programación con IA durante un tiempo. Pero a medida que llegaban más programadores sin experiencia, también empezó a envenenar los datos de entrenamiento. Los asistentes que encontraban formas de lograr que los usuarios aceptaran su código siguieron haciéndolo cada vez más, aunque eso significara desactivar comprobaciones de seguridad y crear datos verosímiles pero inútiles. Mientras la propuesta se aceptara, se consideraba buena, y es poco probable que el dolor posterior pudiera rastrearse hasta su origen.

La generación más reciente de asistentes de programación con IA ha ido más lejos, automatizando cada vez más el proceso de programación con funciones parecidas a un piloto automático. Eso solo acelera el proceso de aplanamiento, porque quedan menos puntos en los que una persona puede ver el código y darse cuenta de que algo va mal. En su lugar, el asistente probablemente seguirá iterando para intentar lograr una ejecución exitosa. Al hacerlo, es probable que aprenda las lecciones equivocadas.

Creo firmemente en la inteligencia artificial y considero que los asistentes de programación con IA desempeñan un papel importante a la hora de acelerar el desarrollo y democratizar la creación de software. Pero perseguir beneficios a corto plazo y apoyarse en datos de entrenamiento baratos, abundantes pero en última instancia de baja calidad seguirá dando resultados de modelo peores que inútiles. Para volver a mejorar los modelos, las empresas de IA para programación deben invertir en datos de alta calidad, quizá incluso pagar a expertos por etiquetar el código generado por IA. De lo contrario, los modelos seguirán produciendo basura, entrenándose con esa basura y, por tanto, produciendo aún más basura, como una serpiente que se muerde la cola.