La carrera por convertirse en el mejor asistente de programación se ha acelerado en las últimas semanas. En apenas doce días se han presentado tres modelos punteros orientados al desarrollo de software: GPT-5.1 (OpenAI), Gemini 3.0 (Google) y Claude Opus 4.5 (Anthropic). La gran pregunta es evidente: ¿cuál conviene usar según el tipo de proyecto?
El laboratorio Kilo.ai ha publicado un benchmark detallado en el que pone a prueba a los tres modelos en tres tareas de programación diferentes. No es un test sintético de laboratorio, sino ejercicios relativamente realistas que cualquier equipo de desarrollo podría necesitar: implementar una pieza de código con requisitos muy estrictos, refactorizar un API legacy lleno de problemas y extender un sistema de notificaciones ya existente.
Los resultados muestran algo importante: no hay un ganador absoluto, sino tres estilos muy distintos de “programar con IA”.
Tres pruebas, tres estilos de programar
Kilo.ai definió tres retos:
- Prompt Adherence Test
Implementar en Python un rate limiter con 10 requisitos muy rígidos: nombre exacto de la clase (TokenBucketLimiter), firma de métodos concreta, mensajes de error literales, uso obligatorio detime.monotonic(),threading.Lock(), etc.
Aquí se valora sobre todo obediencia al enunciado. - Code Refactoring Test
Refactorizar un handler TypeScript de 365 líneas lleno de problemas: más de 20 posibles inyecciones SQL, ausencia de validaciones, tiposanypor todas partes, operaciones sin transacciones, secretos en claro, etc.
Había que dividir en capas (Servicio/Controlador/Repositorio), añadir validaciones con Zod, sanear la arquitectura y aplicar buenas prácticas de seguridad. - System Extension Test
Analizar un sistema de notificaciones (unos 400 líneas) con Webhook y SMS, explicar primero la arquitectura y después añadir soporte de correo electrónico.
Aquí se medía la capacidad de entender código existente y extenderlo imitando su estilo.
En todos los casos se trabajó desde proyectos vacíos en Kilo Code, usando modos de análisis y de escritura específicos para cada modelo.
Test 1: cuando seguir el prompt al pie de la letra es la clave
En la prueba del rate limiter el modelo que mejor lo hizo fue Gemini 3.0, con una puntuación de 99/100. Entregó exactamente lo pedido, sin adornos ni validaciones extra. Código limpio, corto (unos 90 líneas) y ceñido a los 10 requisitos.
Claude Opus 4.5 quedó muy cerca, con 98/100. También cumplió el enunciado, pero fue algo más verboso e introdujo docstrings más detallados. Perdió un punto por un detalle menor: llamó a una variable interna _tokens en lugar de _current_tokens, nombre que se esperaba para una clave del diccionario.
GPT-5.1 obtuvo 97/100, no por errores, sino por “exceso de celo”: añadió validaciones que el enunciado no mencionaba (por ejemplo, que el número de tokens fuera positivo) y chequeos adicionales en el constructor. Desde el punto de vista de robustez está muy bien, pero ya no es la implementación minimalista que pedía la prueba.
Conclusión del Test 1:
- Gemini 3.0 es el campeón cuando hace falta seguir el prompt al milímetro.
- Claude Opus 4.5 añade algo más de documentación.
- GPT-5.1 tiende a sobre-proteger el código con validaciones que nadie le ha pedido.
Test 2: refactorización profunda y seguridad
En el segundo reto, la prioridad era sanear un API legacy con problemas serios de seguridad y diseño. Aquí cambia completamente el ranking.
Claude Opus 4.5 fue el único modelo que obtuvo 100/100. Implementó los 10 requisitos, incluido un sistema de rate limiting que los otros dos ignoraron. Añadió cabeceras de límite de peticiones, una clase específica RateLimitError y gestionó secretos a través de variables de entorno en lugar de dejarlos en claro en el código.
GPT-5.1 quedó muy cerca, con 91/100. Aunque no implementó el rate limiting, fue especialmente fuerte en seguridad:
- Añadió comprobaciones de autorización para evitar que un usuario pudiera ver tareas de otro.
- Implementó transacciones de base de datos en operaciones multi-paso.
- Mantuvo la compatibilidad hacia atrás aceptando tanto los nombres de campos antiguos como los nuevos.
Gemini 3.0 consiguió 82/100. Identificó muchos problemas y limpió parte del código, pero dejó agujeros importantes:
- Detectó que hacían falta transacciones… pero no las implementó, solo dejó un comentario.
- No añadió comprobaciones de propiedad en ciertos endpoints, lo que dejaba la puerta abierta a fugas de datos.
- Se centró en simplificar y hacer el código más legible, pero no llegó tan lejos en la parte de seguridad.
En esta prueba también se midió la cantidad de código generado. Claude y GPT-5.1 produjeron en torno a 1.300–1.400 líneas (muy completo, con tipos, validaciones y capas bien separadas), mientras que Gemini se quedó en unas 750, reflejando su estilo más minimalista.
Conclusión del Test 2:
- Claude Opus 4.5 es el más recomendable cuando se necesita una refactorización integral “enterprise”, con seguridad y buenas prácticas de serie.
- GPT-5.1 se comporta como un desarrollador defensivo y consciente del legado.
- Gemini 3.0 prioriza la limpieza y la simplicidad, pero requiere supervisión extra en temas críticos.
Test 3: entender una arquitectura y ampliarla
El tercer examen medía la capacidad de leer código existente, explicarlo y luego ampliarlo sin romper el diseño.
En la fase de análisis:
- GPT-5.1 destacó con un informe de más de 300 líneas, citando números de línea, incluyendo un diagrama de secuencia en Mermaid y detectando bugs sutiles en la lógica de enrutado y retries.
- Claude Opus 4.5 produjo un análisis algo más breve, pero muy estructurado, también con diagramas Mermaid y propuestas concretas de mejora.
- Gemini 3.0 ofreció un resumen correcto pero más superficial, identificando los patrones (Strategy, Observer) pero sin entrar tanto en detalle ni señalar fallos ocultos.
En la implementación del nuevo EmailHandler:
- Claude Opus 4.5 volvió a ser el más completo: creó plantillas para los 7 tipos de evento del sistema (altas de usuario, login, pagos, pedidos, envíos, etc.) y añadió métodos para gestionar las plantillas en tiempo de ejecución.
- GPT-5.1 imitó muy bien la arquitectura existente y añadió soporte avanzado (múltiples destinatarios, CC/BCC, adjuntos…), pero solo para 3 eventos.
- Gemini 3.0 implementó una versión funcional pero básica, sin gestionar casos como adjuntos o listas complejas de destinatarios.
En tiempos y costes, Opus fue el más rápido en el global de las tres pruebas (unos 7 minutos de uso acumulado) pero también el más caro. Gemini resultó el más económico en cómputo total, y GPT-5.1 quedó en un punto intermedio, generando normalmente más líneas de código por su tendencia a documentar y validar todo.
¿Qué modelo elegir según el proyecto?
El benchmark de Kilo.ai deja una idea clara: los tres modelos son muy capaces, pero no sirven para lo mismo.
- Claude Opus 4.5
Ideal para quien quiere que la IA entregue soluciones completas, organizadas y casi “listas para producción”. Implementa todos los requisitos, añade buenas prácticas (variables de entorno, gestión de errores, límites de uso…) y suele entender bien las arquitecturas complejas. A cambio, consume más y puede ser “demasiado” para scripts pequeños. - GPT-5.1
Destaca en código defensivo y en análisis profundo de sistemas existentes. Añade validaciones, documentación y compatibilidad con el legado casi por defecto. Es muy útil cuando el objetivo es evitar sorpresas en producción, pero conviene vigilar que no cambie contratos o añada restricciones no deseadas. - Gemini 3.0
Brilla cuando se busca precisión y minimalismo: hace exactamente lo que se le pide, de forma rápida y barata. Es una buena opción para prototipos, tareas acotadas o desarrolladores que prefieren añadir a mano la capa de seguridad y documentación.
La conclusión para los equipos de desarrollo es pragmática: más que un “ganador absoluto”, lo que ofrece el mercado es un catálogo de estilos de programación asistida por IA. Elegir uno u otro modelo dependerá de si se prioriza la completitud (Claude), la seguridad y el contexto (GPT-5.1) o la precisión económica y minimalista (Gemini 3.0).
Fuente: Kilo Code blog
