Programación difícil en repositorios reales con IA local

En repositorios de 10 a 15 archivos con dos fallos que interactúan, varios modelos locales aprueban 9 o 10 de 10 en el Banco IT Lab. Las diferencias entre ellos quedan dentro del ruido y la velocidad de generación no predice el acierto.

• Con dos repeticiones, cuatro de los cinco modelos medidos obtienen 9 o 10 de 10; la diferencia entre 9 y 10 no establece un orden.
• El modelo más rápido (115,3 tok/s) obtiene 7 de 10; los que llegan a 10 de 10 generan a unos 40 tok/s.
• A juicio de IT Lab, el mantenimiento de código existente es una tarea que un modelo local de 16 GiB ya puede asumir con revisión humana.

La pregunta de negocio

Un equipo de desarrollo de una pyme dedica buena parte de su semana a mantener código que ya existe, no a escribir aplicaciones nuevas. La pregunta es si un modelo que corre dentro de la empresa, sin enviar el código a un tercero, puede localizar y corregir fallos en un repositorio de tamaño realista. Un ejercicio corto y aislado no responde esa pregunta; por eso esta familia de pruebas usa repositorios completos.

Qué mide la prueba y por qué representa trabajo real

La familia de programación realista mide si un modelo resuelve, sin ayuda, repositorios de 10 a 15 archivos con fallos que interactúan entre sí, en varios lenguajes.

Es trabajo de mantenimiento reconocible: entender un conjunto de archivos, encontrar más de una causa, corregirlas todas y no dañar lo que funciona. El contenido de los casos no se publica. El formato de entrega es fijo: cada archivo modificado se devuelve completo, rotulado con su ruta.

Cómo se aprueba

Aprueba el caso un juez automático y fijo: programas deterministas, sin un modelo evaluando a otro. El juez avanza por etapas y se detiene en la primera que falla, de modo que el resultado indica dónde se rompió el trabajo.

El protocolo aplica además una escalera de razonamiento. Cada caso parte del nivel más bajo de razonamiento que ofrece el modelo y sube al siguiente solo si ese caso falló; los casos aprobados no se repiten en niveles superiores. La regla separa dos preguntas: cuántos casos resuelve un modelo y cuánto razonamiento, tiempo y tokens necesita para resolverlos.

Resultados

Diez casos por modelo: cinco repositorios, dos repeticiones con semilla fija. Umbral de aprobación: el juez por etapas descrito arriba, caso por caso. Banco IT Lab, edición 1. Velocidad: mediana de la segunda repetición, registrada por el servidor de inferencia.

Qwen3.8-27B-GSQ-RCO y Muse-Glimmer-30B empatan en 10 de 10, y Swift 1.5 y gpt-oss 20B en 9 de 10. Con dos repeticiones, varios casos cambian de resultado entre una y otra, de modo que 9 contra 10 es una diferencia dentro del ruido y IT Lab no declara un ganador entre ellos.

Swift 1.5 es un modelo aparte y se informa por separado.

La velocidad no predice el acierto

Gemma-4-26B-A4B genera a 115,3 tok/s, la velocidad más alta de la tabla, y obtiene 7 de 10: su resultado se repite en las dos repeticiones. Los modelos que llegan a 10 de 10 generan a unos 40 tok/s. gpt-oss 20B, también rápido, escribe entre 18.000 y 41.000 tokens por intento en los casos difíciles; más tokens no significó una mejor solución, sino más esfuerzo.

La métrica relevante para una empresa es el tiempo hasta una solución correcta y el número de reintentos que cuesta, no los tokens por segundo. Las cifras de tiempo total de las corridas no se publican en esta edición.

La escalera como regla de operación

La columna de niveles de la tabla muestra por qué el puntaje solo no basta. Dos modelos con el mismo puntaje pueden diferir en cuánto razonamiento consumen: uno resuelve casi todo en el nivel bajo con salidas cortas; otro necesita el nivel alto en más casos. Swift 1.5 llega a 9 de 10 porque necesitó el nivel máximo en un caso.

Para una empresa, la regla se traduce así: empezar con razonamiento bajo y subir solo cuando el caso lo exige. Razonar más corrige fallos, pero cuesta tokens y minutos de GPU; usarlo siempre multiplica el costo sin necesidad.

Tres clases de falla

El banco clasifica cada caso no aprobado según de quién es la causa:

• Error del modelo. El modelo entrega código incorrecto o incompleto: por ejemplo, corrige parte de los fallos y deja otra sin tocar.
• Defecto del instrumento. El caso o el juez estaban mal calibrados. Estos casos se corrigen y se rejuzgan; un resultado contaminado por el instrumento no se usa como conclusión de calidad.
• Formato, límite o transporte. El código es correcto, pero el formato de entrega no lo es, o la corrida choca contra un límite. Cuando el código extraído pasa las pruebas y el formato falla, el banco informa ambos resultados por separado en lugar de fabricar una sola cifra.

Esta separación evita descartar un modelo por un problema que era de la medición y permite a una empresa distinguir un fallo de comprensión de uno de presentación.

Qué implica para una empresa chilena

• Qué automatizar. A juicio de IT Lab, la corrección de fallos en código existente es una tarea que los modelos locales evaluados abordan con resultados altos en esta prueba.
• Qué revisar. Todo cambio que proponga un modelo debe pasar por la compilación y las pruebas del propio proyecto, y el formato de la respuesta debe validarse antes de aplicarla.
• Qué hardware. Las mediciones corresponden a una tarjeta de 16 GiB, con cuantización de 3 o 4 bits.
• Cómo decidir. Medir tiempo hasta la solución correcta y reintentos, y fijar la regla de subir el razonamiento solo cuando el caso lo exige.

Preguntas frecuentes

¿Puede una IA local corregir fallos en el código de una pyme? En repositorios de 10 a 15 archivos con dos fallos que interactúan, varios modelos locales aprueban 9 o 10 de 10 en el Banco IT Lab.

¿Un modelo más rápido programa mejor? No: el modelo más rápido (115,3 tok/s) obtiene 7 de 10, y los que llegan a 10 de 10 generan a unos 40 tok/s.

¿Qué hardware hace falta y se requiere revisión? A juicio de IT Lab, el mantenimiento de código existente es una tarea que un modelo local de 16 GiB ya puede asumir con revisión humana.

Limitaciones y alcance

• Dos repeticiones por modelo y caso; 9 contra 10 es una diferencia dentro del ruido y no establece un orden.
• La pasada oficial se separa de las sondas y los diagnósticos.
• Tope de memoria de la GPU en las campañas normales: 15,5 GiB.
• "Razonamiento desactivado" no es homogéneo entre familias de modelos: no se comparan esos niveles entre familias.
• El banco no mide costos. Operar IA local implica costos reales (energía, inversión inicial en hardware, mantención y tiempo) y a juicio de IT Lab, los precios actuales de los servicios de pago pueden no reflejar su costo real.
• Medición de IT Lab sobre un único equipo; no es una recomendación de compra ni una certificación.

Ficha de medición

• Equipo: las mediciones se realizaron en un equipo que IT Lab definió y armó específicamente para pruebas: procesador Ryzen 7 5700X, 31 GiB de RAM y una tarjeta gráfica AMD Radeon RX 9070 XT de 16 GiB, con Linux. La tarjeta se eligió por ser hoy la opción más asequible con buena relación costo-beneficio que una empresa pequeña puede comprar. Los modelos evaluados cuentan con versiones optimizadas para tarjetas NVIDIA, por lo que se espera que el patrón general sea comparable en ese hardware; las cifras publicadas corresponden a este equipo.
• Cuantización: de 3 o 4 bits, según el modelo.
• Tope de memoria de GPU: 15,5 GiB en campañas normales.
• Pasadas: dos repeticiones con semilla fija.
• Banco IT Lab, edición 1.

Informe técnico relacionado: Informe técnico 2: Código

Método completo: Cómo evalúa IT Lab un modelo de IA local

Contacto: IT Lab evalúa modelos de IA local sobre el código y los datos de organizaciones chilenas. Conversemos

El Banco IT Lab es un instrumento vivo, en perfeccionamiento continuo. Parte de las mediciones proviene de versiones previas del instrumento y de modelos de generaciones anteriores, y algunas cifras pueden contener imprecisiones que se corrigen en cada nueva edición. Las conclusiones expresan el criterio de IT Lab a partir de sus propias mediciones.