Todos los artículos

Blog

Mejor IA para programar: ninguna escribe código seguro sin revisión

Claude, GPT-5, Gemini: la mejor IA para programar aún deja pasar vulnerabilidades. La clasificación con cifras y lo que protege tu código.

  • Por Azziz ERRIME
  • 11 min de lectura
Fila de máquinas de escribir antiguas, idénticas y sin rótulo, como los aspirantes a mejor IA para programar, con una sola hoja levantada y tachada en rojo

TL;DR

  • En seguridad, ningún modelo te exime de revisar, y elegir bien el modelo no sustituye una revisión centrada en la seguridad.
  • Según Veracode, la mejor IA para programar de su clasificación genera código seguro en el 72 % de las tareas; Claude Sonnet 4.5, en el 50 %.
  • Yo elegiría el modelo por la productividad del equipo y pondría el esfuerzo de seguridad en la revisión de código.

En marzo de 2025, un investigador escaneó 1 645 aplicaciones generadas con IA y encontró 170 cuya base de datos respondía a cualquiera. No he encontrado en ningún sitio qué modelo había escrito ese código. Y, sin embargo, es lo primero que se pregunta quien busca la mejor IA para programar. En seguridad, la respuesta no dice nada de lo que le ocurre al código una vez generado.

El 20 y el 21 de marzo de 2025, Matt Palmer examinó proyectos publicados con Lovable, un servicio que genera aplicaciones web con IA. En 170 de los 1 645 proyectos contó 303 puntos de acceso expuestos. Avisó a Lovable el día 21. Después contó en una entrada publicada más tarde lo que se podía leer en ellos: direcciones de correo electrónico, números de teléfono, datos de pago y claves de API de servicios de terceros.

En abril, Lovable lanzó una versión 2.0 con un escáner de seguridad. El 14 de abril, un ingeniero de Palantir dio por su cuenta con la misma vulnerabilidad y la publicó en X. El 29 de mayo, la vulnerabilidad recibió un identificador público, CVE-2025-48757. Matt Palmer reprocha al nuevo escáner que se limite a comprobar que hay una regla de protección: según él, «merely checks for the existence of any RLS policy, not its correctness».

Las aplicaciones funcionaban, las pantallas se cargaban y la vulnerabilidad solo se veía si alguien iba a buscarla. Antes de comparar modelos, tengo presente esta escena: la pregunta útil también tiene que ver con lo que se hace con el código una vez escrito.

Una base de datos abierta no aparece en ninguna demostración

La regla que faltaba en esas aplicaciones se llama RLS, por Row Level Security. Definida en la base de datos, decide qué filas puede leer cada usuario. Sin ella, la interfaz puede mostrar a cada uno solo sus propios datos mientras la base, por detrás, responde a cualquier consulta que se le haga.

En la práctica, el atacante no tiene que romper nada. Abre la aplicación en su navegador y observa las peticiones que salen hacia la base. Localiza la dirección y la clave pública que sirven para consultarla, y repite la petición pidiendo la tabla entera, que la base devuelve si ninguna regla filtra.

Una vulnerabilidad así es una ausencia. Falta una línea de configuración, y ninguna prueba funcional la echa en falta, porque todo funciona. La generación de código produce este defecto sin hacer ruido, porque no rompe nada visible. Queda por saber si el modelo mejor clasificado lo produce menos que los demás, y sobre eso hay mediciones.

La mejor IA para programar aún suspende el 28 % de las tareas de seguridad

Veracode, proveedor de herramientas de seguridad de aplicaciones, somete periódicamente a los principales modelos a una misma batería de tareas de programación. Cada tarea expone a una vulnerabilidad conocida, y Veracode comprueba si el código generado la evita. Su actualización publicada el 18 de noviembre de 2025 da la clasificación siguiente. Es la última clasificación por modelo que he podido leer. La medición de marzo de 2026 solo ofrece una media.

Modelo Porcentaje de tareas en las que el código generado es seguro
GPT-5 Mini 72 %
GPT-5 (con razonamiento) 70 %
Gemini 2.5 Pro 59 %
Grok 4 55 %
GPT-5-chat (sin razonamiento) 52 %
Gemini 2.5 Flash 51 %
Qwen3 Coder 50 %
Claude Sonnet 4.5 50 %
Claude Opus 4.1 49 %

La parte alta de la tabla es para los modelos que razonan antes de responder. Dentro de la misma familia, GPT-5 pasa del 52 % sin razonamiento al 70 % con él. Veracode lo explica con una imagen que me parece acertada: los pasos de razonamiento «function like an internal code review». El modelo compara varias formas de escribir la función y descarta las menos seguras antes de responder.

Si buscas la mejor IA para programar solo con este criterio, la tabla te da una recomendación de compra. Leída con calma, deja dos preguntas abiertas. ¿Qué vale el código de ese 28 % de tareas que ni siquiera el primero supera? ¿Y qué mide exactamente esta clasificación, que solo contempla vulnerabilidades conocidas en tareas elegidas de antemano?

Un modelo mejor en el benchmark puede introducir bugs más graves

Sonar, proveedor de herramientas de análisis de código, puso a varios modelos a resolver ejercicios en Java y después analizó el código obtenido. Su informe del 13 de agosto de 2025 señala una paradoja. Al pasar de Claude 3.7 Sonnet a Claude Sonnet 4, la puntuación en el benchmark mejora. Sin embargo, los bugs que introduce el nuevo modelo tienen una probabilidad más de un 93 % mayor de clasificarse como BLOCKER, la categoría bloqueante.

La clasificación de Veracode tampoco ve las dependencias. Una IA que genera código también propone bibliotecas que instalar, y algunas no existen. El estudio de Spracklen y sus colegas, presentado en USENIX Security en 2025, mide esos nombres inventados. Encuentra un 3,59 % entre los paquetes que recomienda GPT-4 Turbo, la cifra más baja, un 13,63 % en el mejor modelo abierto, un DeepSeek, y un 19,7 % de media. Y el 43 % de esos nombres inventados se repite en diez ejecuciones. Un atacante que detecte un nombre inventado recurrente puede publicar un paquete malicioso con ese nombre y esperar a que algún desarrollador lo instale.

El benchmark BaxBench plantea por fin la pregunta que les falta a los otros dos. Pone a once modelos a escribir servicios completos, comprueba que funcionan y luego los ataca: alrededor de la mitad de los programas funcionalmente correctos siguen siendo explotables. La vulnerabilidad de Lovable pertenece a esa familia, la del código que hace lo que se le pide y nada de lo que se olvidó pedirle.

Queda un argumento serio a favor de la clasificación: los modelos de razonamiento avanzan deprisa, y bastaría con quedarse con el primero.

Dos puentes colgantes uno junto a otro, el más logrado con un cable portante roto

El más logrado de los dos fue el primero en ceder.

Sin razonamiento, ningún modelo ha mejorado desde julio de 2025

El progreso de los modelos de razonamiento es real, y no lo minimizo. Entre GPT-5-chat y GPT-5 con razonamiento, la diferencia llega a dieciocho puntos. Para un equipo que genera mucho código, no es poca cosa.

Aun así, el mismo informe describe un mercado estancado: «Models from Anthropic, Google, Qwen, and xAI released between July and October 2025 did not show meaningful security improvements.» Los modelos de estas empresas siguen agrupados entre el 50 y el 59 %, la horquilla que ya se veía en verano. Su medición siguiente, publicada el 24 de marzo de 2026, registra un 55 % de tareas que dan código seguro, unas cifras que «have barely budged» desde el primer informe de 2025.

Yo leo ahí un indicio, no una prueba: la única mejora clara viene de un paso que Veracode compara con una revisión. Ninguno de los estudios que he leído mide lo que aporta una revisión humana al código generado.

Falta saber quién revisa, y cómo lo hace.

Una instrucción de seguridad cambia lo que ve el revisor

Lo tentador es que otra IA revise el código que ha escrito una IA. Kim y sus colegas midieron hasta qué punto los modelos se equivocan a la vez, en un trabajo presentado en ICML en 2025. En un conjunto de datos de clasificación, cuando dos modelos fallan los dos, cometen el mismo error en torno al 60 % de los casos. Esa cifra solo vale para ese conjunto de datos. Me basta para dudar de que un segundo modelo vea lo que se le escapó al primero.

La revisión humana tiene su propio punto débil, y se corrige con facilidad. Pedir explícitamente a un revisor que mire la seguridad multiplica por ocho sus probabilidades de encontrar la vulnerabilidad, según Braz y sus colegas, en código escrito por personas.

En la práctica, una revisión de código generado por IA centrada en la seguridad busca primero lo que falta, antes que lo que está escrito. Una regla de acceso en cada tabla, una validación en cada entrada, una dependencia que existe de verdad y que es la que uno cree. En un artículo anterior expliqué por qué la revisión de código ya no sigue el ritmo de la IA.

Puerta de caja fuerte entreabierta, con la cerradura en su sitio pero el pestillo sin echar

La cerradura está ahí. Nadie comprobó que estuviera cerrada.

Elegir la mejor IA para programar por una clasificación equivale a comprobar que existe una regla

Según Matt Palmer, el escáner de Lovable comprobaba que existía una regla de protección, sin comprobar que protegiera. Elegir la mejor IA para programar por una clasificación, y luego confiar en esa elección, es el mismo atajo. Se verifica que hay una garantía, sin medir su efecto en tu código.

Yo elegiría el modelo por la productividad del equipo, sus lenguajes y el lugar adonde van tus datos, y pondría el esfuerzo de seguridad del código en otra parte:

  • una línea en la plantilla de PR que pida explícitamente revisar la seguridad, ya que esa instrucción por sí sola multiplica la detección;
  • una comprobación de cada dependencia que añada un modelo: que el paquete exista y que sea el correcto;
  • una revisión que empiece por lo que falta, reglas de acceso y validaciones, antes que por lo escrito;
  • un nuevo vistazo a la clasificación cada trimestre, sin convertirla en una política.

Es también lo que estoy midiendo ahora: lo que los desarrolladores detectan, o dejan pasar, cuando revisan código escrito por una IA. Los modelos cambian más deprisa que los hábitos de revisión.

Mantengo una reserva. Los modelos de razonamiento han ganado dieciocho puntos en Veracode, y nada impide que la próxima generación haga menos necesaria la revisión. Cambiaré de opinión cuando una medición independiente lo demuestre. Hasta entonces, reviso.

Preguntas frecuentes sobre la mejor IA para programar

¿Cuál es la mejor IA para programar?

En seguridad, ninguna destaca lo bastante como para ahorrarte la revisión. En la medición publicada por Veracode el 18 de noviembre de 2025, GPT-5 Mini genera código seguro en el 72 % de las tareas y GPT-5, en el 70 %. Claude Sonnet 4.5 y Qwen3 Coder se quedan en el 50 %. En productividad, la mejor IA para programar depende de tus lenguajes y tus herramientas: pruébala con tu propio código.

¿Claude o ChatGPT para programar?

En el duelo Claude vs ChatGPT, la medición de Veracode da un 70 % de tareas seguras a GPT-5 con razonamiento y un 50 % a Claude Sonnet 4.5. Sin razonamiento, GPT-5-chat baja al 52 %, así que la diferencia depende más del modo que de la marca. Las dos familias necesitan una revisión centrada en la seguridad.

¿Es seguro el código generado por IA?

No por defecto. Según la medición de Veracode publicada el 24 de marzo de 2026, solo el 55 % de las tareas de generación da código seguro, una tasa que apenas se ha movido desde 2025. El benchmark BaxBench encuentra que alrededor de la mitad de los programas funcionalmente correctos siguen siendo explotables. El código generado por IA debe pasar una revisión de código centrada en la seguridad, igual que el código humano.

¿Es seguro Copilot?

El estudio de Pearce y sus colegas, publicado en 2021, encontró alrededor de un 40 % de programas vulnerables entre 1 689 programas generados por Copilot en 89 escenarios. Una replicación posterior, hecha con versiones más recientes de la herramienta, mide un 27,25 %. El progreso es real, y más de uno de cada cuatro programas sigue siendo vulnerable en esos escenarios.

Fuentes