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

Desde cómo controlar el contexto, manejar la tendencia a agradar de la IA, hasta cómo definir las condiciones de finalización de tareas, es actualmente uno de los artículos más claros que he visto sobre la práctica de ingeniería con Claude/Codex.

Autor: sysls

Compilado por: Deep潮 TechFlow

Introducción de Deep潮: El desarrollador y bloguero sysls, con 2.6 millones de seguidores, escribió un artículo práctico que fue compartido por 827 personas y recibió 7000 me gusta. La idea central es: tus plugins, sistemas de memoria y diversos harness probablemente te están haciendo más daño que bien. Este artículo no da grandes teorías, sino que resume principios operativos basados en proyectos reales en producción — desde cómo controlar el contexto, manejar la tendencia a agradar de la IA, hasta cómo definir las condiciones de finalización de tareas. Es, hasta ahora, la explicación más clara de la práctica de ingeniería con Claude/Codex.

Texto completo:

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é algunos parecen construir cohetes con IA, mientras tú ni siquiera logras apilar dos piedras sin que se caigan.

Piensas que es problema de tus harness, plugins, terminal, lo que sea. Usaste beads, opencode, zep, y tu CLAUDE.md tiene 26000 líneas. Pero, por más que lo intentas, no entiendes por qué estás cada vez más lejos del cielo, mientras otros juegan con ángeles.

Esa es la razón por la que esperabas este artículo.

Por cierto, no tengo intereses particulares. Cuando hablo de CLAUDE.md, también incluyo AGENT.md; cuando digo Claude, también incluyo Codex. Los uso ambos a gran escala.

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

Parece que hay unos pocos que logran construir todo un mundo con los agentes, mientras la mayoría se pierde en un mar de herramientas, sufriendo de síndrome de selección — creyendo que encontrar el paquete, habilidad o harness correcto 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 nuevo, ni mil paquetes, ni leer millones de artículos para mantenerte competitivo. De hecho, tu entusiasmo puede ser más perjudicial que útil.

No vengo de turismo — empecé a usarlo cuando los agentes apenas podían escribir código. Probé todos los paquetes, harness, paradigmas. Escribí fábricas de agentes para señales, infraestructura y pipelines, no proyectos de juguete, sino casos reales en producción. Después de todo eso…

Hoy uso una configuración casi minimalista, solo con CLI básico (Claude Code y Codex), y una comprensión fundamental de los 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 detenerse 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 mejor.

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 la mayoría de las instrucciones, incluso las complejas y anidadas — como “lee A primero, luego B, si C, lee D” — y en la mayoría de los casos, sigue la secuencia.

¿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.

Usar muchas librerías y harness te encierra en una “solución” que quizás no exista 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 tiene una buena solución, las empresas punteras serán los mayores usuarios de esa solución. ¿Y qué harán después? Integrarla en sus productos. Piensa: ¿por qué una compañía permitiría que otro producto resuelva un problema real y cree dependencia externa? ¿Cómo sé que eso es cierto? Mirando habilidades, harness de memoria, sub-agentes… todos empiezan con soluciones para problemas reales, y tras pruebas en la práctica, se demuestran útiles.

Por eso, si algo realmente tiene un impacto disruptivo y puede ampliar los casos de uso de los agentes de forma significativa, eventualmente será parte del núcleo de los productos de las empresas base. Confía en mí: estas 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 dirán: “SysLS, uso tal harness, ¡y es increíble! ¡Recreé Google en un día!”. Y yo 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 muchos plugins y dependencias externas es que sufres de “inflación de contexto” — tu agente se ahoga en demasiada información.

¿Hacer 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 en la conversación 71 por demasiados subprocesos generados. ¿Siempre hay que poner notas? Bueno… ¿qué tiene que ver 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 esto, mejor será el rendimiento del agente. Pero si introduces sistemas de memoria extraños, plugins, o habilidades con nombres y llamadas confusos, le estás dando instrucciones para hacer una bomba o una tarta, cuando solo quieres que escriba un poema sobre un bosque de secuoyas.

Por eso, predico de nuevo: elimina todas las dependencias, y…

Haz cosas realmente útiles

Describe con precisión los detalles de implementación

¿Recuerdas que el contexto lo es todo?

¿Que quieres que el agente tenga la información precisa para completar la tarea, ni más ni menos?

La primera forma de lograrlo es separar investigación y ejecución. Sé extremadamente preciso en lo que pides al agente.

¿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 busca en internet, llenando el contexto con detalles de implementación que quizás no sirvan. Cuando llegue el momento de implementar, será más fácil confundirse o tener ilusiones irrelevantes.

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

Por supuesto, no siempre sabes los detalles. Muchas veces no tienes claro qué es correcto, y a veces quieres que el propio agente decida los detalles. ¿Qué hacer entonces? Muy simple: crea una tarea de investigación para explorar diferentes implementaciones, y deja que el agente decida qué usar, o que otro agente con contexto nuevo implemente la decisión.

Al pensar así, podrás detectar dónde el flujo de trabajo del agente se ensucia con información innecesaria, y podrás crear barreras en ese flujo, abstraer información irrelevante, y dejar solo lo que el agente necesita para destacar en la tarea. Recuerda: tienes un equipo muy talentoso y listo, que conoce todo en el universo — pero si no le dices qué quieres diseñar, solo hablará de esferas y beneficios de los círculos.

Limitaciones del diseño para agradar

Nadie quiere un producto que te critique, te diga que estás equivocado, o ignore tus instrucciones. Por eso, estos agentes tienden a estar muy dispuestos a concordar contigo y hacer lo que quieres.

Si le pides que cada 3 palabras añada “feliz”, obedecerá — la mayoría entiende esto. Su obediencia es lo que los hace útiles. Pero tiene una característica interesante: si dices “ayúdame a encontrar un bug en la base de código”, encontrará uno — incluso si necesita “fabricarlo”. ¿Por qué? Porque quiere complacer tus instrucciones.

Muchos se quejan de que los LLMs inventan cosas o tienen alucinaciones, pero no se dan cuenta de que el problema está en ellos. Tú pides algo, y el modelo entrega eso — aunque tenga que distorsionar la realidad un poco.

¿Y qué hacer? Descubrí que los “prompt neutros” son muy efectivos: no inclinas al modelo a 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. Pero no lo sesga hacia “tener bugs”.

Otra forma de manejar la tendencia a agradar es convertirla en ventaja. Sé que el agente intenta complacerte, y puedo inclinarlo hacia un lado u otro.

Por ejemplo, para encontrar bugs, hago que un agente los identifique y les asigne puntos: bugs menores +1, con impacto medio +5, graves +10. Sé que ese agente será muy entusiasta en identificar todo, incluso cosas que no son bugs reales, y me dará un puntaje total. Lo veo como un superconjunto de todos los posibles bugs.

Luego, hago que un agente adversario refute esos bugs, y que por cada refutación correcta gane el puntaje del bug, pero si se equivoca, pierda el doble del puntaje. Este agente intentará refutar tantos bugs como pueda, pero con penalizaciones, así que será cauteloso. Seguirá intentando refutar incluso bugs reales. Lo veo como un subconjunto de bugs reales.

Finalmente, hago que un árbitro combine las respuestas y asigne puntuaciones. Le digo que tengo la verdad, y que si acierta, +1; si se equivoca, -1. El árbitro evalúa las respuestas de los otros dos agentes en cada bug. La mayoría de las veces, este método es sorprendentemente preciso, casi sin errores.

Quizá pienses que solo el agente de bugs es suficiente, pero a mí me funciona bien porque aprovecha la tendencia natural del agente a agradar.

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

Parece complicado, como si necesitaras estudiar mucho y seguir las últimas tendencias en IA, pero en realidad es simple… si OpenAI y Claude lo implementan o compran la empresa que lo hace, probablemente sea útil.

¿Notaste que las “habilidades” (skills) ya están en todas partes y son parte de la documentación oficial de Claude y Codex? ¿Notaste que OpenAI compró a OpenClaw? ¿Que Claude añadió memoria, voz y funciones remotas?

¿Y la planificación? ¿Recuerdas que muchos descubrieron que planear antes de actuar es muy útil, y ahora es una función central?

Sí, esas cosas son útiles.

¿Y los “stop-hooks” infinitos? Porque los agentes no quieren hacer trabajos largos… y cuando salió 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 “novedades” o “mantenerte actualizado”.

Ayúdame un momento: actualiza de vez en cuando tu CLI, revisa qué funciones nuevas tiene. Eso es suficiente.

Compresión, contexto y suposiciones

Algunos encuentran un gran problema al usar agentes: a veces parecen los más inteligentes del mundo, y otras veces no creen que no los estén engañando.

“¿Este cosa es inteligente? ¡Es un tonto!”

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 claramente, y la situación empeora.

Una de las reglas más importantes en CLAUDE.md es cómo obtener el contexto, y cómo indicar al agente que, cada vez que lea CLAUDE.md (o después de comprimir), debe leer esa regla primero. Como parte de la obtención del contexto, unas instrucciones simples pueden hacer una gran diferencia: volver a leer el plan de la tarea, y antes de continuar, releer archivos relevantes.

Decirle al agente cómo terminar la tarea

Para nosotros, los humanos, la sensación de “finalizar” una tarea es bastante clara. Para el agente, el mayor problema es que sabe cómo empezar, pero no cómo terminar.

Esto suele dar resultados frustrantes: el agente termina con un montón de tareas incompletas y se detiene.

Las pruebas son un gran hito, porque son deterministas: puedes establecer expectativas claras. A menos que esas pruebas fallen, la tarea no está terminada; y no puedes modificar las pruebas.

Luego, solo revisas las pruebas, y si todas pasan, puedes estar seguro. Puedes automatizar esto, pero lo importante es — recuerda: “el final de la tarea” es algo natural para los humanos, pero no para los agentes.

¿Sabes qué otro método reciente funciona como final de tarea? La captura de pantalla + verificación. Puedes hacer que el agente implemente algo hasta que pase todas las pruebas, y luego tome una captura y verifique que el diseño o comportamiento en la captura sea correcto.

Esto te permite iterar con el agente y ajustar el diseño sin preocuparte de que se detenga tras el primer intento.

Una extensión natural es crear un “contrato” con el agente, y ponerlo en las reglas. Por ejemplo, un {TASK}CONTRACT.md que indique qué hacer antes de terminar la sesión. En ese contrato, especificas pruebas, capturas, y otras verificaciones necesarias antes de considerar la tarea finalizada.

Agentes que corren continuamente

Me preguntan mucho cómo hacer que un agente funcione 24 horas sin desviarse.

Una forma sencilla: crea un stop-hook que impida al agente terminar la sesión, a menos que {TASK}_CONTRACT.md esté completo.

Si tienes 100 contratos claros, con todo lo que quieres construir, el stop-hook impedirá que termine hasta que todos estén completos, incluyendo pruebas y verificaciones.

Consejo profesional: no recomiendo sesiones de 24 horas continuas. Desde la estructura, introducen inflación de contexto, porque toda la información irrelevante entra en la misma sesión.

Mejor, cada contrato en una sesión nueva. Cuando necesites hacer algo, crea un contrato nuevo.

Construye una capa de orquestación que cree nuevas sesiones para cada contrato, y maneje esas sesiones.

Eso cambiará radicalmente tu experiencia con los agentes.

Itera, itera, itera

¿Contratas un asistente? ¿Esperas que desde el primer día sepa tu agenda? ¿O que sepa cómo tomar café? Obviamente no. Vas ajustando tus preferencias con el tiempo.

Lo mismo con los agentes. Comienza con una configuración simple, olvida estructuras complejas o harness, prueba solo con CLI básico.

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

Reglas

Si no quieres que el agente haga algo, escríbelo como regla. Y en CLAUDE.md, indícalo. Por ejemplo: “Antes de programar, lee coding-rules.md”. Las reglas pueden ser anidadas, condicionales. Si estás programando, lee coding-rules.md; si estás haciendo pruebas, lee coding-test-rules.md; si fallan, lee coding-test-failing-rules.md. Puedes crear reglas con lógica condicional, y Claude (y Codex) las seguirá, siempre que estén claramente en CLAUDE.md.

De hecho, esa es mi primera recomendación práctica: trata tu CLAUDE.md como un árbol lógico, que indique dónde buscar en cada escenario y resultado. Debe ser simple, solo con lógica IF-ELSE que indique “en qué circunstancias buscar en qué lugar”.

Si ves que el agente hace algo que no quieres, añádelo como regla, y que lea esa regla antes de volver a hacerlo. Así, evitará repetir ese comportamiento.

Skills

Las skills son similares a reglas, pero en lugar de preferencias de codificación, representan pasos operativos. Si quieres que algo se haga de una forma específica, ponlo en una skill.

Muchos se quejan de que no saben cómo resolver un problema, y eso genera inseguridad. Para hacerlo más determinista, primero haz que el agente investigue cómo resolverlo, y escribe esa solución en una skill. Así, podrás ver cómo lo abordará, y corregir antes de que pase.

¿Cómo hacer que el agente conozca esa skill? Fácil: en CLAUDE.md, pon que cuando vea ese escenario, lea ese skill.md.

Gestionar reglas y skills

Seguramente querrás agregar reglas y skills continuamente. Es la forma de darle personalidad y preferencias. Casi todo lo demás es redundante.

Al hacerlo, tu agente parecerá magia. “Hace lo que quieres”. Y sentirás que has “entendido” la ingeniería de agentes.

Pero…

Verás que el rendimiento empieza a caer.

¿Qué pasa? Muy simple. Cuanto más reglas y skills añades, más se contradicen, o el contexto se inflama. Si necesitas que lea 14 archivos markdown antes de programar, tendrás el mismo problema de información inútil.

¿Qué hacer? Limpia. Haz que tu agente “haga un spa”, integre reglas y skills, y actualiza tus preferencias para eliminar contradicciones.

Así, volverá a parecer magia.

Eso es todo. Es el secreto: mantén las cosas simples, usa reglas y skills, trata CLAUDE.md como un índice, y sé consciente de sus límites y contexto.

Responsabilízate de los resultados

Hoy, no hay agentes perfectos. Puedes delegar mucho en ellos, pero debes ser responsable de los resultados.

Así que, cuidado… y disfruta.

Jugar con juguetes del futuro (mientras usas esas mismas herramientas para tareas serias) es un placer.