Una fábrica local de software es un sistema que mantiene producto, código y evidencia conectados en la máquina que tienes delante. No una ventana de chat. No una carpeta de Markdown. No una pestaña dentro de la nube de otro. Un sitio donde una idea se convierte en decisión, la decisión en especificación, la especificación en trabajo que un agente puede ejecutar, y el resultado vuelve con la prueba adjunta; todo en un sistema conectado, todo local.
Eso es una afirmación de categoría, así que la voy a defender en lugar de soltarla.
La generación de código está básicamente resuelta. Claude Code, Codex y compañía escriben código lo bastante bien como para que “¿puede el modelo escribir esta función?” ya no sea la pregunta interesante. El trabajo no desapareció. Se movió. Ahora consiste en mantener vivo el contrato de producto mientras muchos agentes escriben, fallan, se recuperan, integran y producen evidencia. Hoy eso lo hace una persona a mano, sin ponerle nombre. Tú eres el scheduler. Tú eres la memoria entre sesiones. Tú eres el bucle de recuperación cuando una ejecución muere. Tú eres la puerta de calidad que decide qué significa “hecho”. Tú eres el runtime.
Una fábrica es lo que construyes cuando te cansas de ser el runtime a mano.
El impuesto de la desconexión
Mira cómo se mueve de verdad un cambio por un flujo moderno asistido por IA.
La idea nace en un chat. La decisión de construirla vive en tu cabeza, quizá en un hilo de Slack. Los requisitos acaban en una página de Notion o un ticket de Linear. El agente recibe un prompt que parafrasea una parte de eso. El código aterriza en un repositorio. Los tests, si se ejecutaron, imprimieron una salida que se fue del terminal hace una hora. La razón por la que descartaste el otro enfoque ya no está. Tres semanas después, un segundo agente —o tú, que lo has olvidado— abre el archivo y ve un diff sin memoria alrededor.
Cada uno de esos traspasos pierde algo. Esa pérdida es un impuesto, y se acumula. Cuanto más rápido escriben los agentes, más pagas, porque el volumen de cambios crece y el tejido conectivo no. Un build en verde te dice que el código compiló. No te dice que el comportamiento que prometiste se instaló, ni que la restricción que te importaba sigue en pie.
Ese es el problema real del código generado por IA, y no es que el código sea malo. Cada pieza suele ser correcta en local. El sistema deriva hacia incoherente en global porque nada sostiene el conjunto. Cada herramienta posee una parte —el editor posee el diff, el gestor posee el ticket, el chat posee la conversación— y ninguna posee el hilo que va de la intención a la prueba.
Una fábrica es la respuesta a ese fallo concreto: poner las partes en un sistema para que el hilo sobreviva.
Qué se conecta dentro de la fábrica
Uso la palabra fábrica a propósito, y también con cuidado. No una feature factory —la máquina que se mide por output enviado y a eso lo llama producto—. Lo contrario. Aquí una fábrica es un sitio con estaciones, donde entra material, se trabaja en un orden definido y sale como algo probado. Seis estaciones, un bucle.
Descubrir. Convierte una incertidumbre en hipótesis, evidencia, un experimento pequeño y una decisión. La salida es una decisión, registrada, no una sensación que recordarás mal.
Definir. Mantén el contrato de producto —el PRD, las épicas, las historias, los criterios de aceptación— como algo trazable, no un documento que nadie lee. La salida es un contrato al que se puede exigir a un agente.
Planificar. Refina alcance, dimensiona el trabajo, gestiona dependencias, haz visible el sprint. La salida es trabajo acotado.
Construir. Entrega al motor un contrato preparado, contexto aislado y una definición de hecho ejecutable. La salida es un cambio, no una esperanza.
Verificar. Gates, tests, capturas, trazas. Sin evidencia, no hay luz verde. La salida es prueba, no un autoinforme.
Aprender. Devuelve el resultado, la historia del código y las decisiones a la memoria para que el siguiente bucle arranque más listo. La salida es memoria.
Cada estación produce contexto para la siguiente. Nada importante queda atrapado en un prompt ni abandonado en un documento de planificación. Ese es todo el truco, y es poco vistoso: el valor no está en ninguna estación, está en que estén conectadas y en que la conexión sea duradera.
Un grafo de producto sobre un grafo de código
El tejido conectivo tiene forma. Debajo hay un grafo de código: las funciones, archivos, servicios y sus relaciones, eso que un agente de código necesita de verdad en lugar de un prompt más largo. Encima vive un grafo de producto: evidencia de discovery enlazada con decisiones, decisiones con especificaciones, especificaciones con historias y criterios, criterios con el código que los implementa, y el código de vuelta con la evidencia que lo valida.
La mayoría de herramientas aplanan tu producto hasta una lista de tickets y pierden los enlaces. La gracia del grafo es que los enlaces son de primera clase. Puedes abrir cualquier capacidad meses después y recuperar cuatro cosas a la vez: qué hace, por qué existe, dónde vive y qué demuestra que funciona. Esa es la diferencia entre un sistema que recuerda y un montón de artefactos que por casualidad comparten carpeta.
Cuando un motor puede enrutar trabajo entre distintos modelos sin vendor lock-in, el grafo es lo que sobrevive al cambio. El modelo es intercambiable. La memoria no, y la memoria es lo que de verdad posees.
Por qué local es arquitectura, no nostalgia
Aquí la categoría se gana su nombre. “Local” no es una preferencia por los viejos tiempos. Es el único sustrato sobre el que todo esto sigue conectado sin pedirte que confíes la forma entera de tu producto a una cadena de terceros.
Piensa en lo que guarda la fábrica: tus notas de discovery, tus opciones descartadas, tus apuestas sin publicar, tus criterios de aceptación, tu código, la evidencia de tus tests. Eso no es un repositorio. Es la estrategia detrás del repositorio. Dónde vive eso es una decisión de arquitectura, y merece la misma seriedad que darías a elegir una base de datos.
Ponlo en tu máquina y tres cosas se vuelven ciertas por construcción, no por política. El estado está al lado del trabajo, así que la latencia entre “decidí esto” y “el agente lo ve” es una lectura de disco, no un viaje de red y el rate limit de otro. Los datos son tuyos, en almacenamiento inspeccionable que puedes abrir, así que la privacidad es una propiedad de la arquitectura y no una promesa en una pantalla de ajustes. Y nada del sistema depende de que un proveedor siga existiendo, mantenga su precio o no cambie sus términos.
Local no significa cerrado, y esa distinción importa. La fábrica funciona en tu ordenador, pero llama a los proveedores de IA que elijas, trabaja en repositorios git normales y se mantiene abierta en los límites donde importa la portabilidad. Los modelos son remotos —y conviene decirlo claro: la nube hace inferencia mejor de lo que la hará tu portátil—. Lo que se queda local es todo lo que define tu producto: el contrato, el grafo, las decisiones y la prueba. Envías tokens fuera cuando tú decides. No entregas la fábrica.
Qué hace mejor la nube, y qué cuesta
No voy a fingir que el intercambio sea de una sola cara. Las herramientas en la nube son excelentes en cosas que una fábrica local no. El estado compartido entre un equipo, sin configuración, funciona en cuanto alguien abre un navegador. El cómputo pesado es problema de otro. El software se actualiza solo. Para un equipo grande que vive en un mismo espacio compartido, esas son ventajas reales y no las voy a despachar.
El coste de esa comodidad es justo aquello de lo que va esta categoría. Cuando el estado vive en la nube de otro, la memoria de tu producto es inquilina, no propietaria. La conexión entre intención y prueba existe a su discreción, en su formato, exportable en sus términos. Estás alquilando el hilo. Para un fundador en solitario o un equipo pequeño que construye algo que pretende seguir entendiendo dentro de un año, poseer ese hilo vale más que la configuración que te ahorra.
Esa es la versión completa de la elección, y es una elección, no un veredicto.
La fábrica de una sola persona
La razón por la que esto importa ahora, y no hace cinco años, es que los agentes cambiaron las unidades económicas de construir. Una sola persona con una fábrica que funciona puede sostener más software en marcha en la cabeza de lo que antes podía un equipo pequeño, porque el sistema sostiene las partes que la persona sostenía a mano. El scheduler, la memoria, el bucle de recuperación, la puerta: esos eran el techo de cuánto podía llevar una persona. Muévelos a un sistema y el techo sube.
Esa es la promesa, y quiero ser exacto: no que enviarás un 40% más rápido, ni ninguna cifra que tendría que inventarme. La afirmación es estructural. Cuando producto, código y evidencia siguen conectados en tu máquina, dedicas menos día a ser el tejido conectivo y más a decidir qué debería existir. Construir se abarató. Decidir se encareció. Una fábrica es donde pones la parte barata para poder permitirte hacer bien la cara.
Deja de ser el runtime a mano
Aquí está la prueba de si algo de esto ha calado. Piensa en tu última semana dura de enviar con agentes. Cuenta las horas que pasaste sin construir, sin decidir, solo sosteniendo el conjunto: reexplicando contexto que una sesión perdió, buscando por qué se tomó una decisión, reejecutando trabajo porque no podías fiarte de un “hecho”, cargando el plan entre herramientas en tu propia cabeza. Eso eras tú siendo el runtime. No aparece en ningún changelog, y es la mayor parte del trabajo ahora.
Una fábrica no hace desaparecer ese trabajo por arte de magia. Lo convierte en tarea del sistema en vez de tuya. La planificación, la memoria, la recuperación, la puerta —las partes que hacías a mano— se mueven a algo que las sostiene de forma duradera, conectada, en tu máquina. Lo que te queda es la parte que siempre fue tuya: decidir qué debería existir y juzgar si existió. Ese es el intercambio que la categoría está construida para hacer.
Para profundizar
La fábrica se entiende mejor una estación cada vez. El argumento de mantener el sistema entero en tu máquina es el desarrollo con IA local-first, y su versión más afilada es por qué tu código se queda en casa aunque los modelos no. Esa postura tiene un hogar nativo en las herramientas nativas de macOS sobre las que corre, y trae libertades más pequeñas, como herramientas que no piden cuenta.
En el lado del modelo, una fábrica enruta el trabajo al modelo que tú traigas y te da un sitio para controlar los costes de IA en lugar de verlos flotar. La comparación completa con la alternativa está en nube frente a herramientas locales. Y la razón de que todo esto importe ahora es económica: es lo que hace posible una fábrica de una sola persona. Para el cuadro operativo dentro del que vive la fábrica, empieza por construir software con agentes de IA.
Dónde encaja PaellaDoc
PaellaDoc es la fábrica local de software que estoy construyendo porque este problema es mío antes que de nadie. Funciona en macOS, local-first, gratis hasta tres proyectos, sin cuenta. Conecta discovery, decisiones, especificaciones, agentes, el grafo de código y la evidencia en un sistema en tu máquina, y llama a los modelos que le apuntes. Los datos de producto, los repositorios y la prueba se quedan locales; el manifiesto es la versión larga del porqué.
No inventé la fábrica local de software como un marco de marketing y luego busqué un producto que encajara. Construí el producto porque ser el runtime a mano dejó de escalar, y después me di cuenta de que la forma de lo que había construido era una categoría. Este artículo es yo poniéndole nombre claro. Los agentes seguirán mejorando en escribir código. Lo escaso —un sitio donde tu producto, tu código y tu prueba sigan conectados, y ese sitio sea tuyo— es lo que merece la pena construir.
Preguntas frecuentes
¿Qué es una fábrica local de software?
Una fábrica local de software es un sistema que mantiene producto, código y evidencia conectados en tu propia máquina. Una idea se convierte en decisión, la decisión en especificación, la especificación en trabajo que un agente ejecuta, y el resultado vuelve con la prueba adjunta; todo en un sistema conectado en lugar de disperso entre un chat, un gestor y un repositorio. Local significa que el hilo de la intención a la prueba es tuyo, no alquilado.
¿Es lo mismo una fábrica local de software que una feature factory?
No, es lo contrario. Una feature factory se mide por output enviado y a eso lo llama producto. Una fábrica de software es un sitio con estaciones —descubrir, definir, planificar, construir, verificar, aprender— donde entra material, se trabaja en orden y sale probado. La gracia no es el volumen de features. Es que intención, código y evidencia sigan conectados para que el sistema no derive hacia incoherente mientras los agentes escriben.
¿Necesito ejecutar los modelos de IA en local?
No. Local se refiere a dónde vive el estado de tu producto, no a dónde ocurre la inferencia. La fábrica está en tu máquina pero llama a los proveedores de IA que elijas, y la nube hace inferencia mejor de lo que la hará un portátil. Lo que se queda local es todo lo que define el producto: el contrato, el grafo, las decisiones y la prueba. Envías tokens fuera cuando tú decides, sin entregar la fábrica.
¿Una fábrica local de software solo sirve para desarrolladores en solitario?
Importa sobre todo a un fundador en solitario o un equipo pequeño que construye algo que pretende seguir entendiendo dentro de un año, porque poseer el hilo vale más que la configuración que ahorra una nube compartida. Los equipos grandes ganan cosas reales con la nube: estado compartido sin configuración, cómputo pesado como problema de otro, software que se actualiza solo. La elección depende de si poseer la memoria de tu producto pesa más que esa comodidad.