- Durante la implementación en Go de ML-DSA, un algoritmo de firma resistente a la computación cuántica designado por NIST, surgió un problema en el que la verificación de firmas fallaba
- Claude Code v2.0.28 logró encontrar rápidamente un bug complejo de bajo nivel usando solo el código de pruebas y las rutas del código fuente
- Se confirmó que la causa fue un error de fusión de funciones que recalculaba los bits altos de
w1 en la etapa de Verify
- En un segundo experimento, Claude también encontró por separado un error en el cálculo de constantes de Montgomery y un bug de discrepancia en la longitud de la firma
- Como identificó correctamente los bugs en los tres intentos, mostró el potencial de la IA para la depuración de bajo nivel
Implementación de ML-DSA y problema inicial
- El autor implementó desde cero en Go ML-DSA (Post-Quantum Signature Algorithm), designado por NIST
- Tras 4 días de live coding, en las pruebas apareció un problema donde la función Verify rechazaba todas las firmas
- En los logs de prueba se repetía el error
invalid signature
- Debido al cansancio, dejó la depuración y le pidió a Claude Code que analizara el problema
Primera depuración con Claude Code
- A Claude Code v2.0.28 (modelo Opus 4.1, sin system prompt) se le proporcionó la siguiente información
- Comando para ejecutar las pruebas (
bin/go test crypto/internal/fips140/mldsa)
- Ubicación del código (
src/crypto/internal/fips140/mldsa)
- La explicación de que “la firma siempre es rechazada” y la pista de que “
w1 es diferente”
- En pocos minutos, Claude devolvió una propuesta de corrección completa
- La causa fue que, después de combinar
HighBits y w1Encode en una sola función, en Verify se volvieron a tomar los bits altos del resultado de UseHint, aunque este ya los había generado
- Es decir, un error estructural que calculaba dos veces los bits altos de
w1
- Claude identificó la causa justo después de cargar el código y escribió sus propias pruebas para validar la hipótesis
- La corrección propuesta no era perfecta, pero acortó el tiempo de depuración al detectar la causa central
- Después, el autor refactorizó
w1Encode para que recibiera los bits altos como entrada y también acortó el proceso de conversión de la representación Montgomery
Segundo experimento: bug en la etapa de generación de firmas
- También hubo fallas en las pruebas de la implementación de generación de firmas
- Primer bug: error al calcular las constantes (1, -1) en el dominio Montgomery
- Era un problema difícil de encontrar, que requirió muchos
printf y conjeturas, y tomó alrededor de 1 a 2 horas
- Segundo bug: error en la longitud de un valor incluido en la firma (32 bits en lugar de 32 bytes)
- Fue relativamente fácil de descubrir por la diferencia en la longitud de la firma
- El autor consideró que estos dos bugs eran adecuados para evaluar el desempeño de Claude y volvió a ejecutar Claude Code con una versión anterior del código
Resultados de la segunda depuración con Claude Code
- En el primer prompt, Claude realizó depuración con printf y rastreo de valores, encontró la constante incorrecta y la corrigió
- El tiempo de resolución fue menor que el de un humano y detectó con precisión la causa de la falla en las pruebas
- En el segundo prompt, encontró el problema de discrepancia en la longitud de la firma
- Tras explorar varias rutas, Claude propuso una corrección que solo modificaba la longitud asignada
- La corrección propuesta no era completa, pero señaló con precisión la ubicación del error principal
- En los tres intentos independientes, Claude encontró por sí solo la causa exacta de los bugs
Eficiencia e implicaciones de la depuración con IA
- El enfoque de Claude fue efectivo como asistente automatizado especializado en buscar la causa de fallas en pruebas
- El usuario no aplicó directamente las correcciones de Claude, sino que confirmó la ubicación del bug y luego lo corrigió manualmente
- El autor menciona la necesidad de una herramienta que, cuando fallen las pruebas, use automáticamente un LLM para analizar y explicar la causa
- Considera que la forma ideal no es un chat simple ni la generación automática de PR, sino un agente de depuración basado en pruebas
Patrocinio y otra información
- El mantenimiento open source del autor recibe apoyo a través de Geomys, y
Smallstep, Ava Labs, Teleport, Tailscale y Sentry están entre sus patrocinadores
- Ava Labs destaca la importancia del desarrollo open source sostenible de protocolos criptográficos
- Teleport presenta la plataforma Teleport Identity para prevenir el secuestro de cuentas de usuario y reforzar el control de acceso
Apéndice: imágenes y mención personal
- El texto incluye a Clippy, de Microsoft Office, con un globo de diálogo que dice que “tomó dos veces los bits altos de
w1”
- Al final también hay una foto de un gato, presentada como una broma para aliviar los debates emocionales sobre la IA
2 comentarios
Últimamente he estado desarrollando un poco kernels de GPU usando triton o cuda, y aunque incluso en 3.5 casi nunca veía que ejecutara algo correctamente, en 4.5 sí se nota que ya genera código y optimizaciones más o menos decentes.
Opiniones de Hacker News
Usar agentes de programación para rastrear la causa raíz de un bug funciona bastante bien.
Los tres intentos de depuración de una sola pasada tuvieron éxito. La clave es que el LLM no corrija el código directamente, sino que actúe como un asistente que solo indica dónde está el bug para que yo mismo pueda juzgarlo y arreglarlo.
Este enfoque también puede ser un buen punto de partida para los escépticos de los LLM. No hace falta que escriba el código por ti; basta con ponerlo a buscar bugs molestos.
La sugerencia de “hay que arreglar esto” no necesariamente es incorrecta, pero muchas veces no tiene que ver con el problema central. Al final se acumulan propuestas de cambios inútiles y, si un desarrollador junior las aplica tal cual, solo aumenta el trabajo innecesario.
Yo también uso estas herramientas, pero a veces siento que “termino perdiendo más tiempo explicándoselo a un junior”.
También generan bien pruebas para problemas algorítmicos, pero en situaciones de concurrencia tienen limitaciones. Aun así, tienen suficiente valor para usarlos en generación de tests o depuración.
Siguen quedándose cortos para refactorización de código o mantenimiento a largo plazo.
Aun así, al usarlos como cazadores de bugs, tal como recomendaba el blog, fueron sorprendentemente efectivos. En unas pocas semanas encontré varios bugs en producción.
Si le haces escribir documentación extensa relacionada antes de meterte a fondo en el código, aunque se equivoque el costo es bajo, y también es un buen punto de partida para alguien escéptico.
Me daría pena delegarle ese proceso a una máquina. Cazar bugs te obliga a entender profundamente la estructura del sistema y, a largo plazo, te ayuda a convertirte en un mejor programador.
Sin esa experiencia, existe el riesgo de terminar dependiendo del LLM incluso para juzgar tu propio código.
Mi consejo es uno solo: AI First.
Si primero le planteas el problema a la IA, aprendes los límites del modelo y al mismo tiempo mejoras tu capacidad para estructurar prompts.
Los modelos más recientes son lo bastante potentes como para tratarlos como colegas en la mayoría de los problemas. Aun así, lo importante es entender sus patrones de falla y desarrollar intuición.
Cada vez que sale una nueva generación de modelos, recomiendo dejar atrás el proceso anterior y experimentar con modelos nuevos como GPT-5-Codex o Sonnet 4.5.
Si eres experto en el dominio, puedes distinguir las alucinaciones y errores del LLM, pero si no lo eres, terminas perdiendo tiempo.
Al final, estas herramientas son más útiles para expertos, y para principiantes la calidad es muy irregular.
Yo también probé Sonnet 4.5, pero me pareció solo una mejora ligera frente a la versión anterior. Sigue habiendo mucho tiempo perdido.
Anthropic me dio Claude Max gratis durante varios meses.
Últimamente también hay muchísimo contenido sobre Claude en anuncios de Instagram. Siguen apareciéndome anuncios como “instala Claude Code”, así que parece que el equipo de marketing realmente está trabajando duro.
Los desarrolladores encuentran Claude Code muy útil, y hay bastante gente pagando la suscripción de 200 dólares al mes. Si el producto es rentable, es lógico invertir fuerte en marketing.
El LLM ayuda a encontrar bugs, pero también puede dar explicaciones disparatadas y hacerte perder tiempo.
Al final, lo importante es mantener el pensamiento crítico.
El LLM es una gran herramienta, pero tiende a sacar conclusiones apresuradas. En el momento en que la persona deja de pensar, el modelo se va por cualquier lado.
Estoy de acuerdo con la idea de que “usar LLM solo como chat o autocompletado no convence mucho”.
Yo también empecé a verle potencial recién al usar Claude Code/Codex. Si existiera un modo de ejecución continua, sería todavía más interesante.
Podría borrar archivos por error o arruinar un repositorio Git. Por eso yo solo experimento en un entorno sandbox.
Quiero una herramienta colaborativa, en estilo socrático, donde el modelo me haga preguntas y yo intervenga directamente mientras aprendo.
El enfoque actual, centrado en la “automatización”, corre el riesgo de volver analfabetos de código a los desarrolladores. En cambio, si se diseña bien, puede ser una herramienta que amplifique la comprensión y la intuición.
La terminal CLI sigue siendo una interfaz muy poderosa.
Gemini CLI y Qwen Code son gratis, y además es fácil conectarlos a una API compatible con OpenAI.
Las tareas simples se pueden automatizar, y las partes difíciles se pueden resolver de un tiro con Grok. Solo con CLI + servidor MCP + archivos MD ya se pueden crear programas inteligentes.
Me parece interesante la idea de hacer que el LLM analice automáticamente la causa cada vez que falla un test.
Se puede hacer ejecutando Claude CLI con un Git hook.
Se pueden ver ejemplos y una chuleta en esta guía.
Parece probable que pronto aparezcan casos de ataques adversariales contra los datos de entrenamiento de los LLM para inducir errores criptográficos.
Que una “corrección incluya agregar una función totalmente nueva” me parece peligroso cuando se trata de implementaciones criptográficas.
Siento que el artículo da un mal consejo.
El código de corrección se descartó, y la persona lo escribió por su cuenta. Más bien parece un caso de uso conservador y responsable.
El LLM no debe usarse como “reparador”, sino como un detector de fugas de gas que te señala dónde está el problema.
Los LLM han eliminado muchos problemas tediosos al reconocer patrones ambiguos en el código.
Pero eso también puede convertirse en un efecto secundario. Mi codebase parece de Node.js, pero en realidad no lo es, así que el modelo la confunde constantemente con un proyecto de Node.