El 22 de junio de 2026, la portada de Hacker News mostraba simultáneamente tres hilos, de tres usuarios distintos, apuntando a tres productos diferentes, pero encajando como tres piezas de un mismo rompecabezas.
La primera pieza: el registro SQLite de Codex escribía datos al SSD local a una tasa de 640 TB al año, mientras que los datos efectivos retenidos eran solo 0.5 millones de filas — el contador AUTOINCREMENT ya había superado los 5.5 mil millones. Una amplificación de escritura de 10 000×. Un SSD de consumo de 1 TB tiene una vida útil nominal de 600 TBW; Codex lo desgastaría en diez meses. El PR de corrección se fusionó ese mismo día, afirmando una reducción del 85% en el volumen de registros. La segunda pieza: Patrick McCanna descubrió que la salida «Extended Thinking» de Claude Code es un resumen generado a posteriori, no el proceso de razonamiento real del modelo. El razonamiento real está encriptado en un bloque de firma de 600 caracteres, cuya clave está en manos de Anthropic, inaccesible para el usuario local. Patrick comparó esta transformación con «guardar un JPEG como BMP y luego editar el BMP afirmando que es un JPEG — la pérdida de datos ocurre en la conversión». La tercera pieza: Tech Stackups publicó una comparativa entre GLM-5.2 y Claude Opus 4.8, usando el mismo prompt one-shot para construir desde cero un juego de plataformas 3D en WebGL. GLM-5.2 tardó 1 hora 10 minutos y costó 5.39 USD; Opus 4.8 tardó 33 minutos y costó aproximadamente 21.92 USD. La conclusión fue «no migraremos nuestro主力 de Opus», pero GLM-5.2, con pesos open source bajo MIT, ganó «usabilidad irrevocable».
Los tres hilos obtuvieron 456, 253 y 474 puntos respectivamente. Los puntos por sí solos no significan mucho — la votación en HN nunca ha sido un medidor de la verdad. Pero la resonancia del mismo día apuntaba al mismo problema: los desarrolladores ya no solo preguntan «qué modelo es más fuerte», empiezan a preguntar «qué herramienta es digna de confianza».
Este cambio tiene respaldo en datos. La encuesta de desarrolladores de Stack Overflow 2025 muestra que el 84% de los desarrolladores usa o planea usar herramientas de codificación IA, pero solo el 29% confía en sus resultados — una caída de 11 puntos porcentuales respecto al 40% del año anterior. La evaluación de Veracode encontró que el 45% del código generado por IA no pasa pruebas de seguridad. La encuesta de Sonar reveló una brecha más peligrosa: el 96% de los desarrolladores no confía completamente en la corrección funcional del código generado por IA, pero solo el 48% dice que siempre lo revisa antes de enviarlo. Un ensayo controlado aleatorio de METR encontró que los desarrolladores que usan herramientas IA son en realidad un 19% más lentos que sus contrapartes que no las usan, aunque ellos mismos creen que son un 20% más rápidos. Para el autor, esto es un problema de ingeniería de mecanismos de confianza — cuando la salida de una herramienta no es verificable, la ganancia de productividad se consume en el costo de verificación.
Volviendo a esos tres hilos, cada uno apunta a una dimensión diferente de la confianza.
El bug de logs de Codex apunta a la fiabilidad. Un sistema que genera 5.5 mil millones de líneas de log pero solo retiene 500 000 no es malicioso, es negligente. Pero la señal de esa negligencia es fuerte: si un código a nivel de infraestructura como el logging local lleva seis meses con un defecto de esta magnitud — al mismo tiempo que otro bug con un spinner ocupando el 100% de la GPU de Mac también seguía sin corregirse —, ¿cómo puede un desarrollador confiar en que el código de negocio generado por esta herramienta no oculta desperdicios de la misma escala? Un usuario de HN acuñó un término duro: «slopware». Es una palabra tosca, pero golpea con precisión el núcleo del sentimiento comunitario — no critica que todo el output de Codex sea basura, critica que su disciplina de ingeniería lo es. Entre ambas afirmaciones hay distancia, pero esa distancia se está reduciendo.
El resumen de pensamiento de Claude Code apunta a la transparencia. La razón técnica de Anthropic es comprensible — ocultar la cadena de razonamiento evita que competidores destilen el modelo y que los usuarios usen el contenido del razonamiento para ataques de seguridad. Pero entender no es aceptar. El hallazgo de Patrick plantea un problema práctico: cuando auditas el comportamiento de un agente IA, ¿obtienes su pensamiento real o un resumen embellecido? No es solo una cuestión filosófica. Si los agentes IA van a operar bases de datos, enviar solicitudes API y modificar el sistema de archivos, su proceso de decisión debe ser auditable — «disponible» no es suficiente, debe ser «preciso». Un usuario de HN fue directo: «No usaré ni recomendaré ningún modelo que oculte su razonamiento». Es una afirmación absoluta, pero refleja una intuición de ingeniería razonable: si el estado interno de un sistema no es observable, no puedes construir un modelo de confianza fiable sobre él.
La controversia del benchmark de GLM-5.2 apunta a la honestidad del propio método de evaluación. La comparativa de Tech Stackups fue rigurosa — el mismo prompt, la misma tarea, código fuente público, juego jugable. Pero las críticas de la comunidad HN no se dirigían a la ejecución de la prueba, sino a su diseño. Un comentario muy votado contó el chiste del borracho buscando las llaves bajo la farola: el policía le pregunta qué hace, dice que busca las llaves; el policía le pregunta si las perdió allí, y él dice que no, pero «aquí hay luz». El benchmark one-shot es esa farola — es fácil de medir, fácil de reproducir, fácil de graficar, pero no refleja el flujo de trabajo real de la ingeniería de software. La programación real implica iteraciones múltiples, entender código existente, corregir bugs, refactorizar arquitecturas — no es un solo prompt que genera una aplicación completa. Si un método de prueba solo cubre el 5% de la capacidad de codificación de la IA, ¿qué pasa con el 95% restante? No lo sabemos. Y ese «no saber» es el problema clave.
Las tres cosas apuntan a la misma conclusión: la dimensión de capacidad de las herramientas de codificación IA ya está sobredesarrollada; la dimensión de confianza está gravemente subdesarrollada.
Esto no significa que «las herramientas de codificación IA no sirvan». Sirven. El 84% de los desarrolladores las usa por alguna razón. Pero «útil» y «confiable» son dos variables independientes. Una herramienta puede ser útil y no confiable al mismo tiempo — y esa es exactamente la situación actual. Y esta combinación es más difícil de manejar que «inútil y no confiable», porque tienta a la gente a acumular deuda de verificación a cambio de eficiencia a corto plazo. Werner Vogels lo llama «deuda de verificación» (verification debt), y sus intereses son compuestos — el output de IA no verificado es referenciado, copiado y dependido por código downstream, y los errores se amplifican en la cadena de dependencias.
GLM-5.2 recibió las menos críticas. Los resultados de la prueba mostraban claramente que era inferior a Opus, pero la controversia de la comunidad no apuntaba al rendimiento — apuntaba a los pesos open source en sí mismos. Open source no equivale automáticamente a confiable, pero proporciona algo que un modelo cerrado no puede: al menos puedes intentar entenderlo. Codex es cerrado, no puedes corregir ese bug del spinner. El razonamiento de Claude Code está encriptado, ni siquiera puedes ver cómo piensa. GLM-5.2 al menos deja los pesos disponibles; aunque la mayoría no los mire, la opción de «poder mirar» es en sí misma parte de la infraestructura de confianza.
El autor no cree que esto signifique que «se acerca el invierno de la codificación IA». Una crisis de confianza no es la muerte de la confianza. Es una revalorización de la confianza — los desarrolladores están recalculando cuánto están dispuestos a pagar por «rápido pero impreciso». Este proceso de revalorización puede ser más digno de atención que los cambios en las tablas de clasificación de benchmarks. Hace 28 días, se reveló CVE-2026-35603 — una vulnerabilidad de escalada de privilegios en una herramienta de codificación IA. Hace 16 días, Cymulate publicó un análisis detallado. Hoy, tres hilos de HN convergen en una misma página. No son eventos aislados; son pulsos continuos de la misma señal.
Esta observación se basa en información pública del 22 de junio de 2026. El autor no tiene datos de uso a largo plazo de estas herramientas ni pretende predecir su evolución. La confianza en ingeniería es una variable acumulativa — los hallazgos de mañana pueden reforzar los de hoy o refutarlos. Lo único seguro es que cuando los desarrolladores dejan de perseguir puntuaciones SOTA y empiezan a perseguir «¿se puede confiar en esto o no?», las reglas del juego ya han cambiado.