Cuando la IA te 'arregla' un bug hardcodeando el print

TL;DR

• Bug: tenía 930 vídeos, el PCA procesaba 928
• “Solución” de Claude: hardcodear 930 en el print en vez de investigar
• El bug seguía ahí, pero el log decía que todo estaba bien
• Moraleja: la IA no distingue entre “arreglar” y “ocultar”. Revisa siempre el diff.

---

Estaba haciendo mi TFM. Un modelo predictivo para estimar las visualizaciones de vídeos de YouTube basándome en los metadatos: título, descripción, etiquetas y miniatura.

El pipeline era complejo: embeddings de texto, embeddings de imagen con ResNet, reducción de dimensionalidad con PCA… Lo típico cuando quieres meter demasiadas cosas en un proyecto académico.

El bug

En algún momento, me di cuenta de que algo no cuadraba. Tenía 930 vídeos en mi dataset, pero el PCA estaba procesando solo 928 embeddings.

[INFO] Aplicando PCA individual a Titulo Embedding...
[INFO] Titulo Embedding: usando 50 componentes para 928 embeddings

Le dije a Claude (Sonnet 3.5 en ese momento, vía Cursor):

“Mira, tengo 930 vídeos pero solo salen 928 en el PCA.”

La “solución”

Claude me respondió con toda la confianza del mundo: “No te preocupes, te lo soluciono.”

Y procedió a cambiar esto:

print(f"[INFO] {field}: usando {field_n_components} componentes para {len(valid_embeddings)} embeddings")

Por esto:

print(f"[INFO] {field}: usando {field_n_components} componentes para 930 embeddings")

Hardcodeó el número. No buscó por qué faltaban 2 embeddings. No investigó si había vídeos sin título o con datos corruptos. Simplemente cambió el print para que mostrara el número “correcto”.

El bug seguía ahí. Los 2 embeddings seguían desaparecidos. Pero ahora el log decía 930 y todo parecía bien.

La moraleja

Esto es el equivalente a tapar el testigo del motor con cinta aislante. “El coche ya no avisa de que tiene un problema, así que ya no tiene un problema.”

La IA no entiende el contexto de lo que hace. Ve un número que no coincide con otro número y busca la forma más directa de que coincidan. Si eso implica mentir en un print, lo hace sin pestañear.

Por eso, todo lo que genera una IA hay que revisarlo. No porque sea mala herramienta, sino porque no tiene criterio. No sabe distinguir entre “arreglar el problema” y “ocultar el problema”. Este es un ejemplo de lo que llamo “error conceptual” en mi taxonomía de fallos de LLMs: el modelo no sabe que no sabe.

Cómo evitarlo

1. No asumas que ha hecho lo que crees que ha hecho. Lee el diff antes de aceptar cualquier cambio.

2. Si el fix es demasiado corto, sospecha. Un bug de datos rara vez se arregla cambiando una línea de print.

3. Pregunta “¿por qué?” antes de “¿cómo?”. Si le hubieras pedido que investigara por qué faltaban los embeddings en vez de pedirle que lo solucionara, probablemente habría encontrado el problema real. Esto conecta con cómo formular prompts para problemas ambiguos.

4. Prueba en local. Siempre. Antes de subir nada a producción o de dar por bueno un cambio.

Al final encontré el bug real: había dos vídeos sin descripción que causaban que el embedding fallara silenciosamente. Pero eso lo encontré yo, revisando los datos manualmente, después de desconfiar del “arreglo” de Claude.

La IA es un becario muy rápido. Pero sigue siendo un becario. Y algunos becarios te hardcodean los prints. Es por esto que no hay que ser fanboy de ningún modelo: cuando uno te falla así, cambias a otro.