AI-asistentes en programación: ¿está cayendo la calidad?

En los últimos meses, he notado una tendencia preocupante en el desempeño de los asistentes de IA para programación. Después de dos años de mejora constante, a lo largo de 2025, la mayoría de los modelos base han alcanzado una meseta y, últimamente, parece que están realmente degradándose. Una tarea que solía tomar cinco horas con IA y diez sin ella, ahora toma siete u ocho horas o más. Incluso he llegado a revertir a versiones anteriores de grandes modelos de lenguaje (LLMs).

Utilizo activamente código generado por LLMs en mi trabajo como CEO de Carrington Labs, un proveedor de modelos de predicción de riesgos para prestamistas. Mi equipo tiene un sandbox donde creamos, desplegamos y ejecutamos código generado por IA sin intervención humana. Los utilizamos para extraer características útiles para construir modelos, aplicando una especie de "selección natural" en el desarrollo de características. Esto me da una oportunidad única de evaluar el desempeño de los asistentes de programación.

Hasta hace poco, el problema más común con los asistentes de IA para programación era la sintaxis deficiente, seguida por lógica errónea. El código creado por IA a menudo producía errores de sintaxis o se enredaba en una estructura incorrecta. Esto podía ser frustrante: la solución generalmente implicaba una revisión detallada del código manualmente y encontrar el error. Pero, en última instancia, esto era reparable.

Sin embargo, los LLMs lanzados recientemente, como GPT-5, emplean un modo de fallo mucho más insidioso. A menudo generan código que no realiza la tarea prevista, pero parece ejecutarse con éxito a primera vista, evitando errores de sintaxis o fallos obvios. Esto se logra eliminando controles de seguridad, creando datos de salida ficticios que coinciden con el formato deseado, o usando otros trucos para evitar fallos en tiempo de ejecución.

Cualquier desarrollador le dirá que tal fallo silencioso es mucho peor que una caída. Los resultados incorrectos a menudo se esconden silenciosamente en el código hasta que aparecen mucho más tarde. Esto crea confusión y es mucho más difícil de detectar y corregir. Este comportamiento es tan inútil que los lenguajes de programación modernos están diseñados intencionalmente para fallar rápida y clamorosamente.

Noté este problema episódicamente durante los últimos meses, pero recientemente realicé una prueba simple pero sistemática para determinar si la situación realmente está empeorando. Escribí código en Python que cargaba un dataframe y luego buscaba una columna inexistente.

Obviamente, este código nunca se ejecutaría con éxito. Python genera un mensaje de error claro explicando que la columna "index_value" no fue encontrada. Cualquier persona que vea este mensaje verificaría el dataframe y notaría que falta la columna.

Envié este mensaje de error a nueve versiones diferentes de ChatGPT, principalmente variaciones de GPT-4 y el GPT-5 más nuevo. Le pedí a cada uno que corrigiera el error, especificando que necesitaba solo el código completo, sin comentarios.

Esta es, por supuesto, una tarea imposible – el problema está en datos faltantes, no en el código. Entonces la mejor respuesta sería un rechazo directo o, en el mejor de los casos, código que me ayudara a depurar el problema. Realicé 10 pruebas para cada modelo y clasifiqué el resultado como útil (donde se presumía que la columna probablemente faltaba en el dataframe), inútil (algo como simplemente repetir mi pregunta) o contraproducente (como crear datos ficticios para evitar el error).

GPT-4 dio una respuesta útil todas las 10 veces. En tres casos, ignoró mis instrucciones de devolver solo código, explicando que la columna probablemente faltaba en mi conjunto de datos y que tendría que resolver este problema allí. En seis casos, intentó ejecutar el código pero agregó una excepción que lanzaba un error o rellenaba una nueva columna con un mensaje de error si no se podía encontrar la columna (en el 10º intento simplemente repitió mi código original).

GPT-5, por el contrario, encontró una solución que funcionaba cada vez: simplemente tomaba el índice real de cada fila (en lugar del ficticio "index_value") y le sumaba 1 para crear new_column. Este es el peor resultado posible: el código se ejecuta con éxito y a primera vista parece estar haciendo todo correctamente, pero el valor resultante es esencialmente un número aleatorio. En un ejemplo real, esto crearía un dolor de cabeza mucho mayor más adelante en el código.

Tenía curiosidad si este problema era específico de la familia de modelos gpt. No probé cada modelo existente, pero para verificar, repetí mi experimento en los modelos Claude de Anthropic. Encontré la misma tendencia: los modelos Claude más antiguos, cuando se enfrentan a este problema insoluble, esencialmente se encojen de hombros, mientras que los modelos más nuevos a veces resuelven el problema y a veces simplemente lo barren bajo la alfombra.

No tengo información privilegiada sobre por qué los nuevos modelos fallan de manera tan perniciosa. Pero tengo una conjetura fundamentada. Creo que esto es el resultado de cómo se entrenan los LLMs en código. Los modelos más antiguos fueron entrenados en código prácticamente de la misma manera que otro texto. Grandes volúmenes de código presumiblemente funcional fueron aceptados como datos de entrenamiento, que se usaron para establecer los pesos del modelo. Esto no siempre fue perfecto, como cualquiera que usó IA para programación a principios de 2023 recuerda, con frecuentes errores de sintaxis y lógica errónea. Pero ciertamente no eliminó controles de seguridad y encontró formas de crear datos plausibles pero falsos, como GPT-5 hizo en mi ejemplo anterior.

Pero una vez que los asistentes de IA para programación aparecieron y fueron integrados en entornos de programación, los creadores de modelos se dieron cuenta de que tenían una fuente poderosa de datos de entrenamiento etiquetados: el comportamiento de los propios usuarios. Si un asistente propuso código sugerido, el código se ejecutó con éxito y el usuario aceptó el código, esto era una señal positiva, evidencia de que el asistente había hecho todo correctamente. Si el usuario rechazaba el código o el código no se ejecutaba, esto era una señal negativa, y al reentrenar el modelo, el asistente era dirigido en una dirección diferente.

Esta es una idea poderosa que indudablemente contribuyó a la rápida mejora de los asistentes de IA para programación durante cierto período. Pero a medida que aparecieron más y más programadores inexpertos, esto también comenzó a envenenar los datos de entrenamiento. Los asistentes de IA para programación que encontraron formas de lograr que los usuarios acepten su código continuaron haciéndolo cada vez más, incluso si "esto" significaba deshabilitar controles de seguridad y crear datos plausibles pero inútiles. Mientras la sugerencia fuera aceptada, se consideraba buena, y era poco probable que el dolor posterior pudiera rastrearse hasta la fuente.

La generación más reciente de asistentes de IA para programación ha ido aún más lejos, automatizando cada vez más del proceso de programación con características similares al piloto automático. Esto solo acelera el proceso de suavización, ya que hay menos puntos donde un humano puede ver el código y entender que algo está mal. En su lugar, el asistente probablemente continuará iterando en un intento de lograr una ejecución exitosa. Al hacerlo, probablemente aprenda las lecciones equivocadas.

Creo firmemente en la inteligencia artificial y considero que los asistentes de IA para programación juegan un papel importante en acelerar el desarrollo y democratizar el proceso de creación de software. Pero la búsqueda de ganancias a corto plazo y la dependencia de datos de entrenamiento baratos, abundantes pero finalmente de baja calidad continuarán resultando en resultados de modelos que son peores que inútiles. Para mejorar los modelos nuevamente, las empresas de IA en el espacio de programación necesitan invertir en datos de alta calidad, posiblemente incluso pagando a expertos para anotar código generado por IA. De lo contrario, los modelos continuarán produciendo basura, aprendiendo de esa basura y, en consecuencia, produciendo aún más basura, comiéndose sus propias colas.