🏎️ Motor × chasis

Cuando se habla de "usar IA para programar", casi todo el mundo piensa solo en el modelo — la IA propiamente dicha, un modelo de lenguaje (LLM) como Claude o GPT. Pero el modelo es solo una pieza. Todo lo que le agregas alrededor de él tiene un nombre: harness (se pronuncia «ârnes»; en inglés es el arnés/chasis que sostiene todo).

El harness consta de cuatro cosas que tú controla: (1) los prompts que escribes; (2) las skills que le das al agente; (3) el entorno (las herramientas y los permisos que tiene); y (4) el codebase donde trabaja. En palabras del propio Matt Pocock: "el modelo es útil, pero el harness requiere la misma cantidad de trabajo, y tienes mucho más control sobre el harness que sobre el modelo."

Esta es la imagen central del método Pocock. Todo el mundo es obsesionado con el motor (el modelo): «salió un modelo nuevo, ¿es mejor?». Pero los pilotos e ingenieros de F1 saben que el auto es un sistema. El motor por sí solo no corta el aire, no toma las curvas ni cambia la llanta en el momento adecuado.

Dicho en nuestro lenguaje: cambiar de modelo es cambiar el motor. Puede dar un impulso, pero si el chasis (tu harness) es malo, no ganas la carrera. Y hay un detalle que lo cambia todo: prácticamente no controla el motor (quien entrena el modelo es OpenAI, Anthropic…), pero controla el chasis casi 100%. Por eso el esfuerzo inteligente se destina al chasis.

El modelo es una caja negra que no entrenaste. En cambio, el harness está completamente en tus manos — y tienes tres palancas que puedes accionar hoy, sin esperar ningún lanzamiento:

Pocock resume el motivo en una sola frase: "tienes mucho más control sobre el harness que sobre el modelo." Vale la pena desglosar lo que esto significa en la práctica, porque es fácil estar de acuerdo y aun así no actuar. Del lado del modelo, tus opciones son muy pocas: elegir cuál usar y quizá ajustar algún detalle. No decides cómo piensa, no corriges sus sesgos ni aceleras el próximo lanzamiento: te quedas esperando. Del lado del harness, el menú es enorme e inmediato: reescribir un prompt para que sea específico, guardar una skill con el estándar de tu proyecto, habilitar o quitar una herramienta, renombrar archivos para que la IA encuentre las cosas. Cada uno de estos cambios cabe en un solo día de trabajo y el efecto se nota en la siguiente respuesta —sin release, sin pedirle nada a nadie. Por eso tiene sentido dedicar aquí casi toda tu atención: es el único lado donde hacer cambios realmente altera el resultado.

Pocock llama a esto "mirar lo que no corresponde: el juguete nuevo y brillante". El ejemplo extremo es el vibe coder que salta de una herramienta a otra (¿salió un modelo nuevo? Lo cambia; ¿salió una app nueva? La cambia) y nunca aprende ningún fundamento. Siempre se mantiene en la superficie.

El problema práctico: si atas todo a un modelo específico, cuando cambia (o aparece uno más barato), se rompe toda tu configuración. Y peor aún: no desarrollaste las habilidades que de verdad crecen. Centrarse en el modelo es alquilar; centrarse en el harness es construir patrimonio.

La mayoría trata al modelo como el 90 % del resultado y la optimización del harness como el 10 %. Pocock invierte la proporción: piensa en 50/50. El modelo importa de verdad, pero el harness tiene el mismo peso y es el lado que tú controlas. Una consecuencia práctica enorme: mitad de tu resultado está en algo que puedes mejorar hoy. Y hay un beneficio extra: con un harness mejor, un modelo más barato ofrece el mismo resultado (verás esto en el módulo 1.5, "Economía de tokens").

Fíjate en la asimetría que esconde ese 50/50: es la frase de Pocock que vale oro: "el modelo es útil, pero el harness requiere la misma cantidad de trabajo, y tienes mucho más control sobre el harness que sobre el modelo." Los dos lados tienen el mismo peso, pero solo uno de ellos te obedece. El motor es prácticamente fijo: no entrenas a Claude ni a GPT, no eliges sus datos ni cambias cómo razonan por dentro. El chasis, en cambio, lo ajustas línea por línea: reescribes el prompt, guardas una skill, organizas un archivo, habilitas o bloqueas una herramienta. Así que piensa en el esfuerzo en términos de respuesta: impulsar el lado del motor es casi como empujar una pared (solo puedes esperar a la próxima versión); impulsar el lado del harness cambia el equilibrio de inmediato. Por eso, cuando la mitad del peso está bajo tu control directo y la otra mitad está bloqueada, el camino racional es obvio: invertir donde la palanca responde.

Un ejemplo concreto para fijar la idea. Imagina que tomas la tarea «refactorizar este módulo de pagos» y la IA entrega algo confuso. La lectura «90% modelo» dice: "el modelo es débil, voy a esperar al próximo lanzamiento" — y te quedas quieto. La lectura 50/50 dice: "la mitad del problema es mía" — y entonces actúas: divides el pedido en pasos más pequeños, agregas una skill con los patrones de pago del proyecto, señalas las pruebas que ya existen y despejas el archivo que se había convertido en un laberinto. El igual el modelo, ese mismo día, empieza a entregar resultados correctos. No fue el motor lo que cambió — fue el chasis. Ese es exactamente el punto: no esperaste a nadie; te hiciste cargo de la mitad que te correspondía.

Para cerrar: cada vez que vayas a «mejorar la IA», tradúcelo en mejorar el harness. Antes de culpar al modelo por un mal resultado, ejecuta el diagnóstico de abajo: es el resumen práctico de todo lo que vimos. Cópialo y pégalo cuando te atasques:

Resultado ruim da IA? Antes de trocar de modelo, cheque o HARNESS:
[ ] PROMPT — o pedido estava claro e específico? Dei contexto suficiente?
[ ] SKILLS — faltou um procedimento/padrão salvo pra ela seguir?
[ ] AMBIENTE — ela tinha as ferramentas e permissões certas?
[ ] CODEBASE — o código é fácil de navegar e mudar, ou é um labirinto?
Se 3+ falharam, o problema é o chassi — não o motor.