🧭 Configuración agnóstica al agente

En el módulo 1.2 concluimos que no vale la pena quedarse esperando la IA mejore. Pero en el módulo 1.1 vimos que el modelo cambia todo el tiempo. ¿Cómo actuar ahora sin depender de un modelo que quedará obsoleto en tres meses? La respuesta de Matt Pocock es mantener tu configuración agent-agnostic (agnóstico al agente).

Agnóstico significa: tu harness — tus prompts, tus skills, la forma en que tu codebase está organizado — no depende de qué IA hay dentro. En sus palabras: "mantén el harness independiente del agente y aplica buenos fundamentos → seguirá funcionando con el próximo modelo." La consecuencia es poderosa: cuando salga un modelo mejor, solo cambias el motor. El auto (que pasaste tiempo ajustando) sigue valiendo. Es lo opuesto a reconstruir todo con cada lanzamiento, y por eso Pocock dice que no es un «pundit» (opinólogo), solo está "haciendo lo mejor que puedo con lo que tengo ahora."

Optimizar es bueno, pero esconde un veneno en la palabra overoptimizar. El propio Pocock confiesa el riesgo, con una frase que vale la pena recordar: "If I over-optimize around a model... I lose focus on the fundamentals" (si optimizo demasiado para un modelo, pierdo el foco en los fundamentos). Cuando adaptas cada prompt, cada skill y cada truco al estilo específico de un modelo, creas un dependencia de proveedor: cambiar pasa a doler tanto que simplemente no cambias, incluso cuando deberías.

El costo aparece de tres formas. (1) Trabajo repetido: sale un modelo nuevo, y tus prompts «mágicos» que dependían de un truco del anterior dejan de funcionar: tienes que rehacer todo. (2) Ceguera: tú te involucras tanto en los trucos de un modelo que no te das cuenta cuando otro, más barato, ya haría lo mismo. (3) Fragilidad: tu configuración se convierte en un castillo de naipes ajustado a un solo motor. Pocock equilibra las cosas (el famoso 50/50 del módulo 1.1): el esfuerzo inteligente se dedica al harness, pero el harness no puede casado con el motor. Optimiza el auto, no la dependencia del motor.

Esta es la frase más importante de todo el método, y Pocock la repite: "People are focused on the wrong thing — the big shiny new thing — when in fact just focus on the stuff that's been working for 30-40 years." Dicho de otro modo: la gente mira el juguete nuevo y brillante, cuando lo que importa es enfocarse en lo que funciona desde hace 30-40 años. Estos son los fundamentos — y, por definición, son agnósticos: ningún modelo de IA puede invalidarlos.

¿Cuáles son? Versionar con git (el «botón de deshacer» de tu proyecto), escribir pruebas (pruebas automáticas de que el código funciona), organizar bien los archivos, documentar lo suficiente, definir claramente el alcance de las tareas. Fíjate: nada de esto tiene que ver con «qué IA». Son principios de ingeniería que servían antes de la IA y siguen sirviendo después. Y aquí está la clave: cuando tu base de código respeta estos fundamentos, cualquier el modelo trabaja mejor con él — incluso los más baratos (lo verás claramente en el módulo 1.5). Los fundamentos no son «la forma antigua»; son la base que hace funcionar la nueva forma.

Pocock da un ejemplo concreto del antipatrón: el vibe coder que "cambia de herramienta cada semana (replit → lovable → …) y nunca aprende ningún principio." Cada semana sale una app o un modelo nuevo, y la gente migra: nuevo dashboard, nuevos atajos, una nueva promesa. El problema no es la curiosidad: es que cada cambio reinicia el aprendizaje. Quien nunca pasa suficiente tiempo en una herramienta nunca llega más allá de su superficie.

Aquí está el matiz que Pocock insiste en señalar: "la diferencia está en el ENFOQUE, no en creer o no en la IA." Él no está diciendo «no uses IA» ni «la IA es puro hype». Tanto él como el vibe coder creen en la IA; la diferencia es el manera. El vibe coder optimiza para la novedad (la herramienta del momento); el método Pocock optimiza para los fundamentos (la habilidad que perdura). Es exactamente la trampa del módulo 1.2 vista desde otro ángulo: en vez de quedarse esperando a que el modelo mejore, el vibe coder persigue cada modelo nuevo, y ambos extremos dan el mismo resultado: nunca construir nada que dure.

"Blindarse" no es dejar de evolucionar — es todo lo contrario. Pocock y David Ondrej coinciden en un punto práctico: mejora activamente la configuración, todos los días (Ondrej menciona cosas como VPS, Tailscale, etc.) Y usa el mejor modelo. Las dos cosas juntas. El secreto es dónde tú inviertes ese esfuerzo en las piezas que permanecen (skills bien redactadas, codebase organizado, fundamentos), no en trucos ligados a un motor que se irá. Mueves todas las palancas del módulo 1.1, pero te enfocas en las que son agnósticas.

Incluso hay una advertencia de prudencia en el método: Pocock espera cerca de un mes antes de adoptar un modelo nuevo en el flujo de producción (fue lo que hizo con el Opus 4.5). No es miedo a las novedades: es dar tiempo para saber si el nuevo motor realmente encaja sin sorpresas. Una configuración blindada significa que adoptas lo mejor, pero a tu ritmo, sin que cada lanzamiento se convierta en una emergencia.

Para cerrar: cada vez que vayas a adoptar una nueva herramienta, prompt o truco, haz una pregunta de filtro — «¿esto sigue siendo válido si mañana cambio de modelo?». Si la respuesta es no, estás creando dependencia, no patrimonio. La lista de verificación de abajo es el resumen práctico del módulo. Cópiala, pégala al principio de tu proyecto y ejecútala antes de cada decisión de configuración:

VISTORIA DE AGNOSTICISMO — rode antes de cada decisão de setup
Pergunta de filtro: "isto continua valendo se eu trocar o modelo amanhã?"

[ ] MODELO trocável? Mudar de IA é editar 1 linha de config — ou refazer tudo?
[ ] SKILLS portáteis? Funcionam em Claude Code, Codex etc. — ou só num app?
[ ] FUNDAMENTOS no lugar? git + testes + organização + docs + escopo claro.
[ ] PROMPTS sem manha? Pedidos claros em inglês/português simples,
    não truques que dependem de um modelo específico.
[ ] CODEBASE organizado? Qualquer modelo (até o barato) navega fácil.
[ ] RITMO próprio? Adota modelo novo quando comprovado (~1 mês), não no hype.

3+ "não" = seu setup está casado com um motor. Blinde antes de otimizar.