En el desarrollo con IA local-first, los modelos pueden vivir en la nube, pero el sistema que los rodea vive en tu máquina. La orquestación, el estado, la memoria entre sesiones, la verificación, el bucle de recuperación: eso corre en tu Mac. La inferencia es una llamada que haces fuera y un resultado que traes de vuelta.
Ese reparto no es un apaño. Es el diseño. Y me costó ver por qué es el correcto, porque la versión más ruidosa de “desarrollo con IA” hoy asume lo contrario: que todo, incluido el sistema que coordina el trabajo, pertenece a la pestaña del navegador de alguien.
Voy a defender el reparto tal como muerde de verdad, del dolor que sientes cada día al dolor que sientes una vez por trimestre.
Latencia: el impuesto que pagas en cada bucle
El bucle agéntico es apretado. Lee estado, decide, actúa, comprueba, actualiza estado, repite. Ejecutas ese bucle cientos de veces al día, y cada vez que el estado tiene que viajar a un servidor y volver, pagas el viaje de ida y vuelta.
No duelen los milisegundos en bruto. Duele lo que le hacen a tu atención. Una lectura local está por debajo del umbral en el que tu mente se va. Un viaje de red por la cola de otro, sujeto a sus rate limits una tarde con tráfico, suele estar por encima. Cruza ese umbral suficientes veces y dejas de estar en flow para ser una persona esperando pestañas.
Cuando el estado de la fábrica es un archivo SQLite en tu disco, la latencia entre “decidí esto” y “el agente puede verlo” es una lectura de disco. Lo único que esperas es el modelo, que ibas a esperar de todos modos. Todo lo demás es instantáneo porque todo lo demás es local. Esa es la diferencia que sientes primero, y la que decide si la herramienta desaparece dentro del trabajo o se sienta entre tú y él.
Coste: medido donde debe, gratis donde no
Aquí hay una distinción que el modelo de precios en la nube borra en silencio. Parte de lo que haces es caro de ejecutar —inferencia de modelo, de verdad—. La mayoría de lo que haces es barato: leer tus propias decisiones, navegar tu propio grafo, comprobar qué hizo un agente, reejecutar un gate. En una herramienta enteramente en la nube, todo eso está detrás del mismo contador, porque el almacenamiento, el cómputo y la coordinación son del proveedor y él los factura.
Local-first pone el contador solo donde está el coste real. La inferencia cuesta lo que cobra el proveedor, y lo pagas directo, con tu propia clave API, sin margen de plataforma encima. Todo lo demás —las lecturas, la coordinación, el estado— no cuesta nada por operación porque ocurre en hardware que ya tienes. Puedes navegar tu grafo de producto mil veces y es gratis. Enrutas el trabajo caro al modelo adecuado sin vendor lock-in, y mantienes el trabajo barato fuera de cualquier contador.
Esto también cambia lo que estás dispuesto a hacer. Cuando coordinar es gratis, coordinas con más cuidado. Cuando cada lectura se mide, lees menos, y tomas peores decisiones con menos contexto porque el contexto tiene precio. Las operaciones locales gratis no son un error de redondeo. Cambian tu comportamiento hacia el sistema.
Privacidad: una propiedad, no una promesa
Tu código es lo de menos. La fábrica guarda las partes que nunca pegarías en un canal público: la estrategia, las apuestas descartadas, las restricciones sensibles de seguridad, los criterios de aceptación que describen exactamente cómo se supone que funciona lo sensible.
Cuando eso vive en tu disco, la privacidad es una propiedad de la arquitectura. Nadie tiene que prometer no mirar, porque en su lado no hay nada que mirar. Tú decides, por llamada, qué fragmento de contexto va a qué proveedor. Por defecto, la forma de tu producto se queda en casa.
Quiero ser claro con el límite, porque la versión real es más útil que la de marketing. Cuando llamas a un modelo remoto, los tokens que envías van a ese proveedor, bajo sus términos. Local-first no hace que eso desaparezca. Lo que hace es convertirlo en una decisión que tomas a propósito, llamada a llamada, en vez de un valor por defecto donde todo tu espacio de trabajo se sincroniza sin parar a un servidor como precio de usar la herramienta. De eso va tratar la privacidad como decisión de arquitectura y no como una casilla: la pregunta deja de ser “¿confío en su política?” y pasa a ser “¿qué elijo enviar?”.
Control: el que muerde una vez por trimestre, pero muerde fuerte
La latencia te molesta a diario. El coste te da la lata cada mes. El control es el que olvidas hasta el día en que importa, y entonces importa del todo.
Un proveedor cambia su precio. Deprecia la función de la que dependía tu flujo. Lo compran y lo apagan. Cambia sus términos de una forma que no habrías aceptado si te preguntan. Se cae la tarde en que ibas a publicar. Cuando tu fábrica vive en su nube, cada una de esas es tu problema, y no tienes más jugada que aceptarlo o migrar a la fuerza.
Cuando la fábrica es local y abierta en sus límites —repositorios git normales, almacenamiento inspeccionable, modelos que puedes cambiar— ninguno de esos eventos puede quitarte el sistema. Que un proveedor desaparezca te cuesta ese proveedor, no la memoria de tu producto. Esta es la menos vistosa de las cuatro razones y la que me negaría a ceder. Poseer aquello sobre lo que construyes no es nostalgia; es la diferencia entre una herramienta y una dependencia a la que no le ves el fondo.
Qué no es local-first
No es maximalismo offline, ni la pretensión de que tu portátil haga la inferencia. Los modelos frontier corren en centros de datos por buenas razones, y fingir que un MacBook de 16 pulgadas compite con eso sería mentira. Local-first no es anti-nube. Es específico sobre qué partes van dónde.
La regla es simple. Lo que es genuinamente caro y genuinamente mejora con la escala —la inferencia— puede ser remoto. Lo que define tu producto y deberías poseer —el contrato, el grafo, las decisiones, la prueba— se queda local. No rechazas la nube. Te niegas a alquilar las partes que deberías poseer.
Y fíjate en que las cuatro razones se apilan en vez de competir. La misma decisión de diseño que te da latencia a velocidad de disco es la que mantiene la coordinación fuera de un contador, la forma de tu producto fuera de un servidor y el mal día de un proveedor lejos del tuyo. No cambias una por otra. Poner el sistema en tu máquina compra las cuatro a la vez, y por eso local-first es una sola decisión y no cuatro features separadas que tienes que ensamblar.
Dónde encaja PaellaDoc
PaellaDoc es la fábrica local de software construida local-first justo por estas cuatro razones. Corre sobre herramientas nativas de macOS, mantiene tu grafo de producto, tus repositorios y tu evidencia en almacenamiento local en tu máquina, y llama a los modelos que elijas —proveedores en la nube con tus propias claves, o motores locales— sin enrutar tu espacio de trabajo por el servidor de nadie. Gratis hasta tres proyectos, sin cuenta.
Los modelos seguirán mejorando, y seguirán viviendo en centros de datos. Está bien. El sistema que convierte un modelo en una fábrica —la parte que planifica, recuerda, verifica y recupera— es la parte que debería vivir donde puedas verla, en la máquina que tienes delante.
Preguntas frecuentes
¿Qué significa desarrollo con IA local-first?
El desarrollo con IA local-first mantiene el sistema que rodea a los modelos en tu máquina mientras los modelos siguen siendo remotos. La orquestación, el estado, la memoria entre sesiones, la verificación y la recuperación corren en tu Mac; la inferencia es una llamada que haces fuera y un resultado que traes de vuelta. El reparto es deliberado. La parte cara que mejora con la escala puede ser remota, y las partes que definen tu producto se quedan locales.
¿Es privado el desarrollo con IA en local?
La privacidad pasa a ser una propiedad de la arquitectura en lugar de una promesa. Tu estrategia, tus apuestas descartadas y tus criterios de aceptación viven en tu disco, así que en el lado del proveedor no hay nada que mirar. El límite real: cuando llamas a un modelo remoto, los tokens que envías van a ese proveedor bajo sus términos. Local-first convierte eso en una decisión por llamada, no en un valor por defecto donde todo tu espacio de trabajo se sincroniza a un servidor.
¿Necesito ejecutar los modelos de IA en mi ordenador para ser local-first?
No. Local-first no es maximalismo offline ni pretende que tu portátil haga la inferencia. Los modelos frontier corren en centros de datos por buenas razones. Lo que se queda local es el contrato, el grafo, las decisiones y la prueba: las partes que definen tu producto y que deberías poseer. Los modelos siguen siendo remotos, llamados con tus propias claves. Te niegas a alquilar las partes que deberías poseer, no la nube en sí.
¿El desarrollo local-first es más lento que las herramientas en la nube?
Suele ser más rápido donde importa la velocidad. El bucle agéntico lee estado, decide, actúa y actualiza cientos de veces al día. Cuando el estado es un archivo SQLite en tu disco, cada lectura va a velocidad de disco en vez de un viaje de red por los rate limits de otro. Lo único que esperas es el modelo, que ibas a esperar de todos modos. Todo lo demás es instantáneo porque todo lo demás es local.