Informe técnico 2: IA local para escribir código

Código: ITL-IT-03 · Banco IT Lab, edición 1

Resumen

Este informe reúne las tres familias de pruebas de código del Banco IT Lab: código sobre base existente, código desde cero y programación realista. Las dos primeras usan una aplicación compuesta por un motor en Rust y una API web en Ruby on Rails, y un juez automático por etapas que se detiene en la primera que falla. La tercera usa repositorios de 10 a 15 archivos con fallos que interactúan, y se mide en dos repeticiones.

Sobre una base con huecos marcados, tres de diez modelos locales superan las seis etapas en 17 a 43 segundos. Desde cero, ninguno de los diez modelos locales supera el criterio, mientras que dos modelos de pago sí lo superan. En programación realista, dos modelos locales obtienen 10 de 10 y otros dos 9 de 10, diferencias que quedan dentro del ruido de dos repeticiones; la velocidad de generación no predice el acierto. A juicio de IT Lab, los resultados respaldan usar modelos locales para completar y mantener código con revisión, y exigir revisión obligatoria cuando el modelo crea código desde cero.

1. Introducción y pregunta

Una empresa que desarrolla software se pregunta si un modelo que corre en su propio equipo, sin enviar el código a un tercero, puede asumir trabajo de programación y en qué condiciones. La pregunta tiene al menos tres formas distintas, y el Banco IT Lab las separa porque las respuestas no coinciden.

La primera es completar una base que ya existe: un sistema funcional al que le faltan piezas, con pruebas ya escritas. Es el trabajo de mantenimiento y de extensión. La segunda es crear una aplicación desde cero, sin esqueleto, donde el modelo debe decidir la estructura además de escribir la lógica. La tercera es resolver fallos reales en repositorios de tamaño medio, donde dos defectos se influyen entre sí y hay archivos que no deben tocarse.

El informe responde tres preguntas de negocio. Primero, qué fracción de los modelos locales evaluados completa una base existente y con qué rapidez. Segundo, qué ocurre cuando se retira el esqueleto y cómo se compara con lo que logra un modelo de pago. Tercero, qué determina el acierto en repositorios realistas: la velocidad, el nivel de razonamiento o la forma de entregar el resultado. El método general del banco se describe en el Informe técnico 4; los artículos de sitio Código: completar vs crear y Programación difícil en repositorios reales resumen estas conclusiones para un lector de negocio.

2. Método

Familias de prueba

Código sobre base existente. Se entrega a cada modelo un sistema con un motor en Rust y una API web en Ruby on Rails, con la lógica de varios huecos marcados sin implementar. El modelo debe completar las piezas faltantes en los dos lenguajes. Los archivos de prueba los fija el laboratorio y el instrumento invalida las corridas que no respetan las reglas de entrega.

Código desde cero. Se entrega solo un encargo y ningún esqueleto. El modelo debe crear los archivos del motor y del puente web, entregar exactamente los archivos pedidos y dejar un sistema que compile y supere las pruebas. Las mismas reglas de entrega invalidan la corrida si no se respetan.

Programación realista. Repositorios de 10 a 15 archivos con fallos que interactúan entre sí, en varios lenguajes. Esta familia se apoya en una etapa previa de casos realistas más pequeños, que sirve de referencia y se informa aparte. El modelo entrega cada archivo completo en un formato fijo, y la entrega se juzga por su contenido ejecutado, no por su apariencia.

Juez automático por etapas

En las dos primeras familias el juez es un programa determinista, sin un modelo que evalúe a otro, y avanza por etapas encadenadas (compilación, comportamiento, pruebas de la capa web y prueba de extremo a extremo) que se detienen en la primera que falla. Sobre base existente son seis etapas; desde cero, cinco.

El diseño convierte el suspenso en diagnóstico. "No entregó archivos" es distinto de "no compila", que es distinto de "compila pero incumple el comportamiento pedido" y de "el motor funciona pero la capa web falla". El resultado de cada modelo se informa, por tanto, como la cantidad de etapas superadas y la causa de la primera falla, no como una nota única. Una salida truncada por límite, o un razonamiento que consume todo el presupuesto de generación, no recibe una penalización parcial: simplemente no existe entrega.

El juez por etapas solo permite comparar dentro del mismo encargo y con el mismo juez. Un resultado aprobado en este sistema no equivale a "aprobado en Rust" en general.

Criterio de aprobación

El criterio lo fija el juez antes de la corrida. En las dos primeras familias, un modelo aprueba si supera todas las etapas. En programación realista, el veredicto de cada caso es aprobado o no aprobado según pruebas visibles y ocultas que se ejecutan de forma determinista; el puntaje es la cantidad de casos aprobados sobre el total de las repeticiones. El instrumento no se modifica para favorecer a un modelo.

Mejor oportunidad para cada modelo

El protocolo exige investigar la documentación de cada modelo y usar sus mejores parámetros y su mejor forma de instrucción. En programación realista, además, se revisó la configuración de cada modelo antes de la segunda repetición y se confirmó que fuera la óptima para ese modelo. La misma tarea se entrega a todos; la diferencia entre formas de instrucción es parte de lo que se mide, no un defecto del banco.

Escalera de razonamiento

En programación realista, cada caso comienza en el nivel de razonamiento más bajo que ofrece el modelo y solo sube al nivel siguiente si ese caso falló. Los casos ya aprobados no se repiten en niveles superiores. La regla convierte la pregunta vaga de qué tan capaz es un modelo en dos preguntas medibles: cuántos casos resuelve y cuánto razonamiento, tiempo y tokens necesita para resolverlos.

Tres clases de falla

Cada falla se clasifica según de quién es la responsabilidad. La clase (a) es un error real del modelo. La clase (b) es un defecto del instrumento, ya sea del caso o del juez. La clase (c) es de formato, de límite o de transporte. La clasificación separa un modelo que escribe código incorrecto de un instrumento que cambia las reglas durante la medición.

Controles de calidad del instrumento

Se aplican los controles generales del banco: control de memoria de la GPU y declaración explícita del número de pasadas. En estas pruebas el tope de memoria de la tarjeta fue de 15,5 GiB.

3. Resultados

Código sobre base existente, pasada oficial

Una pasada por modelo. Criterio de aprobación: seis etapas superadas. Banco IT Lab, edición 1.

Tres de diez modelos locales superan las seis etapas, en un rango de 17 a 43 segundos. Dos modelos se detienen en las pruebas web, a una etapa de aprobar; uno se detiene en el comportamiento del motor; dos no compilan; y dos no entregan archivos por razones distintas. En el caso de GPT-OSS-20B, el juez registra una salida agotada antes de escribir archivos, una falla de presupuesto y no de comprensión. En el de DeepSeek-Coder-V2-Lite, la ausencia de archivos se produce en 6,4 segundos. El juez por etapas separa ambos casos; una nota numérica los habría confundido.

Un ensayo de modo equipo, con varios agentes coordinados, se realizó solo con dos modelos locales, ya que el resto del lote no llegó a entregar. Ninguno de los dos aprobó: uno se detuvo en el comportamiento del motor y el otro no compiló. El ensayo no es concluyente, porque tiene una pasada por modelo.

Código desde cero, pasada oficial: modelos locales

Una pasada por modelo y configuración. Criterio de aprobación: cinco etapas superadas. Banco IT Lab, edición 1.

Ninguno de los diez modelos locales supera el criterio. El más avanzado compila, pero incumple el comportamiento pedido al motor: el código existe y no hace lo que se le pidió. Entre los que no dejan archivos, el de mayor tiempo de pared, 395,6 segundos, no alcanza ninguna etapa; el gasto de tiempo no compró resultado.

Código desde cero, pasada oficial: modelos de pago

Una pasada por modelo y configuración, salvo la fila indicada. Criterio de aprobación: cinco etapas superadas. Banco IT Lab, edición 1. "Sin razonar" indica razonamiento desactivado, que no es comparable entre familias de modelos.

Sonda: razonamiento forzado en modelos locales

Sonda, no pasada oficial. Se repitió el encargo desde cero con razonamiento de nivel medio en cinco modelos locales, en dos tandas, para un total de diez corridas. En todas el contenido entregado fue de cero caracteres: el razonamiento consumió el presupuesto completo de salida y el modelo no escribió ningún archivo. Subir el razonamiento no mejoró el resultado; lo dejó en cero.

Sonda: contenido sin la envoltura de formato

Sonda, no resultado oficial. Los dos resultados no aprobados de mimo-v2.6-flash corresponden al formato de entrega y no al código. Al retirar la envoltura de formato y juzgar el mismo contenido, el modelo superó las cinco etapas. La sonda no modifica el resultado oficial de la tabla de modelos de pago; muestra que existen dos formas de no aprobar un examen de código y que no son el mismo problema: el conocimiento puede estar completo y la entrega rota.

Programación realista: casos realistas menores

Una pasada por modelo. Criterio de aprobación: caso aprobado por el juez automático. Casos realistas de uno o dos archivos tocados, que anteceden a la serie difícil. Banco IT Lab, edición 1.

Los cuatro modelos más fuertes aprueban todos los casos; lo que cambia entre ellos es cuánto razonamiento necesitan, no el puntaje.

Programación realista: serie difícil, dos repeticiones

Dos repeticiones sobre cinco casos, es decir, diez corridas por modelo. Criterio de aprobación: caso aprobado por pruebas visibles y ocultas. Banco IT Lab, edición 1. Las columnas de nivel y velocidad son las agregadas de la segunda repetición.

Los casos aprobados y los fallidos se informan con el resultado final del juez. No se publica el tiempo total hasta la solución de cada modelo, porque las dos fuentes disponibles de ese dato no coinciden y no se informa una cifra que no se pueda sostener.

Clases de falla observadas

En las cuatro etapas de programación, los fallos de transporte son prácticamente inexistentes; la clase (c) vive sobre todo en el formato. Un caso queda excluido de las conclusiones limpias de calidad porque el defecto del instrumento (b) lo contamina.

Hay además un caso frontera entre las clases (a) y (c): dos variantes del mismo modelo produjeron un bloque de código sin cerrar y al extraer el código intacto, ese mismo código superaba las pruebas visibles y ocultas. La decisión es conservar el fallo contractual de formato e informar por separado el éxito del código, en lugar de producir una sola cifra. El mismo resultado puede leerse como 1 de 3 o como 2 de 3 según qué se cuente, y el informe lo declara.

4. Discusión

Qué es señal

Completar supera a crear. Sobre una base existente con pruebas fijas, tres de diez modelos locales aprueban y en menos de un minuto cada uno. Desde cero, ninguno de los diez aprueba y los modelos de pago sí. A juicio de IT Lab, la diferencia entre ambas familias es una señal robusta, porque es de diez modelos a cero y se repite en estructura (tres de diez frente a cero de diez), aunque cada familia tenga una sola pasada por modelo.

El razonamiento forzado no es una palanca universal. En el encargo desde cero, subirlo dejó el contenido entregado en cero caracteres en diez corridas. En programación realista, la escalera lo usa solo cuando el caso lo exige. La regla operativa que IT Lab deriva es subir el nivel solo cuando el caso lo exige y medir el tiempo y los tokens que cuesta.

La velocidad de generación no predice el acierto. El modelo de mayor velocidad mediana, 115,3 tok/s, obtuvo 7 de 10, y dos modelos de alrededor de 40 tok/s obtuvieron 10 de 10. El segundo mayor en velocidad, de 87,5 tok/s, escribe entre 18.000 y 41.000 tokens por intento en los casos difíciles de nivel alto y obtuvo 9 de 10: más tokens no fue una mejor solución, sino más esfuerzo. La métrica pertinente para una decisión de trabajo es el tiempo hasta una solución correcta y la cantidad de reintentos que cuesta, no los tokens por segundo.

La entrega pesa tanto como el código. El modelo que no aprobó por formato superó las cinco etapas al retirar la envoltura; los modelos con formato descuidado pierden casos que tenían resueltos. Una parte relevante de los fallos que una organización atribuiría a "la IA" son, en el banco, fallos de integración o de instrumento.

Qué es ruido

En programación realista, 10 de 10 frente a 9 de 10 no establece un orden. Con dos repeticiones y casos que cambian de resultado entre ellas, IT Lab considera las diferencias entre Qwen3.8-27B-GSQ-RCO, Muse-Glimmer-30B, Swift 1.5 y gpt-oss-20B dentro del ruido de dos repeticiones. Este informe no declara una clasificación entre ellos ni un modelo elegido por IT Lab. Sí es una señal que el modelo con 7 de 10 falla de manera estable el mismo caso, con el mismo patrón, en las dos repeticiones.

Tampoco se interpretan como diferencias de capacidad las de tiempo de una sola pasada entre modelos de pago, ni las diferencias de una etapa entre modelos locales de la familia de base existente, que tienen una sola pasada.

5. Implicancias para organizaciones con recursos acotados

Para completar y mantener código sobre una base existente, a juicio de IT Lab hay modelos locales que aprueban la tarea en menos de un minuto, con pruebas de comportamiento incluidas y sin que el código salga de la infraestructura de la empresa. La condición es que existan pruebas fijas que decidan si el trabajo está bien, y que una persona revise el cambio como lo haría con cualquier otro.

Para crear módulos desde cero, el resultado local es cero de diez. IT Lab recomienda que la creación desde cero sea una tarea de revisión obligatoria, o que se delegue en un modelo de pago cuando la política de datos lo permita. En ese caso, la decisión es de riesgo y de volumen: si el código puede salir hacia un proveedor, cuántas veces se repite la tarea y qué ocurre si falla.

Para quien mantiene repositorios realistas con varios archivos y fallos que interactúan, hay modelos locales que obtienen 10 de 10 en una GPU de 16 GiB. Antes de descartar un modelo por un mal resultado, la organización debería comprobar si el problema fue del código o de la forma de entregarlo; y antes de subir el razonamiento "para que mejore", medir lo que cuesta.

Preguntas frecuentes

¿Puede una IA local escribir código? Sobre una base con huecos marcados, tres de diez modelos locales superan las seis etapas en 17 a 43 segundos. Desde cero, ninguno de los diez lo logra.

¿La velocidad de generación predice el acierto? No: el modelo de mayor velocidad mediana, 115,3 tok/s, obtuvo 7 de 10, y dos modelos de unos 40 tok/s obtuvieron 10 de 10.

¿Qué recomienda IT Lab? Usar modelos locales para completar y mantener código con revisión, y exigir revisión obligatoria cuando el modelo crea código desde cero.

¿Cuánto cuesta una IA local? 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.

6. Limitaciones y alcance

• Código sobre base existente y desde cero tienen una sola pasada por modelo; las diferencias pequeñas, incluida la de una etapa, son ruido. Programación realista usa dos repeticiones, con diferencias dentro del ruido.
• La pasada oficial se informa aparte de las sondas y los diagnósticos, rotulados como sondas en la sección de resultados.
• Tope de memoria de la GPU: 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.
• El juez por etapas solo permite comparar dentro del mismo encargo y con el mismo juez; el resultado no se extrapola a Rust, a Ruby ni a programación en general.
• Los tiempos totales de la serie difícil no se publican, porque no coinciden entre las fuentes.
• El ensayo de modo equipo tiene dos modelos y una pasada: no es concluyente.
• Los resultados son de una medición de IT Lab sobre un único equipo; no son una recomendación de compra ni una certificación.

7. Conclusiones

1. Sobre una base existente con huecos marcados, tres de diez modelos locales superan las seis etapas en 17 a 43 segundos. A juicio de IT Lab, completar y mantener código es viable hoy con modelos locales en hardware accesible.
2. Desde cero, ninguno de los diez modelos locales supera el criterio, y dos modelos de pago sí.
3. En programación realista, varios modelos obtienen 9 o 10 de 10 y las diferencias están dentro del ruido de dos repeticiones. La velocidad de generación no predice el acierto.
4. La escalera de razonamiento, que sube de nivel solo cuando el caso lo exige, es la regla operativa que IT Lab adopta. El razonamiento forzado en bloque puede dejar el resultado en cero.
5. Las fallas se clasifican en error del modelo, defecto del instrumento y formato, límite o transporte. Una parte importante de los fallos observados no es del modelo, y el banco las separa.

Anexo: ensayos de orquestación multiagente

Este anexo es breve, porque la evidencia procede de ensayos exploratorios con una pasada por modelo.

Se ensayó una jerarquía de roles sobre un único modelo local, con historiales y presupuestos separados: un coordinador que planifica y decide al final, un integrador que descompone el encargo, un constructor que escribe el código, un revisor que busca defectos con severidades y un reparador que actúa solo si el revisor lo pide. El flujo tiene siete fases, y la reparación es condicional.

La mecánica funciona cuando el modelo responde en un formato estructurado fiable: ocho de diez modelos terminan su corrida y el coordinador acepta el resultado en cinco. El cuello de botella no es la capacidad del modelo, sino el formato. En las matrices tempranas, 14 de los 17 fallos listados fueron errores de decodificación del formato estructurado. Tras validar una reparación de formato determinista, los fallos listados bajaron de 17 a 13 en lotes del mismo tamaño: una mejora real, y lejos de ser suficiente.

Orquestar más no compensa a un modelo que no sabe programar. En el encargo desde cero, el único modelo que completó las 13 de 13 fases del bucle entregó un esqueleto vacío, que el juez detuvo en la segunda etapa; los demás no llegaron a entregar. En la familia de base existente, los dos modelos probados en modo equipo no aprobaron. A juicio de IT Lab, el modo equipo no queda incorporado al banco con este nivel de evidencia.

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 local.
• Tope de memoria de GPU: 15,5 GiB.
• Pasadas: una por modelo y configuración en código sobre base existente y desde cero; dos repeticiones en programación realista.
• Banco IT Lab, edición 1.

Cómo citar

IT Lab, Informe técnico ITL-IT-03, Banco IT Lab, edición 1.

Artículos relacionados: Código: completar una base existente vs crear desde cero · Programación difícil en repositorios reales · Método: Informe técnico 4: Metodología del Banco IT Lab

Contacto: IT Lab evalúa modelos de IA local para organizaciones chilenas con su propio código y sus propios datos. 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.