Las nuevas reglas del "context engineering" para los modelos Claude 5

Leyendo el hilo de Thariq (@trq212), quien trabaja en Claude Code en Anthropic, sobre cómo cambió la forma de escribir instrucciones para la nueva generación de modelos Claude 5. Acá te dejo los takeaways explicados de forma simple, con varios ejemplos.

Primero, lo básico: ¿qué es el “context engineering”?

Cada vez que le escribís algo a Claude, no solo lee tu mensaje. También hay un montón de “instrucciones invisibles” que vienen antes de tu mensaje: quién es Claude en ese producto, qué reglas debe seguir, qué herramientas puede usar y qué sabe de vos o de tu proyecto. A todo ese paquete de instrucciones invisibles se le llama contexto, y diseñarlo bien es lo que se conoce como context engineering.

Es parecido a cuando entrenás a alguien nuevo en un trabajo: podés darle un manual gigante con cada regla posible para cada situación, o podés confiar en su sentido común y aclararle solo lo importante. Durante mucho tiempo, con la IA había que hacer lo primero (el manual gigante), porque los modelos más viejos necesitaban reglas muy explícitas para no cometer errores graves. Ahora que los modelos entienden mejor el contexto, gran parte de ese manual sobra.

El dato que abre el post

Anthropic eliminó más del 80% del system prompt de Claude Code (las instrucciones base que recibe el modelo) para los modelos más nuevos, y no notaron ninguna caída en sus evaluaciones de código. Es decir: gran parte de lo que antes parecía “necesario” para guiar al modelo, hoy sobra.

Los 6 cambios, explicados simple

1. Antes: reglas estrictas. Ahora: se confía en el criterio de Claude.
Antes había que ser muy explícito para evitar errores graves (como que borrara archivos por error), aunque esas reglas no siempre fueran correctas para todos los casos. Hoy el modelo tiene mejor criterio y puede decidir según el contexto, en vez de seguir una regla fija a rajatabla.

2. Antes: mostrar ejemplos de uso. Ahora: diseñar bien la herramienta.
Cuando le mostrás a Claude un ejemplo de “así se usa esta herramienta”, el modelo tiende a copiar ese patrón al pie de la letra, incluso cuando no es la mejor forma de resolver algo distinto. Es mejor diseñar la herramienta (sus opciones, sus nombres) de forma clara, para que no haga falta mostrar ejemplos.

3. Antes: poner todo en el prompt inicial. Ahora: cargar información solo cuando hace falta (“progressive disclosure”).
En vez de meter absolutamente todo en las instrucciones iniciales (lo cual ocupa espacio y satura al modelo), ahora se divide la información en piezas más chicas (“Skills”) que Claude consulta solo cuando las necesita. Es como tener carpetas organizadas por tema en vez de un solo documento gigante.

4. Antes: repetir la misma instrucción en varios lugares. Ahora: decirla una sola vez, en el lugar correcto.
Los modelos viejos necesitaban que se les repitiera lo mismo en distintas partes del prompt para no olvidarlo. Los modelos nuevos no: alcanza con poner la instrucción una sola vez, justo donde corresponde.

5. Antes: el usuario tenía que guardar memoria a mano. Ahora: Claude la guarda sola.
Antes, si querías que Claude recordara algo tuyo (como tu stack tecnológico preferido), tenías que escribirlo vos mismo en un archivo. Ahora Claude detecta qué es relevante durante la conversación y lo guarda automáticamente.

6. Antes: planes simples en texto. Ahora: referencias más ricas.
Antes, un plan de trabajo era básicamente una lista en un archivo de texto. Ahora Claude puede trabajar con referencias mucho más precisas: una maqueta visual en HTML, una suite de tests, o incluso una “rúbrica” que define qué es un buen resultado en un área específica.

Ejemplos de prompts: antes vs ahora

Así se ven estos cambios en texto real de prompt, según lo que comparte el hilo (y algunos ejemplos adicionales para que quede más claro):

1. Reglas rígidas → criterio propio

ANTES (system prompt viejo):
"Por defecto, no escribas comentarios. Nunca escribas docstrings de
varios párrafos ni bloques de comentarios de varias líneas — máximo
una línea corta. No crees documentos de planificación, decisión o
análisis salvo que el usuario los pida."

AHORA (system prompt nuevo):
"Escribí código que se lea como el código que lo rodea: igualá la
densidad de comentarios, nombres e idioma del resto del archivo."

Enter fullscreen mode Exit fullscreen mode

2. Ejemplos de uso → diseño de la herramienta

ANTES (con ejemplos en el prompt):
"Herramienta Todo. Ejemplo de uso:
  todo_write(status='pending', text='Escribir tests')
  todo_write(status='in_progress', text='Escribir tests')
  todo_write(status='completed', text='Escribir tests')
Seguí este patrón para cada tarea."

AHORA (diseño del parámetro, sin ejemplos):
"status: enum ['pending', 'in_progress', 'completed'].
Solo puede haber un ítem en estado in_progress a la vez."

Enter fullscreen mode Exit fullscreen mode

3. Todo al inicio → progressive disclosure

ANTES (CLAUDE.md monolítico):
"# CLAUDE.md
Este repo es una API en Node. Usa Express. Los archivos de rutas
están en /routes. Para verificar tu trabajo corré los tests con
npm test, después revisá el linter con npm run lint, después
revisá los tipos con npm run typecheck, después revisá que no
haya console.log, después... [200 líneas más de pasos]"

AHORA (CLAUDE.md liviano + skill referenciada):
"# CLAUDE.md
Este repo es una API en Node/Express. Los tipos viven solo en
types/index.ts, no los repitas en otros archivos.
Para verificar tu trabajo, usá la skill de verificación."
(la skill 'verificacion.md' se carga solo cuando hace falta)

Enter fullscreen mode Exit fullscreen mode

4. Repetir instrucciones → descripción simple en la herramienta

ANTES (duplicado en el system prompt Y en la herramienta):
System prompt: "Cuando uses la herramienta Read, recordá que
solo lee archivos, no directorios. Usá ls para listar directorios."
Descripción de la herramienta Read: "Lee un archivo. No lee
directorios, usá ls para eso."

AHORA (una sola vez, en la herramienta):
Descripción de la herramienta Read: "Lee un archivo. No lee
directorios, usá ls para eso."
(el system prompt ya no repite esta instrucción)

Enter fullscreen mode Exit fullscreen mode

5. Memoria manual → memoria automática

ANTES (el usuario tenía que escribirlo a mano):
Usuario escribe: "#Siempre prefiero TypeScript sobre JavaScript
en mis proyectos nuevos"
-> esto se guardaba tal cual en CLAUDE.md

AHORA (Claude lo detecta y lo guarda solo):
Usuario dice en la conversación: "che, en este proyecto prefiero
TypeScript"
-> Claude guarda automáticamente esa preferencia en su memoria

Enter fullscreen mode Exit fullscreen mode

6. Specs simples → referencias enriquecidas

ANTES (spec como markdown):
"plan.md:
1. Crear componente de login
2. Debe tener campos email y password
3. Debe validar el formato del email"

AHORA (spec como artifact HTML o test suite):
"Referencia: login-mockup.html (artifact con el diseño exacto,
colores y espaciado del formulario)"
o
"Referencia: tests/login.spec.ts (suite de tests que define el
comportamiento esperado del login)"

Enter fullscreen mode Exit fullscreen mode

7. Ejemplo extra: instrucciones que se contradicen

Este es un problema real que menciona el hilo: cuando distintas partes del contexto se pisan entre sí.

ANTES (choque de instrucciones sin resolver):
System prompt: "NO agregues comentarios en el código."
Skill del equipo: "Dejá documentación cuando corresponda."
Usuario: "Documentá bien esta función, es compleja."
-> El modelo viejo no sabía bien a cuál instrucción priorizar.

AHORA (se confía en que Claude resuelva la tensión con criterio):
El modelo nuevo entiende que el pedido explícito del usuario en
ese momento tiene más peso que una regla general, y documenta
solo esa función compleja sin romper el resto de las convenciones.

Enter fullscreen mode Exit fullscreen mode

8. Ejemplo extra: usar una rúbrica en vez de una regla fija

ANTES (regla fija y genérica):
"Los endpoints de la API deben seguir buenas prácticas de diseño."

AHORA (rúbrica concreta para verificar):
"Antes de dar por terminado un endpoint nuevo, verificá:
1. ¿Usa el verbo HTTP correcto (GET no modifica datos)?
2. ¿Devuelve códigos de error claros (404, 400, 401)?
3. ¿El nombre del recurso está en plural y en inglés?
Si falla alguno, corregilo antes de continuar."
(esta rúbrica se puede pasar como referencia, y hasta usarse
para que un agente verificador revise el trabajo de otro)

Enter fullscreen mode Exit fullscreen mode

Cómo armar tu propio contexto (con ejemplos concretos)

• System prompt: define en qué producto está operando Claude. Ejemplo: “Sos el asistente de soporte de Acme Inc. Respondé siempre en español neutro y nunca inventes precios.” Si estás construyendo tu propio agente, es donde más tiempo tenés que invertir.
• CLAUDE.md: que sea liviano, enfocado en las particularidades del repo. Ejemplo: en vez de explicar qué es un archivo package.json (obvio para Claude), escribí algo como “Los tipos compartidos viven solo en types/index.ts, no los dupliques en otros archivos.”
• Skills: guías livianas para tareas puntuales. Ejemplo: una skill llamada verificacion.md que Claude abre solo cuando necesita revisar su propio trabajo, con los pasos específicos de tu equipo (correr tests, chequear linter, etc.).
• Referencias: podés mencionar archivos con @ para dar contexto de alta fidelidad. Ejemplo: en vez de describir “quiero un botón azul con bordes redondeados”, adjuntar un mockup en HTML con el diseño exacto suele dar mejores resultados que una descripción en palabras.

Mi conclusión

Todo el hilo se puede resumir en una sola idea: a medida que los modelos mejoran su criterio, dejar de controlar cada detalle y empezar a guiar solo lo justo y necesario. Vale la pena revisar tus propios CLAUDE.md, prompts y skills con esa misma pregunta: ¿estoy poniendo reglas que este modelo ya no necesita?

Resumen basado en el hilo de Thariq (@trq212) en X.