Leyendo el hilo de Thariq (@trq212), quien trabaja en Claude Code en Anthropic, sobre cómo cambió la forma de escribir system prompts, skills y archivos CLAUDE.md para la nueva generación de modelos Claude 5. Estos son los puntos que más me llamaron la atención, traducidos y resumidos.
El dato que abre el post
Anthropic eliminó más del 80% del system prompt de Claude Code para modelos como Claude Opus 5 y Claude Fable 5, sin pérdida medible en sus evaluaciones de código. Es decir: gran parte de lo que antes se consideraba "necesario" para guiar al modelo, hoy sobra.
¿Qué es "context engineering"?
Cuando le mandás un mensaje a Claude, el prompt que escribís es solo una parte pequeña del contexto que realmente recibe el modelo. El resto se arma con el system prompt, los Skills, los archivos CLAUDE.md, la memoria y otras fuentes. A diferencia de un prompt puntual, el contexto se usa de forma general en muchas solicitudes distintas, así que no puede ser tan específico.
Los 6 cambios de paradigma (antes → ahora)
- De reglas rígidas a criterio propio. Antes se le daban instrucciones muy estrictas a Claude para evitar errores graves (como borrar archivos), aunque no siempre fueran ciertas para todos los casos. El problema: para ciertos usuarios o partes de código muy complejas, esas reglas eran directamente incorrectas. Ver ejemplo de prompt más abajo.
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."
- De ejemplos a buen diseño de herramientas. Dar ejemplos de cómo usar una herramienta termina limitando el espacio de exploración del modelo a repetir ese mismo patrón. Es mejor invertir en el diseño de los parámetros de la herramienta para que sean expresivos por sí mismos.
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."
- De volcar todo al inicio a "progressive disclosure". En vez de meter toda la información posible en el system prompt, ahora se separa en Skills que Claude carga solo cuando las necesita. Esto también aplica a las herramientas: algunas tienen "carga diferida" (deferred loading), donde el agente busca su definición completa recién cuando la necesita.
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)
- De repetir instrucciones a descripciones simples en las herramientas. Los modelos más viejos podían necesitar instrucciones repetidas en varios lugares del contexto. Los modelos nuevos no: la instrucción vive una sola vez, en la descripción de 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)
- De guardar memoria manual en CLAUDE.md a memoria automática. Antes se animaba a los usuarios a escribir a mano en su CLAUDE.md. Ahora Claude guarda automáticamente en su memoria lo que es relevante para el trabajo y para el usuario, sin ese paso manual.
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
- De specs simples a referencias enriquecidas. Antes los planes eran solo markdown. Ahora Claude puede manejar referencias más ricas: artifacts HTML, suites de tests, funciones de otro repositorio, o incluso "rúbricas" para verificar el buen gusto en un área concreta.
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)"
Cómo armar tu propio contexto (resumen práctico)
- System prompt: define en qué producto está operando Claude. 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 (los "gotchas"), no en cosas obvias que Claude ya puede inferir del código.
- Skills: guías livianas para que Claude encuentre información cuando la necesita, sin sobre-restringir. Ideales para codificar prácticas u opiniones específicas de tu equipo.
- Referencias: podés mencionar archivos con @ para dar contexto de alta fidelidad. Un mockup en HTML, por ejemplo, suele funcionar mejor que una simple descripción o captura de pantalla.
Mi conclusión
El hilo completo se puede resumir en una idea: a medida que los modelos mejoran su criterio, la ingeniería de contexto pasa de "controlar todo" a "guiar lo justo y necesario". Vale la pena revisar nuestros propios CLAUDE.md, prompts y skills con esta misma lupa: ¿estamos sobre-restringiendo al modelo con reglas que ya no hacen falta?
Resumen basado en el hilo de Thariq (@trq212) en X.
Top comments (1)
Enterada. gracias por compartir