LLMs + Workflows
Del modelo al obrero de software: córrelo donde estés, dale manos, y ponlo a trabajar con un workflow.
Tres cosas que casi nadie explica
El modelo
Correr un LLM donde tú estés — 8 GB, 16 GB o un VPS. Cuantización, KV cache y MoE.
Darle manos
Tool use: cómo un generador de texto escribe archivos y corre comandos.
El workflow
QuipuFlow: roles, briefs y control por diseño — el modelo convertido en trabajo real.
El modelo
Correr un LLM con lo que ya tienes. Tres trucos.
Lo que un LLM ya puede
hacer por ti
Escribir código contigo
Autocompleta, refactoriza y explica — dentro de tu editor.
Chatear con tus documentos
Contratos, manuales, código — sin que nada salga de tu control.
Trabajo en lote
Resumir, clasificar, redactar — mil veces, sin pagar por token.
Ejecutar tareas de verdad
El obrero de esta charla: un modelo que trabaja, no que opina.
Todo esto, con modelos abiertos. La pregunta no es cuánta máquina tienes — es cómo los pones a trabajar.
llama.cpp + GGUF
- Motor de inferencia en C/C++ — sin Python, sin frameworks pesados
- GGUF: un solo archivo — pesos empaquetados y cuantizados, mapeados a memoria
- Reparte capas entre GPU y CPU — tú decides con
-ngl - Es lo que corre debajo de Ollama y LM Studio — aprenderlo es entender qué hacen por ti
$ llama-server -m qwen3.8-27B.gguf -ngl 99 --port 8117
De 16 bits a 4
Pierdes una precisión casi imperceptible. Ganas que quepa.
Así, un modelo que nació para un servidor termina corriendo en una computadora de escritorio — con sitio de sobra para el contexto.
El otro devorador de VRAM
Cada token procesado guarda sus keys y values para no recalcular el pasado. Ese cache crece con el largo del contexto — no con el modelo.
MoE: expertos en RAM,
atención en GPU
$ llama-server -m moe-gigante.gguf -ngl 99 --n-cpu-moe 20 # o por regex: --override-tensor 'ffn_.*_exps=CPU'
Todos los expertos deben estar en memoria — pero no todos en la VRAM. Los expertos van a la RAM; la atención se queda en la GPU. Más lento que en VRAM pura — pero posible. Y posible es toda la diferencia.
Cada una es otra charla
Fine-tuning eficiente
Afinar modelos hasta 2× más rápido y con menos VRAM. Sus quants «dynamic» protegen las capas críticas del modelo.
Varios tokens por paso
Un modelo pequeño propone, el grande verifica en una sola pasada. Velocidad casi gratis, misma calidad.
Un modelo capaz,
con lo que ya tienes.
Ya cabe. Ya responde. Pero todavía solo habla. Ahora hay que darle manos.
Darle manos
Tool use: el secreto detrás de la palabra «agente».
El modelo no escribe archivos.
No corre comandos.
Solo genera texto.
Entonces… ¿cómo es que «el agente» crea carpetas, edita código y ejecuta builds?
Le describes herramientas…
…y le pides que, cuando quiera usar una, no conteste en prosa: que devuelva un JSON con su intención.
{
"tool": "write_file",
"path": "src/views/CosteoView.vue",
"content": "<template>…</template>"
}
El modelo propone.
El harness dispone.
Modelo
genera el JSON
Harness
parsea y valida
Sistema real
disco · terminal · navegador
Resultado
vuelve al modelo
El programa que envuelve al modelo ejecuta la función real: abre el archivo, corre el comando. El modelo nunca toca el disco. Crear una carpeta es una herramienta. Correr un test es una herramienta.
El loop agéntico
Propone
emite una tool call
Ejecuta
el harness corre la acción
Observa
recibe el resultado — o el error
Decide
siguiente paso, corrección… o «terminé»
Eso — y nada más — es un «agente». No hay magia. Hay un bucle.
Con run_command sin límites…
…puede hacer cualquier cosa: borrar archivos, tocar producción, salirse del proyecto.
Por eso el diseño importa: dónde actúa, qué herramientas tiene, qué le está prohibido.
El workflow
QuipuFlow · roles, briefs y control · un ERP en producción.
Una obra de construcción
Arquitecto
Claude
Diseña, escribe el brief, audita el diff. No pone ladrillos: no escribe código.
Director
yo
Da la orden. Firma cada avance. Nada llega a la rama sin su visto bueno.
Obrero
modelo en mi GPU
qwen38 vía OpenCode. Ejecuta la tarea — solo dentro de su caja aislada.
Siete pasos, cero confianza ciega
- Orden en lenguaje natural — del director
- Planos: .worker-brief.md — objetivo, permitido, prohibido, criterios
- Worktree aislado — copia del repo, caja de arena
- El obrero ejecuta — solo dentro de la caja
- Auditoría del diff — línea por línea, como el PR de un junior
- Tests y verificación — gates antes de tocar nada real
- Commit — firmado por el arquitecto, nunca por el obrero
El brief es la única fuente de contexto del obrero: no conoce las convenciones del proyecto — solo lo que dicen sus planos.
El obrero, trabajando de verdad
$ opencode run --dir /tmp/oc-worker-SQ-168 --auto "Lee .worker-brief.md y ejecuta"✔ brief leído — 3 archivos permitidos✔ 6 ediciones · 1 componente nuevo (CosteoView.vue)✔ npm run build — 2 515 módulos · 18.13 s✔ validación en navegador (Playwright) — click a click— el obrero nunca salió de su worktree ▌
No es un ejemplo de laboratorio: es el registro de una feature real de costeo en mi ERP. Un modelo, las herramientas que le di, su caja aislada. Y todo esto corre en una GPU de gamer de 16 GB — la prueba, no el requisito.
El control no es confianza.
Es diseño.
El arquitecto tiene las herramientas de escribir código removidas: no puede tocar una línea ni aunque se lo ordene. El obrero no puede hacer commit ni salir de su worktree.
El sistema no espera que la IA se porte bien. Está diseñado para que no pueda portarse mal.
A un obrero nuevo no lo sueltas:
primero, el manual
llms.txt
raíz · el mapa
módulo
su llms.txt
capa
su llms.txt
archivos
recién ahora
Consumir el índice antes que los archivos: menos tokens, mejor orientación. Mi estándar wake-up.
Que la obra avance
mientras duermo
Un alter ego en un VPS: el mismo patrón que acaban de ver — director, arquitecto, cuadrilla — corriendo sin mí.
El obrero no vive en el hardware: vive en el workflow. No es ciencia ficción — es el siguiente paso.
El futuro no es de quien
usa la IA.
Es de quien sabe dirigirla.