Flint: un modelo de programación local para tu portátil

Un modelo de programación local que va en serio

Llevo tiempo esperando un modelo de programación local que no se quede en una curiosidad. Ayer Recursive presentó Flint, y por fin parece uno de los que puedes usar a diario: abierto, rápido y pensado para trabajar como agente de código en tu propio portátil, sin mandar el código a ningún sitio.

Qué es Flint

Es un modelo de mezcla de expertos (MoE): tiene unos 40.000 millones de parámetros, pero en cada token solo trabajan unos 2.500 millones. Por eso es tan ligero y tan rápido. Para hacerse una idea de la escala: Muse Spark Open, el modelo abierto de Meta para Mac que salió la semana pasada, usa 816.000 millones de parámetros y pide al menos 1 TB de memoria.

Algunos datos de la ficha en Hugging Face:

• Licencia Apache 2.0, así que puedes usarlo y adaptarlo sin pedir permiso.
• Pensado para agentes de código: investigar un repositorio, arreglar bugs, implementar funcionalidades y escribir tests.
• Soporta razonamiento y llamadas a herramientas en formato compatible con OpenAI.
• Recursive recomienda trabajar con hasta 256.000 tokens de contexto, aunque admite más.

Cuánto corre

Según Recursive, en un MacBook Pro con M4 Pro saca más de 125 tokens por segundo, y en una NVIDIA RTX Spark de 64 GB más de 150, con contextos cortos. En la nota de TechCrunch lo comparan con modelos parecidos en la misma máquina, que se quedan entre 58 y 69. Para escribir código con un agente, esa velocidad cambia mucho la experiencia.

Lo que dicen los benchmarks

Recursive dice que Flint es el mejor modelo MoE de menos de 50.000 millones de parámetros en benchmarks de código con agentes, y en la ficha da un 74,2 % en SWE-bench Verified. Son cifras de la propia empresa, así que yo las tomaría como una señal y no como un veredicto. Me fío más de lo que cuente la gente cuando lo use en sus proyectos.

Dónde flojea (y lo dicen ellos)

Lo que más me ha gustado del anuncio es su honestidad. Recursive dice que Flint puede necesitar más guía que los modelos cerrados grandes, y recomienda partir las tareas complejas en subtareas más pequeñas, con instrucciones explícitas.

Para mí esto es la clave. Un modelo así no te va a sacar un proyecto entero a partir de una frase vaga. Pero si le das una tarea pequeña, bien definida y con criterios claros, tiene todo lo necesario para hacerla bien. Es exactamente lo que defiendo con Spec-Driven Development: trocear el trabajo y escribir lo que hay que construir antes de que el agente empiece. Lo contaba en vibe coding vs SDD.

Cómo lo usaría yo como agente de código

• Elige bien la herramienta. Recursive dice que funciona con llama.cpp, Ollama, Unsloth, LM Studio, vLLM y SGLang, y además saca su propio motor, rec, optimizado para M4 Pro y M5 Pro/Max.
• Ojo con la versión que bajas. El checkpoint completo de Hugging Face pesa unos 80 GB y está pensado para una GPU de servidor. Para el portátil, Recursive prepara versiones cuantizadas aparte.
• Dale tareas acotadas. Una spec corta por tarea, con lo que tiene que hacer y cómo sabrás que está bien.
• Revisa lo que haga. La propia ficha avisa de que puede generar código con fallos o elegir mal una herramienta, y recomienda poner tus propios permisos y límites de ejecución.

Por qué me importa

Para muchos equipos, el freno para usar agentes de código no es técnico: es no poder mandar el código fuera, o no saber cuánto va a costar. Un modelo local que rinde bien quita esos dos frenos de golpe. No va a sustituir a los modelos grandes en las tareas difíciles, pero sí puede encargarse de mucho trabajo del día a día sin salir de tu máquina.

Lo que me llevo

Flint me confirma algo que veo cada semana: cuanto mejor defines el trabajo, menos importa el tamaño del modelo. Si tu equipo quiere usar agentes de código sin sacar el código de casa, en onext te ayudamos a montarlo. Y si lo pruebas antes que yo, cuéntame qué tal.