Posibles problemas detectados en curl con una herramienta de IA

• Joshua Rogers encontró una gran lista de posibles problemas en la base de código de curl usando su propio conjunto de herramientas basado en IA
• La lista incluye no solo defectos menores de estilo de código, sino también pequeños bugs y posibles vulnerabilidades de seguridad
• La mayoría de los problemas encontrados son bugs pequeños, aunque 1 o 2 podrían ser fallas de seguridad críticas
• Como son problemas que no se habían descubierto antes, el resultado tiene un valor real muy alto
• Con base en lo reportado, ya se completaron 22 correcciones de bugs
• Aún quedan más del doble de issues sin confirmar, por lo que la revisión y corrección continúan
• Los problemas detallados fueron marcados como "Reported in Joshua's sarif data" y, si te interesa, puedes revisar esos datos directamente

[GN⁺]

Comentarios de Hacker News

• Esto es la forma ideal de un "compañero de codificación con IA" en mi opinión
  En vez de escribir o corregir código directamente, quiero que señale las partes sospechosas del código y dónde debería revisar con más detalle
  Si le pido a Claude que encuentre bugs en mi librería de C de 20 mil líneas, termina dividiendo los archivos y haciendo grep de patrones específicos de código, y al final solo me enumera mis comentarios FIXME (jaja)
  La verdad, eso es algo que un simple script de bash podría hacer y resulta bastante decepcionante
  ChatGPT es todavía menos útil: solo repite "¡todo se ve bien! ¡increíble! ¡chócala!"
  Hasta ahora, el análisis estático tradicional me ha ayudado mucho más a encontrar bugs reales, aunque que el análisis estático salga limpio no significa que no haya bugs lógicos
  Justo ahí es donde creo que un LLM debería brillar
  Si para obtener información útil sobre bugs potenciales de un LLM hay que construir un entorno tremendamente personalizado, entonces al final su utilidad baja, igual que pasa con las herramientas de análisis estático cuando requieren configuraciones complejas y la gente termina sin usarlas
  • Casi no se habla de que a muchos programadores les gusta diseñar y programar por sí mismos, salvo quizá el código repetitivo, pero no les gusta tanto revisar código
    La idea de que la IA escriba el código y que el programador solo revise parece ir en una dirección equivocada
    Claro, entiendo por qué lo venden con el enfoque de "aumenta la cantidad de líneas de código~"
  • Cuando Claude da resultados decepcionantes como los mencionados, muchas veces funciona bien "preguntarle directamente al propio Claude qué prompt sería efectivo"
    Por ejemplo: "¿Qué prompt debería usar para que Claude Code arme un plan para revisar bugs lógicos de forma efectiva, ignorando comentarios como FIXME o TODO?"
    El prompt resultante es demasiado largo para ponerlo aquí, pero se puede ver en este ejemplo publicado como gist
    A partir de ese resultado, incluso se puede seguir refinando hasta convertirlo en un agente
  • Cursor BugBot encaja bastante bien en ese rol
    Después de la prueba gratis gustó mucho dentro de nuestro equipo de desarrollo, así que lo adoptamos formalmente
    Salvo algunos falsos positivos ocasionales, es muy útil
    Ahorra bastante tiempo tanto a quien abre el PR como a quien lo revisa
  • He tenido la experiencia de preguntarle a Claude: "Hay un bug de lentitud en la respuesta de cierto endpoint, pero no parece estar relacionado con uso de CPU/memoria ni con la DB, ¿cuál podría ser la causa?" y, tras varias iteraciones, obtuve pistas sobre bugs realmente difíciles de encontrar
    Hubo casos en que resolví un problema que antes me habría tomado horas gracias a esas pistas
    Me entusiasma mucho ese tipo de uso posible de la IA
  • GPT-5 adula mucho menos en este tipo de situaciones que los modelos anteriores
    Me sorprende un poco que haya salido una respuesta tipo "todo se ve bien"
    Cuando lo uso en Codex CLI, a menudo sí plantea dudas
    Gemini 2.5 Pro también va bastante bien en eso
• La verdad, jamás habría esperado una anécdota positiva sobre curl y la IA
  Conviene revisar el historial: enlace de búsqueda en HN sobre curl+AI
  • Me parece admirable que Daniel Stenberg haya abordado esto con una actitud generosa, a pesar de los varios problemas que tuvo antes con reportes de bugs generados por IA
• El punto parece ser que es un "conjunto de herramientas". No lo están confundiendo con un piloto automático, sino que combinan bien las herramientas y las usan como un sistema
  • Parece que el autor invitado incluyó más detalles en el texto original blog de referencia (mención en Mastodon: enlace relacionado)
  • Da pena que la discusión se haya reducido a un marco binario tipo "conducción autónoma vs. abandono"
    Al final, parece más acertado verlo como la diferencia entre quienes lo usan entendiendo bien lo que hacen y quienes simplemente programan siguiendo el ambiente o la moda
  • Stenberg lo describió como un conjunto de herramientas, pero también me da curiosidad saber qué piensa el contribuidor que realmente usó las herramientas
• En el repositorio de curl hay 55 PR cerrados que mencionan "sarif data", y los PR mencionados esta vez son justamente ese grupo
  Contrasta con lo mucho que Daniel Stenberg sufrió en el pasado por temas de supuesta seguridad mal hechos generados por IA
  Sobre HackerOne: "A los que reportan basura generada por IA los baneo de inmediato. Es prácticamente un ataque DDoS. Hasta dan ganas de cobrarles por el tiempo perdido"
  También vale la pena revisar una entrada del blog de Daniel de enero de este año: The I in LLM stands for Intelligence?
  • Algunos bugs, como usar un especificador de formato printf incorrecto para size_t, pueden detectarse solo con configurar bien los flags de warnings del compilador
    Sería bastante útil que la IA te dijera: "te faltan flags importantes de warnings del compilador"
    Algunos PR probablemente se deban a coincidencias de dependabot, y si buscas "Joshua sarif data" puedes ver una lista más específica de PR aquí
  • Da la impresión de que los modelos usados en ese momento han mejorado mucho
    Supongo que esa es la razón por la que cambió la impresión de Daniel Stenberg
• Entre los escáneres SAST comerciales hay algunos buenos, pero la mayoría no convence
  Se insiste mucho en adoptar tecnología SAST basada en IA y de hecho ya han salido productos relacionados, pero la gran mayoría sigue quedando por debajo de lo esperado
  Con suerte solo decepcionan; en el peor caso, generan una falsa confianza en una seguridad incorrecta, y eso es peligroso
  Aquí se presenta una mirada crítica a los escáneres SAST basados en IA y sus fundamentos: aquí
• No fue fácil entender de inmediato cuáles eran exactamente las herramientas de IA
  Me da curiosidad por qué esta estrategia resultó más efectiva en una situación donde varias herramientas ya existentes no habían podido encontrar los bugs
  • Se puede encontrar algo más de información en este blog con un capítulo sobre el producto
    Supongo que el enlace a Mastodon sirve para confirmar que sí era un bug real aunque hubiera fragmentos de código incorrectos
• Como tema relacionado, se menciona este caso de "hacer algo con IA sin entender qué se está haciendo": You did this with an AI and you do not understand what you're doing here