¿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 sobre la práctica de ingeniería con Claude/Codex que he visto.

Autor: sysls

Traducido por: Deep潮 TechFlow

Deep潮 Introducción: El desarrollador y bloguero con 2.6 millones de seguidores, sysls, escribió un extenso 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 perjudicando. Este artículo no da grandes teorías, sino que resume principios operativos basados en proyectos reales — 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, usas a diario Claude y Codex CLI, y te preguntas 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, escribiste 26000 líneas en CLAUDE.md. 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 hablo de 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 programar. 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 simple, con solo CLI básico (Claude Code y Codex), y una comprensión fundamental de algunos principios de ingeniería de agentes, y he logrado mi trabajo más innovador hasta ahora.

Entender que el mundo avanza rápidamente

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”. La mayoría de las veces, 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, 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 sus mayores usuarios. ¿Y qué harán después? Integrarán esa solució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 habilidades, harness de memoria, sub-agentes… todos empiezan con soluciones a problemas reales, y tras pruebas en el mundo real, se demuestran útiles.

Por eso, si algo realmente tiene un impacto revolucionario y puede escalar en casos de uso de agentes, eventualmente será parte del núcleo de los productos de las empresas base. Confía en mí: 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 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.

¿Quieres que haga un juego de adivinar palabras en Python? Fácil. Pero, ¿qué pasa con la nota “gestionar memoria” de 26 conversaciones atrás? Ah, el usuario tiene una pantalla atascada por generar demasiados subprocesos. ¿Siempre hay que poner notas? Bien, sin problema… ¿Y qué tiene que ver con el juego de adivinar palabras?

Lo entiendes. 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 raros, plugins, o habilidades con nombres y llamadas confusos, le estás dando instrucciones para hacer una bomba o una torta, 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?

¿Recuerdas que quieres darle al agente la información precisa, 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, llena el contexto con muchas posibles implementaciones 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 quieres que el agente decida por ti. ¿Qué hacer entonces? Muy simple: crea una tarea de investigación para explorar diferentes implementaciones, deja que decida o que tú decidas qué usar, y que otro agente con un contexto limpio implemente.

Al pensar así, notarás dónde el contexto del agente se ensucia innecesariamente, y podrás crear barreras en el flujo de trabajo del agente, abstraer información innecesaria, y dejar solo lo que realmente 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 que quieres un espacio para bailar y divertirte, solo te hablará de las ventajas de las esferas.

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 tiene que “fabricarlo”. ¿Por qué? Porque quiere complacer.

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.

¿Y qué hacer? Descubrí que los “prompt neutros” son muy efectivos, es decir, no sesgar al modelo 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, 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 sesga al modelo hacia “tener un bug”.

Otra forma de manejar la tendencia a agradar es convertirla en ventaja. Sé que el agente intenta agradarme y seguir mis instrucciones, así que puedo aprovechar eso.

Por ejemplo, para encontrar bugs, puedo hacer que un agente identifique todos los bugs en la base, asignando puntuaciones: los bugs menores +1, los de impacto medio +5, los graves +10. Sé que ese agente será muy entusiasta en identificar todos los bugs, incluso los que no lo son, y me dará un puntaje total. Lo veo como un superconjunto de todos los bugs posibles.

Luego, uso un agente adversario que intente refutar cada bug, con una puntuación: si refuta correctamente, obtiene esa puntuación; si se equivoca, pierde el doble. Este agente intentará refutar tantos bugs como pueda, pero con penalizaciones, así que será cauteloso. Seguirá intentando refutar, incluso los bugs reales. Lo veo como un subconjunto de bugs reales.

Finalmente, un árbitro que combine ambas entradas y asigne una puntuación. Le digo que tengo una respuesta correcta, y que si acierta, +1; si se equivoca, -1. El árbitro puntúa a los otros dos agentes en cada “bug”. El árbitro dice qué es la verdad, y yo verifico. Este método, sorprendentemente, funciona con alta fidelidad, y a veces comete errores, pero ya es casi infalible.

Quizá pienses que solo el agente de bugs basta, pero este método me funciona porque aprovecha la tendencia natural del agente a agradar.

¿Cómo saber qué es útil o 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.

¿Notas que las “habilidades” (skills) 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 trabajo remoto?

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

Sí, esas cosas son útiles.

¿Y los “stop-hooks” infinitos? Son muy útiles porque los agentes no quieren hacer trabajos largos… y cuando salió Codex 5.2, esa necesidad desapareció de un día para otro.

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 “mantenerte actualizado”.

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

Compresión, contexto y suposiciones

Algunos usuarios descubren un gran problema: a veces los agentes parecen los más inteligentes del mundo, y otras veces no puedes creer que te estén engañando.

“¿Este agente 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 seguir esa regla. Como parte de la obtención del contexto, unas instrucciones simples pueden hacer una gran diferencia: volver a leer la planificación, 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 a menudo lleva a resultados frustrantes: el agente termina solo con unos stubs y se detiene.

Las pruebas son un gran hito, porque son deterministas: puedes establecer expectativas claras. Si no pasa una prueba, la tarea no está terminada; y no debes modificar la prueba.

Solo revisa las pruebas, y cuando todas pasen, puedes estar tranquilo. Puedes automatizar esto, pero lo importante es — recuerda que “finalizar” es natural para los humanos, pero no para los agentes.

¿Sabes qué otro método de finalización de tareas ha sido útil últimamente? ¡Capturas 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 especifique qué hacer antes de terminar la sesión. En ese contrato, defines pruebas, capturas y otras verificaciones necesarias antes de considerar la tarea finalizada.

Agentes que corren continuamente

Frecuentemente me preguntan cómo hacer que un agente funcione 24 horas sin desviarse.

Aquí tienes un método sencillo: 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 los contratos, pruebas y verificaciones estén completos.

Consejo profesional: no recomiendo sesiones de 24 horas continuas. Desde la estructura, esto introduce inflación de contexto, porque se acumulan contextos irrelevantes de otros contratos.

En su lugar, cada contrato debe tener su propia sesión. Cuando necesites hacer algo, crea un contrato nuevo y una sesión específica para ello.

Esto cambiará radicalmente tu experiencia con los agentes.

Iterar, iterar, iterar

¿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, y 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ícale esa regla. 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á si están claramente indicadas en CLAUDE.md.

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 en cada escenario y resultado. Debe ser lo más simple posible, 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 específicos. Si quieres que algo se haga de una forma concreta, ponlo en una skill.

Muchos se quejan de que no saben cómo el agente resolverá un problema, y eso genera inseguridad. Para que sea más predecible, haz que el agente investigue cómo resolverá, y escribe esa solución en una skill. Así, podrás anticipar y ajustar antes de que ocurra.

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

Gestionar reglas y skills

Seguramente querrás agregar reglas y skills continuamente. Eso es cómo le das 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 otra vez.

¿Cómo? Muy simple. Cuantas 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?

Limpiar. 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. Esa es la clave. Mantén las cosas simples, usa reglas y skills, trata CLAUDE.md como un directorio, y sé consciente de sus límites y contexto.

Responsabilidad sobre los resultados

Hoy, no existe un agente perfecto. Puedes delegar mucho en ellos, pero debes ser responsable de los resultados.

Así que, cuidado… y disfruta.

Jugar con juguetes del futuro (mientras usas IA para tareas serias) es una experiencia divertida.