Un modelo local no sirve para programar porque escriba bonito. Sirve cuando atraviesa un flujo real: leer contexto, llamar herramientas, entender errores, corregir bugs y dejar evidencia que puedas verificar.
Más allá del buen texto
Muchos modelos pueden explicar código con seguridad. Menos modelos pueden operar dentro de un proyecto sin romperlo. La diferencia está en si sostienen el ciclo completo: inspección, hipótesis, cambio, ejecución, error, ajuste y reporte.
Tool-calls como prueba de realidad
Un tool-call obliga al modelo a tocar el mundo: leer un archivo, correr una prueba, consultar un log, revisar un diff. Ahí se cae el asistente que improvisa. Si no puede interpretar resultados y cambiar de estrategia, no está listo para trabajo serio.
| Capacidad | Pregunta de evaluación | Señal PASS |
|---|---|---|
| Lectura de contexto | ¿Encuentra el archivo correcto sin adivinar? | Cita rutas y líneas reales. |
| Ejecución | ¿Corre pruebas o comandos relevantes? | Reporta output real, no inventado. |
| Corrección | ¿Ajusta después del error? | Explica causa y cambia el fix. |
| Cierre | ¿Deja evidencia? | Diff, test, screenshot o log verificable. |
Bugs reales y regresiones
nn
Un bug real casi nunca se arregla con una respuesta perfecta al primer intento. Hay que reproducir, aislar, cambiar lo mínimo y volver a ejecutar. Un modelo útil acepta esa disciplina; uno flojo salta directo a reescribir medio proyecto.
Contexto pesado sin perder el hilo
n
n
En proyectos grandes, el reto no es recordar todo: es priorizar. El modelo debe distinguir entre archivo relevante, ruido histórico, test crítico y detalle cosmético. Un contexto largo sin criterio solo aumenta el costo de equivocarse.
Escenarios reales para saber si un modelo local sirve programando
La prueba buena no es pedirle “haz una app”. Es darle un tramo verificable del pipeline y medir si cierra con evidencia.
| Escenario | Qué debe hacer el modelo | Señal de confianza |
|---|---|---|
| Bug con test fallando | Leer el error, ubicar archivo, cambiar lo mínimo y volver a correr tests. | No declara victoria sin output real. |
| Refactor pequeño | Mantener API, simplificar una función y no tocar lo que no entiende. | Diff corto y reversible. |
| Tool-call real | Consultar archivos, ejecutar comandos y usar el resultado. | No inventa rutas, logs ni métricas. |
| QA navegador | Abrir la UI, capturar evidencia visual y corregir overflow/estado roto. | Screenshot o reporte DOM después del fix. |
Mini protocolo de evaluación
- Dale un bug real con reproducción.
- Limita el scope a un archivo o módulo.
- Exige comando de verificación.
- Rechaza respuestas sin evidencia.
- Registra si mantuvo el contexto después del primer error.
Esto conecta con el criterio central de FreakingJSON: si no hay ejecución o evidencia, todavía es hipótesis.
Checklist para elegir modelo coding local
- Prueba con un bug real, no con un kata.
- Exige tool-calls y output verificable.
- Mide si mantiene contexto después de un error.
- Evalúa si propone cambios pequeños o reescrituras innecesarias.
- Revisa si sabe decir “esto no está probado”.
Relacionado: cómo leer benchmarks sin mezclar fases y IA local sin humo.
Preguntas frecuentes
¿Un modelo local puede reemplazar a un dev?
No. Puede tomar tramos del pipeline si hay pruebas, límites y revisión.
¿Qué pesa más: velocidad o precisión?
Para coding, precisión verificable. Velocidad sin tests solo acelera errores.
El criterio no es solo escribir código
Un modelo útil para programar también debe sostener contexto, pedir herramientas con precisión y sobrevivir una corrección real. Para ver dónde encaja en una estación local, consulta nuestro workflow de IA local. Como contraste, el hito de competición descrito en los modelos que alcanzaron el oro en ICPC no sustituye esta prueba de herramientas, bugs y contexto.
El conocimiento verdadero trasciende a lo público 🌀
¿Quieres seguir la línea de investigación? Continúa con artículos relacionados y guarda esta lectura para volver después.
Ver relacionados
