Pagas tarifa premium del mejor LLM del mercado para que ese LLM haga, turno tras turno, el mismo trabajo de fontanería que tú harías con un script de cinco líneas. Estás quemando tokens para hacer de andamio humano.
Y después te sorprende la factura. Y, peor, te sorprende el retorno de la inversión.
La IA es una herramienta perfecta si la combinamos con pensamiento estratégico. Si la usas como un martillo, el resultado será mediocre. Si la usas como una caja con múltiples herramientas, podrás construir cualquier cosa.
La pregunta que planteo aquí es la siguiente: cómo bajar tu factura de IA sin tocar el modelo, sin renunciar a calidad y sin cambiar de proveedor. La pieza que falta casi siempre no es prompt engineering. Es el andamio que soporta el prompt.
A ese andamio, en jerga, se le llama scaffolding. Y casi todos los tokens que se están quemando con IA en pymes, agencias y departamentos serios se desperdician por no entender la diferencia entre cinco piezas que no son lo mismo.
Sí, también puedes usar plugins para hablar como un cavernícola. El caso más explícito que he visto es getcaveman.dev, donde lo llevan al extremo con humor. Pero eso sigue siendo aporrear por fuerza bruta, cuando lo que necesitas es pensar.
Qué pasa cuando no hay andamio
Lunes después de la Datolada, conversación de barra. Sale el tema de los costes con IA y alguien lo resume sin filtro: ”estoy gastando una pasta en tokens y los resultados son... meh”.
Casi todos los presentes con un agente en marcha en su trabajo asienten. Mientras tanto, yo tuerzo el gesto: no pensamos, aporreamos.
No es la primera vez que escucho esto. Seguro que tú tampoco. Lo mismo pasa en kick-offs con clientes que llevan medio año con su “asistente de IA”: la factura sube, el criterio no mejora, la calidad sigue siendo inconsistente. La trampa es la misma siempre: confunden el modelo con el sistema.
De esto a pensar que la IA te está desayudando solo hay un paso.
Un LLM, solo, no termina trabajo de verdad. Necesita que alguien le diga qué hacer, dónde mirar, con qué datos, en qué orden, validar el resultado y decidir si vale.
Si no le pones andamio, ese alguien eres tú. Copias del CRM al chat, le pides que razone, sacas datos de Sheets, vuelves a pegar, le dices “comprueba”, relees, corriges, vuelves a pedir, repites el contexto porque se le ha olvidado, exportas, formateas. Cada turno es un razonamiento desde cero, con todo el contexto reinyectado. Y cada turno son tokens.
Si haces tú esos pasos, eres el plug-in humano. Mientras tanto, claro, pagas una factura premium para que el modelo replanifique cada turno desde cero el mismo problema que tú ya entiendes.
De aquí en adelante, voy a concretar varias cosas.
Las cinco piezas que componen un andamio y la regla de bolsillo que las separa.
El movimiento multi-agente que más dinero ahorra hoy y que casi nadie aplica bien.
El caso de Gary Tan, que reescribió en 2026 por 200 dólares lo que en 2008 le costó cuatro millones.
Los tres tipos de daño que aparecen, por orden, cuando ignoras el andamio: el último saca a la palestra nombres que seguro conoces.
Las cinco piezas del andamio
Voy de lo pequeño a lo grande. Primero la regla mnemotécnica, los matices después.
Prompt: lo haces una vez. Pregunta puntual, encargo único, no se repite.
Skill: lo repites con criterio. Markdown que explica cómo lo haces tú (la receta). Cuando algo se va a hacer cinco veces igual, sale del prompt y entra en skill.
Plugin: el workflow empaquetado. Reúne uno o varios skills, scripts, conectores y un orden. Lo instalas, lo invocas, hace una pieza completa de trabajo.
MCP / conector: el enchufe a un sistema externo. Salesforce, GA4, GSC, Sheets, Asana, BigQuery. El agente deja de “imaginar” tus datos y los toca de verdad.
Script o hook: lo determinista que no debes dejar al modelo. Validar un JSON, correr un test, llamar a una API, comprobar formato. Cualquier cosa que tenga respuesta unívoca no es trabajo de LLM, es trabajo de código.
La regla de bolsillo: si lo haces una vez es prompt; si se repite es skill; si tiene que viajar al equipo es plugin; si toca otro sistema es MCP; si tiene que ser exacto, es script.
Una analogía útil: piezas de Lego. Apiladas con sentido te dan un workflow real que tu equipo puede usar sin ti delante. Tiradas en una caja te dan tokens quemados y la sensación de que la IA “casi funciona”.
Modelo caro para pensar, modelo barato para ejecutar
El error operativo más caro que se ve hoy es usar el mismo modelo (normalmente el más potente, normalmente premium) para todo: planificar, ejecutar, validar y resumir, en la misma conversación.
Un sistema bien montado se parece más a esto:
Un agente planificador con el modelo bueno y caro: lee el contexto, propone el plan, decide qué hay que hacer y en qué orden. Pocas llamadas, mucho razonamiento por llamada.
Un agente ejecutor con un modelo más barato y rápido: hace el trabajo paralelizable (escribir, transformar, traducir, iterar variantes). Muchas llamadas, poco razonamiento por llamada.
Un script determinista que valida (no lo deciden los modelos: lo decide el código).
Un hook que pregunta al humano cuando el sistema no está seguro.
Un ejemplo estupendo para ilustrarlo: el uso de un agente gestor de proyectos con agentes de tareas por debajo.
En abril, Andrej Karpathy puso un agente a iterar 700 experimentos sobre su propio código de entrenamiento mientras dormía, con tres reglas duras: un solo archivo editable, una sola métrica, un solo presupuesto de tiempo por experimento. Hit rate bajo (unas 20 mejoras de 100), ritmo inhumano, y mejora del 11% en código que él ya había peinado durante meses. La pieza interesante es que esa misma arquitectura (un agente que revisa lo que hace otro agente) ya se usa para reescribir prompts y skills enteros automáticamente: lo llaman meta-agent + task-agent.
Detalle fundamental:
Cuando emparejas dos modelos del mismo fabricante (Claude planificando para Claude, GPT para GPT), la pareja funciona mejor que mezclar familias.
La intuición se llama model empathy: el planificador “piensa como” el ejecutor y le escribe instrucciones que sí va a entender bien. Para tu día a día significa una cosa simple: si pruebas multi-agente, prueba primero pareja del mismo fabricante. Te ahorras una capa de “perdón, no te entendí”.
Imagina la de dinero que te ahorras ahí. Perdón, de tokens 😅
Hay un movimiento más fino que el reparto por tarea: enfrentar dos modelos sobre el mismo trabajo, uno generando y el otro criticando. No para validar formato (eso es trabajo de script), sino para atacar el razonamiento, encontrar supuestos no declarados y sacar lagunas.
La intuición es, en este caso, la opuesta a model empathy: aquí quieres que cada modelo traiga sus sesgos distintos, porque lo que uno acepta sin pestañear el otro lo cuestiona.
Gary Tan lo cuenta así en la entrevista de Lightcone trabaja con Claude Code como agente principal, pero cuando huele a respuesta inflada llama a un Codex en segundo plano con un comando que dice “busca todos los problemas y bugs y devuélvemelos”. Claude reescribe con la crítica encima.
Nota geek: en CrewAI esto se monta como un agente “crítico” dentro del crew, con un prompt cuya orden no es “aprueba esto” sino “ataca el razonamiento del agente anterior”. Sale más caro por tarea, pero te ahorra el coste real, el de equivocarte en producción.
En la práctica, así reparto los modelos en mi día a día:
Pensar, planificar y revisar criterio: Claude Opus. Pocas llamadas, mucho razonamiento, caro por llamada pero compensa porque no se equivoca en lo que importa.
Programar: Composer 2 (Cursor) cuando lo que importa es velocidad sobre código mediano; Claude Sonnet cuando hay arquitectura más delicada o lógica menos obvia.
Decisiones de bajo nivel en un sistema agéntico (clasificar, rutear, resumir, comprobar formato, decidir en qué cubo cae algo): modelos lite tipo Gemini Flash o Claude Haiku. Cuestan céntimos por miles de llamadas y son lo bastante rápidos como para no romper el flujo.
La regla mental es simple: si el coste de equivocarse es alto, modelo bueno; si vas a llamar mil veces y cada llamada es trivial, modelo lite.
Sobre herramientas:
Cursor es mi setup principal para todo el trabajo asistido del día a día. Te resuelve el día sin tener que pensar en orquestación.
Para sistemas multi-agente más serios, donde tiene sentido orquestar tres o cuatro agentes con roles distintos y aplicar este reparto de modelos por tarea, uso CrewAI. Te obliga a pensar la orquestación, que es justo donde se aprende a hacer scaffolding bien.
Dentro de una misma cadena multi-agente sí mantengo pareja del mismo fabricante para planificador y ejecutor cuando importa el handoff (model empathy). Mezclo familias entre tareas distintas, no dentro del mismo bucle.
El caso que conviene tener fresco
Para que no quede como una idea abstracta y ya está: Gary Tan, presidente de Y Combinator, reescribió en enero un blogging-platform completo (Posterous) que en 2008 le costó cerca de 4 millones de dólares, dieciocho meses y siete personas.
El segundo intento, en 2014, le costó un par de cientos de miles y tres meses.
La tercera vuelta, en 2026, le costó 200 dólares (su cuenta Claude Code Max) y cinco días.
No multiplicó por cuatrocientos su productividad porque el modelo sea cuatrocientas veces mejor.
Multiplicó por cuatrocientos porque construyó un stack de skills y micro-agentes (lo llama GStack: un agente “CEO” de revisión, un agente revisor de código, un Codex de segunda opinión que entra cuando Claude empieza a inventar, un script que valida en navegador con Playwright) y dejó que el sistema rebotara entre ellos. El humano firma, decide qué se promueve a producción y dice cuándo parar. Lo demás lo hace el andamio.
Trocear el problema usando nombres propios
Hay un patrón mental que cierra esto sin necesidad de hablar de paper alguno: divide y vencerás. Es uno de los que más uso en mi día a día y me ayuda a desatascar cosas y pensar con mayor claridad.
Dividir el problema en trocitos con nombre propio, lo bastante pequeños como para responderlos o falsarlos con evidencia, y mapear cada trocito a la pieza de andamio que le corresponda.
Ejemplo rápido: ”auditar SEO de un sitio nuevo” no es un trocito. Es un saco. Trocea: extraer URLs (script + MCP a GSC), clasificar intención de búsqueda (skill + modelo barato), revisar 50 muestras a mano (modelo bueno, criterio caro), montar el informe en plantilla (skill + plugin), abrir reunión con el cliente (humano).
Ahora cada pieza tiene un andamio que la sostiene. Y, ojo, no todo necesita IA. Si una validación se puede hacer con un if, hazla con un if. El modelo no es la herramienta de propósito general; es una herramienta más del estuche, y muchas veces no es la que toca.
Repite conmigo: la IA es una herramienta más. No es un fin. Es un método.
Qué se rompe si no pones un andamio decente (por orden de aparición)
Tres cosas, por orden de tiempo en que llegan:
Coste. Si todo va al modelo caro y todo va en el mismo turno, quemas tokens sin que la calidad mejore. Es lo más visible y lo primero que hace saltar la alarma de finanzas.
Calidad. El contexto se pudre, el modelo pierde el hilo, las tareas largas se contaminan entre sí. Aparecen errores raros, inconsistentes y silenciosos. Esto es peor que el coste, porque no salta solo: salta cuando ya has tomado decisiones con la salida.
Seguridad. El caso Lily, plataforma interna de IA en McKinsey: 22 endpoints de 200 que no llevaban incorporada autenticación, incluido uno con permisos de escritura a producción. La causa raíz no fue olvidar poner un candado en la puerta. Lo fue diseñar el sistema sin asumir que iba a llegar un agente a tocarlo. Cuando el andamio es débil deja de ser un problema de coste y se convierte en superficie de ataque.
La pregunta operativa de esta semana
Si te ahorra horas hoy una conversación gigantesca con el modelo bueno, vale, sirve. Pero si llevas tres meses así y el resultado no escala (la gente del equipo no lo replica, los costes suben, la calidad varía sesión a sesión), no es problema del LLM. Estás siendo tú el plug-in.
Llévatelo en una pregunta concreta para los próximos siete días: en lo que has hecho con IA en la última semana, ¿qué piezas son prompt, cuáles deberían ser skill, qué workflow merece plugin, dónde necesitas un conector real a datos y qué partes ya no deberían tocar al modelo y deberían ser script?
Si no puedes nombrarlas, ya estás pagando el precio sin haberlo decidido.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.