¿Claude y Codex se vuelven más tontos cuanto más los usas? Porque tu contexto es demasiado abultado

Autor: sysls

Compilado por: Deep潮 TechFlow

Guía de Deep潮: El creador de contenido y desarrollador con 2.6 millones de seguidores, sysls, escribió un artículo práctico y extenso que fue compartido por 827 personas y recibió 7000 me gusta. La idea central es una sola frase: tus plugins, sistemas de memoria y diversos harness probablemente están haciendo más daño que bien. Este artículo no se basa en grandes principios teóricos, sino que recopila principios operativos extraídos de proyectos reales en producción — desde cómo controlar el contexto, manejar la tendencia de la IA a complacer, hasta cómo definir las condiciones de finalización de una tarea. Es, hasta ahora, el artículo más claro que he visto sobre la práctica de ingeniería con Claude y Codex.

El texto completo es el siguiente:

Introducción

Eres un desarrollador y todos los días usas Claude y Codex CLI, preguntándote si realmente has exprimido toda su capacidad. De vez en cuando, ves que hacen cosas absurdamente tontas y no entiendes por qué algunas personas parecen construir cohetes con IA, mientras tú ni siquiera logras apilar dos piedras sin que se caigan.

Piensas que el problema puede estar en tus harness, plugins, terminal, o qué sé yo. Usas beads, opencode, zep, y tu CLAUDE.md tiene 26,000 líneas. Pero, por más que lo intentas, no entiendes por qué cada vez estás más lejos del paraíso, mientras otros juegan con ángeles.

Esa es la clase de artículo que has estado esperando.

Por cierto, no tengo intereses ocultos. Digo que CLAUDE.md también incluye AGENT.md, y que Claude incluye a Codex; los uso ambos en gran medida.

En los últimos meses, he observado algo interesante: casi nadie sabe realmente cómo maximizar la capacidad de los agentes.

Parece que hay un pequeño grupo que puede hacer que los agentes construyan todo un mundo, mientras que el resto se pierde en un mar de herramientas, sufriendo de síndrome de selección — creyendo que encontrar el paquete, la habilidad o el harness correctos desbloqueará la AGI.

Hoy, quiero romper con todo eso, dejarte una frase sencilla y honesta, y partir de allí. No necesitas el harness más reciente, ni instalar un millón de paquetes, ni leer un millón de artículos para mantenerte competitivo. De hecho, tu entusiasmo puede ser más perjudicial que beneficioso.

No estoy aquí de turismo — empecé a usar estos agentes cuando apenas podían escribir código. Probé todos los paquetes, harnesses y paradigmas. Escribí fábricas de agentes para señales, infraestructura y tuberías de datos; no son «proyectos de juguete», sino casos de uso reales en producción. Después de todo esto…

Hoy, uso una configuración casi minimalista, con solo lo básico: CLI (Claude Code y Codex), y una comprensión fundamental de algunos principios de ingeniería de agentes, y con eso he logrado mi trabajo más innovador hasta ahora.

Entender que el mundo avanza a toda velocidad

Primero, debo decir que las empresas de modelos base están en una carrera revolucionaria, y claramente no van a desacelerar pronto. Cada mejora en la «inteligencia de los agentes» cambiará la forma en que colaboras con ellos, porque están diseñados para seguir instrucciones cada vez más fácilmente.

Hace unas generaciones, si en CLAUDE.md ponías «Antes de hacer cualquier cosa, lee READTHISBEFOREDOINGANYTHING.md», tenías un 50% de probabilidad de que te respondiera «vete a la mierda» y siguiera haciendo lo que quería. Hoy, cumple con la mayoría de las instrucciones, incluso con instrucciones anidadas complejas — como decir «Primero lee A, luego lee B, y si C, lee D» — y en la mayoría de los casos, seguirá tus indicaciones.

¿Y qué significa esto? La regla más importante es entender que cada nueva generación de agentes te obliga a repensar qué es la mejor solución, y por eso menos es más.

Cuando usas muchas librerías y harnesses diferentes, te encadenas a una «solución» que puede no existir en la próxima generación de agentes. ¿Sabes quiénes son los usuarios más entusiastas y que más usan los agentes? Exacto: empleados de empresas punteras, con presupuestos ilimitados de tokens, usando los modelos más recientes. ¿Sabes qué implica eso?

Implica que si un problema real existe y tiene una buena solución, esas empresas serán los mayores usuarios de esa solución. ¿Y qué harán después? La integrarán en sus productos. Piensa: ¿por qué una compañía permitiría que otro producto resuelva un problema real y cree dependencias externas? ¿Cómo sé que eso es cierto? Mirando las habilidades, memorias, harnesses, subagentes… todos ellos comienzan con una «solución» que resuelve un problema real, y que ha sido probada en la práctica y demostrada útil.

Por eso, si algo realmente tiene un impacto revolucionario y puede escalar en los casos de uso de los agentes de manera significativa, eventualmente será parte del núcleo del producto de las empresas base. Créeme, esas empresas avanzan a toda velocidad. Así que relájate: no necesitas instalar nada ni depender de terceros para hacer un trabajo excelente.

Preveo que en los comentarios pronto dirán: «SysLS, uso tal harness, ¡y es increíble! ¡Recreé Google en un día!» — y a eso digo: ¡Felicidades! Pero tú no eres el público objetivo; representas a una comunidad muy pequeña, que realmente entiende la ingeniería de agentes.

El contexto lo es todo

De verdad. El contexto lo es todo. Otro problema de usar mil plugins y dependencias externas es que sufres de «inflación de contexto»: tu agente se ahoga en demasiada información.

¿Quieres que haga un juego de adivinar palabras en Python? Fácil. Espera, ¿qué dice esa nota de «gestión de memoria» de hace 26 conversaciones? Ah, el usuario tiene una pantalla atascada desde hace 71 conversaciones por generar demasiados subprocesos. ¿Siempre hay que poner notas? Bueno, sin problema… ¿qué tiene que ver esto con el juego de adivinar palabras?

Lo sabes. Solo quieres darle al agente la información precisa para completar la tarea, ni más ni menos. Cuanto mejor controles eso, mejor será su rendimiento. Pero si empiezas a introducir sistemas de memoria extraños, plugins, o habilidades con nombres y llamadas confusos, le estás dando instrucciones para construir una bomba y una receta para un pastel, cuando solo quieres que escriba un poema sobre un bosque de secuoyas.

Por eso, vuelvo a predicar: elimina todas las dependencias, y…

Haz algo realmente útil

Describe con precisión los detalles de implementación

¿Recuerdas que el contexto lo es todo?

¿Recuerdas que quieres darle al agente la información exacta, ni más ni menos, para completar la tarea?

La primera forma de lograr esto es separar investigación y ejecución. Debes ser extremadamente preciso sobre qué le pides al agente que haga.

¿Y qué pasa si no eres preciso? «Haz un sistema de autenticación». El agente tendrá que investigar: ¿qué es un sistema de autenticación? ¿Qué opciones hay? ¿Cuáles son sus ventajas y desventajas? Ahora, tendrá que buscar en internet un montón de información que en realidad no le sirve, y en su contexto se llenan de detalles de implementación posibles. Cuando llegue el momento de implementar, será más fácil confundirse o tener ilusiones irrelevantes o innecesarias sobre las soluciones.

En cambio, si dices: «Usa bcrypt-12 para hash de contraseñas y crea JWT con rotación de tokens, expiración en 7 días…», el agente no necesita investigar otras alternativas, sabe exactamente qué quieres, y puede llenar el contexto con detalles de implementación.

Por supuesto, no siempre sabrás los detalles de implementación. Muchas veces, no sabrás qué es correcto, y a veces querrás dejar esa decisión en manos del agente. ¿Qué hacer entonces? Muy simple: crea una tarea de investigación para explorar diferentes opciones, decide tú mismo o deja que el agente decida qué implementación usar, y luego pasa esa decisión a otro agente con un contexto completamente nuevo para que la implemente.

Al pensar así, notarás en qué partes del flujo de trabajo el contexto del agente se está contaminando innecesariamente, y podrás crear barreras en ese flujo, abstraer esa información innecesaria, y dejar solo el contexto que realmente necesita para destacar en la tarea. Recuerda: tienes un equipo muy talentoso y listo, que conoce todos los tipos de bolas en el universo — pero a menos que le digas que quieres diseñar un espacio para bailar y divertirse, seguirá hablando de las ventajas de las formas esféricas.

Limitaciones del diseño para complacer

Nadie quiere usar un producto que te critique, te diga que estás equivocado o ignore tus instrucciones por completo. Por eso, estos agentes harán todo lo posible por estar de acuerdo contigo y hacer lo que quieres.

Si les pides que cada 3 palabras añadan «feliz», harán su mejor esfuerzo — y la mayoría entenderá esto. Su obediencia es lo que los hace productos tan útiles. Pero hay una característica muy interesante: eso significa que si dices «ayúdame a encontrar un bug en la base de código», lo encontrará — incluso si necesita «fabricar» uno. ¿Por qué? Porque quieren complacer tus instrucciones con todas sus fuerzas.

Muchos se quejan rápidamente de que los LLMs inventan cosas o generan falsedades, pero no se dan cuenta de que el problema está en ellos mismos. Tú pides algo, y eso es lo que entregan — aunque tengas que estirar un poco la realidad.

¿Y qué hacer? Descubrí que los «prompts neutros» son muy efectivos: no sesgan al agente hacia un resultado específico. Por ejemplo, en lugar de decir «ayúdame a encontrar un bug en la base de datos», dices «escanea toda la base de datos, sigue la lógica de cada componente, y reporta todo lo que encuentres».

Este prompt neutro a veces encuentra bugs, a veces solo describe cómo funciona el código objetivamente. Pero no sesga al agente hacia la suposición de que hay un bug.

Otra forma de manejar la tendencia a complacer es convertirla en una ventaja. Sé que el agente intenta agradarme y seguir mis instrucciones, así que puedo inclinar la balanza a mi favor.

Por ejemplo, hago que un agente que busca bugs identifique todos los bugs en la base de datos, asignando +1 punto a los bugs de bajo impacto, +5 a los de impacto medio, y +10 a los graves. Sé que ese agente será muy entusiasta en identificar todo tipo de bugs (incluidos algunos que no son bugs), y me dará un puntaje total, por ejemplo, 104. Lo considero un superconjunto de todos los posibles bugs.

Luego, hago que un agente adversario refute esos bugs, diciendo que cada bug refutado vale su puntaje, pero si se equivoca, pierde el doble de ese puntaje. Este agente intentará refutar tantos bugs como pueda, pero con una penalización, será cauteloso. Seguirá intentando refutar bugs (incluidos los reales), pero con un sesgo a la prudencia. Lo considero un subconjunto de los bugs reales.

Finalmente, hago que un árbitro combine las entradas de ambos y asigne una puntuación. Le digo que tengo una respuesta correcta, y que acierta +1, y se equivoca -1. Entonces, ese árbitro puntúa a los agentes de búsqueda y refutación en cada «bug». El árbitro dice qué es la verdad, y yo verifico. En la mayoría de los casos, este método es sorprendentemente preciso, aunque a veces comete errores, pero ya es un proceso casi infalible.

Quizá pienses que solo con el agente de búsqueda de bugs sería suficiente, pero a mí me funciona muy bien, porque aprovecha la tendencia natural del agente a querer agradar.

¿Cómo saber qué es útil y qué vale la pena usar?

Parece una pregunta difícil, que requiere profundizar en el estado del arte de la IA, pero en realidad es muy simple… si OpenAI y Claude lo implementan o adquieren la empresa que lo hace, probablemente sea útil.

¿Has notado que las «habilidades» (skills) están en todas partes y forman parte de la documentación oficial de Claude y Codex? ¿Has visto que OpenAI compró a OpenClaw? ¿Has visto que Claude añadió memoria, voz y trabajo remoto?

¿Y la planificación? ¿Recuerdas que muchos descubrieron que planear antes de implementar es muy útil, y que eso se convirtió en una función central?

Sí, esas cosas son útiles.

¿Y los «stop-hooks» infinitos, que son súper útiles porque los agentes no quieren hacer trabajos de larga duración… y luego, con Codex 5.2, esa necesidad desapareció de la noche a la mañana?

Eso es todo lo que necesitas saber… si algo es realmente importante y útil, ¡Claude y Codex lo implementarán por sí mismos! Así que no te preocupes demasiado por usar «nuevas cosas» o familiarizarte con ellas, ni siquiera necesitas «mantenerte actualizado».

Hazme un favor: actualiza de vez en cuando tu CLI preferido, revisa qué funciones nuevas tiene. Eso es suficiente.

Compresión, contexto y suposiciones

Algunas personas descubren un gran problema al usar agentes: a veces parecen los seres más inteligentes del planeta, y otras veces no puedes creer que te estén tomando el pelo.

«¿Este cosa es inteligente? ¡Es un idiota!»

La mayor diferencia está en si el agente se ve obligado a hacer suposiciones o «rellenar vacíos». Hoy en día, todavía son pésimos en «conectar puntos», «rellenar vacíos» o hacer suposiciones. Cuando lo hacen, se nota inmediatamente, y la situación empeora claramente.

Una de las reglas más importantes en CLAUDE.md es sobre cómo obtener el contexto, y cómo indicar al agente que, cada vez que lea CLAUDE.md (es decir, después de comprimir), debe leer esa regla primero. Como parte de las reglas para obtener contexto, unas instrucciones simples pueden tener un impacto enorme: volver a leer el plan de la tarea, y volver a leer los archivos relevantes antes de continuar.

Decirle al agente cómo terminar la tarea

Nuestra percepción de «completitud» de una tarea es bastante clara. Para el agente, el mayor problema actual es que sabe cómo empezar, pero no cómo terminar.

Esto a menudo lleva a resultados frustrantes: el agente termina implementando unos stub y se queda ahí.

Las pruebas son un gran hito para el agente, porque son deterministas: puedes establecer expectativas muy claras. A menos que esas X pruebas pasen, la tarea no está completa; y no puedes modificar las pruebas.

Luego, solo revisas las pruebas, y si todas pasan, puedes estar tranquilo. También puedes automatizar esto, pero lo importante es — recuerda: «el fin de la tarea» es algo natural para los humanos, pero no para los agentes.

¿Sabes qué otro método reciente se ha vuelto una forma viable de definir el fin de una tarea? ¡Capturas de pantalla + verificación! Puedes hacer que el agente implemente algo hasta que pase todas las pruebas, y luego tome capturas y verifique que el diseño o comportamiento en la captura sea correcto.

Esto te permite iterar con el agente y trabajar hacia el diseño que quieres, sin preocuparte de que se quede atascado en la primera versión.

Una extensión natural de esto es crear un «contrato» con el agente, y codificarlo en reglas. Por ejemplo, ese {TASK}CONTRACT.md especifica qué debe hacerse antes de que puedas terminar la sesión. En ese contrato, defines las pruebas, capturas y otras verificaciones necesarias antes de que puedas certificar que la tarea terminó.

Agentes que corren siempre

Una pregunta frecuente que me hacen es: ¿cómo hacer que un agente funcione 24 horas y que no se desvíe?

Aquí tienes un método muy simple: crea un stop-hook que impida que el agente termine la sesión, a menos que se hayan cumplido todas las partes del {TASK}_CONTRACT.md.

Si tienes 100 contratos bien definidos, que contienen todo lo que quieres construir, el stop-hook impedirá que el agente termine hasta que los 100 contratos estén completos, incluyendo todas las pruebas y verificaciones.

Consejo profesional: he descubierto que las sesiones largas de 24 horas no son la mejor opción para «hacer cosas». Parte de la razón es que, estructuralmente, esto introduce inflación de contexto, porque todos los contratos irrelevantes entran en la misma sesión.

Por eso, no lo recomiendo.

Una mejor automatización es abrir una nueva sesión por contrato. Cada vez que necesites hacer algo, crea un contrato nuevo.

Construye una capa de orquestación que cree un nuevo contrato y una nueva sesión cada vez que algo necesita hacerse.

Eso cambiará radicalmente tu experiencia con los agentes.

Iterar, iterar, iterar

¿Contrataste a un asistente administrativo? ¿Esperas que desde el primer día sepa tu agenda? ¿O cómo tomas tu café? ¿Cenas a las 6 en lugar de a las 8? Obviamente no. Con el tiempo, desarrollarás preferencias.

Lo mismo con los agentes. Comienza con una configuración simple, olvida las estructuras complejas o los harnesses, y prueba solo con lo básico del CLI.

Luego, añade tus preferencias poco a poco. ¿Cómo?

Reglas

Si no quieres que el agente haga algo, escríbelo como una regla. Y en CLAUDE.md, indícale esa regla. Por ejemplo: «Antes de escribir código, lee coding-rules.md». Las reglas pueden ser anidadas, y condicionales. Si estás escribiendo código, lee coding-rules.md; si estás escribiendo pruebas, lee coding-test-rules.md; si las pruebas fallan, lee coding-test-failing-rules.md. Puedes crear reglas con lógica condicional para que el agente las siga, y Claude (y Codex) estarán encantados de seguir esas instrucciones, siempre que en CLAUDE.md quede claramente explicado.

De hecho, esa es mi primera recomendación práctica: trata tu CLAUDE.md como un directorio lógico y anidado, que indique dónde buscar el contexto en diferentes escenarios y resultados específicos. Debe ser lo más simple posible, incluyendo solo lógica IF-ELSE que indique «en qué circunstancias buscar en qué lugar».

Si ves que el agente hace algo que no apruebas, añádele una regla, y dile que antes de volver a hacerlo, lea esa regla. Seguro que no lo volverá a hacer.

Habilidades (Skills)

Las habilidades son similares a las reglas, pero en lugar de preferencias de codificación, son más bien pasos operativos. Si quieres que algo se haga de una forma específica, intégralo en una habilidad.

De hecho, mucha gente se queja de no saber cómo resolver un problema, y eso genera inseguridad. Si quieres que sea determinista, primero haz que el agente investigue cómo resolvería ese problema, y escribe esa solución en un archivo de habilidades. Así, podrás ver cómo el agente abordará ese problema antes de que realmente lo enfrente, y podrás corregir o mejorar la solución.

¿Cómo le dices al agente que esa habilidad existe? Exacto: en CLAUDE.md, escribe que cuando encuentres ese escenario, lee el archivo SKILL.md correspondiente.

Gestionar reglas y habilidades

Seguramente querrás seguir añadiendo reglas y habilidades. Esa es la forma en que le das personalidad y memoria de preferencias. Casi todo lo demás es redundante.

Una vez que empieces a hacer esto, tu agente parecerá magia. «Hará las cosas como quieres». Y finalmente sentirás que has «entendido» la ingeniería de agentes.

Y luego…

Verás que el rendimiento empieza a disminuir otra vez.

¿¡Qué pasa!?

Muy simple. Cuantas más reglas y habilidades añades, más empiezan a contradecirse, o el agente sufre de inflación de contexto severa. Si necesitas que lea 14 archivos markdown antes de programar, tendrás el mismo problema de información inútil.

¿Qué hacer?

Limpiar. Haz que tu agente «haga un spa», integre reglas y habilidades, y mediante tus indicaciones actualizadas, elimine contradicciones.

Y volverá a parecer magia.

Eso es todo. Esa es la clave: mantenerlo simple, usar reglas y habilidades, tratar CLAUDE.md como un directorio, y ser consciente de sus límites y de cómo el contexto puede limitarlo.

Responsabilidad por los resultados

Hoy en día, no existe un agente perfecto. Puedes delegar muchas tareas de diseño e implementación, pero debes ser responsable de los resultados.

Así que, ten cuidado… y disfrútalo.

Jugar con juguetes del futuro (mientras claramente usas esas herramientas para tareas serias) ¡es un placer!