Claude 5: Anthropic eliminó el 80% del prompt y no pasó nada

En pocas palabras: Anthropic reveló que para Claude Opus 5 y Fable 5 eliminó el 80% del system prompt de Claude Code sin impacto en rendimiento, y estableció nuevas reglas de contexto conciso, sin instrucciones redundantes.

Anthropic sacudió el tablero de la ingeniería de contexto en julio de 2026. Sin mucho preámbulo, la empresa anunció que para la nueva generación de modelos Claude 5 eliminó más del 80% del system prompt que usaba Claude Code. ¿El resultado más llamativo? Según sus métricas internas de evaluación de código, no hubo ninguna pérdida de rendimiento. Cero.

Anthropic es una empresa de inteligencia artificial que desarrolla la familia de modelos Claude, diseñados para tareas de lenguaje natural como generación de texto y asistencia. Fue fundada para avanzar en sistemas de IA seguros y robustos.

La ingeniería de contexto es el arte de ensamblar todas las piezas de información que el modelo recibe antes incluso de que el usuario escriba una sola palabra: el system prompt, los archivos de configuración como CLAUDE.md, las Skills cargadas, la memoria persistente y cualquier otra directiva general. A diferencia de un prompt —que es específico para una consulta—, el contexto se reutiliza una y otra vez en múltiples requests. Anthropic acaba de mostrar que, para la generación Claude 5, ese contexto reusable puede (y debe) ser mucho más flaco de lo que veníamos armando.

¿Qué es la ingeniería de contexto en los modelos Claude 5 de Anthropic?

Ingeniería de contexto es el proceso de diseñar, depurar y mantener todo el material que el modelo recibe como marco de trabajo permanente. No hablamos del prompt que escribís en el momento —”hacerme un script en Python que parse CSV”— sino de las instrucciones generales que definen cómo debe comportarse el asistente en cada interacción. El system prompt de Claude Code, por ejemplo, incluía (hasta mediados de julio de 2026) cientos de líneas con reglas de estilo, restricciones de output, ejemplos de formato y guías de troubleshooting que el modelo acarreaba en cada conversación.

Ponele que armás un agente para revisar PRs en GitHub. La ingeniería de contexto incluiría tu archivo CLAUDE.md con las convenciones del equipo, el system prompt que define el tono del feedback, y quizás una Skill que le explica cómo conectarse a la API de GitHub. Todo eso se carga antes de que el usuario diga “revisame este PR”. El problema, según descubrió Anthropic, es que mucho de ese material sobra cuando el modelo ya infiere la intención por su cuenta.

¿Cómo cambiaron las reglas de contexto para Claude 5?

El cambio es brutal en términos cuantitativos, y casi invisible en los resultados. El equipo de Anthropic hizo la prueba extrema: tomó el system prompt completo de Claude Code —esa masa de instrucciones que se fue acumulando con los años— y empezó a podar. Sacaron restricciones, eliminaron ejemplos redundantes, borraron guías paso a paso para tareas que los modelos nuevos resuelven con una sola oración. Cuando terminaron, habían volado el 80% del contenido. Complementá con nuestra comparativa de GPT y Claude.

Lo probaron con Claude Opus 5 y Claude Fable 5 en sus evaluaciones internas de programación. La puntuación no se movió. No decayó la calidad del código generado, no aumentaron los errores de sintaxis, no fallaron las integraciones. El modelo, simplemente, no necesitaba todo ese andamiaje. Es como cuando dejás de explicarle a un dev senior cómo se usa git —se ofende hasta.

Ahora bien, ¿qué implica esto para quien diseña agentes o usa Claude Code a diario? Que podés (y deberías) hacer una auditoría de tu propio contexto. Abrí tu CLAUDE.md, revisá tu system prompt, mirá tus Skills. ¿Cuánto de eso le está explicando al modelo cosas que ya sabe? ¿Cuántas restricciones son muletas heredadas de generaciones anteriores? La regla de oro que propone Anthropic es: si el modelo puede inferirlo, no se lo digas.

¿Por qué Anthropic eliminó el 80% del prompt del sistema de Claude Code?

La razón de fondo es que Claude Opus 5 y Claude Fable 5 tienen una capacidad de inferencia mucho más refinada que sus predecesores. Donde antes necesitabas decir “cuando generes código, usá snake_case para las variables, no mezcles comillas simples con dobles dentro del mismo archivo, y acordate de cerrar todos los paréntesis”, ahora el modelo mira el archivo CLAUDE.md, detecta el estilo del proyecto y se alinea solo.

El problema de tener contextos inflados no es solo el costo en tokens (que también, y en la API se paga), sino que las instrucciones excesivas compiten entre sí. Un system prompt demasiado detallado puede hacer que el modelo se vuelva rígido en situaciones que requieren criterio, o que priorice una regla menor por encima de la intención real del usuario. El anuncio oficial de Anthropic plantea que el exceso de contexto no solo es inútil, es contraproducente.

Al afinar el contexto, los modelos ganan flexibilidad. Responden mejor a prompts ambiguos, se adaptan a cambios de rumbo en medio de una sesión de código, y evitan ese fenómeno tan molesto de “disculpá, pero mi system prompt me prohíbe hacer eso”.

¿Cuáles son los principios clave de la nueva ingeniería de contexto?

El artículo de Anthropic no baja una lista numerada de mandamientos, pero los principios se desprenden con claridad del experimento que hicieron y de cómo reescribieron su propio system prompt. Los resumo acá: Lo explicamos a fondo en el análisis de ofertas de OpenAI y Anthropic.

• Sé conciso, casi hasta lo brutal. Si una instrucción no cambia el output de manera apreciable, probablemente sobra. Mejor pecar de corto que de extenso.
• Eliminá toda redundancia. No le digas al modelo dos veces lo mismo con distintas palabras. No refuerces reglas obvias con ejemplos. Confiá en que entendió a la primera.
• Usá Skills y CLAUDE.md con moderación. Las Skills son herramientas, no muletas. Cargá solo las que el flujo de trabajo realmente necesita. ¿Tu agente nunca toca bases de datos? No le cargues la Skill de SQL “por si acaso”.
• Priorizá la claridad sobre la cantidad. Un párrafo de 50 palabras bien escrito pesa más que tres párrafos de 100 que dicen lo mismo dando vueltas. Cada oración tiene que ganarse su lugar en el contexto.
• Probá iterativamente. Sacá una sección del system prompt, corré tus tests, medí. Si no notás diferencia, dejalo afuera. Es la misma lógica de un refactor de código: si no rompe nada y simplifica el archivo, va para adentro.

Ojo con el exceso de optimismo acá. Que Anthropic haya logrado recortar el 80% en sus propios tests no significa que vos puedas llegar y amputar tu system prompt de un saque. La poda fue quirúrgica y validada contra un benchmark interno. La moraleja no es “borrá todo”, es “cuestioná todo”. Cada línea de tu contexto debería estar bajo sospecha.

¿Cómo aplicar estas reglas en Claude Code y en tus propios agentes?

Arrancá por lo más pesado. Abrí tu archivo CLAUDE.md —ese que fuiste llenando con buenas intenciones durante meses— y leelo con la cabeza de Claude 5. Preguntate: si yo fuera un modelo que ya sabe programar en TypeScript, ¿necesito que me expliquen que las interfaces van en archivos separados? Probablemente no. Lo que sí necesita es saber el path donde tu proyecto guarda las interfaces, o el prefijo que usan para nombrarlas. Eso es información que el modelo no puede inferir. Lo otro es ruido.

Con las Skills, la misma lógica. Si tu agente hace CI/CD, la Skill que le explica cómo correr tests unitarios es redundante —cualquier LLM decente sabe cómo ejecutar pytest o jest—, pero la Skill que le da acceso a tu pipeline interno de Jenkins y le explica la estructura de stages específica de tu empresa es oro puro.

El proceso que sugiere Anthropic (y que yo mismo apliqué esta semana con resultados bastante decentes) es:

• Hacé un backup. Siempre. Parece obvio, pero la cantidad de gente que edita system prompts en caliente sin versionar es alarmante.
• Empezá por las secciones más largas. Las secciones con ejemplos extensos, reglas de formato y guías paso a paso son las primeras candidatas a reducción.
• Eliminá una sección por vez, corré tu batería de tests, medí el resultado. Si tu evaluación de código no tiene métricas claras, armálas antes de tocar nada —sin medición, estás podando a ciegas.
• Consolidá reglas dispersas. A veces tenés la misma restricción repetida en tres formatos distintos (en el system prompt, en CLAUDE.md y en una Skill). Unificá todo en un solo lugar y borrá el resto.
• Dejá que el modelo respire. En vez de decirle exactamente cómo formatear una respuesta, describí el objetivo y confiá en que encontrará la forma. “Quiero feedback claro y accionable sobre PRs” rinde más que “usá bullets, empezá con verbo en imperativo, máximo 3 líneas por comentario, no uses negrita, etc.”.

¿Qué modelos de Claude 5 se benefician más de estas reglas?

Anthropic menciona específicamente dos modelos: Claude Opus 5 y Claude Fable 5. La diferencia entre ambos no es menor, y determina cuánto podés confiar en que el modelo infiera lo que necesita. Relacionado: la capacidad de cómputo de Anthropic en 2026.

Característica	Claude Opus 5	Claude Fable 5
Inferencia	Máxima. Ideal para tareas complejas, razonamiento multi-step, debugging profundo.	Alta, pero optimizada para velocidad y eficiencia.
Tolerancia al contexto mínimo	Muy alta. Funciona bien con instrucciones escuetas incluso en escenarios ambiguos.	Alta, pero conviene dejar directivas clave para mantener consistencia.
Uso recomendado	Agentes complejos, code review en proyectos grandes, arquitectura de software.	Automatizaciones rápidas, CI/CD liviano, agentes de productividad diaria.
Cuánto podar	Agresivamente. Podés eliminar hasta el 80-90% del contexto heredado.	Con criterio. Apuntá a un 50-70%, reteniendo reglas de negocio específicas.
Velocidad	Menor, por profundidad de razonamiento.	Mayor, optimizado para baja latencia.

La lógica es simple: si estás pagando por Opus 5, es porque necesitás razonamiento fino. Ese modelo ya viene con un motor de inferencia tan potente que explicarle cosas obvias es literalmente tirar tokens a la basura. Con Fable 5, que está pensado para tareas más repetitivas y donde la velocidad importa, conviene mantener algunas directivas mínimas que eviten desvíos, sobre todo si operás en un entorno con reglas de negocio muy específicas.

¿La reducción de contexto afecta la eficiencia o la precisión del modelo?

No, y ese es justamente el punto. Según los datos publicados por Anthropic, la eliminación del 80% del system prompt de Claude Code no produjo ninguna pérdida medible en sus evaluaciones de programación. Digo “medible” porque los benchmarks internos de la empresa son la vara con la que miden —no hay un paper independiente auditando esto, y habría que ver si la comunidad de desarrolladores reporta lo mismo cuando haga sus propias pruebas.

Hay un efecto colateral positivo que Anthropic no destaca demasiado pero que para cualquiera que use la API es evidente: menos contexto fijo significa menos tokens de entrada por cada request. Si tu agente hace cientos de llamadas por día, recortar system prompt se traduce en menor latencia y menor costo operativo. En producción, eso es plata y tiempo de respuesta.

Eso sí, me queda una duda razonable. El anuncio habla de evaluaciones de código —un dominio donde los modelos ya son muy buenos—, pero no menciona otros escenarios. ¿Qué pasa con tareas de razonamiento legal o médico, donde las restricciones del system prompt existen por compliance y no por capricho? Ahí la poda requiere más cuidado. No es lo mismo eliminar una regla de formato de código que borrar una restricción sobre datos sensibles. Habrá que ver qué reportan los equipos que usan Claude en esos verticales regulados.

¿Puedo usar Claude 5 con ingeniería de contexto para tareas de programación o generación de código?

Sí, y de hecho es el caso de uso donde más brilla esta nueva filosofía. Claude Code ya corre con Claude Opus 5 y Claude Fable 5 bajo estas reglas recortadas recientemente. Si estás usando Claude Code hoy, ya te estás beneficiando de la poda sin haber movido un dedo —el system prompt que carga Anthropic ya es el flamante y depurado.

Para tus propios agentes de código, la pregunta no es si podés, sino cómo. Empezá chico: tomá un agente que usás seguido, hacé una copia de su contexto, y metele tijera quirúrgica. Probá en staging, no en prod. Medí la calidad del output con un set de casos representativo y compará con la versión anterior. Si no perdés precisión, ganaste en velocidad y en costos. En la comparativa detallada entre OpenAI y Anthropic profundizamos sobre esto.

Errores comunes al aplicar la nueva ingeniería de contexto

He visto a más de un equipo emocionarse con el anuncio y mandarse cagadas que se podían evitar. Estos son los tres errores que más se repiten:

• Borrar restricciones de seguridad o compliance pensando que son “redundantes”. El modelo puede inferir cómo escribir buen código, pero no puede inferir las políticas de privacidad de tu empresa ni las regulaciones de tu industria. Las reglas que existen por obligación legal o contractual se quedan, siempre. No son negociables, por más que el modelo “podría deducirlas” —no querés que las deduzca mal.
• Confundir “contexto mínimo” con “cero instrucciones”. Anthropic eliminó el 80% de su system prompt, no el 100%. El 20% que quedó cumple una función: alinear el tono, establecer límites de lo que el asistente puede o no hacer, y darle información que ningún modelo puede inferir. Si dejás el system prompt en blanco, el modelo funciona, pero perdés control sobre el comportamiento.
• No medir antes y después de cada cambio. Podar contexto sin métricas es como refactorizar sin tests —”funciona en mi máquina” no es un argumento. Definí un conjunto de casos de prueba representativo, medí métricas clave (tasa de éxito, relevancia del output, latencia) y solo validá el cambio si los números te respaldan. Si no tenés ganas de armar un benchmark, al menos hacé una revisión manual de 20 o 30 outputs antes y después del cambio.

Qué significa para equipos de desarrollo en Latinoamérica

En la región, donde muchas startups y equipos corren agentes de código sobre infraestructura ajustada, pagar menos tokens por request es una ventaja nada despreciable. Si tu agente de revisión de PRs hace 500 llamadas diarias a la API y cada una gasta 2.000 tokens de entrada en un system prompt inflado, estás quemando un millón de tokens por día solo en instrucciones que el modelo ya no necesita. Podar ese contexto no solo mejora la calidad del output, también baja la factura.

Para equipos que hospedan sus agentes en servidores locales o VPS —como los que ofrece donweb.com—, la reducción de tokens se traduce en menor latencia de procesamiento y en la posibilidad de correr más requests por minuto con el mismo hardware. En ambientes donde cada milisegundo cuenta (CI/CD con triggers automáticos, por ejemplo), el impacto es palpable.

Preguntas Frecuentes

¿Qué es la ingeniería de contexto en los modelos Claude 5?

Es el conjunto de técnicas para diseñar, depurar y optimizar toda la información que el modelo recibe como marco de trabajo fijo (system prompt, CLAUDE.md, Skills, memoria) antes de cualquier interacción del usuario. Anthropic demostró recientemente que los modelos Claude 5 funcionan mejor con contextos mucho más escuetos que sus predecesores, al punto de eliminar el 80% del system prompt de Claude Code sin perder rendimiento en evaluaciones de código.

Si querés saber más sobre el nuevo modelo de Anthropic, leé nuestro artículo sobre Opus 5.

¿Por qué Anthropic eliminó el 80% del prompt de sistema de Claude Code?

Porque Claude Opus 5 y Claude Fable 5 infieren mucho más por su cuenta que los modelos anteriores. Las reglas detalladas, los ejemplos redundantes y las restricciones excesivas se volvieron innecesarios y hasta contraproducentes, ya que competían con la capacidad del modelo para adaptarse a cada tarea. La poda redujo el costo en tokens y mejoró la flexibilidad del asistente sin sacrificar precisión en la generación de código.

¿Cómo puedo aplicar las reglas de ingeniería de contexto en mi propio agente con Claude 5?

Hacé una copia de tu contexto actual, revisá el system prompt, CLAUDE.md y Skills, y eliminá toda instrucción que el modelo pueda inferir por sí mismo. Probá cada recorte contra un conjunto de casos representativo, midiendo la calidad del output antes y después. Mantené solo las reglas específicas de tu negocio o entorno que ningún LLM podría deducir sin información externa.

¿Qué diferencia hay entre Claude Opus 5 y Claude Fable 5 para ingeniería de contexto?

Opus 5 tolera contextos extremadamente mínimos, incluso en tareas complejas, y podés eliminar hasta el 80-90% de las instrucciones heredadas. Fable 5, optimizado para velocidad y eficiencia, se beneficia de una poda más moderada (50-70%), conservando directivas clave que mantengan la consistencia en tareas repetitivas o entornos con reglas de negocio muy específicas.

Conclusión

Anthropic acaba de validar con números lo que muchos intuíamos pero no nos animábamos a probar: que los modelos de quinta generación no necesitan que les digamos cómo hacer su trabajo. El experimento de podar el 80% del system prompt de Claude Code sin perder rendimiento es una señal fuerte de hacia dónde va el diseño de agentes: contextos mínimos, instrucciones quirúrgicas y mucha más confianza en la capacidad de inferencia del modelo.

Si mantenés tu CLAUDE.md con cientos de líneas, tus Skills con instrucciones obvias y tu system prompt atiborrado de ejemplos que ya no suman, hacete un favor esta semana: versioná todo, abrí el bisturí y empezá a podar. Probá en staging, medí con cabeza, y dejá solo lo que realmente importa. Los números de Anthropic dicen que funciona. Los míos, después de una semana de pruebas, coinciden.

Fuentes

• Anthropic – The new rules of context engineering for Claude 5 generation models
• Anthropic – Claude Code documentation
• Anthropic – Official news and announcements (2026)