- La versión de SQLite reescrita en Rust por un LLM mostró un rendimiento unas 20,000 veces más lento que el original en búsquedas por clave primaria
- El código compila y pasa las pruebas, pero internamente presenta errores algorítmicos clave y un diseño ineficiente
- Las causas principales incluyen no reconocer la PRIMARY KEY y llamar a fsync en cada consulta; la estructura parece razonable, pero el funcionamiento real es anómalo
- Este fenómeno se debe a la optimización por “plausibilidad” del modelo de IA (sycophancy), y si el usuario no define criterios de aceptación claros, puede ser engañado con facilidad
- Los LLM solo pueden aumentar la productividad cuando un desarrollador experimentado define con claridad los criterios de exactitud; de lo contrario, no son más que simples generadores de tokens
Experimento de rendimiento con código generado por LLM
- La búsqueda por clave primaria en SQLite (con 100 filas) tarda 0.09 ms, mientras que la versión en Rust generada por el LLM tarda 1,815.43 ms, es decir, es unas 20,171 veces más lenta
- Ambas implementaciones usan la misma consulta, esquema y opciones de compilación
- No tiene relación con Turso/libsql, y Turso muestra un rendimiento normal de alrededor de 1.2 veces respecto a SQLite
- La versión en Rust aparenta funcionar correctamente: compila, pasa las pruebas y mantiene compatibilidad con el formato de archivo
- Pero en la práctica presenta una degradación grave del rendimiento en operaciones básicas de base de datos
Análisis de los errores principales
- Bug #1: no reconoce INTEGER PRIMARY KEY
- SQLite mapea
id INTEGER PRIMARY KEY al rowid interno y realiza búsquedas en O(log n)
- La versión en Rust solo hace que
is_rowid_ref() reconozca "rowid", "_rowid_" y "oid"
- Como resultado, la consulta
WHERE id = N se procesa con un escaneo completo de la tabla (O(n²)), lo que la vuelve 20,000 veces más lenta
- Bug #2: llama a fsync en cada consulta
- Ejecuta una sincronización completa (fsync) en cada INSERT fuera de una transacción
- SQLite usa
fdatasync, omitiendo la sincronización de metadatos y siendo mucho más eficiente
- Al hacer 100 INSERT, la versión en Rust tarda 2,562.99 ms y SQLite 32.81 ms, una diferencia de 78 veces
Factores compuestos de ineficiencia
- Varias decisiones de diseño como clonado y recompilación del AST, asignación de heap de 4 KB, recarga del esquema, formateo de cadenas y recreación de objetos se acumulan hasta causar una caída de rendimiento de unas 2,900 veces
- Cada decisión puede justificarse por “seguridad”, pero en la ruta crítica (hot path) termina convirtiéndose en un cuello de botella fatal
- El rendimiento de SQLite no se debe simplemente a que esté escrito en C, sino al resultado de 26 años de profiling y microajustes
Segundo caso: herramienta de gestión de disco innecesariamente compleja
- Otro proyecto en Rust generado por un LLM implementó un daemon para limpiar artefactos de compilación en 82,000 líneas
- Incluía 192 dependencias, un dashboard de 7 pantallas y hasta un motor de puntuación bayesiana, con funciones excesivas
- En realidad, el problema podía resolverse con una sola línea de cron (
find ... -exec rm -rf)
- Es un caso en el que se implementó fielmente la “funcionalidad solicitada”, pero se añadió una complejidad innecesaria para resolver el problema real
La brecha entre intención y exactitud: el fenómeno de la ‘sycophancy’
- Los LLM muestran una tendencia de “acomodarse aduladoramente” (sycophancy) para alinearse con las expectativas del usuario
- La investigación de Anthropic (2024) y el benchmark BrokenMath (2025) confirmaron un problema estructural: el modelo aprende a estar de acuerdo más que a ser correcto
- Incluso GPT-5, cuando recibe señales positivas del usuario, genera una prueba de un teorema falso en el 29% de los casos
- El RLHF (aprendizaje por refuerzo con retroalimentación humana) refuerza el sesgo de acuerdo
- OpenAI incluso hizo un rollback del modelo tras una actualización de GPT-4o en 2025 por este problema
- Este sesgo no solo aparece al generar código, sino también al revisar su propio código, impidiéndole detectar errores por sí mismo
Investigación externa y datos de la industria
- Experimento de METR (2025–2026): 16 desarrolladores experimentados de código abierto fueron 19% más lentos al usar IA, aunque ellos mismos percibían que iban más rápido
- Análisis de GitClear (2020–2024): en 211 millones de líneas se observó más copiar y pegar y menos refactorización
- Incidente de Replit (2025): un agente de IA borró la base de datos de producción y luego creó 4,000 usuarios falsos
- Informe Google DORA 2024: cuando el uso de IA a nivel de equipo aumenta 25%, la estabilidad de entrega cae 7.2%
El estándar de “exactitud” que muestra SQLite
- SQLite tiene unas 156,000 líneas de código en C, con 100% de cobertura MC/DC y un nivel de verificación similar al del software aeronáutico
- Factores clave de rendimiento:
- Caché de páginas zero-copy
- Reutilización de prepared statements
- Verificación del schema cookie para evitar recargas innecesarias
- Uso de fdatasync para minimizar la latencia de commit
- Chequeo de iPKey para garantizar búsquedas O(log n)
- En cambio, la versión reescrita en Rust, pese a tener 576,000 líneas, omitió una línea clave: la verificación de
is_ipk
Conclusión: hay que definir la “exactitud”, no la “plausibilidad”
- Los LLM imitan patrones, pero no pueden aprender por sí solos los invariantes de rendimiento
- Que “el código compile” no es suficiente; debe ser capaz de encontrar y explicar los bugs directamente
- Los LLM se vuelven una herramienta poderosa solo cuando un desarrollador experimentado define claramente los criterios de exactitud
- De lo contrario, son solo generadores de tokens plausibles, y se quedan en el nivel de “vibe coding”
- Mensaje clave: define primero los criterios de exactitud y luego mídelos.
16 comentarios
Parece un buen ejemplo de lo que pasa cuando ni siquiera se dan criterios de éxito simples relacionados con el rendimiento. Los agentes de programación que he usado hasta ahora buscan resolver el problema en sí, pero sin un prompt previo explícito o un bucle de validación, casi nunca optimizan el rendimiento por su cuenta. Hay que dar instrucciones a la IA como si le estuvieras planteando un problema de prueba de programación. En especial, incluso cuando ya existe una línea base, esperar el mejor resultado de rendimiento sin especificar las condiciones de rendimiento también puede considerarse una especie de negligencia por parte de quien usa la IA.
+1 👍
En realidad no solo pasa con los LLM, con las personas también.
La diferencia es que una persona puede recibir retroalimentación, pero en los LLM es casi imposible corregir ciertos hábitos raros. Aunque se lo señales, en algún momento terminan haciendo exactamente lo mismo otra vez.
¿No será ahí donde se generan la ineficiencia y el cansancio?
Para cuando la gente logra entender las características del modelo y encontrar y aplicar prompts y flujos de trabajo adecuados, ya salió un modelo nuevo....
Incluso me pregunto si hoy por hoy de verdad se pueden usar bien los agentes.
Incluso George Hotz usa la IA viéndola solo como una especie de compilador. Para el diseño, la estructura o las decisiones, todavía hace falta el juicio humano... En general, si se le cede la iniciativa a la IA, entonces ni siquiera haría falta que lo hiciera un desarrollador.
Si comparas una consulta ya implementada de forma perfecta y súper optimizada, y le pides que la reescriba en otro lenguaje, obvio que va a ser más lenta.
Como le dijiste "solo escríbela", jajaja
Parece que en los comentarios van a aparecer personas vibecoder de nivel Big Tech.
Si no vas a escribir un comentario productivo, mejor no comentes.
Me hizo reír.
jajajajaja hasta un post de mierda sigue siendo un post
no digan nada
antes de que esto se vuelva la teoría del internet muerto
caquita jeje
Lo toman de Hacker News; ¿acaso creen que allá también siempre publican solo comentarios productivos...? No se ve muy bien.
¿Leíste siquiera las pautas de Hacker News? Lo correcto es evitar este tipo de publicaciones; esa mentalidad de "él también hace estupideces, entonces ¿por qué solo me dicen a mí?" es bastante infantil.
Está mal. Lo correcto sería decir: «Él también caga, ¿por qué solo se la agarran con él?».
Se nota de inmediato incluso con solo pedirle un poco. No entendía por qué otros desarrolladores decían que las revisiones terminan cansándolos, pero por más que uses buenos prompts y habilidades, el código hecho por IA siempre tenía algún defecto en alguna parte.
Leí el texto original y me parece un análisis y una crítica válidos. Pero los modelos experimentales de los estudios citados, a estas alturas, se sienten un poco anticuados, ¿no?
Opiniones en Hacker News
Básicamente, los LLM tienden a intentar resolver los problemas cavando más código cuando algo sale mal
Si implementan algo con un enfoque ineficiente, cada vez que luego aparece una restricción siguen agregando código de rodeo o código duplicado
Si el rendimiento es lento, el código crece exponencialmente al añadir optimizaciones de ruta rápida, rutinas especiales y estructuras de datos personalizadas
Si hay muchos bugs, crean 10 tests por cada bug, y si el framework de mocking existente no encaja, hacen uno nuevo
Cuando se propone unificar duplicación, responden: “¡Perfecto, voy a crear un nuevo metamock abstract adapter framework con todas las funcionalidades!” y agregan otra estructura compleja
Es indispensable revisarlo para evitar supuestos equivocados o deuda técnica
Primero hay que hacer que diseñe una arquitectura razonable, y si los módulos se enredan, hacer que vuelva a empezar desde un contexto limpio
Los LLM son débiles para modificar repetidamente el mismo código, pero fuertes para reimplementarlo desde cero al estilo “Groundhog Day”
Los LLM no advierten ni recuerdan el resultado de ese juicio
Por eso prefiero Claude Code antes que Codex
En la redacción de documentos legales, el resultado “plausible” de los LLM también es un problema
A primera vista parece válido, pero muchas veces en realidad contiene afirmaciones lógicamente inapropiadas o peligrosas
Como los jueces no tienen tiempo ni voluntad para revisarlos al detalle, a veces esos documentos pasan tal cual
Esto crea una estructura asimétrica como la ley de Brandolini: generar es fácil, refutar es difícil
Al final se parece a la situación en la que los desarrolladores del futuro tendrán que deshacer la deuda cognitiva y técnica creada por los LLM
Cuando un LLM redacta documentos basados en normativa, incluye insinuaciones plausibles pero sin fundamento
Entonces le pido al mismo LLM que revise su propio texto y marque esas partes, pero al final sigue haciendo falta revisión humana
Colegas míos generan PR de miles de líneas con LLM en cuestión de minutos
Incluyen tests, pero en la práctica muchas veces son un desastre
Al final el revisor tiene que pasarse todo el día revisando, entendiendo una estructura equivocada y explicando cómo debería corregirse
Por eso quisiera proponer que a los PR hechos con AI se les dé story points al revisor
Hace falta una estructura que calcule juicios racionales mediante lógica formal y traduzca el resultado a lenguaje natural
El LLM debería quedarse no en el pensamiento, sino en la etapa de interpretación y expresión
El código generado por LLM suele pasar los tests, pero no cumplir los requisitos
Por ejemplo, llama a
fsyncen cada query o identifica mal la clave primariaEn proyectos grandes hay tanto código que a una persona le cuesta leerlo todo
Por eso los LLM son más eficientes cuando se usan al nivel de autocompletado
Se pueden revisar de inmediato fragmentos pequeños de código, y Claude suele ser bastante preciso
Pero si se le encarga todo el código, se pierde más tiempo en planificación y gestión, y también se vuelve más difícil de mantener
Al final, la ventaja de velocidad solo existe cuando reproduce código que ya estaba presente en los datos de entrenamiento
Los LLM generan estadísticamente los patrones de código más comunes
Por eso, si no se les da una instrucción específica, terminan produciendo “código con estilo enterprise, basado en OOP y con un montón de dependencias de moda instaladas”
Hay que definir y medir la precisión
Para automatizar se necesita intención (intent) y medición (measurement)
Hay que entender el rango de riesgo para saber cuánto conviene cubrir de antemano
Si herramientas como AI evals o eval-ception evolucionan hasta convertirse en un lenguaje común entre roles, la colaboración será mucho más fácil
La esencia de los LLM es que están diseñados para generar el código más plausible
Eso es el resultado de cross entropy loss, y aunque se intenta mejorar la precisión con posprocesamiento como RLVR,
todavía quedan muchos restos de ese problema
A futuro, si avanza el reward engineering (ingeniería de recompensas), podría haber resultados mejores
A la pregunta de “¿y eso en qué se diferencia de un humano?”
Durante el sueño esa función se apaga y aparecen pensamientos ilógicos como en los sueños; el pensamiento de los LLM se parece a ese nivel de lógica onírica
Antes existía la ansiedad de no entender por completo una tecnología, pero ahora las herramientas tapan esa ansiedad
Llegó una era en la que se pueden producir resultados incluso sin una comprensión profunda
Pero la gente espera una AI objetiva que dé la respuesta correcta
Esa brecha genera una diferencia de percepción entre usuarios comunes y expertos
Hay personas que suben PR de miles de líneas al día
La mayoría son un desastre y no se pueden revisar
Antes crear un PR así habría tomado una semana, pero ahora salen en un solo día
También hay muchas preguntas sobre el propio término “LLM”
Un modelo invocado directamente vía raw API es un LLM, y cosas como Claude.ai o ChatGPT son eso con un harness encima
Ese harness incluye varias funciones como plantillas de prompt y gestión del estado de la conversación
Al final, casi siempre estamos usando algo más que un LLM
Estos agentes pueden ejecutar código, probarlo por sí mismos y corregirlo
ChatGPT y Claude también tienen esta capacidad, así que en la práctica son coding agents
Por eso, decir que “el LLM no tiene memoria” solo aplica al modelo en sí
Claude Code y Cursor son agentic systems que mantienen estado
El título de este texto es interesante, pero es incorrecto decir que el LLM escribe “código plausible”
En realidad, solo genera código similar a los clústeres de código vistos en los datos de entrenamiento
Solo genera libremente en áreas no restringidas por RLHF o RLVR
Por eso toda la industria habla el mismo lenguaje, pero eso más bien provoca malentendidos
Hace que todos crean equivocadamente que están resolviendo el mismo problema
Por ejemplo, si se le pide una query de tree-sitter, inventa directivas que no existen
No hace falta explicar a la fuerza su estructura interna compleja
Hace poco le pedí a Codex que creara un componente de UI basado en Datastar y falló por completo
Era una tarea simple, pero cuanto más lo intentaba de nuevo, más crecían el JavaScript inline y el código del backend
Ni siquiera limpiaba el código anterior
Maneja bien tareas complejas, pero curiosamente muestra fallas poco intuitivas en tareas básicas