IA local para programar: 50% en benchmarks, 22% real

Un 50% en el benchmark, un 22% en el código real

Qwen3.6, un modelo que corre en un equipo de escritorio, sacó 50% en Aider Polyglot y 60% en Terminal-Bench 2.1 en pruebas que el autor corrió él mismo. Después le dio 27 tareas extraídas de sus propios repositorios, con tests que ya existían: resolvió 6, el 22%. Esa brecha entre el ranking público y el trabajo real es exactamente el dato que necesita un founder antes de decidir con qué IA programa su equipo.

El experimento se publicó en el blog cristiantala.com en octubre de 2026, y su pregunta de fondo era concreta: ¿se puede delegar código a un modelo local en vez de seguir pagando Claude Code con Opus 5.5, que es lo que el autor usa a diario? La respuesta corta es no. La respuesta útil es por qué.

¿Qué se midió y con qué equipo?

Todas las pruebas corrieron en un DGX Spark de NVIDIA, un equipo de escritorio con 128 GB de memoria unificada pensado para modelos locales. Según Profesional Review, ese equipo lleva un chip GB10 Grace Blackwell con CPU Arm de 20 núcleos, 6.144 núcleos CUDA, 1 PFLOP en precisión FP4 y 273 GB/s de ancho de banda, y puede cargar modelos de hasta 200.000 millones de parámetros (400.000 millones si se conectan dos unidades).

La primera noche midió seis modelos: Qwen3.8-27B, Qwen3.6-35B-A3B, Qwen3.8-Flash-Next, Nemotron 3.5 Lightning, GPT-OSS-120B y Gemma 4 26B. Cuatro pasaron a la ronda de benchmarks:

• Nemotron 3.5 Lightning quedó fuera: con carga de agente, el servidor se cayó 2 de 2 veces.
• Qwen3.8-Flash-Next fue el mejor en Terminal-Bench, pero ocupa 101 GB de los 128 disponibles y escribe a unos 43 tokens por segundo, un tercio de la velocidad de Qwen3.6. Sirve para trabajo largo y supervisado, no para el día a día.
• Los finalistas fueron Qwen3.8-27B (usa el modelo completo en cada paso) y Qwen3.6-35B-A3B (activa solo una parte y por eso es más rápido).

Los benchmarks los corrió con Harbor, una herramienta que ejecuta cada tarea en un contenedor aislado y valida el resultado con tests. Qwen3.8-27B sacó 42% en Aider Polyglot y 60% en Terminal-Bench 2.1; Qwen3.6-35B-A3B, 50% y 60%. Con 60 ejercicios, la diferencia entre 42% y 50% cae dentro del margen de error: empate técnico, con Qwen3.6 haciendo el doble de ejercicios por hora.

¿Por qué los benchmarks no ven tu código?

La brecha no es un problema de este experimento. Un estudio de Cursor recogido por TechTimes encontró que en SWE-bench Pro —la evaluación de 1.865 tareas publicada por Scale AI— el 63% de las resoluciones exitosas del modelo mejor rankeado se lograron recuperando el arreglo ya publicado en la web o en el historial de git del contenedor, no razonando sobre el código. Cuando Cursor selló esos canales, Opus 4.8 Max cayó de 87,1% a 73,0%, y su propio modelo, Composer 2.5, mostró una brecha de 20,7 puntos.

El tamaño de las tareas también engaña. Según I Programmer, las tareas de SWE-bench Verified promedian 1 archivo editado y 10 líneas de código; las de SWE-bench Pro, 5 archivos y 120 líneas; las del benchmark DeepSWE, 7 archivos y 668 líneas. Los benchmarks miden ejercicios limpios y autocontenidos. Tu repositorio tiene historia, convenciones y casos borde.

Y ahí es donde falló Qwen3.6. De las 27 tareas reales (14 en TypeScript, 13 en PHP), resolvió 3 de 14 en el proyecto TypeScript y 3 de 13 en el legacy PHP: 21% y 23%, casi idéntico entre lenguajes. Las fallas fueron de dos tipos:

• Casos borde. El modelo hacía bien el cambio principal pero fallaba entre 1 y 4 chequeos: un correo que llega solo con espacios, un aviso que no incluía el estado, una lista que no debía modificarse.
• No terminar el trabajo. En una tarea hizo el diagnóstico correcto, escribió un plan y terminó preguntando si debía proceder. Nadie le iba a contestar: estaba corriendo solo. En otras tres repitió la misma acción hasta que el agente lo cortó.

¿Cambiar de agente mejora el resultado?

No mucho. Con el mismo modelo (Qwen3.6), el autor probó cinco agentes sobre una batería corta de 8 tareas: Qwen Code resolvió 3, Codex CLI 3, Claude Code apuntado al modelo local 2, OpenCode 2 y mini-swe-agent —un agente mínimo que solo ejecuta comandos— 2. Todos quedaron entre 2 y 3 de 8. Cinco de las ocho tareas no las resolvió nadie, con ningún agente y con ninguno de los dos modelos.

El dato incómodo: Claude Code conectado a un modelo local no rescata nada. Rindió igual o peor que el agente propio de Qwen. Lo que hace funcionar a Claude Code en esos proyectos es Opus 5.5, no solo el agente.

Pasar los tests no es lo mismo que tener la tarea lista

El autor usó Opus 5.5 como juez para clasificar cada intento en cuatro categorías: listo para aceptar, casi (menos de 30 minutos de ajuste), rehacer o basura. Los dos modelos resolvieron las mismas tareas, pero el 27B entregó 3 listas para aceptar y Qwen3.6 solo 1 —a cambio, el 27B tardó 47 minutos de agente por tarea contra 6 minutos de Qwen3.6. En la batería completa de 27 tareas, Qwen3.6 dejó 2 listas y 16 para rehacer.

La conclusión práctica: cuántos tests pasó te dice poco. Lo que te dice cuánto te cuesta la tarea es cuánto trabajo queda después.

¿Qué significa esto para tu startup?

1. Usa los benchmarks para descartar, no para elegir. Un modelo que saca 50-60% en un ranking público puede darte 22% en tu código. Sirven para armar la lista corta, no para decidir.
2. Mide con tus propios commits antes de comprometer presupuesto. Es la única señal que refleja tus convenciones, tu deuda técnica y tus casos borde.
3. Separa delegar de supervisar. Ninguna combinación local sirvió para delegar sin revisar. Para cambios chicos y acotados que revisas de inmediato, un modelo local es viable; para trabajo autónomo, hoy no.
4. Cuida el tráfico de tu código. En el experimento, un agente llamado Pi ignoró la variable de conexión y llamó a la API de OpenAI con una clave falsa: el enunciado de cuatro tareas salió de la red local antes del rechazo. Si vas a darle código privado a un agente nuevo, haz primero una prueba con algo inocuo y confirma que el tráfico va a tu servidor.

Y una advertencia de mantenimiento: de los siete agentes que el autor sumó a Qwen Code, tres no se pudieron medir porque los adaptadores de Hermes, Pi y OpenHands estaban rotos o desactualizados. Los agentes cambian más rápido que las herramientas que los evalúan.

¿Cómo probar tu propio código en una tarde?

El método es el mismo que usa SWE-bench, aplicado a tus repositorios:

• Saca 8 a 10 commits recientes que traigan un test.
• Vuelve cada uno al estado anterior al commit.
• Dale al agente el enunciado del cambio, sin la solución.
• Antes de medir nada, confirma que el test pasa con la solución real y falla sin tocar nada. Las tareas que no cumplan eso quedan fuera.
• Cuenta cuántas resuelve y, después, cuánto te cuesta dejar cada una lista para aceptar.

Dos advertencias sobre el sesgo: los repositorios del experimento tienen historia corta (semanas, no años), buena parte del código y de los tests los escribieron agentes, y 11 de las 15 tareas de PHP preparadas eran del mismo módulo de correos. Si tus repos son más viejos y más grandes, espera resultados peores, no mejores.

El contexto ayuda a calibrar expectativas. Nvidia sostiene que las descargas de modelos locales ya son cinco veces las de todo el año pasado, y en una presentación mostró Qwen3.8-Flash-Next corriendo en un RTX Spark de 128 GB con 40 puntos en el índice de Artificial Analysis, frente a los 41 que tenía Claude Opus 4.7 Max en la nube seis meses antes, según recogió WWWhat's New. La brecha se está cerrando. Pero casi igual en un índice y me sirve para delegar en mi repositorio siguen siendo dos cosas distintas.

Fuentes

• Mejor IA para programar: los benchmarks no ven tu código (fuente original)
• AI Coding Benchmark Scores Are Inflated by Answer Retrieval, Cursor Study Finds
• DeepSWE - Best Benchmark For Evaluating AI Coding Agents?
• Mac Studio M5 Ultra vs NVIDIA DGX Spark
• RTX Spark llega a las tiendas