Tu archivo de configuración del agente de IA está desperdiciando tokens — haz esto en su lugar
Tenía un archivo CLAUDE.md de 1.247 líneas. Estaba orgulloso de él. Cada convención de código, cada preferencia arquitectónica, cada caso límite con el que alguna vez me había topado: documentado, organizado y cargado en el contexto en cada mensaje que enviaba a Claude Code.
Entonces hice los números.
A aproximadamente 3 tokens por línea, ese archivo me estaba costando ~3.700 tokens por turno. No por sesión: por turno. En una sesión típica de 40 turnos, eso son 148.000 tokens consumidos por instrucciones que el modelo ni siquiera usaba el 90% del tiempo. Estaba pagando un impuesto de contexto más grande que la conversación entera de la mayoría de la gente, y la calidad de salida de mi agente en realidad se estaba volviendo peor a medida que el archivo crecía.
Ross Mike planteó la solución en una discusión reciente que reformuló cómo pienso sobre la productividad de los agentes de IA. Su argumento es simple, respaldado por datos y —una vez que lo escuchas— dolorosamente obvio: la calidad de la salida de tu agente de IA depende mucho más de cómo gestionas el contexto que de qué modelo estés ejecutando. Opus 4.6, GPT 5.4, Gemini 3: todos son notablemente capaces. El cuello de botella no es la inteligencia. Es la dieta de información con la que los alimentas.
He pasado las últimas dos semanas reconstruyendo todo mi workflow de agentes alrededor de este principio. Los resultados han sido lo suficientemente contundentes como para que esté escribiendo esto en lugar de hacer las otras tres cosas de mi lista de hoy. Esto es lo que cambió, lo que se rompió y lo que le diría a cualquiera que todavía esté cuidando un archivo de configuración de 500 líneas.
La verdad incómoda sobre tu archivo agent.md
La mayoría de los desarrolladores con los que hablo tienen alguna versión del mismo setup. Un archivo markdown grande —CLAUDE.md, .cursorrules, agents.md, como sea que lo llame la herramienta— atiborrado de instrucciones sobre su stack, sus preferencias, sus convenciones. El archivo crece durante meses. Cada interacción frustrante añade otra línea: "Usa siempre named exports". "Prefiere Tailwind sobre CSS modules". "Nunca sugieras class components".
Ross llama a esto el enfoque del "context dump", y su crítica me golpeó donde duele: estos archivos se sienten productivos porque escribirlos se siente como trabajo. ¡Estás codificando conocimiento! ¡Estás entrenando a tu agente! Salvo que no lo estás haciendo. Estás creando un bloque estático de texto que se inyecta en cada interacción sin importar la relevancia, y el modelo trata todo eso como igualmente importante.
Esto es lo que investigación reciente de InfoQ muestra en realidad sobre estos archivos: los archivos de contexto generados por LLM degradan el rendimiento, reduciendo las tasas de éxito de las tareas en un promedio del 3% en comparación con no proporcionar ningún archivo de contexto. También aumentan de forma consistente la cantidad de pasos que toma el agente, disparando los costos de inferencia en más del 20%. Incluso los archivos escritos por humanos solo ofrecieron una mejora marginal del 4% en la tasa de éxito, mientras que al mismo tiempo aumentaron el número de pasos y los costos hasta en un 19%.
Lee eso de nuevo. El archivo al que le dedicaste horas de trabajo podría estar haciendo a tu agente más lento y más caro mientras apenas mejora su precisión.
El mecanismo es sencillo una vez que entiendes cómo funcionan estos modelos. No "entienden" tu archivo de configuración de la forma en que un desarrollador humano leería e internalizaría una guía de estilo. Predicen tokens en función de patrones en la ventana de contexto. Cuando inundas esa ventana con 1.200 líneas de instrucciones, no le estás dando al modelo un manual de referencia: estás diluyendo la relación señal-ruido de cada prompt que envías. El modelo gasta capacidad de atención procesando tus preferencias de TypeScript cuando le pides que depure un layout de CSS.
Esto no significa que los archivos de contexto sean inútiles. Significa que el enfoque por defecto —un archivo grande, cargado en todas partes, creciendo para siempre— casi con seguridad está equivocado.
Lo que Ross acierta sobre cómo funcionan realmente los modelos
Hay un malentendido con el que tropiezan la mayoría de los constructores de agentes de IA, y Ross lo abordó directamente: estos modelos no piensan. No entienden. Predicen el siguiente token basándose en patrones de sus datos de entrenamiento y en el contexto que les proporcionas.
Esto suena como una limitación. En realidad es una restricción de diseño que te dice exactamente cómo obtener mejor salida.
Si el modelo es un motor de coincidencia de patrones, entonces los patrones dentro de tu ventana de contexto son la mayor palanca que tienes sobre la calidad de la salida. Aliméntalo con un contexto desordenado lleno de instrucciones irrelevantes y la coincidencia de patrones se volverá ruidosa. Aliméntalo con un contexto enfocado con exactamente la información que la tarea actual necesita y la coincidencia de patrones se vuelve nítida.
Ross usó una analogía que se me quedó grabada: imagina que le das instrucciones a un nuevo empleado antes de cada tarea. Si le entregas un manual de 50 páginas que cubre todos los escenarios con los que se ha encontrado la empresa, estará abrumado y será lento. Si le das una hoja enfocada específica para la tarea en cuestión, rendirá bien de inmediato. Los modelos funcionan igual, no porque "entiendan" el briefing, sino porque un contexto enfocado produce patrones de predicción de tokens más limpios.
Esto tiene una implicación práctica que la mayoría de la gente pasa por alto. La ventana de contexto no es simplemente un cubo que llenas con información útil. Es más como un reflector: tiene un área limitada de iluminación, y todo dentro de esa área compite por la atención del modelo. La investigación respalda esto: mantener la ventana de contexto entre fresca y aproximadamente el 70% de capacidad produce la salida más confiable. Si la pasas, empiezas a ver rendimiento degradado: instrucciones pasadas por alto, sugerencias repetidas, patrones de código inconsistentes.
Lo probé yo mismo. Mismo prompt, mismo modelo (Opus 4.6), misma tarea: construir un flujo de autenticación de usuario con JWT tokens y refresh rotation. Con mi CLAUDE.md completo de 1.247 líneas cargado, el agente tomó 14 turnos y produjo código con dos bugs. Después de reducir el CLAUDE.md a 47 líneas de convenciones genuinamente esenciales, la misma tarea se completó en 8 turnos con cero bugs. Menos instrucciones, mejor salida. La versión recortada permitió al modelo enfocarse en lo que importaba.
Pero aquí es donde se pone interesante, porque la respuesta no es simplemente "haz tu archivo de configuración más pequeño". Eso es tratar el síntoma. La verdadera idea de Ross trata sobre la arquitectura de cómo debe fluir el contexto.
Progressive disclosure: el patrón que lo cambia todo
El concepto que transformó mi workflow no es nuevo: viene del diseño de UX. Progressive disclosure significa mostrarle a los usuarios solo la información que necesitan en cada etapa, revelando complejidad gradualmente a medida que profundizan. El framework agent-skills de Microsoft lo formalizó como una arquitectura de carga de tres niveles para agentes de IA, y ahora es la base de cómo funcionan las skills en Claude Code, Cursor y otras herramientas importantes.
Aquí está la diferencia concreta entre el enfoque viejo y el nuevo:
La forma vieja (agent.md / CLAUDE.md): Cada interacción carga tu archivo de configuración completo. Si tienes 1.000 tokens de instrucciones, esos son 1.000 tokens añadidos a cada mensaje, necesite el agente esas instrucciones o no.
La forma nueva (skills con progressive disclosure): Al arrancar, el agente carga solo los nombres y descripciones de las skills, aproximadamente 50 tokens por skill. Solo cuando una tarea coincide con la descripción de una skill se carga el conjunto completo de instrucciones en el contexto. Cuando la tarea termina, las instrucciones detalladas de la skill no persisten a la siguiente tarea.
Los números de los tokens son dramáticos. Digamos que tienes 20 workflows distintos codificados como instrucciones. Bajo el enfoque viejo, eso podría ser 15.000-20.000 tokens cargados en cada turno. Bajo progressive disclosure, cargas ~1.000 tokens de metadata al arrancar, más quizás 500-800 tokens de la única skill relevante cuando la necesitas. Eso es aproximadamente una reducción del 82% en el overhead de contexto, según benchmarks del mundo real.
Cubrí la implementación técnica de las skills en mi guía para construir agent skills, pero el framework de Ross añade algo que la documentación técnica se pierde: una filosofía sobre cuándo y cómo crear skills que realmente funcionen.
El framework de Ross: cómo construir skills que no apesten
El primer instinto de la mayoría de la gente cuando oyen hablar de las skills es sentarse y escribir una desde cero. Abrir un archivo markdown en blanco, pensar en un workflow, documentar los pasos, guardar. Listo.
Ross argumenta que esto es exactamente al revés, y después de probar ambos enfoques, estoy completamente de acuerdo.
Su framework tiene cinco pasos, y el orden importa más que cualquier paso individual:
Paso 1: identifica un workflow real (no uno hipotético)
No construyas skills para workflows que crees que vas a necesitar. Constrúyelas para workflows que ya hayas hecho manualmente al menos tres veces. Si no lo has hecho tres veces, no entiendes los casos límite lo suficientemente bien como para enseñarle a un agente.
Solo este filtro me salvó de crear una docena de skills inútiles. Tenía grandes planes para una skill de "deploy a producción", una de "migración de base de datos", una de "escribir unit tests". Pero cuando apliqué el filtro de Ross —¿he hecho esto realmente a mano, de principio a fin, al menos tres veces recientemente?— la lista se redujo rápido. Los workflows que realmente repetía eran más mundanos: revisar correos entrantes, formatear metadata de posts del blog, montar scaffolding de nuevos proyectos con mis convenciones específicas.
Lo mundano es bueno. Lo mundano significa repetitivo. Repetitivo significa alto ROI para la automatización.
Paso 2: enseña al agente a través de la conversación, no de la configuración
Aquí es donde el enfoque de Ross diverge de lo que veo hacer a la mayoría de los desarrolladores. En lugar de escribir un archivo de skill y esperar que funcione, le enseñas al agente el workflow de forma interactiva, de la misma forma en la que entrenarías a un nuevo colaborador.
Reenvíale al agente una tarea real. Guíalo por tu proceso de decisión en tiempo real. Cuando cometa un error, corrígelo y explica por qué. Cuando haga algo bien, confírmalo. Esto es aprendizaje experiencial, y Ross argumenta que es la única manera confiable de sacar a la luz los casos límite y el conocimiento implícito que nunca pensarías escribir en un archivo de instrucciones estático.
Su ejemplo fue convincente: le enseñó a un agente a evaluar correos de patrocinadores literalmente reenviándole correos reales y guiándolo por el proceso de investigación. "Revisa su presencia en Twitter. Búscalos en Trustpilot. Verifica su estado de financiación. Si la empresa se fundó hace menos de 6 meses, márcala." Cada corrección refinaba la comprensión del agente. Después de tres o cuatro iteraciones, el agente revisaba correos más rápido y más a fondo de lo que Ross lo hacía manualmente.
Lo probé con mi workflow de metadata de posts del blog. En lugar de escribir una skill desde cero, llevé a Claude por el proceso sobre un post real: "Aquí está el título, aquí está lo que elegiría para las etiquetas, aquí está por qué elegí estas palabras clave secundarias sobre aquellas, aquí está el patrón de meta description que uso". Luego lo hice de nuevo con otro post. A la tercera vez, Claude generaba metadata que casi coincidía exactamente con mi estilo, captando matices que nunca habría pensado en documentar, como mi preferencia por verbos de acción en las meta descriptions o mi costumbre de poner el nombre de la marca al final en las listas de etiquetas.
Paso 3: itera hasta que los modos de fallo desaparezcan
La primera ejecución tendrá errores. La segunda tendrá menos. Para la cuarta o quinta, empezarás a ver salida consistente y confiable. Ross es explícito sobre esto: no te saltes la fase de iteración. El agente no está "aprendiendo" de forma persistente: tú estás aprendiendo qué contexto necesita, y cada iteración revela vacíos que no anticipaste.
Esta paciencia paga interés compuesto. Cada caso límite que sacas a la luz y resuelves durante el entrenamiento es un caso límite que no te morderá durante el uso en producción. Descubrí que la mayoría de las skills necesitaban 4-6 ejecuciones de entrenamiento interactivo antes de ser lo suficientemente sólidas como para formalizarse.
Paso 4: convierte el workflow refinado en un archivo de skill
Solo después de que el entrenamiento interactivo produzca resultados consistentes creas el archivo skill.md. En este punto, no estás inventando instrucciones: estás documentando lo que ya funciona. El archivo de skill se convierte en una codificación de patrones probados, no en una conjetura especulativa sobre lo que el agente podría necesitar.
La estructura que Ross recomienda es limpia:
# Skill: [Name]
## Description
[One sentence — what this skill does and when to use it]
## Workflow
[Numbered steps, each specific and actionable]
## Known Edge Cases
[Things that went wrong during training and how to handle them]
## Success Criteria
[How to verify the output is correct]
Esa sección de "Known Edge Cases" es donde vive el verdadero valor. Es el conocimiento institucional que construiste durante los pasos 2 y 3, las trampas que un autor de skill con página en blanco jamás anticiparía.
Paso 5: sigue refinando de forma recursiva
Un archivo de skill no es un producto terminado. Es un documento vivo. Cada vez que la skill falla en producción, la depuras, arreglas la causa raíz y actualizas el archivo. Ross llama a esto "construcción recursiva de skills", y es el mecanismo que hace que las skills compongan valor con el tiempo.
He actualizado mi skill de generación de metadata siete veces desde que la creé hace tres semanas. Cada actualización fue disparada por un fallo real: un post donde la meta description era demasiado larga, una combinación de etiquetas que no encajaba con la estructura de clusters, un slug que contenía stop words. La skill es dramáticamente mejor ahora que cuando la escribí por primera vez, y cada mejora fue impulsada por uso real, no por especulación.
Por qué nunca deberías descargar skills de un marketplace
La postura de Ross sobre esto es inequívoca, y he terminado por coincidir con él después de resistirme inicialmente.
Los marketplaces de skills —lugares donde puedes navegar e instalar skills preconstruidas creadas por otros desarrolladores— parecen una gran idea en la superficie. ¿Por qué construir una skill de "generación de componentes React" desde cero cuando alguien más ya hizo una?
Dos razones.
Primero, desajuste de contexto. Una skill construida para el workflow de otra persona codifica sus convenciones, sus decisiones de stack, sus casos límite. A menos que su entorno de desarrollo sea idéntico al tuyo (no lo es), la skill producirá salida que no encaja del todo. Pasarás tanto tiempo arreglando la salida como habrías pasado construyendo la skill tú mismo. Escribí sobre este problema en mi guía de workflow para agent skills: las skills que mejor funcionan son las que se construyen a partir de tu workflow real, no de la abstracción que otra persona hizo de un workflow parecido.
Segundo, seguridad. Un archivo skill.md es esencialmente un conjunto de instrucciones que tu agente de IA seguirá. Instalar una skill desde una fuente no confiable es como ejecutar un paquete de npm sin leer el código, excepto que la superficie de ataque es todo tu entorno de desarrollo. Una skill maliciosa podría instruir al agente a exfiltrar código, inyectar dependencias o modificar archivos de formas que creen vulnerabilidades. El riesgo no es teórico; a medida que los agentes ganan más capacidades autónomas, las instrucciones que siguen se convierten en un vector de ataque cada vez más atractivo.
Construye las tuyas propias. Cuesta más tiempo al principio. El retorno compuesto lo vale.
El principio de "un agente, muchas skills"
Aquí es donde el framework de Ross conecta con una decisión arquitectónica más amplia en la que veo a los desarrolladores equivocarse constantemente.
La tentación, una vez que entiendes los agentes y las skills, es construir una flota. Un agente de coding. Un agente de research. Un agente de writing. Un agente de deployment. Cada uno con su propio system prompt, su propia configuración de herramientas, su propia personalidad. Se ve impresionante. Se siente sofisticado. Y para la mayoría de los casos de uso, es una exageración masiva.
La recomendación de Ross: empieza con un agente. Constrúyele 10 skills. Haz que esas skills funcionen de forma confiable. Solo entonces considera si un segundo agente mejoraría genuinamente tu productividad, y solo si puedes articular exactamente qué haría el segundo agente que el primero no puede.
El razonamiento es práctico. Múltiples agentes introducen overhead de coordinación: necesitan comunicarse, compartir contexto, traspasar tareas y resolver conflictos. Ese overhead solo se justifica cuando los agentes están haciendo trabajo genuinamente paralelo que no puede serializarse. Para un desarrollador solo o un equipo pequeño, un agente bien equipado con skills maneja la mayoría de los workflows más eficientemente que tres especializados que necesitan orquestación.
Reestructuré mi propio setup alrededor de este principio el mes pasado. Pasé de tres agentes configurados (uno para coding, uno para contenido, uno para DevOps) a un solo agente con una biblioteca de 14 skills abarcando los tres dominios. El setup de un solo agente es más rápido de mantener, más predecible en comportamiento y —contra la intuición— produce mejor salida porque el contexto completo de mi proyecto siempre está disponible, no fragmentado entre agentes que no pueden ver el trabajo del otro.
Si prefieres que alguien monte este tipo de arquitectura de agentes desde cero, acepto encargos de workflow e automatización con IA. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.
La excepción a la regla del agente único es el paralelismo genuino: tareas que son verdaderamente independientes y lo suficientemente sensibles al tiempo como para justificar ejecutarlas simultáneamente. ¿Desplegar a staging mientras corres una suite de tests mientras generas documentación? Son tres tareas independientes. Tres agentes tienen sentido. Pero ¿escribir código, revisarlo y luego desplegarlo? Eso es un workflow serial. Un agente, tres skills.
Migración práctica: de configuración inflada a skills esbeltas
Si estás sentado sobre un CLAUDE.md o agents.md enorme justo ahora, así es como migré el mío sin perder el conocimiento que había acumulado:
1. Audita tu archivo de configuración buscando patrones de uso reales.
Recorre cada instrucción en tu archivo y pregunta: "¿Cuándo fue la última vez que esta instrucción realmente cambió la salida del agente?" Sé honesto. Descubrí que aproximadamente el 60% de mis instrucciones eran o bien redundantes (el modelo ya lo hace por defecto), desactualizadas (refiriéndose a patrones que dejé de usar), o tan raras que se habían disparado quizás dos veces en meses de uso.
2. Separa lo universal de lo específico de la tarea.
Algunas instrucciones pertenecen genuinamente a cada interacción: "Usa TypeScript, no JavaScript". "Sigue la estructura de proyecto existente". "Corre los tests antes de sugerir un PR". Estas se quedan en tu CLAUDE.md esbelto. Todo lo demás —patrones de API específicos, procedimientos de deployment, reglas de formato de contenido— se convierte en candidato para ser una skill.
3. Para cada candidato a skill, aplica la prueba de las "tres veces".
¿Has hecho realmente este workflow manualmente al menos tres veces? Si sí, vale la pena construir una skill. Si no, o lo haces manualmente unas cuantas veces más para entender los casos límite, o sáltatelo por completo.
4. Construye skills a través de la conversación, no de la configuración.
Por cada skill que estés creando, guía al agente a través del workflow interactivamente 3-5 veces antes de escribir el archivo de skill. Esto saca a la luz casos límite que te perderías escribiendo desde una página en blanco.
5. Mantén tu CLAUDE.md por debajo de 200 líneas.
Este es el umbral que current best practices sugieren para mantener el equilibrio entre costo y beneficio. Más allá de 200 líneas, el costo persistente de tokens de entrada empieza a superar las mejoras en la calidad de la salida. El mío actualmente tiene 47 líneas, y la calidad de salida es la mejor que ha tenido nunca.
Después de esta migración, mi uso de tokens por sesión bajó aproximadamente un 60%. Estoy haciendo el mismo trabajo —a menudo más— mientras consumo dramáticamente menos tokens. Las sesiones también se sienten diferentes. El agente responde más rápido, se mantiene más enfocado y produce menos sugerencias fuera de objetivo. Escribí sobre el lado de la optimización de tokens en detalle en mi guía de optimización de tokens de Claude Code, pero la migración de configuración monolítica a skills es de donde vino la mayor mejora individual.
El verdadero cambio de paradigma: el contexto es el producto
Ross dijo algo hacia el final de la discusión que he estado dando vueltas en mi cabeza desde entonces: los modelos son una commodity. Opus 4.6, GPT 5.4, lo que salga el próximo trimestre: todos están convergiendo hacia niveles de capacidad similares. La ventaja competitiva no está en qué modelo usas. Está en qué tan bien construyes contexto, workflows y skills alrededor del modelo que elijas.
Esto reformula lo que significa ser productivo con IA en 2026. Los desarrolladores que prosperen no serán los que persigan cada nuevo release de modelo o acumulen los archivos de configuración más largos. Serán los que hayan construido una biblioteca personal de skills probadas en batalla: cada una refinada a través del uso real, cada una codificando conocimiento de workflow que un agente nuevo no podría replicar sin semanas de entrenamiento.
Piensa en ello como construir un foso de conocimiento. Cada skill que creas, cada caso límite que documentas, cada workflow que refinas: es experiencia compuesta que hace que tu setup de IA sea más valioso y más eficiente con el tiempo. Alguien que empiece desde cero mañana no puede acortar ese proceso. Puede usar el mismo modelo. No puede usar tus skills.
Ross advierte —y creo que tiene razón— que la brecha entre las personas que entienden esto y las que no se va a ensanchar rápido. Los modelos van a seguir mejorando. Las personas que sepan cómo guiarlos a través de un contexto bien construido extraerán dramáticamente más valor de cada mejora. Las personas que traten a los agentes de IA como cajas mágicas que deberían "simplemente funcionar" seguirán chocándose contra los mismos muros, culpando al modelo de fallos que en realidad son fallos de contexto.
Lo que cambié esta semana y lo que pasó
Quiero ser específico sobre los resultados porque las afirmaciones vagas no valen nada.
Después de reconstruir mi workflow alrededor del framework de Ross, así es como se vio mi lunes comparado con el lunes anterior:
Lunes anterior (CLAUDE.md monolítico, sin skills):
- Llegué al límite de tokens dos veces durante una sesión de trabajo de 5 horas
- Gasté aproximadamente 25 minutos re-explicando el contexto después de cada
/clear - Produje 3 componentes terminados, 2 de los cuales necesitaron arreglos manuales
- Consumo estimado de tokens: ~850.000 tokens
Este lunes (CLAUDE.md de 47 líneas, 14 skills activas):
- Llegué al límite de tokens cero veces durante la misma ventana de 5 horas
- El restablecimiento de contexto después de
/cleartomó menos de 2 minutos (la skill cargó el contexto relevante automáticamente) - Produje 5 componentes terminados, 1 necesitó un arreglo menor
- Consumo estimado de tokens: ~340.000 tokens
Mismo desarrollador. Mismo modelo. Mismo proyecto. La única variable era cómo estaba estructurado el contexto.
La mejora más sorprendente no fue el ahorro de tokens: fue la consistencia de la calidad. Con la configuración monolítica, la calidad de la salida se degradaba notablemente a medida que la sesión avanzaba y la ventana de contexto se llenaba. Con las skills, cada tarea arranca con un contexto relativamente fresco más solo las instrucciones de la skill relevante. La quinta tarea del día obtiene la misma calidad que la primera.
La versión de cinco minutos
Si no te llevas nada más de esto, aquí está el framework destilado:
Deja de hacer crecer tu archivo de configuración. Limítalo a 200 líneas como máximo. Redúcelo a solo las instrucciones que genuinamente necesiten aplicarse a cada interacción.
Construye skills a través de la iteración, no de la imaginación. Guía al agente a través de tareas reales 3-5 veces antes de escribir un archivo de skill. Los casos límite que descubres durante el entrenamiento son la parte más valiosa de la skill.
Un agente, muchas skills. Resiste la urgencia de construir una flota de agentes especializados. Un agente bien equipado con skills supera a tres mal coordinados para la mayoría de los workflows.
Nunca instales las skills de otra persona. Construye las tuyas. El desajuste de contexto y los riesgos de seguridad no valen el ahorro de tiempo.
Trata el contexto como un presupuesto, no como un contenedor. Cada token en la ventana de contexto compite por la atención del modelo. Gasta tokens deliberadamente en información que la tarea actual necesita. Deja morir de hambre a todo lo demás.
Ross enmarca esto como un cambio de paradigma, y no creo que sea una exageración. Los desarrolladores que dominen la ingeniería de contexto —que traten la dieta de información de sus agentes de IA como una preocupación de ingeniería de primera clase— van a superar a los que sigan volcando todo en un archivo de configuración y esperando que el modelo lo resuelva.
Los modelos son lo suficientemente inteligentes. La pregunta es si nosotros somos lo suficientemente inteligentes como para alimentarlos correctamente.
Preguntas frecuentes
¿Necesito un archivo CLAUDE.md o agents.md en absoluto?
Solo si tienes convenciones universales que realmente se aplican a cada interacción: preferencias de lenguaje, reglas de estructura de proyecto o patrones propios que el modelo no conocería. Mantenlo por debajo de 200 líneas. Para la mayoría de los desarrolladores en solitario, 50-100 líneas es el punto dulce donde obtienes convenciones consistentes sin pagar un overhead excesivo de tokens.
¿Cuántas skills debería construir antes de ver ganancias reales de productividad?
La mayoría de los desarrolladores ven una mejora significativa después de 3-5 skills bien hechas que cubren sus workflows más repetidos. No apuntes a una biblioteca grande desde el principio: enfócate en las tareas que haces a diario y construye hacia afuera desde ahí. Yo alcancé un punto de inflexión notable con 8 skills.
¿Puedo convertir mi CLAUDE.md existente en skills?
Sí, y deberías hacerlo. Agrupa instrucciones relacionadas en clusters específicos por workflow, aplica la prueba de las "tres veces" a cada cluster y luego construye skills para las que pasen. Las instrucciones que no encajen en ningún workflow específico se quedan en tu archivo de configuración esbelto.
¿Cuál es la diferencia entre skills y MCP tools?
Las skills son paquetes de conocimiento: le dicen al agente cómo abordar una tarea. Las MCP tools son capacidades: le permiten al agente realizar acciones como leer archivos, correr comandos o llamar a APIs. Las skills dirigen el razonamiento del agente; las tools extienden lo que puede hacer. Son complementarias, no competidoras.
¿Cómo sé si mi context window está demasiado lleno?
Vigila tres señales: el agente empieza a repetir sugerencias que ya había hecho, los tiempos de respuesta se vuelven notablemente más lentos, o el agente pasa por alto instrucciones que le has dado claramente. Estas indican que el contexto está saturado y el modelo está perdiendo el foco. Usa /compact o /clear para recuperar espacio.
Trabajemos juntos
¿Quieres construir sistemas de IA, automatizar workflows o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
