Tu modelo necesita entender intent, no ejecutar literal

Pídele a un modelo “agrega un botón rojo”. El modelo malo escribe background: red. El modelo bueno consulta tu design system primero y te dice: “¿quieres var(--danger) o var(--accent-warm)? Tu sistema no usa rojo puro en ninguna parte.”

Esa diferencia, repetida 50 veces al día, es lo que separa un agente que se siente como un colaborador senior de uno que se siente como un junior literal. Y no depende del tamaño del modelo — depende de cómo entiende intent.

Literal vs intent

El modelo literal ejecuta exactamente lo que pides. Para tareas sin contexto funciona: “convierte esta función a async”, “agrega un try/catch”. Cosas mecánicas.

El modelo con intent entiende que tu petición vive dentro de un sistema. Antes de actuar, lee el design system, los ADRs, busca patterns que ya existen en el codebase, mira cómo otras funciones similares se resolvieron. Entonces ejecuta — y a veces te dice “esto que pides choca con X, ¿seguro?”.

El modelo literal es útil. El modelo con intent es un colaborador.

Cómo evaluar uno antes de adoptarlo

Tres pruebas que hacemos en Agentic cuando evaluamos un modelo o un agent setup para un cliente:

1. La tarea ambigua a propósito. Dale algo como “mejora el header” sin más contexto. Observa qué hace:

• Mal: arranca a refactorizar inmediato, asume qué “mejorar” significa.
• Bien: pregunta o lista opciones. “Veo que tu header tiene estos tres componentes. ¿Quieres mejorar accesibilidad, performance, o visual?”

2. El patrón existente. Pídele agregar una feature similar a una que ya existe. Observa si busca el precedente:

• Mal: implementa from scratch, ignorando el patrón establecido.
• Bien: lee el código existente, copia el pattern, mantiene consistencia.

3. El choque con invariantes. Pídele algo que (sin que tú lo digas) viola una regla del proyecto. Por ejemplo, escribe un test que use mocks cuando tus ADRs prohíben mocks en tests de integración:

• Mal: lo hace y sigue.
• Bien: lo nota y te avisa. “Encontré en tus decisions.md que prefieren no mockear DB en integration tests. ¿Hacemos el test sin mock, o aplico la excepción?”

Cómo configurar uno

La buena noticia: el modelo es la mitad. La otra mitad la pones tú.

Contexto curado en raíz del repo. CLAUDE.md, AGENTS.md, o como tu agente lo llame. Esto es donde declaras:

• Convenciones non-negotiable del proyecto
• Design tokens y dónde viven
• Patterns aprobados y cuándo aplicarlos
• Anti-patterns explícitos (“nunca uses X”)

ADRs accesibles. Si tu agente sabe leer markdown, deja tu carpeta de decisions/ accesible. Las decisiones de arquitectura son intent declarado — si el agente las puede leer, las puede respetar.

Trazas de las invocaciones. Logs de qué tools llamó, qué archivos tocó, qué tokens consumió. Cuando algo se siente mal, vuelves a las trazas y entiendes por qué — y ajustas el contexto.

La diferencia real entre modelos hoy

En 2026, todos los modelos top — Claude, GPT, Gemini — son capaces de entender intent si les das contexto. La diferencia entre ellos existe, pero es menor de lo que parece. La diferencia GIGANTE es entre:

• Un equipo con CLAUDE.md curado + ADRs vivos + reglas claras
• Un equipo que le tira al agente al monorepo sin contexto

El primero hace que cualquier modelo medio decente parezca senior. El segundo hace que el mejor modelo del mundo parezca un becario.

Hacia dónde

El futuro de AI coding no son modelos más grandes. Son contextos más curados, agents más especializados, y herramientas que facilitan mantener ambos sincronizados con el código real.

Invertir en el modelo es opcional. Invertir en el contexto es el multiplicador.

---

Si están evaluando qué modelo + setup adoptar para producción, conversemos — el chat está abierto.