Anthropic lanzó Claude Fable 5.1 y Claude Mythos 5.1 el 1 de septiembre, tres meses después de la llegada del Fable 5 original, que fue suspendido poco después por el Departamento de Comercio de Estados Unidos.

En el anuncio oficial, la compañía los presenta como los modelos más avanzados del mundo para programación y trabajo intelectual. Los resultados de las pruebas de rendimiento respaldan buena parte de esa afirmación. De hecho, una de las métricas más que duplicó su puntuación.

Sin embargo, al revisar la documentación para desarrolladores, encontramos algo sorprendente. La segunda frase de la descripción general recomienda comenzar con Claude Opus 5 para la mayoría de las cargas de trabajo.

Es decir, Anthropic está recomendando, desde su propia documentación y el mismo día del lanzamiento, que probablemente su modelo más avanzado no sea la mejor opción para la mayoría de las personas.

Vale la pena detenerse en esta contradicción, porque ayuda a entender prácticamente todo lo que hay detrás de este lanzamiento.

Qué mejoró realmente

Las mejoras son reales, pero no se distribuyen de manera uniforme. Dos pruebas de rendimiento registraron avances extraordinarios, mientras que el resto mostró incrementos de apenas unos puntos porcentuales.

Terminal Bench Science es el resultado más destacado.

Fable 5 obtuvo una puntuación del 24,7 %, mientras que Fable 5.1 alcanzó el 52,6 %.

Anthropic señala que el error estándar se sitúa aproximadamente entre 3,5 y 4,5 puntos por modelo, por lo que la diferencia no puede atribuirse simplemente a variaciones estadísticas.

La automatización de procesos empresariales también estuvo cerca de duplicar su rendimiento.

Pero cuando comparamos los resultados con Opus 5, la situación se vuelve bastante más interesante.

En tareas de conocimiento, Opus 5 obtiene 1824 puntos frente a los 1853 de Fable 5.1.

En Humanity's Last Exam, utilizando herramientas, las puntuaciones son de 63,6 frente a 65,0.

Y en CursorBench, una de las pruebas de programación más exigentes del conjunto, Opus 5 queda apenas tres puntos por detrás.

Desarrolladores de Hacker News señalan que Fable cuesta aproximadamente el doble que Opus.

Pagar el doble por una diferencia de tres puntos en CursorBench no parece una decisión estratégica de producto. Es pagar una factura considerable por una mejora casi imperceptible.

Donde Fable 5.1 realmente consigue diferenciarse es en investigación científica y automatización.

Si trabajas con agentes autónomos que realizan investigaciones complejas durante períodos prolongados, una mejora de 28 puntos en Terminal Bench Science representa un avance importante.

Pero si tu trabajo consiste principalmente en desarrollar operaciones CRUD o endpoints convencionales, probablemente estés gastando mucho más dinero del necesario.

El precio: el cambio más importante no está donde imaginas

La reducción del costo de lectura de caché es la verdadera novedad

El precio de entrada permanece en 10 dólares por millón de tokens.

El de salida continúa en 50 dólares por millón.

Lo que sí cambió es el costo de lectura de caché, que pasó de representar una décima parte del precio de entrada a una cuadragésima parte.

En términos concretos, bajó de 1 dólar a 0,25 dólares.

Anthropic estima que esto puede generar un ahorro del 25 % en cargas de trabajo habituales y de hasta un 45 % en sistemas que utilizan agentes de manera intensiva, donde los prefijos almacenados en caché representan buena parte del consumo.

Estas estimaciones coinciden con los primeros resultados compartidos por profesionales del sector pocas horas después del lanzamiento.

Un equipo que ejecutaba evaluaciones afirmó haber medido una reducción aproximada del 30 % en el costo real por tarea.

Otro desarrollador calculó que, con una tasa de aciertos de caché del 95 %, el contexto utilizable antes de activar la compactación automática prácticamente se duplica, pasando de 200.000 a 400.000 tokens.

Sin embargo, hay un detalle importante si utilizas Claude mediante una suscripción y no directamente a través de la API.

Los ahorros anunciados se aplican a los entornos donde el consumo se factura por tokens.

Varias personas suscritas a los planes Pro y Max preguntaron el día del lanzamiento si estos cambios ampliarían sus límites de uso.

La interpretación del anuncio es que no.

Anthropic sí reinició las ventanas de uso de todas las cuentas, lo que ayudó a suavizar el impacto de esta limitación.

El problema que Anthropic resolvió solo a medias

Desde junio, el principal problema de Fable nunca ha sido su capacidad.

El verdadero inconveniente es que muchas veces no puedes utilizarlo, aunque creas que sí.

Los mecanismos de seguridad de Anthropic redirigen determinadas solicitudes consideradas de doble uso hacia un modelo Opus.

Y para una cantidad considerable de desarrolladores, esta redirección ocurre constantemente.

El anuncio aborda directamente esta situación.

Ahora, las protecciones relacionadas con biología se activan un 85 % menos en consultas benignas sobre biología básica y cuestiones médicas.

Fable 5.1 también puede identificar vulnerabilidades de software, una actividad que forma parte del trabajo defensivo en ciberseguridad.

Además, Anthropic asegura que quienes utilizan Claude Code deberían experimentar aproximadamente un 60 % menos de intervenciones de seguridad por sesión.

Es una mejora importante.

Pero sigue sin ser la solución que esperaban los profesionales de ciberseguridad.

Las pruebas de penetración, la generación de exploits y el análisis de vulnerabilidades en archivos binarios continúan siendo redirigidos a Opus.

La conversación del día del lanzamiento en Hacker News reveló una situación todavía más llamativa.

Un ingeniero de seguridad que había pasado meses completando procesos de verificación de identidad, conocidos como KYC, y procedimientos de adquisición para inscribir a su organización en el Cyber Verification Program descubrió que este programa no habilita el acceso a Fable.

Para conseguirlo, es necesario pertenecer a Project Glasswing, que proporciona acceso a Mythos.

Anthropic afirma que el Cyber Verification Program incluirá modelos de la clase Mythos en un futuro próximo.

El problema es que «futuro próximo» sigue siendo una expresión bastante imprecisa.

La observación que más se repitió durante el lanzamiento no estuvo relacionada con la calidad del modelo, sino con personas que descubrieron que llevaban semanas creyendo que utilizaban Fable cuando, en realidad, sus solicitudes habían sido redirigidas silenciosamente a Opus.

Un desarrollador estimó que realmente estaba utilizando Fable aproximadamente el 20 % de las veces que pensaba estar haciéndolo.

Finalmente, decidió utilizar Opus de forma predeterminada.

Otras personas compartieron experiencias completamente diferentes y afirmaron haber resuelto problemas complejos en un solo intento, con redirecciones ocasionales.

Las respuestas muestran un patrón que depende del ámbito de trabajo.

El desarrollo web y la programación general rara vez activan estas restricciones.

En cambio, los proyectos relacionados con autenticación, seccomp, ingeniería inversa o servicios financieros las activan con mucha más frecuencia.

Si tu actividad pertenece a alguna de estas categorías, las mejoras anunciadas en las pruebas de rendimiento pueden no llegar a beneficiarte.

También es importante considerar el contexto comercial.

Financial Times informó que Fable 5 había registrado una demanda limitada entre clientes corporativos, mientras que las herramientas más económicas seguían ganando terreno.

Ese es el escenario en el que Anthropic presenta una actualización cuyo cambio económico más importante es, precisamente, una reducción de precios.

La mitad de los cambios están relacionados con mecanismos de protección

Migrar de claude-fable-5 a claude-fable-5-1 introduce tres cambios que pueden afectar a las aplicaciones existentes.

Los tres funcionan, en la práctica, como mecanismos de protección frente a la destilación de modelos.

1. El uso forzado de herramientas devuelve un error 400

Configurar tool_choice con el valor any o con el nombre de una herramienta específica ahora provoca que la solicitud sea rechazada.

La explicación oficial de Anthropic es que forzar una llamada a herramientas omite el proceso de razonamiento y reduce la calidad de los argumentos generados.

Al mismo tiempo, este cambio bloquea una técnica conocida que utilizaba una herramienta de razonamiento falsa para extraer directamente la cadena de pensamiento del modelo.

2. Los bloques de razonamiento quedan vinculados al modelo que los generó

Fable 5.1 puede leer bloques de razonamiento producidos por modelos anteriores.

Sin embargo, los modelos anteriores no pueden leer los bloques generados por Fable 5.1.

Cuando el modelo de destino no puede interpretar uno de estos bloques, se descarta silenciosamente.

La excepción es utilizar un encabezado beta específico que permite recibir información sobre los bloques descartados.

3. Modificar mensajes anteriores invalida los bloques de razonamiento

Si modificas el prompt del sistema, el conjunto de herramientas o cualquier mensaje anterior de la conversación, la siguiente solicitud devuelve un error.

Las conversaciones deben construirse ahora de manera acumulativa: se pueden agregar mensajes nuevos, pero no modificar los anteriores.

Esta restricción se aplica a las cuentas creadas a partir del 31 de agosto.

Las cuentas existentes están exentas por el momento, aunque Anthropic afirma que la comprobación se extenderá a todas en futuras versiones de sus modelos.

Claude Code, claude.ai y Agent SDK gestionan automáticamente este comportamiento.

Pero si tu aplicación construye manualmente el arreglo messages, tendrás que adaptar tu implementación.

Anthropic también ha explicado los motivos detrás de estas decisiones.

En febrero, la compañía identificó más de 16 millones de intercambios con Claude vinculados a campañas de destilación realizadas mediante aproximadamente 24.000 cuentas falsas.

La manipulación del contexto de conversaciones era una técnica documentada para intentar extraer el razonamiento interno del modelo.

Bloquear este mecanismo tiene una justificación técnica.

Sin embargo, también es la segunda vez en tres meses que Anthropic introduce restricciones adicionales junto con mejoras de capacidad.

Y la comunidad de desarrolladores lo ha notado.

Una de las interpretaciones más apoyadas del lanzamiento fue especialmente crítica: al menos la mitad de los cambios parecen estar destinados a impedir la destilación.

A esto se suma una nueva capa de procedencia del contenido.

Todas las salidas de texto de estos modelos incorporan ahora una marca de agua estadística de Anthropic.

Según el anuncio, esta medida responde a los compromisos del Código de Buenas Prácticas de la Ley de Inteligencia Artificial de la Unión Europea, al que Anthropic se adhirió en julio y que se aplica a los modelos lanzados después del 2 de agosto.

Las imágenes y los videos incluyen credenciales C2PA firmadas digitalmente.

La API para detectar estas marcas se encuentra en una versión preliminar privada, actualmente limitada a organismos reguladores, investigadores, verificadores de información y organizaciones con obligaciones específicas de cumplimiento normativo.

El avance científico del que casi nadie está hablando

Si dejamos a un lado los precios y las discusiones sobre restricciones de seguridad, aparece una de las partes más interesantes de este lanzamiento: las aplicaciones científicas.

Mythos 5.1 recibió acceso a herramientas de código abierto para el diseño y plegamiento de proteínas.

Su tarea consistía en diseñar moléculas capaces de unirse a objetivos biológicos específicos, conocidas como binders.

Los diseños fueron enviados a dos organizaciones externas para su validación en laboratorio.

En tres objetivos, las afinidades de unión fueron diez veces superiores a las mejores propuestas presentadas en las competiciones de diseño de proteínas de Adaptyv Bio.

La tasa de éxito en un conjunto de 12 objetivos se acercó al 50 %, frente a un promedio habitual del sector de entre el 10 % y el 15 %.

Por otro lado, Fable 5.1 entrenó una red neuronal utilizando datos de radar de la misión Magellan, recopilados hace aproximadamente 30 años.

El resultado fue un nuevo mapa de elevación que cubre un tercio de la superficie de Venus.

El modelo consiguió identificar características geográficas con una resolución de entre 2 y 3 kilómetros, frente a los 10 a 20 kilómetros de las referencias anteriores.

Anthropic publicó este trabajo bajo una licencia Creative Commons, antes de las misiones VERITAS de la NASA y EnVision de la Agencia Espacial Europea.

Pero hay otro resultado que merece especial atención.

Mythos 5.1 desarrolló kernels personalizados para GPU que aceleraron hasta 2,5 veces la ejecución de siete modelos de código abierto relacionados con genómica y proteínas, manteniendo resultados idénticos.

Estas optimizaciones permitieron estimar una reducción del costo de GPU de entre un 30 % y un 60 % en análisis genómicos a gran escala.

Probablemente este sea uno de los avances más importantes y menos comentados del anuncio.

Tradicionalmente, optimizar kernels de este nivel requiere semanas de trabajo por parte de equipos especializados en ingeniería de rendimiento.

Para muchos laboratorios académicos, ese esfuerzo resulta económicamente inaccesible.

Anthropic afirma que tiene previsto publicar estas optimizaciones como código abierto.

Si se concreta, podría facilitar el acceso a capacidades de computación avanzada que hasta ahora estaban fuera del alcance de numerosos equipos de investigación.

¿Para quién tiene sentido Fable 5.1?

Fable 5.1 representa una actualización valiosa para un grupo específico de usuarios, pero puede resultar poco relevante para la mayoría de quienes están siguiendo este lanzamiento.

La decisión de migrar debería depender de las características reales de tu trabajo.

Cuándo sí conviene cambiar

Si ejecutas sesiones prolongadas con agentes de IA y tienes tasas elevadas de aciertos de caché, la reducción de los costos de lectura puede representar un ahorro de entre el 25 % y el 45 %.

Es una diferencia que, acumulada diariamente, puede tener un impacto considerable.

También merece la pena considerar la migración si trabajas en investigación científica o automatización de procesos complejos con múltiples etapas.

En estos escenarios, las diferencias en las pruebas de rendimiento son lo suficientemente grandes como para traducirse en mejoras prácticas.

Cognition anunció el mismo día del lanzamiento que trasladaría parte del tráfico de Opus utilizado en Devin hacia Fable.

El motivo principal fue el nuevo precio de caché, que permite utilizar un modelo de esta categoría para revisiones de código con una estructura de costos más viable.

Cuándo no conviene cambiar

Si tu trabajo está relacionado con seguridad informática, autenticación, ingeniería inversa u otras actividades que activan los clasificadores de seguridad, la migración puede no ofrecerte los beneficios que esperas.

Seguirás pagando las tarifas de Fable mientras determinadas solicitudes terminan siendo procesadas por Opus.

Tampoco parece necesario cambiar si tu actividad se centra en desarrollo de software general.

En la mayoría de las pruebas, Opus 5 se mantiene a pocos puntos de Fable 5.1, pero con un costo aproximadamente dos veces menor.

Y si tienes previsto migrar sistemas basados en agentes, conviene revisar cuidadosamente las notas de comportamiento antes de realizar cualquier cambio.

Fable 5.1 presenta algunas diferencias respecto a Fable 5 que pueden afectar directamente al consumo de tokens y al funcionamiento de tus aplicaciones.

Por ejemplo:

• Agrupa las llamadas paralelas a herramientas de manera menos consistente.
• Genera menos actualizaciones sobre el progreso de las tareas.
• Recurre con mayor frecuencia a la información almacenada en su conocimiento interno cuando opera con un nivel de esfuerzo bajo.
• Tiende a reescribir archivos completos en situaciones donde bastaría con modificar una sección específica.

Cada uno de estos comportamientos puede aumentar el consumo de tokens.

Y cuando trabajas con aplicaciones en producción, pequeñas diferencias repetidas miles de veces pueden convertirse en costos importantes.

La recomendación más importante viene de la propia Anthropic

La documentación oficial propone un enfoque bastante sencillo:

Comienza con Opus 5 y considera cambiar a un modelo superior únicamente cuando tus evaluaciones, incluso utilizando un nivel de esfuerzo alto, demuestren que el rendimiento resulta insuficiente.

Es una recomendación poco habitual para una compañía que acaba de presentar sus modelos más avanzados.

Pero también es, posiblemente, la conclusión más útil de todo este lanzamiento.

No necesitas utilizar el modelo más potente disponible. Necesitas utilizar el modelo que resuelva tu problema con la calidad adecuada y el menor costo posible.

La diferencia entre ambas decisiones puede parecer pequeña cuando realizas unas cuantas consultas.

Cuando construyes productos, automatizaciones o sistemas de inteligencia artificial que funcionan todos los días, esa diferencia puede determinar la viabilidad económica de toda tu operación.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Alibaba escondió la parte más interesante del lanzamiento de Qwen3.8-Max en una página de documentación que pasó casi desapercibida: las instrucciones para conectar Claude Code, el propio entorno de programación de Anthropic, directamente con Qwen.

Piénsalo por un momento. Anthropic desarrolló el entorno de programación, Alibaba replicó la API que funciona por debajo y ahora Claude Code puede ejecutar Qwen sin notar la diferencia. Y lo más curioso es que esto funciona en ambas direcciones: durante el lanzamiento, Alibaba utilizó el propio Claude Code para obtener las puntuaciones de Fable 5 que incluyó en su tabla comparativa.

La propuesta se puede resumir en una sola idea: según las pruebas de Artificial Analysis, una tarea con Fable cuesta 3,14 dólares, mientras que con Qwen cuesta 0,91 dólares. Eso significa que, por el precio de un intento con Fable, puedes realizar tres intentos con Qwen. Y cuando trabajas con tareas que pueden evaluarse mediante pruebas automatizadas, tres intentos suelen ofrecer mejores resultados.

¿Quieres probarlo ahora mismo? Abre el archivo ~/.claude/settings.json e introduce esta configuración:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://token-plan.ap-southeast-1.maas.aliyuncs.com/apps/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "your-model-studio-key",
    "ANTHROPIC_MODEL": "qwen3.8-max"
  }
}

Solo necesitas tres valores para cambiar el modelo que funciona dentro de Claude Code. Así de sencillo.

Cambias la URL base, añades tu clave de API e indicas el modelo Qwen que quieres utilizar. De repente, el entorno de programación que usas todos los días está trabajando con un modelo de mezcla de expertos (Mixture of Experts, MoE) de 2,4 billones de parámetros, con un precio de entrada cinco veces menor.

Y sigue siendo, literalmente, Claude Code.

Hace unos meses, yo misma tenía mis dudas sobre este tipo de afirmaciones. No confiaba demasiado en los sistemas de orquestación que combinan varios modelos, porque normalmente el mejor modelo individual termina ganando cuando comparas precisión y coste.

Pero aquí no estamos hablando de un sistema que decide entre diferentes modelos. Estamos hablando de un único modelo que realiza varios intentos para mejorar sus propios resultados.

Y funciona por una razón puramente matemática.

Las cuentas detrás del precio

Primero, veamos los precios por millón de tokens:

Las publicaciones de la semana del lanzamiento prometían un descuento enorme: cinco veces menos en tokens de entrada y 8,3 veces menos en tokens de salida.

En la práctica, la diferencia real se acerca más a tres veces.

Artificial Analysis evaluó todos los modelos utilizando exactamente el mismo conjunto de pruebas y publicó el coste total: 1.532 dólares para Qwen3.8-Max frente a 5.455 dólares para Fable 5.

Por tarea, eso representa 0,91 dólares frente a 3,14 dólares.

La diferencia se reduce porque Qwen genera mucho más texto.

Con exactamente la misma carga de trabajo, produjo 150 millones de tokens de salida, mientras que Fable necesitó 83 millones. Y que los tokens sean más baratos deja de ser tan relevante cuando utilizas casi el doble.

Kilo Code encontró una proporción similar en su propia prueba de creación de interfaces de usuario, compuesta por diez tareas: 3,05 dólares para Qwen frente a 8,44 dólares para Fable.

Por tanto, la comparación real es bastante sencilla:

Renuncias a un intento con Fable y, por el mismo presupuesto, puedes realizar tres intentos con Qwen para resolver la misma tarea.

Las pruebas de rendimiento

Las tablas comparativas que aparecen durante el lanzamiento de un modelo merecen un análisis riguroso. Veamos qué resultados realmente se sostienen.

En el Intelligence Index de Artificial Analysis, Fable 5 obtiene 62 puntos y Qwen alcanza 58.

La diferencia es de solo cuatro puntos, mientras que el coste de Qwen representa aproximadamente un tercio.

En la clasificación Frontend Code de Arena.ai, donde las personas votan sin conocer qué modelo generó cada resultado visual, Qwen debutó en el cuarto puesto con 1.668 puntos Elo y llegó a superar a Fable 5.

La tabla de lanzamiento de Alibaba también presenta varias victorias adicionales, entre ellas Terminal-Bench 2.1, OSWorld-Verified y pruebas de seguimiento de instrucciones.

Pero el dato más interesante es precisamente la derrota que la propia Alibaba reconoce.

En SWE-bench Pro, una evaluación de ingeniería de software de nivel profesional que utiliza repositorios reales, Fable obtuvo 80,0 puntos frente a los 67,7 de Qwen.

Cuando una empresa presenta una diapositiva en la que su competidor aparece más de 12 puntos por delante, conviene prestar especial atención a ese resultado.

El patrón es bastante consistente en las distintas evaluaciones.

Fable es más inteligente, especialmente en trabajos de ingeniería largos, complejos y distribuidos entre varios repositorios.

Qwen, por su parte, ofrece capacidades cercanas a las de los modelos más avanzados, pero con un descuento sostenido de aproximadamente tres veces.

Ninguno de los dos proveedores discute realmente esta diferencia. Simplemente eligen destacar los resultados que mejor respaldan su propuesta.

artificialanalysis.ai

Una diferencia de cuatro puntos en inteligencia y una diferencia de aproximadamente tres dólares por tarea. Datos: Artificial Analysis, agosto de 2026.

Por qué sigue teniendo sentido utilizar Fable 5

El modelo más caro continúa siendo realmente mejor. Y en algunas situaciones, la diferencia es considerable.

En la comparación directa realizada por Kilo Code, Fable resolvió correctamente las diez tareas en el primer intento, con un promedio de aproximadamente dos minutos por tarea.

Qwen, en cambio, necesitó repetir tres de esas tareas y tardó casi ocho minutos de media.

Esto significa que el modelo más económico resultó ser 3,6 veces más lento por cada tarea completada.

Además, en la única prueba que incluía restricciones estrictas, solo Fable respetó completamente las especificaciones.

Qwen ignoró una limitación explícita que establecía un radio máximo de ocho píxeles para las esquinas.

Las evaluaciones de referencia indicaban que Qwen seguía mejor las instrucciones, pero las pruebas prácticas mostraron lo contrario.

Si una persona del equipo de ingeniería está sentada frente a la pantalla, supervisando lo que ocurre en la terminal, su tiempo se convierte en el recurso más caro.

En ese escenario, el modelo que termina correctamente en el primer intento puede ser la opción más económica, independientemente de cuánto cuesten los tokens.

Esa razón, por sí sola, puede justificar utilizar Fable.

Sin embargo, existe un principio de escalabilidad que cambia por completo el análisis.

Los monos tienen un estudio científico

En 2024, un grupo de investigadores publicó un trabajo titulado Large Language Monkeys, en el que analizaron qué ocurre cuando generamos muchas respuestas diferentes utilizando el mismo modelo.

Descubrieron que el rendimiento mejora siguiendo una relación aproximadamente logarítmica-lineal a medida que aumenta el número de intentos.

DeepSeek-Coder-V2-Instruct consiguió resolver el 15,9 % de los problemas de SWE-bench Lite en el primer intento.

Pero cuando se le permitieron 250 intentos, alcanzó una tasa de resolución del 56 %, superando los mejores resultados de un solo intento disponibles en aquel momento.

Incluso con apenas cinco muestras, el modelo más económico conseguía superar a un único intento de algunos modelos de frontera, y lo hacía con un coste menor.

Investigaciones posteriores continuaron confirmando este patrón: un modelo más pequeño que dispone de mayor capacidad de procesamiento durante la fase de resolución puede superar a otro 14 veces más grande cuando ambos trabajan con presupuestos equivalentes.

Además, pasar de uno a cuatro intentos puede aumentar las tasas de éxito aproximadamente un 50 %.

Ese es el verdadero secreto: un mismo modelo que genera múltiples soluciones para un problema.

Y cuando puedes obtener tres respuestas de Qwen por el precio de una de Fable, entras directamente en un escenario especialmente interesante.

Imagina dos personas jugando a los dardos.

Una tiene una puntería excelente, pero solo dispone de un lanzamiento.

La otra tiene una puntería algo peor, pero puede lanzar tres veces.

En muchos casos, quien dispone de tres oportunidades terminará consiguiendo un mejor resultado, porque puede conservar los aciertos y descartar los errores.

Pero hay un detalle importante.

Necesitas poder ver dónde han caído los dardos.

Lo que dicen las condiciones de este enfoque

La mejora de rendimiento mediante múltiples intentos solo funciona cuando existe algún mecanismo independiente capaz de evaluar los resultados.

Por ejemplo, una batería de pruebas automatizadas, un compilador o un error que pueda reproducirse de manera consistente.

Si eliminas esas comprobaciones, toda la teoría pierde su fundamento.

Y las investigaciones son bastante claras al respecto: aumentar la capacidad de procesamiento sin verificar los resultados es una forma de desperdiciar dinero.

Además, cuando el sistema de verificación tiene errores, los falsos positivos terminan acumulándose.

Tener infinitos monos escribiendo con un árbitro incapaz de distinguir la calidad solo significa que acabarás aceptando cualquier resultado como si fuera una obra de Shakespeare.

Existe un segundo problema.

Los errores de un mismo modelo suelen estar correlacionados.

Si un modelo tiene dificultades para comprender una determinada categoría de problemas, realizar 250 intentos no garantiza que consiga resolverlos.

Y la distancia entre «uno de mis intentos fue correcto» y «entregué la solución correcta» depende completamente de la calidad del sistema de verificación.

Una batería de pruebas poco fiable no solo deja pasar errores. También puede descartar soluciones que realmente funcionaban.

Por tanto, realizar tres intentos resulta ventajoso cuando se cumplen determinadas condiciones: la tarea dispone de una comprobación objetiva y económica, el modelo tiene capacidad para comprender el problema y el tiempo total de ejecución no es una limitación importante.

Las limitaciones que debes conocer

Hay varios aspectos adicionales que los precios de las API no muestran.

Fable 5 te hace esperar.

Su tiempo mediano hasta generar el primer token es de 126 segundos, porque realiza un proceso de razonamiento interno antes de comenzar a escribir.

Qwen, en cambio, empieza a generar respuestas en aproximadamente 2,7 segundos.

Así que el modelo más inteligente puede dejarte mirando una terminal vacía durante dos minutos y luego terminar antes.

Mientras tanto, el modelo más económico empieza casi inmediatamente, pero genera respuestas más largas y necesita más tiempo para completar el trabajo.

Tú decides qué tipo de espera prefieres.

Alibaba también establece un límite de 15.000 solicitudes por minuto para toda la cuenta, no para cada clave de API.

Esto significa que una estrategia basada en generar múltiples respuestas y seleccionar la mejor (best-of-N) puede alcanzar ese límite rápidamente.

Otro aspecto importante es la ubicación de la infraestructura.

El endpoint funciona desde Singapur, en infraestructura propiedad de una empresa china.

Esto introduce consideraciones regulatorias y de cumplimiento normativo que pueden impedir utilizar esta alternativa en sectores como las finanzas, la salud o la administración pública.

También hay que tener cuidado con la expresión pesos abiertos (open weights).

Alibaba publicó los pesos del modelo de 2,4 billones de parámetros, pero el lanzamiento incluye algunas condiciones.

El modelo utiliza una licencia personalizada, solo admite texto y necesita aproximadamente un terabyte de memoria para cargarse.

No estamos hablando de algo que puedas ejecutar fácilmente en una MacBook.

Por último, hay una limitación técnica importante: Claude Code fue diseñado para trabajar con Claude.

Cuando lo conectas a Qwen, pierdes algunas capacidades, como la posibilidad de forzar el uso de determinadas herramientas. El almacenamiento en caché también se comporta de manera diferente.

En general, muchas funciones siguen trabajando correctamente, pero la experiencia no es exactamente la misma.

Cómo organizo mis tareas entre ambos modelos

A septiembre de 2026, esta es la manera en que distribuyo personalmente mis tareas.

Qwen se encarga de los trabajos en los que puedo comprobar fácilmente el resultado.

Por ejemplo, refactorizaciones por lotes respaldadas por pruebas automatizadas, scripts de migración, iteraciones de interfaces de usuario en las que puedo verificar visualmente el resultado y cualquier proceso que pueda ejecutarse durante la noche.

En estos casos, el tiempo de ejecución no representa un problema importante y disponer de un presupuesto tres veces más eficiente significa poder realizar tres intentos para cada dificultad relevante.

Fable 5, en cambio, se encarga de los trabajos donde una decisión incorrecta puede pasar desapercibida hasta que corregirla resulta costoso.

Aquí incluyo tareas de ingeniería que abarcan varios repositorios, decisiones de arquitectura sin pruebas capaces de detectar errores, especificaciones complejas y cualquier situación donde una persona deba identificar manualmente un fallo antes de que pueda iniciarse un nuevo intento.

Elegir un modelo diferente para cada tarea es, en esencia, una forma de enrutamiento.

Y anteriormente he defendido que un sistema de enrutamiento que toma decisiones equivocadas puede terminar siendo peor que pagar directamente por el mejor modelo.

Pero aquí existe una diferencia fundamental.

No necesitas adivinar.

Solo tienes que observar la tarea y preguntarte si dispone de una batería de pruebas capaz de verificar el resultado.

La auditoría que deberías realizar

Antes de cambiar de modelo, conviene revisar algunos aspectos de tu trabajo.

- Cuenta tus pruebas. Revisa las ejecuciones de tus agentes durante el último mes y calcula cuántas terminaron con una batería de pruebas superada correctamente. Esa proporción representa el tipo de tareas que podrías asignar a Qwen.

- Supervisa los tokens de salida. Si Qwen genera más del doble de tokens que Fable para tu carga de trabajo, el ahorro puede desaparecer.

- Calcula cuánto vale tu tiempo. Las sesiones interactivas necesitan modelos capaces de resolver correctamente los problemas en el primer intento. Los procesos desatendidos tienen otras prioridades.

- Comprueba los requisitos de cumplimiento normativo. ¿Puedes procesar tus datos en Singapur? Si la respuesta es negativa, no tiene sentido continuar con esta alternativa.

- Realiza una comparación práctica. Prueba ambos modelos con tres tareas reales de tu propio repositorio antes de migrar cualquier proceso.

La analogía de los dardos resume perfectamente la decisión.

Tres intentos económicos para resolver un módulo que cuenta con buenas pruebas automatizadas pueden representar una excelente oportunidad de ahorro.

Pero tres intentos económicos para diseñar una arquitectura que nadie puede verificar no son más que tres suposiciones.

¿Cómo distribuirías tus tareas entre estos dos modelos?

Cuenta cuántas de tus tareas tienen resultados que puedes verificar objetivamente y comparte ese número.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

En 2025, comencé a trasladar algunos de mis proyectos de ChatGPT a Claude y Gemini.

Y no soy la única persona que lo está haciendo.

¡La participación de ChatGPT en el tráfico web ha caído del 86,7 % al 64,5 % en los últimos 12 meses!

No creo que las personas estén abandonando ChatGPT por completo (yo tampoco lo he hecho).

Lo que está ocurriendo es que quienes más utilizan la inteligencia artificial están descubriendo que otras herramientas, como Gemini y Claude, son mejores que ChatGPT en determinadas áreas.

En esta guía compartiré cuáles son los mejores modelos de IA para diferentes casos de uso. Al terminar, comprenderás por qué muchas personas están empezando a utilizar otras herramientas de inteligencia artificial.

Aquí tienes un resumen rápido:

Leyenda: Mejor = ⭐ | Bueno = ✅ | No = ❌

Seguimiento de instrucciones

He probado mis mejores prompts en ChatGPT, Claude y Gemini.

Claude es la herramienta que mejor sigue mis instrucciones, incluso después de los lanzamientos de GPT-5.2 y Gemini 3. Es capaz de respetar cada detalle, incluso cuando trabajo con prompts largos.

Por ejemplo, tengo un prompt que revisa y corrige mis guías, pero que también muestra los cambios realizados. Las eliminaciones deben aparecer en rojo (con el texto tachado) y las inserciones en azul.

Aquí tienes una comparación entre Claude y ChatGPT.

Claude resaltó correctamente las eliminaciones y las inserciones de texto, mientras que ChatGPT no lo hizo bien.

También pedí una «edición ligera que conservara mi intención y mi estilo». Claude siguió mis instrucciones, mientras que ChatGPT, en algunos casos, cambió completamente mis frases.

Este es solo un ejemplo de un prompt. Tengo muchos otros en los que Claude demuestra ser muy superior a ChatGPT y Gemini cuando se trata de seguir instrucciones.

Análisis de audio y video

Según mi experiencia, Gemini 3 es la mejor herramienta para analizar audio y video.

Le proporcioné a Gemini un video en el que aparecía haciendo ejercicios en el gimnasio, y me ofreció recomendaciones basadas en lo que podía observar.

También le compartí una grabación de audio hablando en inglés (no soy hablante nativa de ese idioma), y me dio comentarios sobre mi pronunciación y los aspectos que necesitaba mejorar.

ChatGPT funciona bien analizando videos, aunque es más lento que Gemini, pero no me ha funcionado para analizar audio.

Subí grabaciones de audio y solicité su transcripción y análisis, pero recibí esta respuesta:

«No puedo escuchar el audio ni ejecutar un modelo adecuado de reconocimiento de voz».

Sin embargo, esto podría cambiar con futuras actualizaciones.

Capacidades de los agentes de IA

Para este apartado, evaluaré los agentes que ofrecen estas herramientas para controlar el navegador y gestionar las carpetas de tu computadora.

ChatGPT, Claude y Gemini cuentan con un modo agente que les permite controlar tu navegador en tu nombre.

Los tres funcionan bien cuando necesitan realizar acciones en páginas web, como hacer clic, desplazarse por la pantalla y otras tareas similares.

Mi opción favorita es Claude.

Aquí tienes una demostración de la extensión Claude para Chrome, que permite controlar el navegador, compartida por Emily Lambert en X.

Si quieres probar estas herramientas, puedes activar el modo agente en ChatGPT o Gemini, o descargar la extensión de Claude.

Por otro lado, Claude Cowork es la única opción que permite realizar acciones directamente sobre las carpetas de tu computadora, como el escritorio, las descargas y otras ubicaciones.

Puede explorar carpetas, gestionar archivos y generar entregables completos.

Aquí tienes un ejemplo:

Para mí, Claude es la herramienta ganadora en esta categoría.

Ofrece capacidades de agente tanto para trabajar en el navegador como para gestionar las carpetas de la computadora.

Uso cotidiano

Actualmente, Claude es mi herramienta de inteligencia artificial favorita, pero no puedo utilizarla tanto como me gustaría.

¿Por qué?

Porque alcanzo su límite diario de uso con mucha frecuencia.

Eso casi nunca me ocurre cuando utilizo ChatGPT o Gemini.

Estos son los límites diarios de ChatGPT Plus, Claude Pro y Gemini Pro:

Aunque prefiero utilizar Claude, ChatGPT y Gemini son mejores alternativas para el uso cotidiano porque ofrecen límites diarios de utilización más altos.

Modo de voz

Utilizo mucho el modo de voz en mi vida diaria.

Y, con diferencia, el modo de voz de ChatGPT es el mejor.

Hablar con Gemini se siente robótico. Tienes la sensación de estar conversando con una inteligencia artificial.

En cambio, hablar con ChatGPT resulta mucho menos robótico. Tiene una voz más natural, una conversación fluida y una personalidad propia.

Una de las cosas para las que utilizo el modo de voz es practicar idiomas extranjeros.

¡Es como hacer un intercambio de idiomas con otra persona!

El modo de voz de ChatGPT comprende las instrucciones que le doy en mis prompts, como la manera en que quiero recibir correcciones sobre el idioma o cómo deseo que continúe la conversación.

Gemini no consigue hacerlo correctamente, mientras que el modo de voz de Claude solo funciona en inglés.

Generación de imágenes y videos

En términos generales, la mejor herramienta de inteligencia artificial para generar imágenes es Nano Banana, de Gemini.

Estas son algunas de las razones:

Comprende bien las instrucciones de los prompts.

Permite mantener personajes consistentes entre distintas imágenes.

Ofrece buenos resultados estéticos, de diseño gráfico y en otros aspectos visuales.

Dicho esto, la generación de imágenes de ChatGPT no está muy lejos de Nano Banana.

De hecho, tengo algunos prompts que funcionan mejor en ChatGPT.

En general, utilizo Nano Banana para crear infografías, transformar ideas en elementos visuales de calidad profesional y combinar varias imágenes.

Para el resto de las tareas, prefiero utilizar ChatGPT.

En cuanto a la generación de videos, Sora 2 y Veo 3 están al mismo nivel.

He probado diferentes prompts y, en ocasiones, Sora genera mejores videos, pero otras veces Veo 3 consigue resultados muy superiores.

Aquí tienes una comparación realizada por TechByMarkandey y compartida en X.

En la publicación, Markandey Sharma explica que antes crear videos con IA era complicado porque había que trabajar con demasiadas pestañas y exportar archivos constantemente.

Ahora es posible utilizar Sora 2, Veo 3.1 y el nuevo Nano Banana 2 dentro de un mismo flujo de trabajo.

Sin necesidad de cambiar de herramienta ni esperar entre procesos. Simplemente, crear.

Bonus: Programación

Para ser completamente transparente, durante 2025 no he utilizado la inteligencia artificial para programar tanto como en años anteriores.

Dicho esto, hace seis meses, Peter Yang descubrió que Claude es la mejor herramienta para programar, mientras que Gemini ofrece la mejor relación entre costo y rendimiento.

Dudo que las cosas hayan cambiado demasiado en los últimos meses, especialmente si tenemos en cuenta la reciente popularidad de Claude Code.

Es una herramienta fantástica, no solo para quienes se dedican a la programación, sino también para cualquier persona que no tenga miedo de interactuar con la terminal de su computadora.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

El 3 de abril de 2026, Andrej Karpathy publicó algo que llamó «LLM Knowledge Bases» (bases de conocimiento para modelos de lenguaje), y en cuestión de horas la idea comenzó a difundirse por toda la comunidad de inteligencia artificial.

La propuesta central era sorprendentemente sencilla: en lugar de utilizar RAG para recuperar fragmentos de archivos originales cada vez que haces una pregunta, puedes hacer que un modelo de lenguaje convierta esos archivos en una wiki estructurada, interconectada y escrita en Markdown.

Esta wiki permanece disponible entre sesiones, acumula conocimiento con el tiempo y permite que cada consulta futura sea más económica.

Karpathy explicó que su método consistía en colocar artículos científicos, capturas de pantalla, repositorios y otros documentos dentro de una carpeta llamada /raw. Después, un modelo de lenguaje procesaba todo ese contenido para crear una wiki con resúmenes, enlaces entre documentos, mapas conceptuales y un archivo índice que el propio modelo podía recorrer de forma autónoma.

Sin embeddings vectoriales, sin sistemas complejos de recuperación de información. Simplemente archivos Markdown cuyo conocimiento se va acumulando.

La publicación se volvió viral, al igual que el GitHub Gist que compartió posteriormente. De repente, todo el mundo hablaba de utilizar conocimiento previamente estructurado como alternativa a los sistemas tradicionales de recuperación de información.

Mi primera reacción fue una mezcla de interés y cierta frustración, porque llevaba tiempo explorando ideas similares mientras trabajaba con Claude Code en repositorios grandes.

Me encontraba con el mismo problema que muchas personas: el modelo vuelve a descubrir toda la estructura de tu código desde cero en cada sesión, y la ventana de contexto se llena mucho antes de que consiga comprender realmente la arquitectura del proyecto.

La explicación de Karpathy hizo que todo encajara. Sin embargo, él mismo reconocía que su implementación era una colección improvisada de scripts, y yo no tenía ninguna intención de construir desde cero mi propio compilador de wikis.

Entonces, apenas 48 horas después, alguien lanzó una herramienta que hacía precisamente eso.

Qué es Graphify y qué no es

Un desarrollador llamado Safi Shamsi publicó Graphify, una herramienta de código abierto que lleva a la práctica el enfoque propuesto por Karpathy, pero orientado específicamente a bases de código.

Solo necesitas indicarle una carpeta y la herramienta analiza todo su contenido: código escrito en 19 lenguajes de programación, documentos PDF, archivos Markdown e imágenes, incluidas fotografías de pizarras y diagramas mediante Claude Vision.

A partir de esa información, construye un grafo de conocimiento completo que incluye detección de comunidades, una visualización HTML interactiva, una bóveda de Obsidian con enlaces inteligentes entre documentos y una wiki.

Cualquier agente puede comenzar desde index.md y recorrer el conocimiento sin necesidad de interpretar archivos JSON.

La instalación requiere una sola línea:

pip install graphifyy && graphify install

Después, escribes /graphify dentro de Claude Code, Codex, OpenCode u OpenClaw y señalas el directorio de tu proyecto.

El resultado se guarda en una carpeta llamada graphify-out/, que contiene varios elementos:

graph.html: permite explorar el grafo de forma interactiva.

GRAPH_REPORT.md: destaca los nodos centrales, también llamados god nodes, y las conexiones inesperadas.

graph.json: almacena el grafo persistente que puede consultarse posteriormente.

Una caché incremental: evita tener que procesar nuevamente todos los archivos en futuras actualizaciones.

Ahora bien, también es importante entender lo que Graphify no es.

No es un sistema RAG, no es una base de datos vectorial y tampoco es una interfaz de chatbot construida sobre otro modelo.

Es una etapa de compilación, exactamente como la describió Karpathy, que transforma un directorio desorganizado en un recurso de conocimiento estructurado.

Gracias a ello, cualquier agente de IA puede razonar sobre el proyecto sin tener que leer todos sus archivos.

La cifra de 71,5 veces: primero el escepticismo, después las matemáticas

La afirmación principal es que Graphify puede reducir hasta 71,5 veces la cantidad de tokens necesarios por consulta en comparación con la lectura de los archivos originales.

La cifra parecía demasiado buena para ser cierta, así que decidí revisar cómo estaban diseñadas realmente las pruebas de rendimiento.

A pequeña escala, con seis archivos Python que representan una capa de transporte HTTP, la compresión es marginal y, en realidad, tampoco es lo más importante.

Esos archivos ya caben dentro de una ventana de contexto. En ese escenario, el verdadero valor está en la claridad estructural.

Puedes identificar que Client, AsyncClient, Response y Request son los nodos centrales del proyecto, y también visualizar los grupos o comunidades que reúnen módulos relacionados.

Eso resulta útil, pero está lejos de representar una mejora de 71 veces.

La situación cambia cuando analizamos un conjunto de 52 archivos compuesto por código, artículos de investigación e imágenes.

En ese caso, la reducción de tokens sí alcanza aproximadamente las 71 veces.

El repositorio incluye ejemplos completos, con los archivos de entrada originales y los resultados reales, de manera que cualquier persona puede comprobar las cifras por su cuenta.

Ese nivel de transparencia es algo que me gustaría encontrar con mayor frecuencia en los proyectos de código abierto.

La razón por la que la compresión mejora a medida que aumenta el tamaño del proyecto es bastante sencilla.

El grafo sintetiza toda la información en nodos, conexiones, resúmenes de comunidades y un informe que el modelo de lenguaje puede recorrer utilizando una fracción de los tokens que necesitaría para leer el contenido original.

Esto es especialmente importante en los flujos de trabajo basados en agentes de inteligencia artificial.

Si tienes varios agentes escribiendo código en paralelo, o estás trabajando durante una sesión prolongada de Claude Code que abarca varios commits, cargar 52 archivos originales en el contexto en cada interacción representa un desperdicio de recursos.

En cambio, proporcionar un informe del grafo que contiene la misma información estructural utilizando aproximadamente una septuagésima primera parte de los tokens cambia por completo el perfil de costos.

Cómo funciona internamente: no hay magia, solo buena ingeniería

La arquitectura es sorprendentemente transparente.

Los archivos de código se procesan mediante el análisis de árboles de sintaxis abstracta (AST) con tree-sitter, compatible con 19 lenguajes:

Python, JavaScript, TypeScript, Go, Rust, Java, C, C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, Elixir y Objective-C.

Todo este procesamiento se realiza de forma local.

En el caso del código, el contenido de los archivos no sale de tu computadora.

Los documentos y las imágenes, por su parte, se procesan mediante la API del modelo que ya utiliza tu plataforma para realizar la extracción semántica.

Por ejemplo, Claude si trabajas con Claude Code, o GPT-4 si utilizas Codex.

NetworkX se encarga de construir el grafo.

El algoritmo Leiden, a través de graspologic, realiza la detección de comunidades.

Y vis.js genera la visualización interactiva.

No necesitas Neo4j ni un servidor externo. Todo funciona localmente.

Además, cada conexión del grafo recibe una etiqueta que indica su nivel de confianza:

EXTRACTED (extraída): la relación se encontró directamente en el material original.

INFERRED (inferida): la relación fue deducida por el modelo a partir del contexto.

AMBIGUOUS (ambigua): la relación no puede determinarse con suficiente certeza.

Esto permite distinguir qué información procede realmente de los archivos y qué parte ha sido interpretada o deducida por la inteligencia artificial.

Donde realmente se aprecia la calidad de la ingeniería es en el sistema de actualizaciones incrementales.

El modo --watch funciona en una terminal en segundo plano y mantiene actualizado el grafo a medida que cambia el código del proyecto.

Cuando guardas un archivo de código, se reconstruye inmediatamente su estructura AST sin realizar ninguna llamada a un modelo de lenguaje.

En cambio, cuando modificas documentos o imágenes, el sistema te indica que ejecutes --update para repetir el análisis semántico.

Los hooks de Git, que se instalan mediante graphify hook install, reconstruyen el grafo después de cada commit y de cada cambio de rama.

Y si una reconstrucción falla, el hook termina con un código de error distinto de cero, lo que permite que Git muestre el problema en lugar de continuar silenciosamente con un grafo desactualizado.

Este último detalle puede parecer menor, pero antes el sistema terminaba con código cero incluso cuando se producía un error.

Eso significaba que el grafo podía quedar desactualizado sin mostrar ninguna advertencia.

Y precisamente ese tipo de errores silenciosos es el que termina debilitando la confianza en las herramientas de desarrollo.

Cómo se ve en la práctica: probando Graphify en mi propio repositorio

Leer pruebas de rendimiento está muy bien, pero quería comprobar cómo funcionaba Graphify en un proyecto real.

Así que decidí ejecutarlo sobre un repositorio propio.

El proyecto era un generador de códigos QR que había construido con Claude Code.

Tenía un total de 27 archivos, distribuidos de la siguiente manera:

18 archivos de código repartidos entre src/, test/ y carpetas de configuración.

4 documentos, entre ellos AGENTS.md, CLAUDE.md y FLOW.md.

5 imágenes, incluidas capturas de pantalla de la interfaz, el logotipo de Towards Deep Learning y un par de archivos PNG utilizados en las pruebas.

El proceso se ejecutó en cuatro etapas.

Primera etapa: exploración y clasificación.

Graphify recorrió la carpeta y clasificó todos los archivos según su tipo.

Segunda etapa: análisis del código.

Procesó los 18 archivos de código utilizando tree-sitter AST de forma local.

No intervino ningún modelo de lenguaje, por lo que esta parte no generó costos de uso de IA.

Solo esta etapa permitió extraer todas las funciones, clases, importaciones y relaciones de llamadas.

El resultado inicial fue de 162 nodos y 240 conexiones.

Por ejemplo, relaciones como:

src_main → calls → selectPalette()

Tercera etapa: interpretación de documentos e imágenes.

El sistema ejecutó seis subagentes de Claude en paralelo para analizar los documentos y las imágenes.

Esta fue la parte que utilizó el modelo de lenguaje y consumió aproximadamente 193.000 tokens.

Los agentes de visión examinaron las capturas de pantalla de la interfaz y consiguieron interpretarlas como elementos funcionales.

Por ejemplo, identificaron una relación que indicaba que la zona donde se arrastra el logotipo comparte datos con el panel de vista previa del código QR.

También reconocieron que la opción de corrección de errores de nivel H en la interfaz estaba relacionada con la justificación del indicador de verificación de decodificación.

Por su parte, el agente encargado de los documentos extrajo conceptos arquitectónicos presentes en AGENTS.md y FLOW.md.

Entre ellos:

Scan Verification Gate: mecanismo de verificación del escaneo.

Darken-and-Retry Loop: ciclo de oscurecimiento y nuevo intento.

Yellow Pitfall: problema o riesgo asociado al color amarillo.

Cuarta etapa: construcción del grafo completo.

Graphify combinó toda la información en un único grafo.

El resultado final fue:

229Nodos 296Conexiones 26Comunidades

El sistema ejecutó el algoritmo Leiden para detectar las comunidades, calculó cuáles eran los nodos centrales y cuáles funcionaban como puentes entre distintas comunidades.

También clasificó todas las relaciones como EXTRACTED, INFERRED o AMBIGUOUS.

La visualización interactiva del grafo, que aparece a continuación, es la que se genera en graphify-out/graph.html.

Puedes hacer clic sobre cualquier nodo para consultar su tipo, la comunidad a la que pertenece, el archivo de origen, su grado de conectividad y sus nodos vecinos.

La barra lateral muestra las 26 comunidades junto con la cantidad de nodos que contiene cada una.

También puedes activar o desactivar comunidades para aislar determinados grupos y analizarlos con mayor facilidad.

Junto con la visualización, Graphify dejó varios archivos almacenados en el disco.

El archivo graph.json contiene el grafo consultable que utiliza el comando graphify query.

El documento GRAPH_REPORT.md incluye un informe de auditoría con los nodos centrales, los hallazgos inesperados y algunas preguntas sugeridas.

Además, las carpetas cache/ y el archivo manifest.json permiten que una futura ejecución de --update procese únicamente los archivos que hayan cambiado.

Sin embargo, lo que más me sorprendió fue descubrir información que no resultaba evidente simplemente ejecutando ls o leyendo el código.

El verdadero centro de gravedad del repositorio no era la generación de códigos QR, sino la ciencia del color.

La parte más densamente conectada del grafo estaba formada por las matemáticas relacionadas con el contraste, las paletas y la extracción de colores.

Mientras tanto, la generación de códigos QR aparecía como dos dependencias de bibliotecas situadas en la periferia.

Los módulos src_main, src_palette y src_verify resultaron ser los principales centros estructurales.

El mecanismo de verificación de escaneo también ocupaba una posición central dentro de la arquitectura.

Eso era exactamente lo que exigía AGENTS.md, pero no habría sido tan evidente sin comparar, una al lado de la otra, la especificación y la implementación.

Las pruebas estaban conectadas directamente con los módulos que verificaban, en lugar de aparecer como elementos aislados.

En otras palabras, el grafo hacía visible una buena decisión de arquitectura.

Los conceptos presentes en AGENTS.md y FLOW.md formaban su propia comunidad independiente.

La especificación coincidía conceptualmente con el código, pero no existían conexiones estructurales directas entre ambos.

Ahí fue donde aparecieron 19 conexiones colgantes.

Además, las capturas de pantalla de la interfaz contenían afirmaciones sobre el producto, como «nunca sale de tu navegador» y «corrección de errores H».

El sistema las convirtió en nodos del grafo y las relacionó con los elementos visuales de la interfaz que justificaban esas afirmaciones.

Ese fue uno de los resultados más interesantes del análisis visual.

Era algo que jamás se me habría ocurrido hacer manualmente.

Después de la ejecución, Graphify también registró la habilidad /graphify.

Eso significa que, en cualquier sesión futura de Claude Code, puedo ejecutar una consulta como esta:

graphify query "why does the download button start disabled?"

Es decir: «¿Por qué el botón de descarga aparece deshabilitado inicialmente?».

Y obtener una respuesta directamente desde el grafo, sin necesidad de volver a leer todo el repositorio desde cero.

Así es como funciona, en la práctica, el concepto de conocimiento compilado.

Pagas una vez el costo de extraer la información y después puedes consultarla sin repetir ese procesamiento.

Las limitaciones que debes conocer

Graphify se encuentra en la versión 0.3.1 y evoluciona rápidamente.

Eso significa que todavía debes esperar algunas imperfecciones.

La calidad de la extracción semántica depende por completo del modelo de lenguaje que utilices.

En mi experiencia, Claude Vision interpreta bien los diagramas y las fotografías de pizarras.

Sin embargo, los resultados pueden variar con otros modelos.

Si tu proyecto depende mucho de la documentación visual, la precisión del grafo estará limitada por la capacidad del modelo de visión para interpretar correctamente esas imágenes.

La cifra de compresión de 71,5 veces también depende del conjunto de archivos analizado.

Si tu proyecto contiene diez archivos Python y un README claro, probablemente no necesitas un grafo de conocimiento.

Lo que necesitas es leer el README.

La herramienta destaca especialmente en repositorios medianos y grandes, donde la complejidad estructural supera lo que una persona desarrolladora, o incluso un modelo de lenguaje, puede mantener en su memoria de trabajo.

También aporta mucho valor cuando el proyecto combina código, documentación y artículos de investigación.

En esos casos, pueden existir conexiones entre diferentes áreas que resultan difíciles de descubrir leyendo los archivos de forma secuencial.

En la versión más reciente se incorporaron parches de seguridad para vulnerabilidades relacionadas con SSRF y la inyección de YAML en la visualización HTML.

El proyecto es joven, recibe mantenimiento activo y está siendo revisado por miembros de la comunidad.

Aun así, si vas a utilizarlo sobre repositorios que contienen información sensible, conviene que revises personalmente los posibles riesgos de seguridad.

No deberías asumir que ya cuenta con el nivel de protección de una herramienta ampliamente consolidada para entornos de producción.

Y existe una limitación todavía más importante.

Un grafo de conocimiento puede mostrarte qué elementos están conectados entre sí.

Pero no necesariamente puede explicarte por qué la persona responsable de la arquitectura tomó una determinada decisión, qué restricciones condicionaron el diseño o qué intentos fallidos llevaron a elegir la solución actual.

Esa información sigue estando en la experiencia y la memoria del equipo, en las conversaciones de las solicitudes de cambios (pull requests) y en los mensajes de los commits.

Graphify te proporciona el mapa estructural.

Pero el conocimiento acumulado por las personas de tu organización sigue siendo responsabilidad de tu equipo.

Por qué esto importa más allá de la propia herramienta

Lo que más me interesa es el cambio de enfoque que representa.

Karpathy describió una transición desde «tokens utilizados para generar código» hacia «tokens utilizados para compilar conocimiento».

Y Graphify es la primera herramienta convincente que lleva ese enfoque a la práctica dentro de bases de código.

El hecho de que apareciera apenas 48 horas después de la publicación original, que ya contara con 1.500 estrellas en GitHub y una versión para .NET, y que comenzara a instalarse como una habilidad en diferentes plataformas de programación con agentes, demuestra que existía una demanda esperando una solución.

Estamos pasando de una inteligencia artificial que lee tu código a una inteligencia artificial que comprende la estructura de tu proyecto.

Y son dos capacidades fundamentalmente distintas.

Leer es un proceso lineal.

El modelo analiza los archivos uno por uno e intenta conservar toda la información posible dentro de su ventana de contexto.

Comprender es un proceso estructural.

El modelo identifica qué módulos dependen de otros, dónde están los nodos centrales, qué componentes forman comunidades relacionadas y cuáles son las conexiones inesperadas entre diferentes áreas del proyecto.

Todavía no sabemos si Graphify terminará convirtiéndose en el estándar a largo plazo.

De hecho, sería sorprendente que este sector se mantuviera tan sencillo durante mucho tiempo.

Lo que sí parece claro es que el enfoque de convertir el código en representaciones persistentes y consultables del conocimiento tiene mucho futuro.

Porque la alternativa consiste en volver a cargar los archivos originales en el contexto durante cada sesión y confiar en que el modelo recuerde lo que aprendió anteriormente.

Y ese enfoque ya está mostrando sus límites.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Guía técnica para comprender y reconstruir los 23 componentes de la arquitectura de Claude Code, desde el ciclo básico de un agente hasta los sistemas multiagente, la gestión de contexto y la ejecución asíncrona.

A principios de 2026, Claude Code superó los 1.000 millones de dólares en ingresos anualizados en apenas seis meses desde su lanzamiento.

No consiguió ese resultado gracias a mejores prompts. Lo consiguió porque Anthropic construyó la infraestructura adecuada alrededor del modelo correcto: un ciclo de ejecución de agentes con transmisión en tiempo real, un sistema de herramientas gobernado por permisos y una capa de gestión del contexto que permite mantener al modelo enfocado durante sesiones de trabajo prolongadas.

Esta infraestructura, conocida como harness, puede reproducirse. Y eso es precisamente lo que vamos a construir en este artículo.

La arquitectura de Claude Code

Claude Code está construido sobre cinco componentes fundamentales que trabajan de manera coordinada:

Un ciclo principal de ejecución de un solo hilo: dirige al modelo a través de ciclos de percepción, razonamiento y ejecución de herramientas, incorporando los resultados al contexto hasta completar la tarea.

Un registro de herramientas con tipado definido: relaciona nombres de herramientas con sus funciones de ejecución, como Bash, Read, Write, Grep o Glob. Cada herramienta cuenta con un esquema de entrada estricto que limita lo que el modelo puede solicitar y lo que la infraestructura puede ejecutar.

Una capa de gestión del contexto: combina la carga de habilidades bajo demanda, la compresión del historial de conversación en tres niveles y la memoria persistente en disco para mantener un razonamiento coherente durante sesiones que superan la ventana de contexto del modelo.

Un sistema de permisos basado en reglas: utiliza tres niveles de evaluación —denegar siempre, permitir siempre y solicitar aprobación del usuario— respaldados por un bus de eventos que permite observar e interceptar las llamadas a herramientas.

Una capa de coordinación multiagente: admite aislamiento del contexto de subagentes, delegación asíncrona, protocolos de comunicación controlados mediante máquinas de estados finitos y aislamiento mediante Git Worktrees para ejecutar tareas en paralelo sin conflictos entre archivos.

Y dentro de estos cinco componentes existen numerosos mecanismos adicionales que explican el funcionamiento de Claude Code.

En este artículo vamos a construir y probar cada componente individualmente para comprender cómo funcionan juntos y qué ventajas ofrecen frente a otras arquitecturas de agentes de IA.

El código del proyecto está disponible en GitHub:

Claude Code From Scratch: 23 componentes de la arquitectura de Claude Code

Estructura del proyecto

El repositorio está organizado de manera que cada componente puede ejecutarse y probarse por separado.

claude-code-from-scratch/
│
├── core.py
├── 01_perception_action_loop.py
├── s02_tool_use.py
├── s03_todo_write.py
├── s04_subagent.py
...
├── s10_team_protocols.py
├── s11_autonomous_agents.py
├── s12_worktree_task_isolation.py
│
├── s13_streaming.py
...
├── s21_mcp_runtime.py
│
├── s22_production_mailbox.py
├── s23_worktree_advanced.py
...
└── skills/

El archivo core.py contiene los fundamentos compartidos, como el cliente del modelo, las herramientas, el sistema de ejecución y los permisos.

Los demás archivos implementan mecanismos específicos. Esta separación permite ejecutar y probar individualmente cada componente sin duplicar innecesariamente la lógica principal.

¿Qué es Harness Engineering?

Harness Engineering es la disciplina que consiste en construir el entorno que rodea a un modelo de inteligencia artificial, en lugar de modificar el modelo en sí.

El modelo razona y toma decisiones. El harness ejecuta esas decisiones, establece restricciones y conecta el modelo con las herramientas y los sistemas externos.

Una infraestructura bien diseñada proporciona al modelo exactamente las herramientas que necesita, sin añadir capacidades innecesarias, y controla las acciones que puede realizar.

Este enfoque puede resumirse en cuatro principios fundamentales.

1. El modelo es la única fuente de decisiones. La infraestructura no introduce una lógica propia para interpretar y decidir qué hacer a partir de las respuestas del modelo. Su responsabilidad consiste en ejecutar las acciones solicitadas.

2. Las herramientas son la interfaz entre el modelo y el mundo exterior. Todas las operaciones, desde leer un archivo hasta iniciar un subagente, se realizan mediante llamadas a herramientas con esquemas definidos y entradas validadas.

3. El contexto es un recurso administrado. La información que recibe el modelo en cada interacción se selecciona, comprime e incorpora deliberadamente. No se acumula todo el historial sin control.

4. Los permisos son declarativos, no procedimentales. Las acciones permitidas, bloqueadas o sujetas a autorización se definen mediante configuraciones, en lugar de distribuir esas reglas entre múltiples condiciones dentro del código.

¿Cómo utiliza Claude Code el Harness Engineering?

Claude Code no es simplemente un framework para agentes. Es una infraestructura de ejecución diseñada para que un modelo pueda trabajar con herramientas de manera controlada.

Anthropic no construyó una lógica específica para decidir cuándo leer archivos o ejecutar pruebas. Proporcionó a Claude las herramientas necesarias para realizar esas operaciones y dejó que el modelo decidiera cuándo utilizarlas.

Su arquitectura aplica los principios de Harness Engineering de varias maneras.

El ciclo principal de ejecución es genérico y no conserva un estado propio específico de cada tarea. Funciona de la misma manera cuando el usuario solicita corregir un error de una línea o realizar una refactorización compleja, porque la inteligencia específica de cada tarea reside en el modelo.

El registro de herramientas funciona como punto de extensión. Añadir una capacidad significa registrar una nueva herramienta con su nombre, descripción y esquema de entrada.

El contexto se administra activamente. Según la arquitectura descrita, cuando el uso de la ventana se aproxima al 92 %, las interacciones anteriores pueden resumirse y almacenarse en disco para mantener la memoria de trabajo enfocada.

Por último, el sistema de permisos funciona como una capa previa a la ejecución: las herramientas deben pasar por una evaluación de reglas antes de ejecutarse.

Esto permite que la seguridad no dependa exclusivamente de cómo se comporte el modelo, sino también de la arquitectura que controla sus acciones.

Fase 1. El ciclo principal del agente

El ciclo de ejecución es el elemento arquitectónico fundamental sobre el que se construye todo lo demás.

Antes de las herramientas, los permisos o la coordinación multiagente, existe un ciclo que llama al modelo, identifica lo que quiere hacer, ejecuta la acción correspondiente y devuelve el resultado.

Cada componente de esta fase incorpora un mecanismo adicional sin modificar ese principio básico.

1. El ciclo mínimo con while

El principio más importante de cualquier sistema de agentes es el ciclo de percepción, acción y observación.

El agente recibe una tarea e intenta resolverla utilizando una herramienta. Después observa el resultado y decide si debe continuar o detenerse.

Estas decisiones están dirigidas por el modelo, no por el código externo.

No estamos hablando de un mecanismo convencional de reintentos ni de una estrategia de respaldo. Este ciclo constituye el núcleo operativo del sistema.

El mismo mecanismo puede utilizarse para corregir un pequeño error de programación o modificar una base de código completa.

Inicializar el cliente de Anthropic

Para construir nuestra implementación inicial, primero debemos configurar el cliente y el modelo.

from anthropic import Anthropic# Clave de API necesaria# Obtenla en: https://console.anthropic.com/ANTHROPIC_API_KEY = "sk-ant-xxx"# Identificador del modeloMODEL_ID = "claude-sonnet-4-6"# Inicializar el clienteclient = Anthropic(    base_url="https://api.anthropic.com",    api_key=ANTHROPIC_API_KEY)MODEL = MODEL_ID

En este ejemplo utilizaremos un modelo de Anthropic porque estamos reconstruyendo la arquitectura de Claude Code.

Sin embargo, también es posible utilizar LiteLLM para conectar modelos de diferentes proveedores. El repositorio está planteado de manera flexible para permitir esa sustitución.

Definir el prompt de sistema

El prompt de sistema establece el comportamiento general del agente.

DEFAULT_SYSTEM = (    f"You are a coding agent at {os.getcwd()}. "    "Use tools to solve tasks. Act, don't explain.")

Aunque el prompt de sistema no siempre requiere una configuración compleja, resulta importante para establecer cómo debe abordar las tareas el modelo.

Definir las herramientas iniciales

Claude Code se construye alrededor de herramientas. Por eso necesitamos ofrecer al agente una forma de interactuar con su entorno.

BASIC_TOOLS = [    {        "name": "bash",        "description": "Run a shell command.",        "input_schema": {            "type": "object",            "properties": {                "command": {"type": "string"}            },            "required": ["command"]        }    }]

Aquí definimos una herramienta llamada bash que permite ejecutar comandos de terminal.

La herramienta incluye un nombre, una descripción y un esquema que especifica el formato esperado de los parámetros.

Crear el registro de ejecución

BASIC_DISPATCH: dict = {    "bash": lambda inp: run_bash(inp["command"])}

El mecanismo de despacho conecta las llamadas del modelo con funciones reales.

En lugar de incorporar la lógica de cada herramienta al ciclo principal, utilizamos un diccionario que relaciona nombres con sus correspondientes funciones.

Esta separación facilita incorporar nuevas herramientas sin modificar el funcionamiento del agente.

Ejecutar las llamadas a herramientas

def dispatch_tools(    response_content: list,    dispatch: dict) -> List[Dict[str, Any]]:    results = []    for block in response_content:        if block.type != "tool_use":            continue        tool_name = block.name        tool_input = block.input        tool_use_id = block.id        handler = dispatch.get(tool_name)        first_val = (            str(list(tool_input.values())[0])[:80]            if tool_input else ""        )        print(            f"\033[33m[{tool_name}] "            f"{first_val}...\033[0m"        )        if handler:            try:                output = handler(tool_input)            except Exception as e:                output = (                    f"Error during tool execution: {e}"                )        else:            output = (                f"Error: Unknown tool '{tool_name}'"            )        print(str(output)[:300])        results.append({            "type": "tool_result",            "tool_use_id": tool_use_id,            "content": str(output),        })    return results

La función dispatch_tools recibe la respuesta del modelo, identifica las llamadas a herramientas, las ejecuta y recopila los resultados.

También registra las operaciones para mostrar qué herramientas está utilizando el agente y cuáles son sus resultados.

Construir el ciclo principal

def agent_loop(    messages: List[Dict[str, Any]],    dispatch: Dict) -> None:    while True:        print("\n\033[36m> Thinking...\033[0m")        response = client.messages.create(            model=MODEL,            system=DEFAULT_SYSTEM,            messages=messages,            tools=BASIC_TOOLS,            max_tokens=8000,        )        messages.append({            "role": "assistant",            "content": response.content        })        if response.stop_reason != "tool_use":            break        results = dispatch_tools(            response.content,            dispatch        )        messages.append({            "role": "user",            "content": results        })

Nuestro agente utiliza un ciclo while que continúa ejecutándose hasta que el modelo genera una respuesta final.

El funcionamiento es sencillo: se envía el historial al modelo, se recibe su respuesta, se comprueba si solicita herramientas y, en ese caso, se ejecutan para devolver los resultados al contexto.

El proceso se repite hasta que el modelo considera que ha terminado.

Probar el agente

Para comprobar su funcionamiento, creamos un historial de conversación y aceptamos instrucciones desde la terminal.

history: List[Dict[str, Any]] = []while True:    try:        query = input("\033[36ms01 >> \033[0m")    except (EOFError, KeyboardInterrupt):        print("\nExiting.")        break    if query.strip().lower() in ("q", "exit", ""):        break    history.append({        "role": "user",        "content": query    })    agent_loop(history, BASIC_DISPATCH)    last_message = history[-1]    print("\n\033[32mFinal Answer:\033[0m")    for block in last_message.get("content", []):        if block.type == "text":            print(block.text)    print()

Probemos con la siguiente instrucción:

s01 >> Enumera todos los archivos Python
       del directorio actual.

El agente intenta ejecutar:

ls *.py

El sistema devuelve un error porque no encuentra el comando.

A continuación, el modelo cambia de estrategia y utiliza:

find . -name "*.py" -type f

Esta vez obtiene los resultados:

./main.py
./utils.py
./agent.py

El ejemplo demuestra el ciclo de percepción, acción y observación.

El agente intentó ejecutar una operación, recibió un error y corrigió su procedimiento sin necesidad de incorporar instrucciones específicas para ese fallo.

2. El patrón de despacho de herramientas

Uno de los componentes más interesantes de la arquitectura de Claude Code es su registro de herramientas.

El artículo original describe una implementación con 18 herramientas registradas, entre ellas Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion y TodoWrite.

Lo importante no es la cantidad de herramientas, sino que agregar una nueva no requiere modificar el ciclo principal.

El registro funciona como un diccionario que relaciona lo que el modelo quiere hacer con la función que realiza esa operación.

EXTENDED_DISPATCH: dict = {    "bash": lambda inp: run_bash(        inp["command"]    ),    "read": lambda inp: run_read(        inp["path"],        inp.get("start_line"),        inp.get("end_line")    ),    "write": lambda inp: run_write(        inp["path"],        inp["content"]    ),    "grep": lambda inp: run_grep(        inp["pattern"],        inp.get("path", ".")    ),    "glob": lambda inp: run_glob(        inp["pattern"]    ),    "revert": lambda inp: run_revert(        inp["path"]    ),}

Cada clave corresponde al nombre exacto que utilizará el modelo.

Cada valor es la función Python encargada de ejecutar la operación.

Cuando Claude necesita leer un archivo, el sistema realiza una búsqueda en el diccionario y ejecuta el controlador correspondiente.

No necesitamos una jerarquía compleja de clases ni múltiples condiciones para elegir las herramientas.

La operación fundamental puede reducirse a:

output = handler(tool_input)

La importancia de las descripciones

Las definiciones de herramientas son tan importantes como sus implementaciones.

El modelo utiliza la descripción para determinar qué herramienta debe llamar.

EXTENDED_TOOLS = BASIC_TOOLS + [    {        "name": "read",        "description": (            "Read a file and return numbered lines. "            "Use when you need to inspect file content "            "or reference specific line numbers. "            "Returns up to 50,000 characters. "            "Use start_line/end_line for large files."        ),        "input_schema": {            "type": "object",            "properties": {                "path": {"type": "string"},                "start_line": {"type": "integer"},                "end_line": {"type": "integer"}            },            "required": ["path"]        }    },    {        "name": "write",        "description": (            "Write content to a file. "            "Automatically snapshots the previous "            "content so you can revert. "            "Creates parent directories if needed."        ),        "input_schema": {            "type": "object",            "properties": {                "path": {"type": "string"},                "content": {"type": "string"}            },            "required": ["path", "content"]        }    },    {        "name": "grep",        "description": (            "Search for a regex pattern across files. "            "Returns file paths and line numbers of matches."        ),        "input_schema": {            "type": "object",            "properties": {                "pattern": {"type": "string"},                "path": {"type": "string"},                "recursive": {"type": "boolean"}            },            "required": ["pattern"]        }    },    {        "name": "glob",        "description": (            "Find files matching a glob pattern, "            "e.g. '**/*.py'. Returns sorted list "            "of matching paths."        ),        "input_schema": {            "type": "object",            "properties": {                "pattern": {"type": "string"}            },            "required": ["pattern"]        }    },    {        "name": "revert",        "description": (            "Restore a file to its state "            "before the last write call."        ),        "input_schema": {            "type": "object",            "properties": {                "path": {"type": "string"}            },            "required": ["path"]        }    }]

Una descripción mal redactada puede hacer que el modelo seleccione la herramienta incorrecta.

Por ejemplo, si grep se describe simplemente como una herramienta para buscar archivos y bash como una herramienta para ejecutar comandos, el modelo puede utilizar Bash para todas las búsquedas.

Las descripciones específicas permiten que el modelo relacione con mayor precisión la intención del usuario con las capacidades disponibles.

Controlar errores en los ejecutores

Las funciones que ejecutan herramientas deben mantener un contrato consistente: reciben parámetros, devuelven resultados y gestionan los errores sin interrumpir el ciclo principal.

def run_read(    path: str,    start_line: int = None,    end_line: int = None) -> str:    try:        with open(            path,            "r",            encoding="utf-8",            errors="replace"        ) as f:            lines = f.readlines()        s = (start_line or 1) - 1        e = end_line or len(lines)        numbered = "".join(            f"{s+1+i:4d}\t{l}"            for i, l in enumerate(lines[s:e])        )        return numbered[:50000] or "(empty file)"    except FileNotFoundError:        return f"Error: file not found: {path}"    except Exception as e:        return f"Error reading {path}: {e}"

La función devuelve líneas numeradas deliberadamente.

Esto permite al modelo identificar secciones concretas de un archivo y realizar modificaciones precisas.

Por ejemplo, puede utilizar las referencias de una lectura anterior para identificar qué líneas necesita reemplazar.

También podemos definir una función de búsqueda:

def run_grep(    pattern: str,    path: str = ".",    recursive: bool = True) -> str:    try:        flags = ["-r"] if recursive else []        r = subprocess.run(            ["grep", "-n", *flags, pattern, path],            capture_output=True,            text=True,            timeout=30        )        return (            (r.stdout + r.stderr).strip()            or "(no matches)"        )[:10000]    except Exception as e:        return f"Error: {e}"

Prueba del sistema de herramientas

Solicitamos al agente:

Encuentra todos los comentarios TODO del proyecto
e indica en qué archivos aparecen.

El modelo utiliza grep:

[grep] TODO

./agents/s03_todo_write.py:45:
# TODO: add priority levels to tasks

./agents/s09_agent_teams.py:112:
# TODO: replace JSONL mailboxes with Redis

El resultado identifica dos comentarios TODO en dos archivos diferentes.

El modelo eligió grep en lugar de bash porque la descripción de la herramienta permitía comprender claramente su función.

Esta es la finalidad del registro de ejecución: la decisión sobre qué herramienta utilizar pertenece al modelo, mientras que el harness proporciona capacidades bien definidas y se encarga de ejecutarlas.

3. Planificación con TodoWrite antes de ejecutar tareas

Uno de los comportamientos más interesantes que muestran los registros de ejecución de Claude Code es lo que ocurre antes de que el modelo empiece a trabajar en una tarea compleja.

En lugar de comenzar inmediatamente a modificar archivos, puede utilizar TodoWrite para establecer un plan de trabajo.

Primero se define el plan y después se ejecutan sus pasos.

Este comportamiento responde a un problema habitual de los agentes de IA: cuando trabajan en tareas de varios pasos sin una planificación explícita, pueden desviarse del objetivo original.

El agente empieza ejecutando una operación, encuentra un resultado intermedio interesante, decide investigarlo y termina trabajando en algo relacionado, pero diferente de lo que solicitó el usuario.

TodoWrite proporciona un mecanismo de seguimiento que permite mantener el objetivo visible durante toda la ejecución.

En la arquitectura descrita, el estado actual del plan se incorpora nuevamente al contexto después de las llamadas a herramientas. De esta manera, el modelo dispone de una referencia continua sobre las tareas pendientes y las completadas.

Implementación de TodoWrite

TODO_FILE = Path(".agent_todo.json")def todo_write(tasks: list) -> str:    data = [        {            "id": i,            "task": t,            "status": "pending"        }        for i, t in enumerate(tasks)    ]    TODO_FILE.write_text(        json.dumps(data, indent=2)    )    return "Plan written:\n" + "\n".join(        f"  [{i}] {t}"        for i, t in enumerate(tasks)    )def todo_read() -> str:    if not TODO_FILE.exists():        return "(no plan)"    data = json.loads(TODO_FILE.read_text())    return "\n".join(        f"  [{t['id']}] "        f"[{t['status']:12s}] {t['task']}"        for t in data    )def todo_update(index: int, status: str) -> str:

Estas tres herramientas funcionan conjuntamente:

todo_write registra el plan completo al inicio.

todo_update modifica el estado de cada tarea a medida que avanza el agente.

todo_read permite consultar el progreso en cualquier momento.

Juntas crean una memoria de trabajo externa que mantiene un registro del proceso de ejecución.

Cada paso tiene un estado persistente, por lo que el sistema puede comprobar qué actividades siguen pendientes.

Hacer obligatoria la planificación

Actualizamos el prompt de sistema para indicar al modelo que debe planificar antes de trabajar en tareas complejas.

SYSTEM = (    f"You are a coding agent at {os.getcwd()}. "    "Before working on any multi-step task, "    "ALWAYS call todo_write first "    "to write your complete plan. "    "Execute each step in order. "    "Call todo_update after completing each step.")

La palabra ALWAYS es importante en este ejemplo.

Sin una instrucción firme, el modelo puede decidir planificar en determinadas ocasiones y omitir ese paso en otras.

Con una instrucción explícita, el comportamiento tiende a ser más consistente.

Ejemplo de ejecución

Solicitamos:

Refactoriza la función run_bash para incorporar
un tiempo de espera configurable y un límite
en la longitud de la salida.

Después, comprueba que no se haya roto nada.

El agente comienza registrando cinco tareas:

[todo_write]

[0] Leer la implementación actual de run_bash
[1] Agregar un timeout configurable de 120 segundos
[2] Limitar la salida a 50.000 caracteres
[3] Guardar la implementación actualizada
[4] Ejecutar las pruebas

Después ejecuta los pasos previstos.

[read] core.py (lines 45-72)
[todo_update] 0 → done

[write] core.py
[todo_update] 1 → done
[todo_update] 2 → done
[todo_update] 3 → done

[bash] python -m pytest tests/test_agents_smoke.py -q

44 passed in 2.1s

[todo_update] 4 → done

El resultado final confirma que la refactorización terminó correctamente, se añadió el tiempo de espera configurable y la limitación de salida, y las 44 pruebas se completaron sin errores.

El modelo definió cinco pasos antes de modificar un solo archivo, los ejecutó y verificó los resultados.

La clave no es que el modelo sea naturalmente más cuidadoso, sino que la infraestructura le proporciona una estructura para trabajar de manera organizada.

4. Aislamiento del contexto mediante subagentes

Los registros de ejecución de Claude Code muestran otro comportamiento interesante cuando el sistema necesita explorar grandes bases de código.

En lugar de incorporar todos los archivos directamente a la conversación principal, el agente puede delegar la exploración en varios subagentes.

Cada subagente trabaja con su propio contexto y devuelve un resumen de los resultados.

La conversación principal no necesita recibir todas las lecturas de archivos, búsquedas y operaciones intermedias realizadas para obtener esas conclusiones.

Este patrón se conoce como aislamiento del contexto de subagentes.

Permite trabajar con repositorios grandes sin llenar la ventana de contexto principal con información secundaria.

La implementación consiste en proporcionar a cada subagente una lista messages[] completamente independiente.

El único estado que se comparte entre el agente principal y el subagente es el resultado final que devuelve este último.

Definir el comportamiento del subagente

SUBAGENT_SYSTEM = (    f"You are a subagent working on "    f"a specific subtask at {os.getcwd()}. "    "Complete your task thoroughly "    "and summarise your findings clearly. "    "Your output will be the only thing "    "the parent agent sees.")

Crear un subagente

def spawn_subagent(prompt: str) -> str:    """Run a fresh agent loop with isolated context."""    print(        f"\033[35m  [subagent spawned] "        f"{prompt[:60]}\033[0m"    )    sub_messages = [        {            "role": "user",            "content": prompt        }    ]    while True:        resp = client.messages.create(            model=MODEL,            system=SUBAGENT_SYSTEM,            messages=sub_messages,            tools=EXTENDED_TOOLS,            max_tokens=8000,        )        sub_messages.append({            "role": "assistant",            "content": resp.content        })        if resp.stop_reason != "tool_use":            break        results = dispatch_tools(            resp.content,            EXTENDED_DISPATCH        )

El subagente ejecuta el mismo ciclo básico que el agente principal.

También dispone de las mismas herramientas.

La diferencia es que su historial comienza desde cero y su prompt de sistema se concentra en una tarea específica.

Cuando termina, los resultados intermedios se descartan y únicamente se devuelve el resumen final.

Registrar la herramienta

Para permitir que el modelo decida cuándo crear un subagente, debemos registrarlo como una herramienta.

SUBAGENT_TOOLS = EXTENDED_TOOLS + [    {        "name": "spawn_subagent",        "description": (            "Spawn an isolated subagent "            "to handle a subtask in a fresh context. "            "Use for exploration tasks, risky operations, "            "or any work that would generate large "            "amounts of intermediate output "            "that the main conversation does not need. "            "Returns only the subagent's final summary."        ),        "input_schema": {            "type": "object",            "properties": {                "prompt": {                    "type": "string"                }            },            "required": ["prompt"]        }    }]

Actualizamos el registro de ejecución:

SUBAGENT_DISPATCH = {    **EXTENDED_DISPATCH,    "spawn_subagent": lambda inp: spawn_subagent(        inp["prompt"]    ),}

Prueba con un repositorio completo

Solicitamos:

Analiza toda la base de código y proporciona
un resumen completo de su arquitectura.

El agente principal crea un subagente para explorar los archivos Python.

El subagente encuentra 25 archivos y comienza a analizarlos.

[subagent] [glob] agents/**/*.py
           → 25 files found

[subagent] [read] agents/core.py
[subagent] [read] agents/s01_agent_loop.py
[subagent] [read] agents/s02_tool_use.py

... 22 lecturas adicionales

Después devuelve una conclusión:

core.py exporta el cliente, las herramientas
y los registros de ejecución.

Cada archivo de sesión importa la base
compartida y añade un mecanismo específico.

La conversación principal registra una sola llamada a herramienta, aunque el subagente realizó 25 operaciones.

Sin aislamiento, el contexto principal habría acumulado el contenido de todos esos archivos.

La ventaja es que el agente principal puede seguir razonando sobre la arquitectura general, en lugar de dedicar parte de su contexto a información de bajo nivel.

Fase 2. Gestión del conocimiento y del contexto

En esta fase incorporamos la infraestructura que permite al agente ir más allá de una única sesión.

El objetivo es cargar conocimientos especializados únicamente cuando se necesitan, comprimir el historial antes de que afecte a la calidad del razonamiento y conservar información persistente en disco.

Estos mecanismos permiten que el agente retome tareas después de reinicios y mantenga un contexto de trabajo útil durante sesiones prolongadas.

5. Carga de habilidades bajo demanda

Uno de los errores más costosos en Harness Engineering es introducir en el prompt de sistema toda la información que el modelo podría necesitar.

Imaginemos un prompt que contiene instrucciones sobre procesamiento de PDF, revisión de código, despliegues y auditorías de seguridad.

Ese prompt podría consumir miles de tokens en cada llamada a la API, aunque la mayor parte del contenido no tenga relación con la tarea actual.

Claude Code aborda este problema mediante un patrón conocido como divulgación progresiva, o progressive disclosure.

El prompt de sistema contiene únicamente descripciones breves de las habilidades disponibles.

Cuando el modelo identifica que necesita una habilidad especializada, llama a una función como load_skill() para incorporar las instrucciones completas al contexto.

De esta forma, el coste de contexto se produce únicamente cuando el conocimiento resulta relevante.

Es posible tener cientos de habilidades instaladas sin cargar todas sus instrucciones en cada interacción.

Estructura de las habilidades

skills/
├── agent-builder/
│   └── SKILL.md
├── code-review/
│   └── SKILL.md
└── pdf/
    └── SKILL.md

Una habilidad incluye metadatos que permiten identificarla y un conjunto de instrucciones que indican cómo realizar una tarea.

Por ejemplo:

---
name: code-review
description: Use when asked to review code,
             audit a file for bugs,
             check quality, or suggest improvements.
---

# Code Review Skill

## Review process

1. Read the full file before commenting
2. Categorise issues: BUG / SECURITY / PERF / STYLE / SUGGEST
3. Cite file and line number for every finding
4. End with a deploy-readiness summary

El mecanismo de descubrimiento explora el directorio de habilidades al iniciar el sistema.

Lee los metadatos de cada archivo SKILL.md y construye un registro ligero que posteriormente se incorpora al prompt de sistema.

Descubrir las habilidades disponibles

SKILLS_DIR = Path(__file__).parent.parent / "skills"def discover_skills() -> dict[str, str]:    skills = {}    for skill_dir in sorted(SKILLS_DIR.iterdir()):        skill_md = skill_dir / "SKILL.md"        if skill_dir.is_dir() and skill_md.exists():            lines = skill_md.read_text(                encoding="utf-8"            ).splitlines()            desc = ""            in_frontmatter = False            for line in lines:                if line.strip() == "---":                    in_frontmatter = not in_frontmatter                    continue                if (                    not in_frontmatter                    and line.strip()                    and not line.startswith("#")                ):                    desc = line.strip()[:100]                    break            skills[skill_dir.name] = (                desc or "No description."            )    return skills

Cargar una habilidad

def load_skill(name: str) -> str:    skill_path = SKILLS_DIR / name / "SKILL.md"    if not skill_path.exists():        return (            f"Error: skill '{name}' not found. "            "Use list_skills to see available."        )    return (        f"=== SKILL: {name} ===\n"        f"{skill_path.read_text(encoding='utf-8')}"    )

El prompt de sistema referencia las habilidades sin cargar todo su contenido.

_skill_list = "\n".join(    f"  - {n}: {d}"    for n, d in discover_skills().items())SYSTEM = (    f"You are a coding agent at {os.getcwd()}.\n"    "When a task requires specialised knowledge, "    "call load_skill(name) to get full instructions "    "before starting. Do NOT guess.\n\n"    f"Available skills:\n{_skill_list}")

Prueba del sistema de habilidades

Solicitamos:

Revisa agents/core.py para identificar errores,
problemas de seguridad y calidad del código.

El agente comienza cargando la habilidad correspondiente.

[load_skill] code-review

Después lee el archivo y realiza búsquedas concretas.

[read] agents/core.py

[grep] def run_bash
[grep] subprocess.run

El análisis identifica tres problemas.

Seguridad: la utilización de shell=True con entradas no validadas puede permitir la inyección de comandos.

Rendimiento: la función run_grep crea un proceso nuevo para cada búsqueda, sin aprovechar resultados anteriores.

Estilo: run_read puede devolver una cadena vacía para determinados archivos, en lugar de ofrecer una respuesta descriptiva.

El resultado concluye que existe un problema de seguridad que debe resolverse antes del despliegue.

La habilidad no aumenta por sí sola la capacidad del modelo. Su función es proporcionar un procedimiento consistente para revisar código y presentar resultados con una estructura definida.

6. Compresión del contexto en tres niveles

Todas las sesiones prolongadas encuentran el mismo problema: la ventana de contexto termina llenándose.

Las salidas de herramientas, resultados intermedios e interacciones anteriores ocupan espacio que podría utilizarse para información relevante de la tarea actual.

El artículo describe un mecanismo de compresión de Claude Code que se activa automáticamente cuando se alcanza aproximadamente el 92 % de utilización de la ventana de contexto.

En lugar de descartar completamente el historial, el sistema lo resume para conservar la información importante mientras reduce el consumo de tokens.

El resumen también puede escribirse en un archivo Markdown persistente.

Funcionamiento de la compresión

La implementación utiliza tres niveles.

Primero conserva literalmente los mensajes recientes porque contienen el contexto activo.

Después comprime las interacciones anteriores en un resumen generado mediante una llamada al modelo.

Finalmente guarda ese resumen en .agent_memory.md, permitiendo que una nueva sesión recupere información importante.

Configuración inicial

COMPRESS_THRESHOLD = 40_000KEEP_RECENT = 6MEMORY_FILE = Path(".agent_memory.md")

En este ejemplo, el umbral se expresa en caracteres y equivale aproximadamente a 10.000 tokens estimados.

Se conservan los últimos seis mensajes sin modificaciones.

Estimar el tamaño del contexto

def _estimate_size(messages: list) -> int:    total = 0    for msg in messages:        content = msg.get("content", "")        if isinstance(content, str):            total += len(content)        elif isinstance(content, list):            for block in content:                if isinstance(block, dict):                    total += len(                        str(                            block.get("text", "")                            or block.get("content", "")                        )                    )                elif hasattr(block, "text"):                    total += len(block.text or "")    return total

Generar un resumen

def _summarize(messages: list) -> str:    text = "\n\n".join(        f"[{m['role']}]: " + (            m["content"]            if isinstance(m["content"], str)            else " ".join(                b.get("text", "")                if isinstance(b, dict)                else getattr(b, "text", "")                for b in (                    m["content"]                    if isinstance(m["content"], list)                    else []                )            )        )        for m in messages    )    resp = client.messages.create(        model=MODEL,        system=(            "Summarise this conversation. "            "Keep all important decisions, "            "code changes, file paths, and context. "            "Be concise but complete."        ),        messages=[            {                "role": "user",                "content": f"Summarise:\n\n{text[:20000]}"            }        ],        max_tokens=2000,    )

La función de resumen mantiene las decisiones importantes, las modificaciones de código, las rutas de archivos y el contexto necesario para continuar.

Activar la compresión cuando sea necesaria

def maybe_compress(messages: list) -> bool:    if _estimate_size(messages) < COMPRESS_THRESHOLD:        return False    if len(messages) <= KEEP_RECENT:        return False    old_messages = messages[:-KEEP_RECENT]    recent = messages[-KEEP_RECENT:]    print(        "[compress] context large - "        "summarising older messages..."    )    summary = _summarize(old_messages)    MEMORY_FILE.write_text(        f"# Agent Memory\n"        f"Generated: {datetime.now().isoformat()}\n\n"        f"{summary}\n"    )    messages.clear()    messages.append({        "role": "user",        "content": (            "[Context summary from previous conversation]"            f"\n\n{summary}"        )    })    messages.append({        "role": "assistant",        "content": (            "Understood. I have the full context "            "from our previous work."        )    })    messages.extend(recent)    return True

La compresión no se activa por tiempo transcurrido, sino por el tamaño estimado del contexto.

Recuperar memoria al iniciar una sesión

history = []if MEMORY_FILE.exists():    mem = MEMORY_FILE.read_text()    print(        f"[memory] loaded from {MEMORY_FILE}"    )    history = [        {            "role": "user",            "content": f"[Loaded memory]\n\n{mem}"        },        {            "role": "assistant",            "content": "Memory loaded. Ready to continue."        }    ]

Resultado de la prueba

El agente recibe una tarea para agregar gestión de errores a las funciones de core.py y crear pruebas.

Durante la ejecución lee archivos, escribe nuevas implementaciones y ejecuta pruebas.

Después de acumular suficiente historial, se activa la compresión.

[compress] context large -
summarising older messages...

[compress] 18 messages → 1 summary

saved to .agent_memory.md

Los 18 mensajes anteriores se convierten en un único bloque de contexto.

Cuando comienza otra sesión, ese resumen se recupera desde el archivo persistente.

El agente puede continuar trabajando sin necesitar que todas las interacciones anteriores se vuelvan a introducir en cada llamada a la API.

7. Grafo persistente de dependencias entre tareas

La compresión del contexto y el seguimiento de tareas resuelven problemas diferentes.

La compresión determina qué información conserva el modelo.

El grafo de tareas determina qué trabajos debe realizar el agente, cuáles ha completado y qué dependencias existen entre ellos.

A diferencia de un plan limitado a una sesión, el grafo permite mantener el estado del proyecto después de cerrar procesos, reiniciar sesiones o incluso reiniciar el equipo.

Cada tarea dispone de un identificador, una descripción, un estado, una prioridad y una lista de tareas que deben completarse previamente.

El grafo se almacena en .agent_tasks.json.

Configurar el almacenamiento

TASKS_FILE = Path(".agent_tasks.json")_TASKS_LOCK = threading.Lock()def _load() -> list:    if TASKS_FILE.exists():        return json.loads(TASKS_FILE.read_text())    return []def _save(tasks: list):    TASKS_FILE.write_text(        json.dumps(tasks, indent=2)    )

Crear tareas con dependencias

def run_task_create(    description: str,    depends_on: list = None,    priority: str = "medium") -> str:    with _TASKS_LOCK:        tasks = _load()        task = {            "id": uuid.uuid4().hex[:8],            "description": description,            "status": "pending",            "priority": priority,            "depends_on": depends_on or [],            "result": "",        }        tasks.append(task)        _save(tasks)    return (        f"created task {task['id']}: "        f"{description}"    )

Seleccionar la siguiente tarea disponible

def run_task_next() -> str:    tasks = _load()    done_ids = {        t["id"]        for t in tasks        if t["status"] == "done"    }    priorities = {        "high": 0,        "medium": 1,        "low": 2    }    for t in sorted(        tasks,        key=lambda x: priorities[x["priority"]]    ):        if t["status"] != "pending":            continue        if all(            dep in done_ids            for dep in t.get("depends_on", [])        ):            return (                f"[{t['id']}] "                f"[{t['priority']}] "                f"{t['description']}"            )    return "(no unblocked tasks available)"

Actualizar el estado de una tarea

def run_task_update(    task_id: str,    status: str,    result: str = "") -> str:    with _TASKS_LOCK:        tasks = _load()        for t in tasks:            if t["id"].startswith(task_id):                t["status"] = status                if result:                    t["result"] = result                _save(tasks)                return (                    f"task {t['id']} → {status}"                )    return f"Error: task '{task_id}' not found"

El bloqueo mediante threading.Lock() es importante porque varios agentes podrían intentar modificar el grafo simultáneamente.

Sin un mecanismo de sincronización, dos agentes podrían leer el mismo estado, modificarlo de manera independiente y sobrescribir accidentalmente los cambios del otro.

El bloqueo protege las operaciones concurrentes de lectura y escritura dentro del mismo proceso.

Ejemplo: migrar las herramientas a ejecución asíncrona

Solicitamos al agente:

Necesitamos migrar toda la base de código
para utilizar implementaciones asíncronas.

Divide el trabajo en tareas, identifica
las dependencias y comienza la ejecución.

El agente crea el siguiente conjunto de tareas:

Auditar todas las funciones síncronas de core.py.

Crear versiones asíncronas de run_bash, run_read y run_write.

Crear versiones asíncronas de run_grep y run_glob.

Actualizar el registro ASYNC_DISPATCH.

Modificar s18_parallel_tools.py.

Ejecutar todas las pruebas.

Las tareas de implementación dependen de la auditoría inicial.

La actualización del registro depende de que las implementaciones asíncronas estén disponibles.

Las pruebas finales dependen de que las modificaciones anteriores hayan terminado.

El agente ejecuta los trabajos respetando este orden.

[task_next]
[a3f2c891] Audit sync functions

[task_update] a3f2c891 → done

[task_next]
[b7d1e445] Write async bash/read/write

[task_update] b7d1e445 → done

[task_next]
[c9f3a112] Write async grep/glob

[task_update] c9f3a112 → done

[task_next]
[d2e8b334] Update ASYNC_DISPATCH

[task_update] d2e8b334 → done

[bash] python -m pytest tests/ -q

44 passed in 2.3s

El resultado confirma que las seis tareas se completaron correctamente y las 44 pruebas finalizaron sin errores.

Si el proceso se hubiera detenido después de la tercera tarea, al reiniciarse podría recuperar el grafo y continuar desde el siguiente trabajo pendiente.

Esa persistencia es la principal diferencia entre un plan de una sola sesión y un sistema de gestión de proyectos basado en dependencias.

Fase 3. Ejecución asíncrona y equipos multiagente

La tercera fase aborda las limitaciones de un único agente y una sola ventana de contexto.

Cuando una tarea requiere ejecutar procesos lentos, analizar varios componentes o modificar múltiples archivos, un solo hilo de ejecución puede convertirse en un cuello de botella.

Esta fase incorpora ejecución en segundo plano, agentes especializados persistentes, protocolos de comunicación, asignación autónoma de tareas y aislamiento de archivos mediante Git Worktrees.

8. Ejecución de tareas en segundo plano con notificaciones

Cuando Claude ejecuta una batería de pruebas, compila un proyecto o realiza una migración de base de datos, no siempre necesita permanecer inactivo hasta recibir el resultado.

Puede iniciar una operación en segundo plano, continuar trabajando y recibir una notificación cuando termine.

Sin esta capacidad, un agente queda limitado por la duración de su llamada a herramienta más lenta.

Por ejemplo, si ejecutar las pruebas requiere 45 segundos, un sistema bloqueante debe esperar ese tiempo antes de realizar cualquier otra operación.

La ejecución en segundo plano permite separar el trabajo operativo del ciclo de razonamiento del agente.

Crear una cola de notificaciones

import threadingimport queueimport subprocess_BG_QUEUE: queue.Queue = queue.Queue()

Ejecutar comandos en segundo plano

def run_bash_background(    command: str,    label: str = "") -> str:    label = label or command[:40]    def _run():        print(f"[bg] started: {label}")        try:            r = subprocess.run(                command,                shell=True,                capture_output=True,                text=True,                timeout=300,                cwd=os.getcwd()            )            output = (                (r.stdout + r.stderr).strip()[:2000]                or "(no output)"            )            status = "completed"        except subprocess.TimeoutExpired:            output = (                "Error: operation timed out after 300s"            )            status = "timed out"        except Exception as e:            output = f"Error: {e}"            status = "failed"        _BG_QUEUE.put(            f"[Background task '{label}' "            f"{status}]\n{output}"        )        print(f"[bg] {label} {status}")    thread = threading.Thread(        target=_run,        daemon=True    )    thread.start()    return (        f"Background task started: '{label}'. "        "You will be notified when it completes."    )

La implementación utiliza un hilo por operación y una cola compartida para almacenar las notificaciones.

Cuando una tarea termina, introduce su resultado en la cola.

El ciclo principal puede consultar esa cola e incorporar los resultados al historial de conversación.

Procesar las notificaciones

def agent_loop_with_bg(messages: list):    stream_loop(        messages,        BG_TOOLS,        BG_DISPATCH,        system=SYSTEM    )    while not _BG_QUEUE.empty():        notification = _BG_QUEUE.get_nowait()        print("[bg] notification injected")        messages.append({            "role": "user",            "content": notification        })        stream_loop(            messages,            BG_TOOLS,            BG_DISPATCH,            system=SYSTEM        )

El agente dispone ahora de una herramienta denominada run_bash_background().

Puede utilizarla cuando necesita iniciar una operación prolongada sin bloquear el hilo principal.

Ejemplo de ejecución simultánea

Solicitamos:

Ejecuta todas las pruebas en segundo plano.

Mientras se ejecutan, añade docstrings
a las funciones de core.py que no tengan
documentación.

El agente inicia las pruebas:

[bash_background]
python -m pytest tests/ -v --tb=short

Background task started: 'full test suite'

Mientras se ejecutan, lee el archivo, identifica las funciones sin documentación y añade los docstrings correspondientes.

Posteriormente recibe la notificación:

[bg] full test suite completed

44 passed in 2.1s

El resultado indica que se documentaron ocho funciones y que todas las pruebas se completaron correctamente.

La ejecución concurrente permite que el tiempo total se aproxime a la duración de la operación más lenta, en lugar de sumar obligatoriamente los tiempos de ambas.

9. Agentes persistentes con buzones JSONL

Los subagentes convencionales suelen crearse para realizar una tarea específica y desaparecer cuando terminan.

Sin embargo, los proyectos de ingeniería también se benefician de contar con especialistas que mantengan su contexto durante varias tareas.

Por ejemplo, podemos utilizar un agente especializado en explorar bases de código y otro dedicado a escribir y modificar archivos.

Los agentes persistentes conservan información sobre el proyecto durante las diferentes actividades que reciben.

Arquitectura de comunicación

Cada integrante del equipo ejecuta su propio ciclo de agente en un hilo de segundo plano.

Dispone de una especialización y de un archivo JSONL que funciona como bandeja de entrada.

El agente principal envía tareas escribiendo mensajes en el buzón del especialista.

El especialista lee el mensaje, ejecuta el trabajo y devuelve el resultado mediante el buzón del agente principal.

Esta comunicación es asíncrona: el agente principal puede continuar trabajando mientras sus colaboradores ejecutan otras tareas.

Configurar los buzones

MAILBOX_DIR = Path(".mailboxes")MAILBOX_DIR.mkdir(exist_ok=True)TEAMMATES = {    "explorer": (        f"You are an explorer agent specialising "        f"in reading and understanding codebases "        f"at {os.getcwd()}. "        "You excel at mapping architecture, "        "finding patterns, and understanding "        "how components connect. "        "Use read, glob, grep."    ),    "writer": (        f"You are a writer agent specialising "        f"in creating and editing code "        f"at {os.getcwd()}. "        "You excel at implementing changes cleanly, "        "following existing patterns, and writing tests. "        "Use write, read, bash."    )}

Enviar y recibir mensajes

def _inbox(name: str) -> Path:    return MAILBOX_DIR / f"{name}.jsonl"def _send(to: str, frm: str, body: str):    with open(_inbox(to), "a") as f:        f.write(            json.dumps({                "from": frm,                "body": body            }) + "\n"        )def _receive(name: str) -> list[dict]:    path = _inbox(name)    if not path.exists():        return []    messages = [        json.loads(line)        for line in path.read_text().splitlines()        if line.strip()    ]    path.write_text("")    return messages

El sistema de buzones es deliberadamente sencillo.

Cada mensaje incluye el remitente y su contenido, y se almacena como una línea JSON.

Cuando el agente recibe los mensajes, vacía el archivo para evitar procesarlos nuevamente.

Ejecutar un agente persistente

def _run_teammate(    name: str,    system: str,    stop_event: threading.Event):    print(f"[{name}] ready and listening")    while not stop_event.is_set():        for msg in _receive(name):            print(                f"[{name}] received: "                f"{msg['body'][:60]}"            )            sub_messages = [                {                    "role": "user",                    "content": msg["body"]                }            ]            while True:                resp = client.messages.create(                    model=MODEL,                    system=system,                    messages=sub_messages,                    tools=EXTENDED_TOOLS,                    max_tokens=4000                )                sub_messages.append({                    "role": "assistant",                    "content": resp.content

El agente comprueba periódicamente su buzón y procesa las instrucciones recibidas.

Después devuelve el resultado al remitente.

Prueba de colaboración multiagente

La tarea consiste en analizar la arquitectura de comunicación entre agentes y añadir registros estructurados a las funciones correspondientes.

El agente principal delega la exploración al especialista explorer.

Este identifica cinco funciones relacionadas con la comunicación en dos archivos.

Después, el especialista writer utiliza esa información para añadir registros con fecha, remitente, destinatario, longitud del mensaje y estado de entrega.

Los dos especialistas colaboran sin incorporar todas sus operaciones intermedias al contexto del agente principal.

La arquitectura permite separar la investigación, la implementación y la síntesis de resultados.

10. Protocolo de comunicación mediante máquinas de estados finitos

Cuando varios agentes intercambian mensajes simultáneamente, pueden aparecer condiciones de carrera y bloqueos.

Un agente podría enviar una segunda solicitud antes de recibir la respuesta de la primera.

También es posible que dos agentes queden esperando indefinidamente una respuesta del otro.

Para evitar estos problemas necesitamos establecer reglas sobre cuándo pueden comunicarse los participantes.

Una máquina de estados finitos, conocida como FSM por sus siglas en inglés, permite controlar esas transiciones.

Los cuatro estados del agente

En nuestra implementación, cada agente puede encontrarse en uno de estos estados:

IDLE: disponible, sin una operación activa.

REQUESTING: enviando una solicitud.

WAITING: esperando una respuesta.

RESPONDING: procesando una solicitud recibida.

La regla fundamental del protocolo es que un agente no puede iniciar una nueva solicitud mientras permanece en el estado WAITING.

Esta restricción evita determinados conflictos asociados a solicitudes simultáneas.

Implementación del protocolo

from enum import Enumclass AgentState(Enum):    IDLE = "idle"    REQUESTING = "requesting"    WAITING = "waiting"    RESPONDING = "responding"class ProtocolAgent:    def __init__(self, name: str, system: str):        self.name = name        self.system = system        self.state = AgentState.IDLE        self._inbox = (            MAILBOX_DIR / f"{name}_proto.jsonl"        )        self._lock = threading.Lock()    def send(        self,        to: "ProtocolAgent",        message: str    ):        with self._lock:            if self.state == AgentState.WAITING:                return (                    "Error: cannot send while "                    "waiting for a response"                )            self.state = AgentState.REQUESTING

Probar el protocolo

Solicitamos analizar la cobertura de pruebas de core.py y crear pruebas adicionales para las funciones que no alcancen un 80 % de cobertura de ramas.

El primer agente analiza la cobertura:

El resultado muestra una cobertura del 71 % e identifica tres funciones con ramas insuficientemente probadas.

El segundo agente recibe la tarea de escribir pruebas para esos casos:

Las transiciones de estado se registran durante todo el proceso.

El protocolo impide que un agente envíe una segunda solicitud mientras espera la respuesta de la primera.

La coordinación queda incorporada a la arquitectura y no depende únicamente de que el modelo recuerde cómo debe comunicarse.

11. Asignación autónoma de tareas

El protocolo FSM controla la comunicación, pero todavía requiere que un agente principal distribuya el trabajo.

En proyectos grandes, el coordinador también puede convertirse en un cuello de botella.

La asignación autónoma elimina la necesidad de que un agente central asigne cada tarea.

Cada integrante examina periódicamente el grafo compartido y, cuando encuentra una tarea disponible, intenta reservarla para ejecutarla.

La reserva debe ser atómica para impedir que dos agentes seleccionen el mismo trabajo simultáneamente.

Reclamar una tarea de manera segura

El principio consiste en proteger las operaciones de selección y modificación del estado mediante un bloqueo.

De esta forma, el primer agente que obtiene el bloqueo puede reservar la tarea.

Cuando el siguiente agente consulta el grafo, esa tarea ya no figura como pendiente.

Esto evita ejecuciones duplicadas y reduce la posibilidad de conflictos.

Ejecución mediante trabajadores autónomos

Cada trabajador mantiene un ciclo en el que consulta las tareas disponibles.

Cuando encuentra una, la reclama y ejecuta el trabajo utilizando su propio contexto y las herramientas registradas.

Después actualiza el resultado en el grafo compartido.

La asignación autónoma permite distribuir tareas sin que el agente principal tenga que intervenir constantemente.

También facilita aumentar o reducir el número de trabajadores disponibles según la carga del proyecto.

El principio sigue siendo el mismo: el modelo decide cómo resolver cada tarea, pero la infraestructura controla las reservas y los cambios de estado.

12. Aislamiento de tareas mediante Git Worktrees

La asignación autónoma permite que varios agentes trabajen simultáneamente, pero genera un problema adicional.

¿Qué ocurre cuando dos agentes necesitan modificar archivos del mismo repositorio?

Si todos comparten el mismo directorio de trabajo, sus operaciones pueden interferir entre sí.

Un agente podría modificar un archivo mientras otro está leyendo una versión anterior.

También podrían producirse sobrescrituras o cambios difíciles de integrar.

La solución consiste en utilizar Git Worktrees.

Un Worktree permite crear un directorio de trabajo independiente asociado al mismo repositorio Git.

Cada agente dispone de su propia rama y de sus propios archivos, evitando que las modificaciones paralelas afecten directamente a los demás trabajadores.

Crear un Worktree para una tarea

Podemos crear un Worktree de Git aislado para cada tarea mediante la siguiente función:

def create_worktree(task_id: str) -> tuple[str, str]:    """Create an isolated git worktree for a task."""    branch = f"task/{task_id}"    path = str(        Path(os.getcwd()).parent        / f".worktree-{task_id[:8]}"    )    if Path(path).exists():        shutil.rmtree(path, ignore_errors=True)        _git("worktree", "remove", "--force", path)    # Gestionar conflictos con ramas de ejecuciones anteriores    if _branch_exists(branch):        _git("branch", "-D", branch)    rc, _, err = _git(        "worktree", "add", "-b", branch, path    )    if rc != 0:        raise RuntimeError(            f"Failed to create worktree: {err}"        )    return path, branch

La función crea un directorio de trabajo independiente asociado a una rama específica de Git.

El nombre de la rama se construye a partir del identificador de la tarea. Si existe un directorio anterior, se intenta eliminar antes de crear uno nuevo.

También se comprueba si ya existe una rama con ese nombre para evitar conflictos con ejecuciones anteriores.

Ejecutar un agente dentro de un Worktree

def run_task_in_worktree(task: dict) -> str:    """Run an agent loop in an isolated worktree directory."""    task_id = task["id"]    wt_path, wt_branch = create_worktree(task_id)    system = (        f"You are a coding agent working in isolated directory: {wt_path}. "        f"Task: {task['description']}. "        "Your changes are on a separate git branch - you cannot affect other agents. "        "When done, summarise every file you changed."    )    messages = [        {            "role": "user",            "content": task["description"]        }    ]    try:        while True:            resp = client.messages.create(

La función ejecuta el ciclo completo de un agente dentro del entorno de trabajo aislado.

Cada agente tiene acceso a las mismas herramientas, pero trabaja en una rama independiente.

Cuando termina, la infraestructura elimina el Worktree y realiza las operaciones de limpieza correspondientes, incluso si la ejecución falla.

Prueba: dos agentes modificando el mismo archivo

Podemos probar este mecanismo creando dos tareas que necesiten modificar core.py y ejecutando dos agentes simultáneamente.

Cada agente creará su propio Worktree, realizará cambios en core.py de manera aislada y ejecutará sus pruebas.

Cuando ambos terminen, la infraestructura detectará que las dos ramas modificaron el mismo archivo y señalará la necesidad de una revisión humana antes de fusionarlas.

La instrucción utilizada es:

s12 >> Ejecuta dos tareas en paralelo:

Tarea A:
Añadir validación de entrada a todas las
funciones de herramientas en core.py.

Tarea B:
Añadir instrucciones de registro a todas las
funciones de herramientas en core.py.

Resultado de la ejecución

> Thinking...

Running 2 tasks in parallel worktrees...

[task-a] worktree created:
.worktree-a1b2c3d4
(branch: task/a1b2c3d4)

[task-b] worktree created:
.worktree-e5f6a7b8
(branch: task/e5f6a7b8)

[a1b2c3][read] agents/core.py
[e5f6a7][read] agents/core.py

[a1b2c3][write] agents/core.py
(added input validation to run_bash)

[e5f6a7][write] agents/core.py
(added logging to run_bash)

[a1b2c3][write] agents/core.py
(added input validation to run_read)

[e5f6a7][write] agents/core.py
(added logging to run_read)

[a1b2c3][bash]
python -m pytest tests/ -q
→ 44 passed

[e5f6a7][bash]
python -m pytest tests/ -q
→ 44 passed

[task-a] completed
[task-b] completed

Conflict detection:

Both branches modified: agents/core.py

Overlap detected on 1 file -
human review required before merging.

Resultados

Tarea A: se añadió validación de entrada a seis funciones de herramientas. Todas las pruebas se completaron correctamente.

Tarea B: se añadieron registros de actividad a seis funciones de herramientas. Todas las pruebas se completaron correctamente.

Se detectó un conflicto de integración: ambas tareas modificaron core.py en ramas diferentes.

Los cambios son compatibles, pero requieren una revisión manual antes de integrarse.

Las ramas task/a1b2c3d4 y task/e5f6a7b8 están listas para su revisión, según el resultado mostrado en el artículo.

¿Qué demuestra este ejemplo?

Ambos agentes leyeron y modificaron core.py simultáneamente.

Sin embargo, como trabajaban en Worktrees separados, las escrituras de uno no interfirieron con las del otro.

Cada agente ejecutó sus pruebas sobre su propia rama y obtuvo resultados correctos.

La detección de conflictos se ejecutó después de que ambas tareas terminaran y señaló correctamente que una persona debe revisar la integración antes de incorporar cualquiera de las ramas a main.

Este es el modelo de aislamiento más sólido del repositorio: ejecución paralela sin interferencias entre los archivos durante el desarrollo de las tareas.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Hola a todos, soy Nitin Gavhane. En este artículo analizo habilidades (skills), plugins y herramientas prácticas para Claude Code que ayudan a reducir el desperdicio de tokens, de modo que una jornada habitual de programación se mantenga por debajo de aproximadamente 13 dólares en consumo de API o permita aprovechar durante más tiempo los límites de una suscripción.

Los costos de tokens en Claude Code provienen principalmente de la acumulación excesiva de contexto: archivos CLAUDE.md demasiado grandes que se cargan en cada interacción, salidas completas de la terminal, lecturas repetidas de archivos, historiales de conversación extensos y respuestas demasiado detalladas del modelo.

Las recomendaciones de Anthropic para gestionar sesiones y varias pruebas de rendimiento realizadas por la comunidad muestran que las sesiones sin control suelen consumir entre 200.000 y 400.000 tokens durante una jornada de trabajo intensa. Con las tarifas actuales de Opus y Sonnet, estos costos pueden acumularse rápidamente. Las herramientas que se presentan a continuación están diseñadas para abordar las principales fuentes de ese consumo innecesario.

Las cifras proceden de archivos README de los proyectos, pruebas de rendimiento independientes y recomendaciones publicadas por Anthropic. Los resultados varían según el tamaño del código base y la forma de trabajar, por lo que los porcentajes deben considerarse puntos de referencia y no garantías.

1. codesight

codesight es una herramienta de línea de comandos (CLI) que no requiere dependencias adicionales. Analiza tu proyecto una sola vez y genera un paquete compacto de contexto que incluye un mapa de la estructura, las funciones y exportaciones principales, el grafo de dependencias, las rutas, los esquemas y los puntos de entrada.

Puedes incorporar el contexto generado a una nueva sesión de Claude Code para que el modelo comprenda la organización del proyecto desde el principio, en lugar de consumir entre 25.000 y 60.000 tokens explorando archivos.

Las reducciones de consumo reportadas se sitúan entre 9 y 13 veces en bases de código medianas y grandes.

Instalación y uso

Ejecuta el siguiente comando desde la carpeta raíz del proyecto:

npx codesight

Para utilizarlo específicamente con Claude Code:

npx codesight --profile claude-code

O bien:

npx codesight --mcp

La segunda opción permite exponer herramientas a través de MCP.

Al comenzar una sesión, pega el contexto generado o indica a Claude que consulte los archivos de salida de .codesight.

También puedes utilizar opciones adicionales:

--wiki: para generar documentación.

--init: para inicializar la configuración.

--hook: para configurar la actualización automática del contexto.

2. Superpowers Framework

obra/superpowers reúne un conjunto de habilidades para organizar los flujos de trabajo, como brainstorming, planificación, desarrollo guiado por pruebas, depuración sistemática y otras tareas.

Estas habilidades obligan a Claude a seguir una secuencia de trabajo estructurada:

Aclarar → Diseñar → Planificar → Programar → Verificar.

Las comparaciones controladas han mostrado un consumo de tokens aproximadamente entre un 9 % y un 14 % menor, además de reducir los ciclos innecesarios de iteración, porque el agente planifica y realiza pruebas antes de efectuar modificaciones importantes en el código.

Instalación y uso

Dentro de Claude Code, ejecuta:

/plugin install superpowers@claude-plugins-official

También puedes registrar primero el marketplace:

/plugin marketplace add obra/superpowers-marketplace

Y después instalar el plugin:

/plugin install superpowers@superpowers-marketplace

Una vez instalado, las habilidades se activan automáticamente cuando las tareas son relevantes.

También puedes invocarlas explícitamente mediante estos comandos:

/brainstorm
/write-plan
/execute-plan

Si las habilidades no aparecen, reinicia Claude Code o inicia una sesión nueva.

3. cost-mode Skill

Sagargupta16/claude-cost-optimizer incluye una habilidad instalable llamada cost-mode, diseñada para optimizar el consumo de tokens.

Esta herramienta elimina contenido innecesario de las respuestas, recomienda modelos más económicos para tareas sencillas, recuerda cuándo conviene compactar el contexto y prioriza los cambios puntuales mediante diferencias de código (diffs) en lugar de reescribir archivos completos.

Los ahorros habituales reportados se sitúan entre el 30 % y el 60 % en cargas de trabajo variadas.

Instalación y uso

Primero, registra el marketplace:

/plugin marketplace add Sagargupta16/claude-cost-optimizer

Después, instala la habilidad:

/plugin install cost-mode@claude-cost-optimizer

Como alternativa, puedes instalarla mediante:

npx skills add Sagargupta16/claude-cost-optimizer

Una vez instalada, puedes activar diferentes modos dentro de cualquier sesión:

/cost-mode
/cost-mode lite
/cost-mode strict
/cost-mode off

El primer comando activa el modo estándar. Los modos lite y strict permiten ajustar el nivel de optimización, mientras que off desactiva la habilidad.

La configuración permanece activa durante toda la sesión hasta que decidas desactivarla.

4. rtk (Rust Token Killer)

rtk-ai/rtk funciona como una capa intermedia entre Claude Code y la terminal.

Intercepta comandos habituales, como git status, herramientas de ejecución de pruebas, ls, grep y otros, para devolver resúmenes comprimidos en lugar de mostrar toda la salida original.

Según las cifras publicadas por el proyecto, permite reducir entre un 60 % y un 90 % los tokens consumidos por los resultados de esos comandos.

Sin embargo, las pruebas de rendimiento independientes han mostrado resultados variados, por lo que conviene medir su impacto en tu propia carga de trabajo.

Instalación y uso

Puedes instalarlo con el siguiente comando:

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh

Otra opción es utilizar Homebrew:

brew install rtk

O instalarlo mediante Cargo:

cargo install --git https://github.com/rtk-ai/rtk

Para verificar la instalación, ejecuta:

rtk gain

Este comando debe mostrar el panel de ahorro de tokens y no un mensaje indicando que el comando no existe.

Después, ejecuta:

rtk init -g

Cuando el sistema solicite autorización para modificar el archivo settings.json, responde y.

Reinicia Claude Code.

A partir de ese momento, los comandos habituales se reescribirán automáticamente para optimizar sus resultados.

Para confirmar que el hook está activo, utiliza:

rtk init --show

5. Headroom

Headroom y su herramienta de línea de comandos de código abierto, disponible en headroomlabs-ai/headroom, funcionan como un proxy local que comprime las salidas extensas de herramientas, registros de actividad (logs) y contenido repetitivo antes de que ingresen al contexto de la conversación.

Los ahorros reportados a nivel de sesión se sitúan aproximadamente entre el 40 % y el 50 % en cargas de trabajo reales con agentes de IA.

Instalación y uso

Puedes instalar Headroom mediante:

pip install "headroom-ai[all]"

También puedes utilizar la aplicación de escritorio disponible en su sitio web o instalarla mediante Homebrew Cask.

Después de la instalación, ejecuta:

headroom wrap claude

Este comando inicia el proxy y ejecuta Claude Code.

Si únicamente deseas utilizarlo con herramientas MCP, ejecuta:

headroom mcp install

Después, inicia Claude Code normalmente.

La compresión es reversible, por lo que Claude puede recuperar el contenido original cuando sea necesario.

6. Habilidades progresivas en lugar de un archivo CLAUDE.md demasiado grande

La documentación de Anthropic y varias guías de optimización coinciden en una misma recomendación: el archivo CLAUDE.md se carga en cada interacción.

Por este motivo, conviene trasladar cualquier instrucción que ocupe más de un par de frases a habilidades independientes.

Las habilidades únicamente cargan una descripción breve al iniciar la sesión, generalmente de unas pocas decenas de tokens cada una. Su contenido completo se incorpora al contexto únicamente cuando Claude determina que la habilidad resulta relevante para la tarea.

Un proyecto que contenga veinte procedimientos habituales puede recuperar entre 10.000 y 15.000 tokens por sesión utilizando este enfoque.

Configuración y uso

Mantén el archivo CLAUDE.md limitado a la información esencial:

Tecnologías utilizadas en el proyecto.

Mapa de directorios.

Algunas reglas obligatorias de funcionamiento.

El objetivo recomendado es mantenerlo por debajo de 150 a 200 líneas.

Crea las habilidades como carpetas dentro de alguno de estos directorios:

Para habilidades disponibles a nivel de usuario:

~/.claude/skills/

Para habilidades específicas del proyecto:

.claude/skills/

Cada habilidad debe incluir un archivo:

SKILL.md

Este archivo debe contener una descripción breve en formato YAML, junto con las instrucciones detalladas correspondientes.

Claude descubre estas habilidades y las carga cuando las necesita.

No se requiere ninguna instalación adicional, aparte de colocar los archivos en las carpetas correspondientes.

7. Hábitos de uso de /compact, /clear y /context

Anthropic explica claramente la importancia de estos comandos en sus recomendaciones oficiales para aprovechar mejor Claude Code.

Los tres comandos están integrados directamente en la herramienta.

Cómo utilizarlos

Utiliza:

/clear

Entre tareas que no estén relacionadas.

Esto evita que el contexto de trabajos anteriores siga incorporándose a cada nueva solicitud.

Ejecuta:

/context

Al comenzar una sesión nueva para comprobar qué información se encuentra cargada.

Esto incluye el prompt del sistema, las herramientas MCP y las habilidades disponibles.

También puedes utilizar:

/compact

Antes de interrumpir tu trabajo.

Compactar la conversación mientras la caché del prompt todavía está activa resulta más económico que tener que reconstruir el contexto posteriormente.

Estos tres comandos tienen un costo prácticamente insignificante y ayudan a eliminar una de las principales fuentes de crecimiento silencioso del consumo de tokens.

8. Subagentes para tareas exigentes

Cuando Claude necesita buscar información en numerosos archivos, ejecutar pruebas largas o explorar una parte extensa del código, es recomendable delegar ese trabajo a un subagente.

Los subagentes disponen de su propia ventana de contexto.

Esto significa que el trabajo realizado por el subagente no tiene que incorporarse íntegramente a la conversación principal.

Únicamente se devuelve el resumen final o el resultado de la tarea.

Cómo utilizarlos

Puedes solicitar explícitamente a Claude que utilice un subagente o la herramienta Task para realizar la parte más exigente del trabajo.

Por ejemplo:

Utiliza un subagente para buscar en todo el código cada llamada a X y devuelve únicamente las ubicaciones encontradas y un breve resumen.

De esta forma, la sesión principal mantiene un contexto reducido y evita acumular información innecesaria.

No es necesario instalar ningún componente adicional, ya que se trata de una funcionalidad nativa de Claude Code.

9. Plugins de inteligencia de código

Anthropic recomienda utilizar plugins de inteligencia de código para trabajar con lenguajes de programación que cuentan con sistemas de tipos.

Estos plugins permiten a Claude navegar directamente entre símbolos, funciones, clases y definiciones, en lugar de depender de búsquedas repetitivas de texto o de la lectura completa de archivos.

Reducir la cantidad de lecturas exploratorias también disminuye los tokens necesarios simplemente para localizar una función o un tipo de dato.

Instalación y uso

Puedes explorar los plugins disponibles mediante:

/plugin

También puedes instalar directamente el plugin del servidor de lenguaje correspondiente.

Por ejemplo, para TypeScript:

/plugin install typescript-lsp@claude-plugins-official

Existen alternativas equivalentes para otros lenguajes:

Python: Pyright.

Go: gopls.

Rust: rust-analyzer.

El ejecutable del servidor de lenguaje debe estar previamente instalado y disponible en la variable de entorno PATH.

Después de instalarlo, Claude utiliza automáticamente las herramientas de navegación estructurada y recibe diagnósticos tras modificar el código.

10. Cambiar de modelo y nivel de esfuerzo según la tarea

No todas las tareas requieren utilizar el modelo más costoso o la configuración de esfuerzo más elevada.

Para generar código repetitivo, corregir errores sencillos, dar formato a archivos o realizar consultas básicas, puedes utilizar Haiku o un nivel de esfuerzo medio.

Una serie de pruebas publicada mostró una reducción aproximada del 45 % en los tokens de salida al pasar de un nivel de esfuerzo alto a uno medio, utilizando el mismo conjunto de tareas y con una pérdida de calidad reducida en trabajos rutinarios.

Configuración y uso

Selecciona el modelo y el nivel de esfuerzo al comenzar la sesión.

Por ejemplo, puedes utilizar:

/model

También puedes establecer estas opciones mediante los parámetros de inicio de la sesión.

Cambiar el modelo o el nivel de esfuerzo durante una conversación puede invalidar la caché del prompt y aumentar el costo.

Por este motivo, es recomendable decidir qué configuración utilizar antes de comenzar.

Utiliza Haiku para trabajos sencillos y reserva los modelos de mayor capacidad para tareas de arquitectura de software o depuración compleja.

Conclusión

Combinar varias de estas técnicas puede generar un efecto acumulativo considerable en el consumo de tokens.

Mantener un archivo CLAUDE.md reducido y complementarlo con habilidades, utilizar codesight para comprender la estructura del proyecto, incorporar cost-mode o Headroom para eliminar información innecesaria, delegar la exploración a subagentes y seleccionar cuidadosamente el modelo permite reducir de forma importante el consumo durante las sesiones.

Aplicadas conjuntamente, estas prácticas pueden reducir sesiones que normalmente consumen alrededor de 300.000 tokens hasta niveles que permitan mantenerse cómodamente por debajo de un objetivo de 13 dólares diarios para un uso moderado de la API, o prolongar el aprovechamiento de los límites de un plan Max.

¿Cuáles de estas herramientas has utilizado en un proyecto real? ¿Qué diferencias observaste en el consumo de tokens antes y después de implementarlas?

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Si has estado usando Claude Code, creo que todas podemos estar de acuerdo en algo: es una herramienta excelente, pero viene con varias limitaciones.

1. No puede ver un video.
2. Escribe de una forma que se nota que fue generada por IA.
3. Cuando le pides que diseñe una aplicación, muchas veces entrega resultados genéricos o de baja calidad.
4. Y, además de todo eso, puedes agotar tu límite de uso mucho más rápido de lo que imaginas.

GitHub está lleno de habilidades para Claude que prometen solucionar estos problemas y muchos otros. El problema es que hay cientos, y la mayoría no merecen tu tiempo.

He pasado meses probando estos repositorios y creando mis propias soluciones para cubrir lo que faltaba.

Estas son cuatro habilidades que solucionan gran parte de los problemas con los que Claude Code suele tener dificultades. Son las que me habría gustado que alguien me hubiera recomendado desde el primer día.

#1 | Ponytail: reduce el desperdicio de tokens en Claude Code

Si estás creando una aplicación, haciendo vibe coding y viendo cómo aumenta rápidamente tu consumo de tokens, Ponytail puede ser muy útil.

El nombre viene del típico cliché cinematográfico del hacker de la dark web: una persona desarrolladora con una larga coleta, una lata de Mountain Dew y una bolsa roja de Doritos sobre el escritorio.

Alguien necesita que consiga entrar en una base de datos gubernamental secreta y extremadamente protegida.

La mira, no dice nada, escribe una sola línea de código y entra.

De ahí viene el nombre: Ponytail.

Ponytail, básicamente, pone a ese personaje dentro de Claude Code.

Esta es la habilidad de Claude que necesitas si quieres construir algo ligero y eficiente, reduciendo al mismo tiempo el consumo de tokens.

Si has estado haciendo vibe coding, probablemente habrás notado que Claude tiende a construir más de lo necesario. Le pides una cosa sencilla y, con frecuencia, termina entregando bastante más de lo que pediste.

Eso tiene un doble costo.

Primero, en tokens, porque cada línea adicional de código que no necesitabas igualmente se genera y consume recursos. Segundo, porque esas líneas extra comienzan a acumularse.

A medida que el proyecto crece, Claude puede empezar a confundirse con su propia complejidad, hasta el punto en que modificar una cosa termina rompiendo otra.

Ponytail intenta evitarlo haciendo que Claude se plantee algunas preguntas antes de escribir cualquier cosa:

• ¿Esto realmente necesita existir?
• ¿Ya construí algo parecido en otra parte del proyecto?
• ¿El navegador ya puede resolver esto de forma nativa?
• ¿Se puede hacer en una línea en lugar de cincuenta?

El beneficio aparece en dos áreas.

Consumes menos tokens y mantienes una base de código más pequeña, limpia y fácil de entender para Claude a medida que el proyecto crece.

Hay una limitación de Ponytail que he notado.

Como está optimizado para ahorrar tokens, también tiende a comprimir las respuestas que recibes en el chat.

En ocasiones, las respuestas llegan tan resumidas que tienes que leerlas dos o tres veces para entenderlas, especialmente cuando se trata de temas técnicos.

Por suerte, es fácil solucionarlo.

Cuando necesites una explicación más detallada, puedes pedirle que te lo explique como si fueras una estudiante de quinto grado.

Claude seguirá manteniendo el código eficiente, pero dejará de comprimir tanto la explicación.

#2 | Claude Video: ver y analizar videos

Cuando se trata de ver videos, Claude prácticamente trabaja a ciegas.

Si le das un enlace de YouTube, probablemente tendrá dificultades.

Puede llegar a obtener la transcripción, pero no podrá ver realmente lo que aparece en pantalla. Y si necesitas comprender el contexto visual del video, una transcripción por sí sola no es suficiente.

La habilidad Claude Video aborda directamente este problema.

Esta habilidad permite que Claude pueda analizar un video y entender qué se muestra en pantalla, obteniendo así el contexto completo del contenido.

Como creadora de contenido, veo muchos tutoriales de YouTube, pero no siempre puedo dedicar treinta minutos completos a escuchar un podcast.

Con esta habilidad instalada, Claude puede leer la transcripción, analizar el video y reunir todo el contexto, incluyendo la información visual.

Además, no funciona únicamente con YouTube.

También puede utilizarse con Loom, TikTok, X, Instagram y otras plataformas.

Para instalar Claude Video, puedes copiar el enlace de la habilidad y pasárselo a Claude Code:

Claude Code — opción recomendada, con actualizaciones automáticas mediante marketplace:

/plugin marketplace add bradautomates/claude-video
/plugin install watch@claude-video

También puedes pedirle directamente a Claude que lo instale utilizando la URL.

Copia y pega lo siguiente en Claude:

Instala este repositorio:
https://github.com/bradautomates/claude-video

Una vez instalado, cuando quieras que Claude analice un video, puedes utilizar el comando:

/watch

Después, pega la URL del video de YouTube, Instagram u otra plataforma compatible y deja que haga el análisis.

Y una última observación.

Antes de instalar cualquier cosa procedente de GitHub, conviene tener cuidado con posibles inyecciones de prompts ocultas dentro de un repositorio.

Cuando no confío completamente en una fuente, le pido primero a Claude que analice el repositorio y extraiga únicamente aquello que necesita.

De esta forma, si existe algún contenido malicioso oculto, reduces las posibilidades de que termine incorporándose a tu sistema.

#3 | Last30Days: investigación de mercado actualizada

Last30Days es la habilidad de Claude más grande de esta lista.

El repositorio tiene alrededor de 50.000 estrellas en GitHub y resuelve un problema con el que probablemente ya te hayas encontrado muchas veces.

Imagina que quieres crear una aplicación de citas para personas divorciadas y le pides a Claude que investigue a la competencia o encuentre oportunidades que todavía no están cubiertas en el mercado.

Cuando le pides a Claude que haga esta tarea, muchas veces devuelve investigaciones basadas en artículos populares de Google, algunos publicados hace meses o incluso años.

Eso puede resultar bastante poco útil en una época en la que una nueva tecnología puede hacer que algo quede obsoleto en cuestión de semanas.

La habilidad Last30Days intenta solucionar precisamente ese problema.

En lugar de limitarse a leer artículos o publicaciones de blogs indexadas, envía a Claude a los lugares donde las personas están hablando activamente sobre la idea o el mercado que estás investigando.

Por ejemplo:

• Reddit
• X, antes Twitter
• YouTube
• TikTok
• Instagram
• Threads
• GitHub
• Y cualquier otra fuente que le indiques

El verdadero valor de Last30Days está en que también analiza los comentarios.

Una búsqueda normal de Claude puede encontrar una publicación de Reddit y obtener una idea general del tema.

Pero normalmente no entra en la sección de comentarios, que es precisamente donde aparecen muchos de los detalles más interesantes.

Esta habilidad sí entra en los comentarios y obtiene información de allí.

Además, contrasta los resultados que encuentra.

Por ejemplo, si alguien se queja de algo en Reddit, aparece la misma queja en X y vuelve a repetirse en un comentario de YouTube, la herramienta puede reconocer ese patrón y asignarle mayor importancia.

Un comentario negativo aislado de una sola persona puede ignorarse.

Tres quejas independientes sobre el mismo problema en tres plataformas diferentes pueden considerarse una señal relevante.

De esta forma, tu investigación no depende únicamente de artículos publicados en Internet, muchos de los cuales pueden tener intereses comerciales detrás.

Claude puede ayudarte a encontrar directamente a las personas que tienen más posibilidades de comprar tu producto y entender qué están diciendo realmente, en lugar de basarse solamente en una publicación escrita por alguien con una determinada perspectiva.

Para utilizarlo, ejecuta el comando:

/last30days

seguido del tema que quieras investigar.

Por ejemplo:

• Encontrar información sobre un tema antes de que alcance su punto máximo:

/last30days qué está creciendo rápidamente en inteligencia artificial

• Obtener noticias actuales sobre cualquier tema:

/last30days Kendrick Lamar

• Comparar herramientas:

/last30days OpenClaw vs Hermes vs Paperclip

• Entender acontecimientos internacionales:

/last30days Irán vs Estados Unidos

• Aprender rápidamente sobre un tema:

/last30days prompting para Nano Banana Pro

Yo utilizo esta habilidad todas las semanas, ya sea para investigar ideas de aplicaciones o para comprobar si un tema merece la pena incluirlo en mi newsletter.

#4 | Humanizer: elimina el estilo de IA de tus textos

Humanizer es una habilidad de Claude pensada para eliminar del texto muchos de los patrones habituales de la escritura generada por inteligencia artificial.

A estas alturas, muchas ya conocemos algunas de las señales más comunes de un texto generado por IA.

Por ejemplo:

• Uso excesivo de rayas largas.
• Construcciones del tipo “no es esto, sino aquello”.
• Frases introductorias como “esto es lo que realmente importa”.
• Palabras y expresiones utilizadas constantemente por modelos de IA.

Cada vez que le pides a Claude que escriba algo, puedes terminar recordándole constantemente que quieres un tono más natural, más casual y menos parecido al de un texto generado por una máquina.

Humanizer intenta eliminar la necesidad de repetir esas instrucciones una y otra vez.

Fue creado tomando como referencia las propias reglas documentadas de Wikipedia para identificar textos generados por inteligencia artificial, y analiza el contenido utilizando 33 patrones diferentes para detectar y eliminar este tipo de señales.

La forma en la que yo lo utilizo consiste en darle primero a Claude algunos ejemplos de mis propios textos para que pueda aprender el estilo que quiero conservar.

Cuando le pido que escriba algo, primero genera un borrador intentando imitar mi voz y después pasa el resultado por Humanizer para eliminar aquellas partes que todavía suenan demasiado artificiales.

Hay algo importante que conviene entender sobre Humanizer.

No es una herramienta para escribir.

Es una herramienta de limpieza.

No puede darte automáticamente una gran idea, crear una historia interesante desde cero o convertir un texto aburrido en una reflexión filosófica brillante.

Si el texto original es malo, Humanizer no puede salvarlo.

Su función consiste principalmente en eliminar palabras, estructuras y patrones comunes de la escritura generada por IA que podrían hacer que el contenido parezca artificial.

¿Qué habilidad de Claude Code deberías instalar primero?

Ninguna de estas herramientas requiere que abandones Claude Code ni que pagues una segunda suscripción completa.

Video, investigación, escritura y tendencia a construir más de lo necesario.

Son cuatro áreas diferentes en las que Claude Code puede quedarse corto cuando lo utilizas sin herramientas adicionales, y para cada una de ellas ya existe una solución específica.

Instala primero aquella que esté haciéndote perder más tiempo esta semana.

Las demás seguirán disponibles cuando las necesites.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Cuando trabajas con Claude Code, organizar bien tus proyectos marca una gran diferencia. Claude funciona mejor cuando tiene un contexto claro, una estructura consistente e instrucciones explícitas.

A continuación encontrarás 5 principios fundamentales que deberías seguir para crear una excelente estructura de proyecto:

1. Coloca CLAUDE.md en la raíz

CLAUDE.md es un archivo fundamental para proporcionar a Claude Code contexto específico sobre tu proyecto. Funciona como una guía de incorporación para que la IA entienda los requisitos de tu proyecto y tu base de código.

Claude lee automáticamente el archivo CLAUDE.md al iniciar.

Este es un ejemplo de lo que puedes incluir en este archivo:

# Descripción general del proyecto
Breve descripción del proyecto.

# Arquitectura
Explicación de los componentes principales.

# Stack tecnológico
Next.js
TypeScript
ShadCN UI
Tailwind

# Convenciones de código
- Usar el modo estricto de TypeScript
- Preferir componentes funcionales
- Evitar exportaciones por defecto

# Estructura de carpetas
Explicación de los directorios.

# Comandos
npm run dev
npm run build

# Reglas importantes
Requisitos de rendimiento
Requisitos de accesibilidad
Estrategia de testing

El archivo debería colocarse en la carpeta raíz de tu proyecto:

my-project/
├── CLAUDE.md
├── package.json
├── src/
├── docs/
└── scripts/

Nota rápida: si ya tienes una base de código existente en tu proyecto, no tienes que empezar desde cero al crear CLAUDE.md.

En su lugar, puedes escribir el comando /init en Claude Code y este generará un primer borrador del archivo:

/init

2. Divide las instrucciones grandes de CLAUDE.md en archivos importados

El archivo CLAUDE.md puede crecer rápidamente.

Como Claude Code lee este archivo constantemente y su contenido se añade al contexto, no es recomendable tener archivos demasiado grandes.

Como regla general, si notas que el archivo supera aproximadamente las 200 líneas de texto, deberías dividirlo en varios archivos.

Claude Code permite realizar importaciones dentro de CLAUDE.md:

@path/to/import.md

Solo necesitas proporcionar el contexto necesario para indicar cuándo Claude debería utilizar cada archivo importado.

Así podría verse un archivo CLAUDE.md actualizado utilizando importaciones:

# CLAUDE.md

# Arquitectura
Para consultar la arquitectura del proyecto, revisa:
@claude/architecture.md

# Convenciones de código
Para consultar las convenciones de código, revisa:
@claude/coding_conventions.md

# Guías de interfaz
Para consultar las guías de interfaz, revisa:
@claude/ui_guidelines.md

Y dentro del directorio del proyecto, la estructura de archivos sería:

CLAUDE.md

claude/
    architecture.md
    coding_conventions.md
    ui_guidelines.md

Esta estructura resulta útil tanto para ti como para la IA porque:

• Es más fácil de mantener cuando quieres modificar algo.
• Permite una carga de contexto más rápida para Claude.
• Los archivos pueden reutilizarse entre diferentes proyectos, especialmente en proyectos de desarrollo web.

3. Añade una carpeta /docs para proporcionar contexto

Si quieres ayudar a Claude a comprender mejor tu proyecto y sus particularidades, es recomendable añadir una carpeta docs/.

Claude entiende especialmente bien la documentación escrita en formato Markdown.

Por ejemplo, puedes añadir información sobre funcionalidades que planeas incorporar a tu producto durante el trimestre o sobre las llamadas actuales a la API que ofrece tu producto.

docs/
    project_roadmap.md
    api.md

Después puedes pedirle a Claude que consulte esa documentación cuando implemente una funcionalidad concreta.

Por ejemplo, si quieres crear un sistema de comprobación del estado de tu servicio web:

Lee docs/api.md e implementa nuestro monitor de estado del servicio disponible mediante llamadas a la API.

De esta manera, Claude puede trabajar utilizando como referencia la documentación específica de tu proyecto.

4. Añade una carpeta /workflows para los flujos de trabajo

Si quieres que Claude siga un flujo de trabajo específico al realizar determinadas tareas, deberías guardar esos procesos en un directorio dedicado.

Por ejemplo, en un proyecto de desarrollo web puedes utilizar una estructura como esta:

claude/
    workflows/
        build-new-component.md
        code-refactoring.md
        write-auto-tests.md
        migrate-db.md

Así podría verse el workflow build-new-component.md.

Ten en cuenta que este es únicamente un ejemplo y que un flujo de trabajo real puede ser mucho más complejo:

# build-component.md

Cuando se te pida crear un nuevo componente para un servicio web,
créalo siguiendo estos requisitos:

- TypeScript
- ShadCN UI
- Accesible
- Mobile-first
- Estilos con Tailwind

Después puedes ejecutarlo con una instrucción como esta:

Sigue claude/prompts/build-component.md para crear una tarjeta para el dashboard.

Una de las ventajas de esta estructura es que puedes activar un flujo de trabajo desde otro.

Por ejemplo, si Claude crea un nuevo componente siguiendo build-new-component.md, puedes indicarle desde ese mismo archivo que también genere pruebas automáticas para validar el nuevo código.

El archivo podría verse así:

# build-component.md

Cuando se te pida crear un nuevo componente para un servicio web,
créalo siguiendo estos requisitos:

- TypeScript
- ShadCN UI
- Accesible
- Mobile-first
- Estilos con Tailwind

Asegúrate también de escribir pruebas automáticas para este componente
siguiendo las instrucciones de:

@workflows/write-auto-tests.md

De esta manera puedes crear flujos de trabajo compuestos y reutilizables.

5. Utiliza una carpeta /tools para las tareas de servicio de Claude

Una de las grandes ventajas de Claude Code es que puede escribir scripts de servicio específicos para agilizar determinados flujos de trabajo.

Por ejemplo, si le pides que organice una migración de base de datos definida en migrate-db.md, Claude probablemente escribirá un script en Python encargado de ejecutar parte de esas acciones.

Mi recomendación es guardar todos estos scripts de servicio dentro de una única carpeta llamada /tools.

tools/
    migrate-db.py
    seed-data.py
    export-data.py

Nota rápida: quizás te preguntes por qué utilizar /tools en lugar de /scripts.

Si estás trabajando en un proyecto de desarrollo web, normalmente el término scripts se asocia con scripts de frontend o backend utilizados directamente por el servicio.

Por eso prefiero utilizar el nombre /tools para las herramientas auxiliares que utilizamos durante el desarrollo.

Esto ayuda a reducir confusiones cuando diferentes personas del equipo revisan la estructura del proyecto.

Una estructura de proyecto bien organizada no solo hace que el código sea más sencillo de mantener.

También permite que Claude Code tenga un contexto más claro, entienda mejor las reglas del proyecto y siga flujos de trabajo de una forma mucho más consistente.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

La mayoría de los desarrolladores no mejoran por aprender más sintaxis. Mejoran cuando aprenden a pensar como ingenieros con experiencia.

Durante mucho tiempo pensé que convertirme en una mejor desarrolladora significaba aprender más.

Más Python. Más frameworks. Más librerías. Más patrones de diseño.

Pero después de pasar más tiempo rodeada de ingenieros con experiencia, noté algo que cambió mi forma de abordar la programación.

Los mejores desarrolladores no necesariamente escribían código más complicado.

De hecho, muchas veces hacían exactamente lo contrario.

Eliminaban la complejidad innecesaria. Hacían que los fallos fueran predecibles. Mantenían las funciones pequeñas. Cuestionaban las abstracciones. Escribían código que otra persona pudiera entender sin necesidad de organizar una reunión para explicarlo.

Con el tiempo, empecé a adoptar esos hábitos.

Estos son nueve patrones de programación que aprendí de ingenieros senior y que han tenido un impacto mucho mayor en mis habilidades como desarrolladora que aprender otro truco de sintaxis.

1. Haz que el camino principal sea evidente

Una de las primeras cosas que noté fue lo poco que les gusta a los ingenieros senior el anidamiento innecesario.

Quienes están empezando suelen escribir código como este:

if user:
    if user.is_active:
        if user.has_permission:
            process_request(user)

Funciona, pero la operación importante queda escondida entre varias capas de condiciones.

Un enfoque basado en cláusulas de guarda hace que el flujo normal sea mucho más fácil de seguir:

if not user:
    return

if not user.is_active:
    return

if not user.has_permission:
    return

process_request(user)

Ahora la función se lee casi como una lista de comprobación.

Primero verificas las condiciones que pueden detener la ejecución y después realizas el trabajo real.

No se trata de seguir una regla que diga que todas las funciones deben utilizar cláusulas de guarda. Se trata de reducir la carga mental innecesaria.

Cuando alguien abra tu código seis meses después, debería poder entender el flujo principal sin tener que desenredar mentalmente un laberinto de sentencias if.

El buen código hace que lo importante sea fácil de ver.

2. Valida los datos en los límites del sistema

Una cantidad sorprendentemente grande de la complejidad de una aplicación aparece porque permitimos que datos no válidos avancen demasiado dentro del sistema.

Imagina una API que recibe información de usuarios.

En lugar de aceptar un diccionario cualquiera y comprobar su contenido en diferentes partes de la aplicación:

def create_user(data):
    # validación distribuida por toda la función
    ...

define desde el principio cómo deben ser los datos válidos.

Por ejemplo, utilizando Pydantic:

from pydantic import BaseModel, EmailStr

class User(BaseModel):
    name: str
    email: EmailStr
    age: int

De esta forma, las entradas no válidas pueden rechazarse antes de que lleguen a la lógica de negocio.

El mismo principio se aplica a la configuración, los argumentos de línea de comandos, los registros de bases de datos, los archivos subidos y las respuestas de servicios externos.

Cuanto antes establezcas un contrato fiable, menos código defensivo necesitarás en el resto de la aplicación.

Valida una sola vez en el límite del sistema, en lugar de cuestionar constantemente los datos en toda la aplicación.

3. Mantén las funciones aburridas

Antes pensaba que una función capaz de hacer cinco cosas era eficiente.

Normalmente, solo era difícil de mantener.

Por ejemplo:

def process_order(order):
    # validar pedido
    # calcular precio
    # guardar en la base de datos
    # enviar correo electrónico
    # escribir registro
    ...

Técnicamente, la función funciona, pero tiene demasiadas responsabilidades.

Un diseño más limpio separa las operaciones:

def validate_order(order):
    ...

def calculate_total(order):
    ...

def save_order(order, total):
    ...

def send_confirmation(order):
    ...

def process_order(order):
    validate_order(order)

    total = calculate_total(order)
    save_order(order, total)
    send_confirmation(order)

Ninguna de estas funciones resulta especialmente impresionante.

Y precisamente por eso me gusta este patrón.

Cada función tiene un propósito claro. Cada una puede probarse de manera independiente. Y cuando cambian los requisitos, tienes menos elementos que desenredar.

Los ingenieros senior suelen escribir código que, cuando lo ves por primera vez, puede parecer incluso aburrido.

Normalmente, eso es una ventaja, no un defecto.

Si una función es fácil de explicar en una sola frase, probablemente también sea más fácil de mantener.

4. Dale a cada componente una responsabilidad clara

Una lección relacionada con la anterior consiste en saber dónde debe vivir cada funcionalidad.

Observa este ejemplo:

def get_users():
    response = requests.get(API_URL)
    users = response.json()

    with open("users.json", "w") as file:
        json.dump(users, file)

    return users

Es práctico, pero la función está realizando dos trabajos que no están directamente relacionados:

1. Obtener los usuarios.
2. Guardar los usuarios.

Separar esas responsabilidades crea límites más claros:

def fetch_users():
    response = requests.get(API_URL)
    response.raise_for_status()
    return response.json()

def save_users(users):
    with open("users.json", "w") as file:
        json.dump(users, file)

Ahora puedes cambiar el mecanismo de almacenamiento sin tocar la lógica relacionada con la red.

Quizás mañana los datos deban almacenarse en PostgreSQL en lugar de en un archivo JSON.

Ese cambio no debería obligarte a reescribir el código responsable de comunicarse con la API.

Esta es una de las ideas más sencillas de la ingeniería de software, pero se vuelve cada vez más importante a medida que las aplicaciones crecen.

Un componente debería tener un motivo para cambiar, no cinco motivos diferentes.

5. Trata los fallos como un resultado normal

El código de quienes están empezando suele asumir que todo va a funcionar.

El código en producción no puede permitirse esa suposición.

Piensa en una petición a una API:

response = client.get(url)
data = response.json()

¿Qué ocurre si el servidor no está disponible?

¿Qué pasa si la solicitud supera el tiempo de espera?

¿Qué sucede si el servidor devuelve un error 500?

¿Y si la respuesta no contiene un JSON válido?

Una implementación más cuidadosa podría verse así:

try:
    response = client.get(url, timeout=10)
    response.raise_for_status()
    data = response.json()

except TimeoutError:
    logger.error("La solicitud superó el tiempo de espera")

except ValueError:
    logger.error("Se recibió una respuesta no válida")

Las excepciones exactas y la estrategia de recuperación dependerán de cada aplicación.

Lo importante es la forma de pensar.

Las redes fallan.

Los archivos desaparecen.

Los usuarios introducen datos inesperados.

Las bases de datos dejan de estar disponibles.

Los servicios externos cambian.

Los ingenieros con experiencia no tratan estas situaciones como casos extremos imposibles. Deciden qué debe hacer la aplicación cuando ocurren.

Un software fiable no es un software que nunca falla. Es un software que falla de manera predecible.

6. Mantén la configuración separada de la lógica de negocio

Una configuración escrita directamente en el código rara vez parece peligrosa al principio.

API_URL = "https://api.example.com"
TIMEOUT = 10
MAX_RETRIES = 3

El problema empieza cuando la configuración se extiende por todo el proyecto.

Con el tiempo, terminas teniendo URLs de bases de datos en un módulo, endpoints de APIs en otro, indicadores de funcionalidades en otro lugar y valores específicos de cada entorno escondidos dentro de funciones.

Un enfoque más limpio consiste en establecer un límite claro para la configuración.

Por ejemplo:

import os

API_URL = os.getenv("API_URL")
TIMEOUT = int(os.getenv("TIMEOUT", "10"))
MAX_RETRIES = int(os.getenv("MAX_RETRIES", "3"))

Ahora la lógica de la aplicación no necesita saber en qué entorno se está ejecutando.

Desarrollo, pruebas y producción pueden proporcionar valores diferentes sin necesidad de modificar el código fuente.

El principio general es importante:

El código debería describir el comportamiento. La configuración debería describir el entorno.

7. Prefiere la composición antes que las abstracciones prematuras

Una de las trampas más fáciles en las que podemos caer mientras crecemos como desarrolladores es intentar que el código parezca demasiado “arquitectónico” demasiado pronto.

Descubres las clases, la herencia, las factorías, las interfaces y los patrones de diseño.

De repente, un problema de 30 líneas termina teniendo 12 clases.

Los ingenieros con experiencia suelen ser mucho más cuidadosos con esto.

Muchas veces empiezan con componentes pequeños y los combinan:

validator = Validator()
repository = Repository()
notifier = Notifier()

service = UserService(
    validator=validator,
    repository=repository,
    notifier=notifier,
)

Cada componente tiene una responsabilidad concreta, pero la aplicación los combina para realizar una operación más grande.

Esto también facilita las pruebas.

Puedes sustituir el repositorio por una implementación falsa sin modificar el resto del servicio.

La lección importante no es “evita las clases”.

Es esta:

No construyas una abstracción hasta que entiendas el problema que esa abstracción necesita resolver.

Una buena arquitectura debería surgir de requisitos reales, no del deseo de hacer que un proyecto pequeño parezca sofisticado.

8. Escribe código que sea fácil de reemplazar

Esta es una de las ideas más útiles que aprendí de desarrolladores con experiencia.

Normalmente pensamos en hacer que el código sea fácil de ampliar.

Pero conseguir que también sea fácil de reemplazar es igual de importante.

Supongamos que tu aplicación se comunica con un servicio externo mediante una única función claramente definida:

def get_exchange_rate(currency):
    ...

El resto de la aplicación no necesita saber cómo funciona ese servicio.

Si más adelante cambias de proveedor, el resto del sistema puede permanecer intacto.

Compáralo con tener llamadas a la API repartidas por decenas de archivos.

Cambiar de proveedor se convierte en un proyecto enorme.

Por eso son importantes las interfaces pequeñas y los límites bien definidos.

El objetivo no es predecir todos los requisitos futuros.

Eso es imposible.

El objetivo es conseguir que los cambios razonables sean baratos.

El buen código no elimina los cambios. Hace que cambiar sea menos doloroso.

9. Optimiza el código pensando en la persona que vendrá después

Este puede ser el patrón más importante de todos.

Cuando escribes código, sabes lo que estabas pensando.

La siguiente persona que trabaje con ese código no lo sabe.

Puede encontrarse con una variable llamada:

x = d[a]

y tendrá que averiguar qué significa.

Compáralo con:

user_email = users[user_id]

La segunda versión comunica inmediatamente cuál es su propósito.

El mismo principio se aplica a los nombres de las funciones, los mensajes de error, la estructura de los módulos, los comentarios y la configuración.

Antes de terminar una funcionalidad, ahora intento hacerme estas preguntas:

¿Esto tendría sentido para alguien que no conoce mi forma de trabajar?

¿Los nombres son descriptivos?

¿La lógica poco habitual está explicada?

¿Los errores realmente proporcionan información útil?

¿La estructura es predecible?

El mejor código no siempre es el código más corto.

Muchas veces es el código que necesita menos explicaciones.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

OpenAI ha lanzado su nuevo modelo Astra.

Lo presentó con un anuncio de estética retro y muy centrado en las personas. En él se mostraba al modelo utilizando aplicaciones, incluso algunas tan complejas como Blender, y cambiando de contexto sobre la marcha para hacer cosas como pedir comida.

La presentación parecía sacada de una película sobre inteligencia artificial.

Y ya era hora.

Internet se llenó inmediatamente de anuncios diciendo que, finalmente, la AGI había llegado.

OpenAI necesitaba desesperadamente dirigirse a todo el mercado y no solamente a los desarrolladores.

Pero la parte de Astra relacionada con el desarrollo de software es mucho más interesante. Y ahí es donde quiero explicar por qué, de alguna manera, Astra acaba de matar al software y cómo, paradójicamente, también podría intentar revivirlo.

Sol, Astra

Sol era NUESTRA estrella.

Astra significa “todas las estrellas”.

Es difícil superar eso.

Per aspera, ad astra.

¡Hacia las estrellas!

Incluso los nombres sugieren que estamos hablando de otra magnitud.

Pero no se preocupen. Todavía pueden avanzar hacia una galaxia y después hacia algo todavía mayor.

¿GPT Universe, quizás?

El modelo destroza prácticamente todos los benchmarks y la gente comparte juegos 3D “impresionantes” programados con él en 30 minutos.

Pero esa no es la razón por la que el software se encuentra en una situación tan extraña.

En 2026 hemos llegado a un punto en el que tenemos más aplicaciones creadas que nunca y, al mismo tiempo, el mayor desinterés hacia el software nuevo.

El modelo SaaS basado en MRR está perdiendo fuerza a medida que cada vez más usuarios buscan alternativas de pago único.

En 2026, casi la mitad de los consumidores canceló al menos una suscripción.

En 2024 era aproximadamente un tercio.

El hogar promedio ahora administra 11 o más suscripciones y subestima su coste real aproximadamente 2,5 veces.

Mientras tanto, las compras únicas y las licencias de por vida pasaron de representar el 6,4 % al 10,3 % de los modelos de monetización de aplicaciones en apenas dos años.

Estamos en uno de los puntos más bajos.

¿La calidad se recuperará o continuará descendiendo?

No tengo idea.

Y luego tenemos el problema de la caída de calidad.

No estoy hablando de alguien que hace vibe coding un domingo por diversión.

Estoy hablando de grandes marcas, empresas respetadas, utilizando inteligencia artificial y entregando auténtica basura digital.

En algún momento, incluso el consumidor que no entiende de tecnología empieza a notar el deterioro.

Astra podría representar un punto de inflexión en todo esto, pero antes tenemos que revisar algunos ejemplos de cómo el software ha empezado a salir mal durante esta década.

SLOPware

El software se está convirtiendo progresivamente en slopware.

Poca supervisión.

Aceptar lo primero que entrega la inteligencia artificial simplemente porque parece suficientemente bueno.

Publicar más cosas, pero sin control, sin planificación y sin criterio.

Amazon

Amazon tuvo cuatro interrupciones de nivel Sev-1 en apenas una semana entre febrero y marzo de 2026.

Sus informes internos señalaban cambios de código “asistidos por IA” como una de las principales causas.

Una interrupción de seis horas les costó aproximadamente 6,3 millones de dólares en pedidos perdidos.

El problema se originó en un despliegue que llegó a producción sin aprobación y prácticamente sin documentación.

Sus propios informes internos describían literalmente estos cambios como modificaciones “asistidas por IA generativa” con un “alto radio de impacto”.

Microsoft

Microsoft quería convertir Windows en una especie de sistema operativo superpotenciado por inteligencia artificial.

El resultado vino acompañado de problemas molestos de rendimiento y una sensación general de falta de pulido.

Algo parecido a la época de Windows Vista.

Windows empieza a sentirse como una capa construida alrededor de funciones de inteligencia artificial que no siempre son necesarias, en lugar de sentirse simplemente como un buen sistema operativo.

Y en este caso ni siquiera estamos hablando necesariamente de inteligencia artificial escribiendo el código de Windows.

El problema tiene más que ver con construir toda la hoja de ruta del producto alrededor del entusiasmo generado por la IA, mientras que muchos usuarios normales utilizan la inteligencia artificial simplemente para buscar la mejor receta de tarta de queso.

Claude Code

Tres errores superpuestos provocaron que la calidad de las respuestas de Claude Code disminuyera durante aproximadamente seis semanas.

Usuarios avanzados cancelaron sus suscripciones.

Investigadores de seguridad publicaron análisis.

La gente se enfadó.

Sonos, antes de la IA

La reescritura de la aplicación de Sonos en 2024 llegó al mercado completamente rota.

Fueron necesarios aproximadamente doce meses de correcciones y decenas de millones de dólares para solucionar sus problemas.

Incluso acabaron reemplazando al CEO.

Muchos usuarios descontentos nunca regresaron a la marca.

Y esto demuestra algo importante:

La confianza no siempre regresa después de perderla debido a errores de baja calidad.

Instagram

Instagram es un enorme desastre.

Un desastre asistido por inteligencia artificial, por supuesto.

Y ni siquiera estoy hablando de los miles de litigios que Meta tiene abiertos.

Aquí tenemos un ejemplo particularmente absurdo.

Durante siete semanas, atacantes aprovecharon el asistente de soporte con IA de Meta para secuestrar cuentas de Instagram.

El método prácticamente no requería conocimientos técnicos.

Siete semanas.

Básicamente, alguien podía abrir un chat con el bot, pedirle que añadiera una nueva dirección de correo electrónico a la cuenta de otra persona, recibir un código de verificación en su propio correo, devolverle ese código al bot y obtener un botón para “Restablecer contraseña”.

Eso, por sí solo, ya supone un problema enorme para la reputación de una marca.

Después puedes añadir una larga lista de errores de interfaz, molestias y problemas de estabilidad.

Meta realmente se ha convertido en una compañía donde la inteligencia artificial parece estar primero en prácticamente todo.

YouTube

Mira cómo se comporta YouTube en un ordenador.

Hay problemas que aparecieron hace aproximadamente seis meses y todavía no han sido corregidos.

Algunos ocurren alrededor de la mitad de las veces.

Y, por supuesto, innumerables startups también publican productos incompletos y rotos.

Pero eso siempre ha sido bastante habitual.

Abundancia → fatiga

El vibe coding provocó un aumento del 84 % en el número de nuevas aplicaciones enviadas a la App Store de Apple durante un único trimestre.

Fue el mayor incremento registrado en una década.

Los tiempos de revisión llegaron en algunos casos hasta los 30 días.

Apple también empezó a eliminar lo que podríamos llamar aplicaciones basura o slop apps.

La mayoría de las aplicaciones creadas durante esta ola consiguieron descargas de un solo dígito.

Puedes construirlo.

Pero eso no significa que a alguien le importe.

Una publicación de Reddit resumía perfectamente la situación:

Mis usuarios totales son, aproximadamente, mi esposa y un tipo de Finlandia que sospecho que la descargó por accidente.

Eso es lo que ocurre cuando la sobreabundancia se encuentra con la sobreestimulación.

La curva de vulnerabilidades

El proyecto Vibe Security Radar de Georgia Tech detectó que las vulnerabilidades de software causadas directamente por programación con inteligencia artificial generativa pasaron de 6 en enero a 15 en febrero y posteriormente a 35 en marzo de 2026.

Publicar tantas cosas tan rápidamente también significa abrir más agujeros en todas partes.

La filtración de Tea

Los chistes prácticamente se escriben solos.

¿Recuerdas Tea?

La aplicación de seguridad exclusiva para mujeres.

Su backend era básicamente una base de datos pública de Firebase sin autenticación.

Se filtraron más de 70.000 imágenes, incluyendo escaneos de pasaportes.

Se convirtió rápidamente en uno de los principales ejemplos utilizados para defender la idea de que:

“Vibe coding = software inseguro”.

Los modelos actuales han mejorado en este sentido.

Pero sabes lo que ocurre.

Tú lo sabes.

Yo lo sé.

Vivimos dentro de nuestra propia burbuja tecnológica.

Convencer nuevamente a la población general, incluyendo a personas afectadas por incidentes como el de Tea, de que pueden confiar en un producto creado mediante vibe coding puede llevar años.

Una vez que las personas empiezan a identificar patrones asociados con productos de baja calidad, comienzan a reconocer esos mismos patrones en muchas otras cosas.

En ocasiones, incluso cuando no están realmente ahí.

El dilema del virtuoso

También existe otro problema: la percepción del esfuerzo.

Imagina a Les Claypool tocando el bajo.

Probablemente sea uno de los mejores bajistas del mundo.

Y cuando lo ves tocar, entiendes rápidamente por qué.

Para una persona normal, lo que hace representa maestría.

Al mismo tiempo, para muchas personas, un DJ extremadamente habilidoso simplemente está “reproduciendo música desde unos vinilos”.

No significa que el DJ no tenga talento.

Puede tener un nivel de creatividad y habilidad musical equivalente al de un virtuoso.

Pero simplemente la cantidad de “tecnología” que existe dentro de su configuración cambia la manera en que muchas personas perciben y comparan a esos dos músicos.

Eso mismo está empezando a ocurrir con la programación y el diseño.

Con el arte ya ha sucedido.

La gente empieza a reconocer el slop.

Empieza a identificar cosas que parecen hechas con poco esfuerzo.

Y en ocasiones percibe falta de esfuerzo incluso cuando realmente hubo muchísimo trabajo detrás.

Entonces, ¿se acabó el software?

¿O simplemente estamos alcanzando el punto máximo de la curva de degradación del software?

Ad Astra

Los modelos están mejorando.

Las personas con experiencia están creando cosas extraordinarias.

Y no, no estoy hablando de clones de GTA 6 creados mediante vibe coding en 30 minutos.

Un gran videojuego no se construirá de esa manera.

Pero Astra ha avanzado un paso más.

Puede probar el frontend y realizar sus propias comprobaciones de control de calidad.

En teoría, eso significa interfaces con menos errores.

Mayor calidad tanto en backend como en frontend.

Mejor seguridad.

Una calidad de código impresionante.

Incluso algunos desarrolladores extremadamente experimentados están sorprendidos por lo que pueden hacer actualmente estos agentes.

Pero aquí aparece algo bastante trágico.

Modelos como Mythos y Astra podrían ser una solución que llega ligeramente tarde.

Sería como reemplazar a un mal actor dentro de una obra de teatro por uno extraordinario cuando el público ya abandonó el teatro después de dejar críticas de una estrella.

Bien.

Sí.

Estoy siendo dramático para que continúes leyendo.

Me descubriste.

Ahora podemos volver a hablar en serio.

Todavía existe una audiencia.

Nosotros, los que vivimos dentro del mundo tecnológico, somos una audiencia que no está dispuesta a abandonar.

Pero eso no es suficiente.

Los laboratorios que desarrollan los modelos de inteligencia artificial más avanzados ya se han dado cuenta.

Y probablemente no estén demasiado contentos con que Susan, una abuela de 80 años, no esté haciendo vibe coding para crear sus propias aplicaciones y gastando enormes cantidades de tokens.

¿Por qué sigue utilizando la inteligencia artificial simplemente para investigar recetas de tarta de queso?

Recuperar la confianza de las personas que no pertenecen al mundo tecnológico llevará tiempo.

¿Tenemos tiempo?

No tengo idea.

La inteligencia artificial ya está empezando a comerse al SaaS.

Quizás ni siquiera exista tiempo suficiente para arreglar el modelo SaaS antes de que eso ocurra.

Estoy en contra y a favor de la IA al mismo tiempo

No me malinterpretes.

Programar con inteligencia artificial puede ser fascinante si entiendes de arquitectura de software.

Definitivamente PUEDES construir cosas.

Para ti mismo.

O para otras personas.

El problema es que el SaaS, especialmente cuando depende de precios mensuales, también está atravesando un momento complicado.

Las personas buscan alternativas más económicas o productos que puedan comprar mediante un único pago.

Hiperpersonalización

Estoy escribiendo esto en un MacBook de 12 pulgadas de 2017.

Instalé Omarchy Linux y el ordenador ha recuperado una nueva vida.

Ahora también es “agéntico”, con inteligencia artificial profundamente integrada dentro del sistema operativo.

¿Por qué es importante?

El MacBook tiene un trackpad bastante grande situado muy cerca del teclado.

Los deslizamientos accidentales movían el cursor mientras escribía y, ocasionalmente, terminaba escribiendo en mitad de una frase anterior.

Era extremadamente molesto.

Así que le pedí al agente que ARREGLARA EL SISTEMA OPERATIVO.

Y lo hizo.

Se acabaron los movimientos accidentales.

También creé algunos plugins para el sistema operativo con el objetivo de mejorar todavía más mi flujo de trabajo.

¿Ves?

La inteligencia artificial no es necesariamente mala.

El problema es que como sociedad tendemos a concentrarnos principalmente en los malos ejemplos porque los seres humanos recordamos mejor ese tipo de historias.

Yo mismo he construido productos utilizando inteligencia artificial.

Y quizás simplemente he tenido suerte, o quizás mi experiencia en diseño me ha ayudado a conseguir que las cosas que he creado realmente cumplan sus objetivos.

Algunas han tenido cientos de usuarios.

Otras, miles.

Pero esa NO es la situación habitual.

Además, reconozco que me encuentro en una posición privilegiada debido al alcance que ya tengo.

Per aspera

¿Salvará Astra al software?

¿O quizás lo hará el siguiente paso?

¿Galaxy?

No lo sabemos.

Todo está acelerándose extremadamente rápido.

¿Por qué ahora todo ocurre tan rápido?

En cierta medida, porque los laboratorios de inteligencia artificial necesitan enormes cantidades de dinero.

Las GPU que utilizan actualmente están envejeciendo y eventualmente deberán ser reemplazadas.

Los inversores empiezan a desconfiar de ciertos modelos de financiación circular y de la posibilidad de que exista una burbuja.

Pero aquí y ahora tenemos más software que nunca.

Y gran parte de él es simplemente malo.

Incluso cuando viene de marcas respetadas.

Puede que sea demasiado tarde para que los modelos consigan revertir esta tendencia de desconfianza.

La gente seguirá necesitando software.

Pero el mayor cambio no está ocurriendo dentro del código.

Está ocurriendo en la percepción pública sobre el buen gusto, el esfuerzo dedicado a crear algo y la atención a los detalles.

Y todavía no estoy seguro de que podamos colocar un signo de igualdad entre un gran bajista y un gran DJ.

Al menos no en la mente del público.

Las personas seguirán considerando que la artesanía, el cuidado y el trabajo bien hecho son cosas por las que vale la pena pagar.

El vibe coding todavía no está asociado con esa idea de artesanía.

Quizás algún día los modelos consigan resolver también esa parte.

Hasta ahora, todavía no lo han hecho.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Cada vez que inicias una nueva sesión con un asistente de programación con IA como Claude Code o Cursor, comienza una secuencia bastante predecible. Haces una pregunta sobre alguna funcionalidad y el agente entra en un ciclo frenético: ls, grep, read_file, repetir.

Está “explorando”.

Y tú estás pagando por cada token que consume mientras intenta descubrir dónde se encuentra la lógica de autenticación de tu proyecto.

Esta fase de descubrimiento es uno de los costes ocultos del desarrollo con agentes. Básicamente, estamos pidiéndole a una inteligencia de nivel extremadamente avanzado que se comporte como un bibliotecario que revisa todos los libros del edificio simplemente para encontrar el índice.

CodeGraph cambia por completo esta dinámica.

Al proporcionar un mapa estructural previamente indexado de tu base de código mediante un servidor Model Context Protocol (MCP), permite que los agentes se salten gran parte del proceso de búsqueda y vayan directamente a la respuesta.

En promedio, esto puede reducir las llamadas a herramientas en más de un 70 % y disminuir el consumo de tokens casi a la mitad.

La ingeniería detrás del grafo

CodeGraph es una herramienta técnicamente sofisticada, diseñada específicamente para ofrecer inteligencia de código de alto rendimiento.

1. El pipeline de análisis con Tree-Sitter

En el corazón de CodeGraph se encuentra el pipeline de análisis basado en Tree-Sitter.

A diferencia de las herramientas tradicionales de búsqueda basadas en expresiones regulares, CodeGraph utiliza un parser real basado en gramáticas para comprender con gran precisión los componentes fundamentales de tu código.

2. El puente de infraestructura MCP

CodeGraph se comunica con tu agente de IA mediante MCP.

Este protocolo funciona como un puente de infraestructura que estandariza la comunicación entre el agente y el grafo utilizando JSON-RPC.

3. El esquema de grafo optimizado en SQLite

Todos los datos y relaciones extraídos se almacenan en un esquema de grafo optimizado sobre SQLite, diseñado para realizar consultas de grafos de alto rendimiento directamente en tu máquina local.

Las ventajas principales: densidad de contexto y privacidad

Más allá de la velocidad, CodeGraph ofrece dos ventajas fundamentales que pueden convertirlo en una herramienta especialmente útil para el desarrollo profesional: densidad de contexto y privacidad.

Densidad de contexto: mejores datos con menos tokens

Los agentes de IA tradicionales suelen verse afectados por el llamado “context bloat” o saturación del contexto.

Esto ocurre cuando se introducen archivos grandes y desordenados dentro del contexto del modelo simplemente para encontrar una única función.

CodeGraph intenta resolver este problema ofreciendo una alta densidad de contexto.

En lugar de enviar archivos completos, extrae únicamente los símbolos relevantes y las relaciones existentes entre ellos, asegurando que el modelo reciba la mayor cantidad posible de información útil utilizando la menor cantidad posible de tokens.

Privacidad: tu código sigue siendo tuyo

En una época dominada por herramientas de inteligencia artificial basadas en la nube, la privacidad es un aspecto fundamental.

CodeGraph funciona completamente dentro de un entorno local de privacidad.

Tu código fuente y el grafo SQLite resultante nunca abandonan tu máquina.

El agente de IA realiza consultas al servidor local, evitando que tu propiedad intelectual tenga que exponerse a sistemas externos de indexación o entrenamiento.

Cómo funciona CodeGraph

La eficiencia de CodeGraph es el resultado de un pipeline interno preciso dividido en cuatro etapas, encargado de transformar código fuente sin procesar en un grafo de conocimiento optimizado para consultas de alto rendimiento.

Cómo empezar

¿Listo para convertir una carpeta en un grafo de conocimiento?

El proceso está diseñado para ser sencillo, local y extremadamente rápido.

1. Instalación

CodeGraph es una herramienta CLI ligera.

Puedes instalarla globalmente utilizando npm en apenas unos segundos:

npm install -g @colbymchenry/codegraph

2. Indexar tu base de código

Accede a la carpeta de tu proyecto y ejecuta el comando init.

CodeGraph analizará tus archivos, interpretará su estructura utilizando Tree-Sitter y construirá un grafo SQLite local.

codegraph init -i

3. Conectar tu agente de IA

Una vez que el proyecto esté indexado, puedes conectar tu asistente de programación con IA favorito, como Claude Code o Cursor, mediante el puente MCP.

Esto permite que el agente consulte directamente el grafo y evite gran parte de la costosa fase inicial de exploración.

codegraph install

Flujo de trabajo colaborativo: desarrollador, agente y grafo

El verdadero potencial de CodeGraph aparece dentro de un flujo de trabajo colaborativo.

El desarrollador aporta la intención.

El agente de IA aporta el razonamiento.

Y CodeGraph proporciona el mapa estructural.

Este flujo circular permite que cada solución se base en la realidad concreta de la base de código.

El panorama de la inteligencia basada en agentes: CodeGraph frente al resto

Aunque CodeGraph es una herramienta potente para crear mapas estructurales del código, forma parte de un ecosistema más amplio de herramientas diseñadas para hacer que los agentes de IA sean más inteligentes.

El flujo completo de CodeGraph

Todo el flujo de trabajo de CodeGraph está diseñado para ejecutarse de forma local, privada y perfectamente integrada con los asistentes de programación con IA que ya utilizas.

Al mapear los símbolos y las relaciones existentes entre ellos, CodeGraph proporciona una comprensión profunda de la arquitectura del proyecto, permitiendo que tu agente de IA pueda actuar con mucha más precisión.

Gracias a su “Toolkit” especializado de comandos MCP, el agente puede navegar por bases de código complejas y realizar análisis de “Blast Radius”, o radio de impacto, para identificar dependencias antes de que se conviertan en problemas.

Conclusiones

CodeGraph es una herramienta interesante para abordar el desarrollo asistido por inteligencia artificial.

Cuando los agentes de IA dedican tiempo y recursos valiosos a “explorar” tu base de código, ese proceso termina costándote dinero.

CodeGraph intenta solucionar este problema proporcionando a los agentes un mapa preciso y previamente indexado, transformándolos de bibliotecarios digitales en solucionadores de problemas mucho más eficientes.

Puedes considerar CodeGraph como un componente importante dentro de tu stack de agentes.

Mientras herramientas como Graphify destacan a la hora de extraer significado semántico y lat.md ayuda a gestionar la intención, CodeGraph proporciona el mapa estructural fundamental de tu base de código.

En conjunto, estas herramientas pueden crear una combinación muy potente, permitiendo que los agentes de IA trabajen con un nivel de precisión y eficiencia mucho mayor.

La filosofía central es sencilla:

Una de las cosas más costosas que puede hacer un agente de IA es “mirar alrededor”. CodeGraph le entrega un mapa para que pueda simplemente “mirar donde debe”.

Esto permite aprovechar mucho mejor el potencial real de la inteligencia artificial basada en agentes, convirtiéndola en un compañero más fluido e inteligente dentro de tu flujo de trabajo de desarrollo.

Gracias por leer.

Nos vemos en el próximo.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Hace unas semanas me di cuenta de que había desarrollado un talento muy específico.

Podía desbloquear mi teléfono simplemente para consultar el clima y, de alguna manera, terminar viendo a alguien reorganizar su despensa, hacer una reseña de los baños de un aeropuerto o explicar por qué levantarse exactamente a las 4:37 de la mañana era, aparentemente, el secreto del éxito.

Al principio era una sesión inocente de veinte minutos.

Después fueron cuarenta.

Y luego tres horas.

Lo peor no era que estuviera perdiendo el tiempo.

Lo peor era que ya ni siquiera lo estaba disfrutando.

Terminaba con dolor de cabeza, pero aun así parecía incapaz de detenerme.

Como alguien que realmente disfruta de Internet, darme cuenta de esto me sorprendió.

Me encanta descubrir cosas interesantes.

Me gusta leer datos completamente aleatorios.

Puedo pasar tranquilamente una hora investigando por qué los pulpos tienen tres corazones o cómo organizaban sus libros las bibliotecas antiguas.

Sin embargo, en algún momento Internet terminó convirtiéndose en algo parecido a esto:

Tres aplicaciones.

Incluso los libros dejaron de ser una solución definitiva.

Terminaba un capítulo, me sentía completamente relajado y, casi inmediatamente después, tomaba el teléfono pensando:

“Solo un minuto”.

Ya sabes cómo termina esa historia.

Así que, en lugar de intentar utilizar menos Internet, decidí intentar utilizarlo de una manera diferente.

Durante los últimos meses he ido guardando sitios web que despiertan mi curiosidad en lugar de dejarme agotado.

Lugares que me permiten aprender algo, reírme de algo o simplemente recordar que Internet todavía está lleno de sorpresas increíbles.

Estos son algunos de ellos.

1. Radio Garden

La primera vez que abrí Radio Garden, realmente pensaba quedarme cinco minutos.

Una hora después ya había escuchado jazz desde Nueva Orleans, una pequeña estación de radio en Islandia y un programa matutino en algún lugar de Japón que no entendía en absoluto, pero que de alguna manera seguía disfrutando.

La idea es maravillosamente sencilla.

Aparece un globo terráqueo digital.

Lo haces girar.

Seleccionas prácticamente cualquier lugar del planeta.

Y puedes escuchar inmediatamente estaciones de radio que están transmitiendo en directo desde esa zona.

Resulta extrañamente reconfortante.

A veces dejo alguna estación reproduciéndose suavemente mientras preparo café y, durante unos minutos, mi cocina parece estar conectada con algún lugar situado a miles de kilómetros.

2. Window Swap

Si las redes sociales muestran las versiones cuidadosamente editadas de la vida de otras personas, Window Swap ofrece algo bastante diferente.

Muestra la realidad.

Personas de todo el mundo envían videos grabados desde sus ventanas.

Algunas tienen vistas a calles llenas de actividad.

Otras muestran bosques, playas, tejados bajo la lluvia o barrios completamente tranquilos.

No sé exactamente por qué observar el martes lluvioso de otra persona puede resultar tan relajante.

Tal vez sea porque, en una época dominada por el consumo y por plataformas que constantemente intentan captar nuestra atención, resulta agradable encontrar un sitio que simplemente muestra una ventana.

Nada más.

Y, curiosamente, eso es suficiente.

3. Earth.fm

Cuando siento que mi cerebro tiene cuarenta pestañas abiertas al mismo tiempo, suelo visitar Earth.fm.

Es una colección de grabaciones de sonidos naturales procedentes de bosques, ríos, playas, montañas y parques nacionales de diferentes lugares del mundo.

No hay discursos motivacionales.

No hay trucos de productividad.

Solo pájaros.

Viento.

Lluvia.

A menudo lo utilizo como sonido de fondo mientras leo y realmente me ayuda a concentrarme en un libro en lugar de sentir la necesidad de revisar mi teléfono cada diez minutos.

4. Internet Archive

Llamar a Internet Archive simplemente “un sitio web” probablemente sea quedarse corto.

Se parece más a un enorme museo digital.

Puedes consultar libros, explorar revistas antiguas, ver películas clásicas, escuchar música e incluso visitar versiones archivadas de sitios web que desaparecieron hace muchos años.

Cada vez que entro termino descubriendo algo que originalmente ni siquiera estaba buscando.

Es uno de esos agujeros de conejo de Internet en los que puedes perderte durante horas.

Pero existe una diferencia importante.

Cuando sales, normalmente sientes que aprendiste algo en lugar de preguntarte por qué acabas de perder dos horas de tu vida.

5. Atlas Obscura

La mayoría de los sitios de viajes te enseñan los lugares que visita todo el mundo.

Atlas Obscura hace prácticamente lo contrario.

Te muestra los lugares a los que casi nadie va.

Puedes encontrar túneles secretos, museos diminutos, castillos abandonados, monumentos extraños y bibliotecas escondidas dentro de antiguos monasterios.

Incluso si no estás planeando ningún viaje, es muy fácil terminar leyendo durante mucho tiempo sobre lugares extraordinarios que existen en diferentes rincones del planeta.

Uno de esos ejemplos es el Osario de Sedlec, en República Checa.

Se trata de una pequeña capilla cuya decoración interior utiliza los restos de decenas de miles de esqueletos humanos.

Es inquietante.

Extraño.

Y, precisamente por eso, resulta difícil dejar de leer sobre lugares así.

6. GeoGuessr

Este puede ser peligroso.

GeoGuessr te coloca en algún lugar del mundo utilizando imágenes similares a las de Google Street View.

Tu misión es descubrir dónde estás.

Al principio probablemente adivines completamente al azar.

Pero después empiezas a prestar atención.

Señales de tráfico.

Idiomas.

Matrículas.

Vegetación.

Arquitectura.

Carreteras.

La forma de las montañas.

Pequeños detalles que inicialmente ignorabas empiezan a convertirse en pistas.

Y sin darte cuenta terminas aprendiendo geografía mientras intentas ganar una partida.

7. Quick, Draw!

Antes de abrir Quick, Draw!, quizá tengas demasiada confianza en tus capacidades artísticas.

Eso puede cambiar rápidamente.

Por suerte, dibujar bien no es realmente necesario.

Esa es precisamente parte de la gracia.

La inteligencia artificial de Google te propone diferentes objetos y tienes veinte segundos para dibujarlos mientras el sistema intenta descubrir qué estás haciendo.

Puede pedirte que dibujes un gato.

Una bicicleta.

Una taza.

Un avión.

Tú intentas representarlo lo mejor posible mientras la inteligencia artificial empieza a lanzar hipótesis.

Es caótico.

Es divertido.

Y puede resultar sorprendentemente adictivo.

8. Neal.fun

Si existe un sitio que conserva gran parte de aquello que hacía tan divertido al Internet de hace años, probablemente sea Neal.fun.

Cada página parece surgir de una idea extraña que alguien tuvo y simplemente decidió convertir en realidad.

Puedes gastar virtualmente la fortuna de una persona extremadamente rica.

Explorar las partes más profundas del océano.

Comparar el tamaño de diferentes planetas.

Descubrir acontecimientos históricos extraños.

Experimentar con escalas difíciles de imaginar.

Y entrar en pequeñas experiencias interactivas que no parecen existir por ningún motivo particular más allá de ser interesantes.

Es muy fácil entrar pensando que vas a permanecer cinco minutos y descubrir una hora después que todavía sigues allí.

9. Little Alchemy 2

El concepto no podría ser más sencillo.

Empiezas con cuatro elementos básicos.

Los combinas.

Y observas qué ocurre.

A partir de esas combinaciones comienzan a aparecer nuevos elementos que, a su vez, puedes volver a mezclar.

Varias horas después puedes terminar creando dinosaurios, planetas, robots y toda clase de cosas que jamás imaginabas cuando comenzaste la partida.

Little Alchemy 2 es uno de esos juegos que recuerdan lo satisfactoria que puede ser la curiosidad cuando simplemente te permites experimentar.

No necesitas ganar nada.

No necesitas completar una misión importante.

Simplemente pruebas cosas para descubrir qué sucede.

10. The Useless Web

Un botón.

Un clic.

Un sitio web completamente aleatorio.

Esa es prácticamente toda la idea detrás de The Useless Web.

Presionas un botón y el sistema te envía a algún rincón extraño de Internet.

Algunos sitios son ridículos.

Otros son sorprendentemente ingeniosos.

Y algunos no tienen absolutamente ningún sentido.

Pero precisamente ahí está parte de la diversión.

Te recuerda una época en la que Internet estaba lleno de personas que construían pequeñas cosas extrañas simplemente porque podían hacerlo.

Sin estrategias de crecimiento.

Sin embudos.

Sin intentar convertir cada interacción en una compra.

Alguien simplemente tenía una idea absurda y decidía crearla.

Quizás Internet necesite un poco más de eso.

El problema no es necesariamente que seamos flojos

No creo que el doomscrolling ocurra simplemente porque somos perezosos o porque nos falta fuerza de voluntad.

Creo que ocurre, en gran medida, porque los algoritmos han conseguido que la opción más fácil parezca también la única opción.

Abres el teléfono.

Instagram.

Reddit.

TikTok.

YouTube.

X.

Deslizas.

Sigues deslizando.

Y veinte minutos después ni siquiera recuerdas exactamente qué acabas de ver.

Pero Internet sigue siendo enorme.

Sigue estando lleno de personas construyendo cosas hermosas.

Cosas inteligentes.

Educativas.

Creativas.

Extrañas.

Y maravillosamente inútiles.

El problema es que muchas veces esas cosas ya no aparecen automáticamente frente a nosotros.

Tenemos que buscarlas.

Cambiar el doomscrolling por curiosidad

La próxima vez que tu pulgar abra automáticamente una red social, puedes probar algo diferente.

Escuchar una estación de radio situada al otro lado del planeta.

Mirar durante unos minutos por la ventana de alguien que vive en Noruega.

Escuchar la lluvia de un bosque.

Explorar un archivo digital de hace cincuenta años.

Intentar descubrir en qué país estás observando simplemente las señales de tráfico.

Crear un dinosaurio combinando elementos.

O entrar en algún sitio completamente absurdo construido por una persona que probablemente un día pensó:

“Esto sería divertido”.

Puede que también termines perdiendo una hora.

Pero existe una diferencia.

Probablemente termines esa hora habiendo aprendido algo, habiendo descubierto algo o simplemente sonriendo.

Y eso recuerda algo importante:

Internet no se convirtió en aburrido.

Simplemente dejamos que los algoritmos decidieran qué parte de Internet veíamos.

Todavía existe una web enorme, extraña, educativa y fascinante más allá del scroll infinito.

Solo tenemos que volver a explorarla.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Durante la mayor parte de mi vida pensé que el objetivo era conseguir un buen empleo.

Entrar en la escalera profesional. Mantenerme leal. Conseguir un ascenso si trabajaba lo suficiente. Construir una pensión durante el proceso. Y, finalmente, jubilarme con una cantidad de dinero razonable.

Justo antes de conseguir el “trabajo correcto”, cambié de opinión.

Las personas más cercanas a mí se sorprendieron.

Decidí “convertirme en un producto”.

Tomé esa decisión después de una conversación difícil con algunos amigos que estaban varios pasos por delante de mí. Resultó que esa mentalidad de “subir la escalera” no había funcionado para ellos como esperaban.

Así que asumí un riesgo calculado y decidí elegirme a mí mismo.

También hubo una reflexión de Thomas Merton que me hizo pensar. Dijo:

“Las personas pueden pasar toda su vida subiendo la escalera del éxito, solo para descubrir, cuando llegan arriba, que la escalera estaba apoyada contra la pared equivocada.”

Me aterraba la idea de terminar en la “pared equivocada”.

La carrera profesional, tal como la conocemos, está desapareciendo

Ve a la escuela.

Consigue un empleo estable.

Sube por la escalera profesional.

Y después jubílate cómodamente.

Ese modelo tenía sentido cuando la riqueza provenía principalmente del trabajo.

Pero para muchas personas ya no está funcionando.

Y ahora, todavía menos.

La lógica que mantenía unido ese sistema está empezando a desmoronarse.

El techo está fijado.

Y muchas de las opciones no están bajo tu control.

Tienes 24 horas.

Un cuerpo.

Un empleo.

Por mucho que trabajaras, no podías multiplicarte.

Tu jefe lo sabía.

El sistema lo sabía.

Y utilizaba ese conocimiento para mantener los salarios predecibles y tus opciones limitadas.

Tu capacidad de apalancamiento era prácticamente cero.

Pero algo cambió.

Las puertas se abrieron y la mayoría de las personas no se dio cuenta

La tecnología no solo cambió lo que hacemos.

Cambió las reglas físicas del trabajo.

Por primera vez en la historia, una persona con una computadora portátil puede llegar a millones de personas, construir un producto que sigue funcionando mientras duerme o escribir algo capaz de cambiar la manera en la que un desconocido piensa sobre su propia vida.

Eso era nuevo.

Pero las personas acostumbradas a depender exclusivamente de un salario no prestaron demasiada atención.

De repente tenían un nivel de apalancamiento que no había existido para la mayoría de las personas una generación atrás.

Pero ¿por qué iban a elegir un camino con poca o ninguna certeza?

Avancemos hasta hoy.

Ahora mismo.

La tecnología tiene inteligencia

Y una gran parte de ella todavía es gratuita.

Balaji tenía razón:

“La tecnología es la fuerza impulsora de la historia. Estar en contra de la tecnología es estar en el lado equivocado de la historia. No puedes volver a meter al genio dentro de la botella.”

Hoy puedes escribir algo una sola vez y llegar a personas al otro lado del océano.

Puedes construir una aplicación una vez y venderla indefinidamente.

Puedes grabar una clase y despertarte al día siguiente con ventas.

Pero muchas personas siguen limitándose a intercambiar tiempo por dinero.

Siguen jugando con reglas que antes eran inevitables.

Pero ya no lo son.

Warren Buffett dijo:

“Si no encuentras una manera de ganar dinero mientras duermes, trabajarás hasta que mueras.”

Hoy también puedes poseer capital.

Dinero que trabaja mientras tú descansas.

Y eso ya no está reservado exclusivamente para las personas ricas.

El acceso al capital, incluso en cantidades pequeñas, se ha ampliado a través de fondos indexados, activos digitales y plataformas de microinversión.

El capital puede seguir creciendo incluso cuando no lo estás observando.

Sin embargo, muchas personas siguen sin aprovecharlo.

Pero hay más.

También existe el código

Un producto que construyes una sola vez puede escalar con muy poco esfuerzo adicional.

Una aplicación.

Una plantilla.

Una herramienta.

La construyes un martes a las dos de la madrugada.

Después la lanzas.

La colocas frente a usuarios reales y empiezas a recibir feedback.

En manos de los usuarios adecuados, puede empezar a propagarse por sí sola mientras duermes.

También existen los medios.

Ideas capaces de difundirse prácticamente sin límite.

Un newsletter.

Un canal de video.

Un hilo que las personas empiezan a compartir.

Las palabras y las ideas no se cansan.

No piden que les pagues horas extra.

Podrías empezar a crear apalancamiento mediante contenido ahora mismo.

Las barreras de entrada son prácticamente inexistentes.

El apalancamiento está disponible para personas comunes de una manera que simplemente no existía antes.

Y si todavía estás intercambiando exclusivamente tu tiempo por dinero, quizá sea momento de replantearte tu manera de trabajar y de vivir.

Yo he invertido en las tres cosas.

Capital.

Código.

Medios.

La diversificación ha sido, desde el principio, la estrategia que mejor me ha funcionado.

Tú eres el producto

Conviértete en un producto.

Un empleo te paga por tus horas.

Un producto te paga por el valor que genera.

Naval dijo una vez:

“Si tuviera que resumir cómo tener éxito en la vida en dos palabras, simplemente diría: conviértete en un producto.”

Eso significa tratar tus conocimientos, tu perspectiva y tus habilidades como algo que puedes empaquetar, distribuir y escalar.

Significa convertir lo que sabes en algo capaz de funcionar sin que tengas que estar permanentemente a su lado.

Un curso.

Una herramienta.

Un libro.

Un newsletter.

Una aplicación de nicho.

Una metodología.

Algo específico.

Algo útil.

No tienes por qué alquilar tu tiempo a un solo empleador a la vez.

Si has pasado años volviéndote bueno en algo, entendiendo determinado problema o viendo patrones que otras personas no detectan, ese conocimiento no tiene por qué ser útil únicamente dentro de una empresa.

Eso es algo.

Y las cosas pueden empaquetarse.

El conocimiento puede convertirse en un producto

Un consultor que trabaja exclusivamente con clientes uno a uno sigue intercambiando tiempo por dinero.

Pero ¿qué ocurre cuando ese consultor convierte su metodología en un curso?

¿O en un libro?

¿O en un sistema que otras personas pueden utilizar bajo licencia?

Eso es convertir el conocimiento en un producto.

No significa necesariamente trabajar más.

Significa cambiar la manera en la que tu conocimiento se distribuye por el mundo.

Tampoco necesitas empezar a lo grande.

Ni tienes que abandonar tu empleo para comenzar a convertir tus conocimientos en productos.

Una profesora podría empezar escribiendo un correo semanal sobre estrategias de aprendizaje.

Dos años después podría tener 5.000 suscriptores y una pequeña comunidad de pago.

Seguiría siendo profesora.

Pero también tendría algo que construyó ella misma.

Algo cuya existencia no depende de que esté físicamente dentro de un aula a las ocho de la mañana.

El verdadero problema: encontrar tu conocimiento específico

La parte más difícil para muchas personas es descubrir qué conocimiento específico pueden convertir en producto.

Naval dice:

“El conocimiento específico se encuentra persiguiendo tu curiosidad y tu pasión genuinas, en lugar de perseguir aquello que está de moda en este momento.”

Y también dijo:

“Nadie puede competir contigo en ser tú, y gran parte de la vida consiste en buscar quién y qué necesita más aquello que tú eres.”

Tu conocimiento específico es aquello que sabes y que no resulta sencillo enseñar mediante una capacitación convencional.

Está relacionado con tu curiosidad genuina.

Con combinaciones inusuales de intereses.

Con tus obsesiones extrañas.

El conocimiento específico normalmente no se parece a la descripción de un puesto de trabajo.

Se parece a ti.

Puede ser la persona obsesionada tanto con la economía conductual como con el diseño y que empieza a descubrir conexiones que nadie más observa.

Puede ser una antigua enfermera que entiende el sistema sanitario desde dentro y comienza a escribir sobre sus experiencias personales y las lecciones que pueden resultar útiles para cualquier persona.

Puede ser un historiador aficionado que explica la historia de una manera que hace que la gente realmente quiera prestarle atención.

El conocimiento específico también puede esconderse dentro de tus propias frustraciones.

Dentro de aquello que has vivido.

De ahí suelen surgir muchas ideas de producto.

Es difícil externalizar ese conocimiento porque está construido sobre tus intereses, tus experiencias y tus combinaciones particulares.

Tú más programación.

Tú más escritura.

La combinación importa.

Las habilidades genéricas compiten

El conocimiento específico se acumula.

La palabra más importante aquí es genuino.

¿Qué es aquello que realmente te entusiasma?

No lo que está de moda.

No aquello que otra persona te dijo que sería valioso.

Sino eso que harías feliz incluso aunque nadie te pagara por hacerlo.

Existe una forma más concreta de encontrarlo.

Pregúntate:

¿Sobre qué cosas las personas suelen pedirte opinión?

¿Qué sabes tú que te parece completamente obvio, pero que parece confundir a prácticamente todos los demás?

Ese espacio entre lo que resulta evidente para ti y lo que permanece invisible para otras personas puede ser tu conocimiento específico.

Empieza a prestar atención a lo que sabes.

Y mejor todavía:

Conviértelo en un producto y haz que se convierta en otra opción profesional para ti.

Los resultados no aparecen al principio

Naval también dijo:

“Todos los retornos de la vida —ya sea en riqueza, relaciones o conocimiento— provienen del interés compuesto.”

Eso significa participar en juegos que puedan repetirse.

Ser constante con aquello que comienzas.

Permitir que las cosas se construyan unas sobre otras.

Una sola edición de un newsletter probablemente no tenga demasiado valor.

Pero 200 ediciones publicadas durante tres años pueden acumular confianza y construir una audiencia.

Conviértelo en un juego infinito.

El interés compuesto solamente funciona si permaneces dentro del juego.

Cuando conviertes tu conocimiento en productos estás construyendo activos.

Los activos se acumulan.

Las habilidades se acumulan.

La audiencia también.

Y la reputación.

Año tras año.

No estás intentando ganar una sola vez.

Estás intentando permanecer en el juego el tiempo suficiente para que el interés compuesto pueda hacer su trabajo.

La mayoría de las personas abandona demasiado pronto

Prueban algo durante seis meses.

Obtienen resultados modestos.

Y concluyen que estaban equivocadas.

Pero durante los primeros meses el crecimiento compuesto prácticamente no se nota.

La curva permanece plana.

Plana.

Plana.

Y entonces empieza a doblarse.

Esta es también la razón por la que perseguir “lo que está de moda ahora” puede convertirse en una trampa.

Cuando algo ya es evidentemente popular, las posiciones más fuertes probablemente ya han sido ocupadas.

La persona que comenzó a seguir su interés genuino hace tres años ahora tiene tres años de ventaja.

Y eso es extremadamente difícil de alcanzar.

El objetivo es la libertad

La libertad de trabajar en cosas que realmente reflejen quién eres.

No necesitar permiso externo para dedicarte a aquello que consideras importante.

Diseñar tu trabajo alrededor de tu vida, en lugar de diseñar tu vida alrededor del trabajo.

La riqueza, si llega, es una consecuencia secundaria de esa alineación.

Surge de convertirte de una manera tan auténtica en ti mismo, tan específico, tan curioso y tan constante, que eventualmente el mundo comienza a prestar atención.

Eso es lo que buscas.

Pasar de empleado a propietario.

De reemplazable a difícil de sustituir.

De alquilar tu tiempo a construir cosas.

Hoy tienes apalancamiento.

Y tienes suficiente tecnología disponible como para empezar a experimentar.

No ignores lo que sabes.

No ignores aquello que has aprendido.

No ignores las cosas que para ti parecen evidentes.

Elige un medio y empieza a experimentar.

Escribe.

Graba.

Enseña.

Construye.

Diseña.

Crea.

Haz cosas capaces de escalar más allá de ti.

Encontrarás tu voz utilizándola.

No tienes que sentirte preparado

Piensa en años, no en meses.

La mayoría de las cosas importantes tardan más de lo que nos resulta cómodo aceptar.

Dale tiempo a tu trabajo para crecer mediante el efecto compuesto.

Y recuerda:

El objetivo es hacer un trabajo que realmente sientas como tuyo.

El objetivo es la libertad.

Libertad significa poder decidir cómo quieres utilizar una tarde cualquiera de martes.

Significa no necesitar permiso para tomarte una semana libre.

Libertad también significa que tu trabajo refleja tu manera de pensar y no solamente aquello que otra persona necesita que hagas.

Significa sustituir la dirección externa por dirección interna.

Me gusta algo que dijo Seth Godin:

“En lugar de preguntarte cuándo serán tus próximas vacaciones, quizá deberías construir una vida de la que no necesites escapar.”

No estás haciendo esto para escapar del trabajo.

Todos tenemos que trabajar.

Pero si consigues hacerlo desde la perspectiva de tu conocimiento específico, puedes encontrar algo que realmente despierte una energía diferente dentro de ti.

Eso es lo que buscas.

La transición del trabajo al apalancamiento.

De tener simplemente un empleo a convertirte en una persona que ha construido algo.

Bajo tus propias condiciones.

La pregunta no es quién va a permitirte hacerlo.

La pregunta es:

¿Quién va a detenerte?

El conocimiento específico es el que genera los mejores intereses.

No necesitas dejar tu trabajo

Pero sí puedes comenzar tu propio experimento de apalancamiento.

Elige un área que despierte una curiosidad genuina en ti.

Trabaja sobre aquello que sabes y sobre aquello que descubres públicamente.

Convierte ideas útiles en pequeños productos.

Repite.

Empieza con algo pequeño.

Una guía breve.

Un newsletter de nicho.

Una herramienta sencilla que resuelva un único problema molesto.

No estás intentando hacerte famoso.

Estás intentando crear apalancamiento.

El mercado laboral seguirá cambiando.

Ahora mismo muchas personas están aterradas ante la posibilidad de perder sus empleos debido a la inteligencia del software.

Algunos puestos desaparecerán.

Los nombres de los cargos cambiarán.

Pero si posees conocimiento específico y sabes cómo empaquetarlo, ya no eres simplemente alguien empleable.

Eres independiente.

Y tienes mucho más control sobre la dirección de tu vida y de tu carrera.

Como dice Naval:

“Gana dinero con tu mente, no con tu tiempo.”

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Tres años construyendo una arquitectura limpia, rutas bien nombradas y un manejo sólido de errores… y, mientras tanto, los tiempos de respuesta estaban perjudicando silenciosamente la experiencia de usuario.

No era por una mala lógica.

No era por una base de datos lenta.

Era por JSON.

Todo salió a la luz durante una reunión de seguimiento un lunes.

El problema estaba en mis propias suposiciones.

Ese fin de semana me costó varias horas de sueño. Pero también cambió para siempre mi forma de pensar sobre el rendimiento.

TL;DR — Qué encontrarás en este artículo

Usa JSON en los límites públicos de tu sistema.

Para todo lo demás, cuando son máquinas comunicándose con máquinas, considera utilizar estos formatos.

El problema del que casi nadie habla

JSON es cómodo.

Es legible.

A la consola de tu navegador le encanta.

Tus compañeras y compañeros pueden abrirlo en el Bloc de notas y entender perfectamente lo que están viendo.

Pero esa comodidad tiene un precio.

En producción puedes estar haciendo esto miles de veces por segundo y asumir que está bien.

Y no siempre está bien.

Aquí tienes un dato real de uno de mis servicios:

Un payload con 10.000 registros de usuarios en JSON pesaba 2,3 MB y tardaba aproximadamente 180 ms en serializarse.

¿Los mismos datos utilizando un formato binario?

620 KB y aproximadamente 34 ms.

Los mismos datos.

Casi 5 veces más rápido.

Déjame enseñarte qué empecé a utilizar.

1. Protocol Buffers (Protobuf)

Google utilizó Protobuf internamente durante años antes de convertirlo en código abierto.

La idea es sencilla: defines una vez el esquema de tus datos en un archivo .proto, y la biblioteca se encarga de codificar y decodificar la información utilizando un formato binario muy compacto.

// user.proto
syntax = "proto3";

message User {
  int32 id    = 1;
  string name  = 2;
  string email = 3;
}

Después puedes codificar y decodificar los datos en Node.js:

const protobuf = require('protobufjs');

async function run() {
  const root = await protobuf.load('user.proto');
  const User = root.lookupType('User');
  const msg = User.create({ id: 1, name: 'Arjun', email: 'a@dev.io' });
  const buf = User.encode(msg).finish();   // buffer binario
  const decoded = User.decode(buf);        // vuelve a convertirse en objeto
}

Los números de los campos —1, 2 y 3— son lo que realmente se transmite.

No se transmiten los nombres de los campos.

Por ejemplo, "name" como cadena de texto ocupa 4 bytes cada vez que aparece en JSON.

En Protobuf, como etiqueta de campo, puede ocupar solo 1 byte.

Ahora multiplica esa diferencia por un millón de solicitudes al día.

Esto ya no es una microoptimización.

Estamos hablando de una reducción real de los costes de infraestructura.

Ideal para: comunicación interna entre servicios, APIs gRPC y pipelines de datos con un gran volumen de tráfico.

2. MessagePack

Piensa en MessagePack como si JSON hubiera empezado a ir al gimnasio.

Sigue siendo un formato basado en pares clave-valor.

Admite prácticamente los mismos tipos de datos.

Pero, en lugar de utilizar texto, codifica todo en binario.

Y no necesita un esquema.

Eso significa que puedes tomar los objetos JSON que ya utilizas y empezar a serializarlos con MessagePack prácticamente hoy mismo, con un esfuerzo de migración mínimo.

De hecho, esta fue la primera opción que probé.

Y, sinceramente, lo hice porque no tenía paciencia para ponerme a escribir esquemas .proto.

En una sola tarde cambié los payloads de nuestros WebSockets de JSON a MessagePack.

El tamaño de los payloads se redujo un 38 %, sin modificar una sola línea de la lógica de negocio.

const msgpack = require('@msgpack/msgpack');

const data = { id: 1, name: 'Arjun', score: 98.5 };
const encoded = msgpack.encode(data);    // Uint8Array, ~20 bytes
const decoded = msgpack.decode(encoded); // vuelve a ser un objeto normal

Compáralo con:

JSON.stringify(data)

que genera:

{"id":1,"name":"Arjun","score":98.5}

Son aproximadamente 37 caracteres, 37 bytes en ASCII.

MessagePack gana en tamaño porque puede utilizar un solo byte para representar valores comunes como números enteros pequeños, booleanos o null, en lugar de utilizar las representaciones completas en texto que necesita JSON.

Pero hay una contrapartida.

Pierdes la facilidad de lectura para una persona.

Por eso, antes de hacer el cambio, asegúrate de que tus sistemas de logging y debugging pueden trabajar correctamente con datos binarios.

Ideal para: payloads de WebSocket, caché en Redis y, en general, cualquier escenario donde controles ambos extremos de la comunicación.

Arquitectura: dónde encajan estos formatos

Este fue el modelo mental que hizo que todo encajara para mí.

El formato que utilizas debería depender de quién va a leer esos datos:

¿una persona o una máquina?

Aplicación cliente
     |
     |  (REST/HTTP — JSON está bien aquí, las personas pueden depurarlo)
     v
 API Gateway
     |
     |  (MessagePack o Protobuf — solo máquinas)
     v
 Servicio A ------> Servicio B ------> Servicio C
     |                                    |
     |  (Avro — streaming de eventos)     |
     v                                    v
 Kafka / Redpanda               Caché (MessagePack)

El límite importa.

Las APIs públicas necesitan ser fáciles de leer.

Las comunicaciones internas necesitan velocidad.

Muchos equipos utilizan JSON absolutamente para todo y después se preguntan por qué determinados procesos son lentos.

En ocasiones, la respuesta está literalmente delante de nosotros:

en la cabecera Content-Type.

3. Apache Avro

Avro es prácticamente el formato que Kafka espera silenciosamente que utilices, aunque nadie te lo haya explicado cuando configuraste tu pipeline.

Al igual que Protobuf, está basado en esquemas.

Pero Avro permite trabajar con el esquema junto con los datos, lo que lo convierte en una opción especialmente interesante para sistemas de streaming de eventos donde el esquema va evolucionando con el tiempo.

Imagina que un consumidor necesita leer eventos generados hace seis meses.

La semana pasada añadiste tres campos nuevos.

Ese consumidor debería seguir funcionando.

Avro está diseñado precisamente para manejar este tipo de evolución de esquemas de forma elegante.

const avro = require('avsc');

const UserEvent = avro.Type.forSchema({
  type: 'record',
  name: 'UserEvent',
  fields: [
    { name: 'id',    type: 'int' },
    { name: 'event', type: 'string' },
    { name: 'ts',    type: 'long' }
  ]
});

const buf = UserEvent.toBuffer({
  id: 42,
  event: 'login',
  ts: Date.now()
});

const obj = UserEvent.fromBuffer(buf);

Después de migrar nuestro bus interno de eventos a Avro, el retraso de los consumidores de Kafka pasó de 40 segundos en momentos de carga máxima a menos de 4 segundos.

Mismo hardware.

Mismas particiones del topic.

Lo único que cambió fue el formato utilizado para transmitir los datos.

La integración con registros de esquemas —ya sea utilizando Confluent o AWS Glue— hace que Avro esté preparado para entornos de producción donde los equipos gestionan pipelines de datos serios y a gran escala.

Ideal para: streaming de eventos con Kafka, data lakes y cualquier entorno donde la evolución del esquema sea una preocupación real a lo largo del tiempo.

4. FlatBuffers

Este probablemente sea el formato más infravalorado de toda la lista.

Y también uno de los más malinterpretados.

FlatBuffers, también desarrollado por Google, utiliza un enfoque completamente diferente.

En lugar de codificar un objeto en bytes y después decodificarlo en el otro extremo, construye el buffer de bytes de manera que tu código pueda leer directamente los datos.

Sin necesidad de realizar un proceso tradicional de deserialización.

No estás abriendo una caja para sacar lo que hay dentro.

Estás leyendo directamente la caja.

// Después de generar el código JS desde tu esquema .fbs:
const flatbuffers = require('flatbuffers');
const { Monster }  = require('./monster_generated');

const builder = new flatbuffers.Builder(128);
const name    = builder.createString('Orc');

Monster.startMonster(builder);
Monster.addHp(builder, 300);
Monster.addName(builder, name);

const orc = Monster.endMonster(builder);

builder.finish(orc);

const buf = builder.asUint8Array();

const monster = Monster.getRootAsMonster(
  new flatbuffers.ByteBuffer(buf)
);

console.log(monster.name());  // 'Orc' - leído directamente del buffer, zero copy
console.log(monster.hp());    // 300

Zero copy.

Prácticamente ninguna asignación adicional de memoria durante la lectura.

Para sistemas donde la latencia es crítica —feeds en tiempo real, datos financieros de mercado, backends de videojuegos— estamos hablando de otra categoría de rendimiento.

El tiempo de deserialización que aparece en el benchmark siguiente no es un error.

El benchmark: números reales

Hice estas pruebas con un payload de 5.000 registros, cada uno con 8 campos, utilizando Node.js 20:

Formato       | Tamaño   | Serialización | Deserialización
------------- | -------- | ------------- | ----------------
JSON          | 1,8 MB   | 142 ms        | 98 ms
MessagePack   | 1,1 MB   | 61 ms         | 44 ms
Protobuf      | 680 KB   | 38 ms         | 29 ms
Avro          | 590 KB   | 35 ms         | 31 ms
FlatBuffers   | 720 KB   | 28 ms         | ~2 ms *

*El tiempo de deserialización de FlatBuffers es prácticamente cero porque no existe una deserialización tradicional: tu código lee directamente desde el buffer de memoria sin procesarlo previamente como un objeto completo.

Entonces, ¿deberías abandonar JSON por completo?

No.

Y esa sería precisamente la conclusión equivocada.

Lo digo después de haber pasado un fin de semana entero intentando convencerme de lo contrario.

JSON es excelente para APIs públicas, archivos de configuración y cualquier situación en la que una persona pueda necesitar leer los datos directamente.

La facilidad para depurar un sistema tiene un valor real.

El soporte de herramientas también tiene un valor real.

La primera vez que tengas un incidente en producción y descubras que tus logs son una colección de blobs binarios imposibles de leer a simple vista, entenderás perfectamente a qué me refiero.

El verdadero cambio consiste en aprender a elegir el formato de manera consciente.

JSON en los límites del sistema, donde las personas necesitan interactuar, inspeccionar o depurar la información.

Formatos binarios en las capas internas, donde las máquinas se comunican con otras máquinas y el volumen de datos realmente importa.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

La propia guía de migración de Anthropic te dice que elimines las instrucciones de verificación que llevas dos años escribiendo.

Ocho cambios de comportamiento, una nueva guía de prompting y la silenciosa llegada de capas de orquestación con fecha de caducidad.

La frase más extraña del lanzamiento de ayer no está en la página de precios ni en el gráfico de benchmarks. Está escondida en un documento de migración y te dice, literalmente, que elimines parte de tu propio trabajo: quita las instrucciones de verificación y autocomprobación heredadas de modelos anteriores, porque provocan una verificación excesiva en Claude Opus 5.

Vuelve a leerlo con tus prompts de producción abiertos.

La línea «incluye un paso final de verificación», que hacía que Opus 4.8 resultara confiable, ahora se convierte en un centro de coste.

La instrucción «sé conservador y reporta únicamente problemas de alta gravedad» dentro de tu prompt de revisión de código ahora puede hacer que el modelo reporte menos problemas.

Y el nivel de effort que utilizabas para acortar las respuestas ya no necesariamente las acorta.

Nadie quiere tocar una biblioteca de prompts heredada.

Esta es la que Anthropic acaba de dejar obsoleta.

Foto de Sally Crierie en Unsplash.

¿Qué te pidió realmente Anthropic que eliminaras?

Dos documentos contienen prácticamente toda la historia, y ninguno recibió demasiada atención durante el lanzamiento.

La sección dedicada a Opus 5 dentro de la guía de migración parece una lista de cosas que debes quitar. Y la guía de prompting, publicada esa misma mañana, es uno de los documentos específicos sobre comportamiento de modelos más extensos que Anthropic ha publicado.

Casi todas sus secciones describen algo que el modelo ahora hace por sí solo.

Si colocas ambos documentos uno al lado del otro, aparecen ocho cambios de comportamiento.

Los ocho están verificados utilizando documentación oficial, no deducidos a partir de impresiones, y pueden organizarse claramente en tres grandes grupos.

Cosas que el modelo ahora hace sin que se lo pidas, así que puedes eliminar la instrucción

Verificación.

Autocorrección.

Narración del progreso.

Cada una de estas tareas tenía un patrón de prompting que hace ocho meses podía considerarse una buena práctica y que ahora puede convertirse simplemente en consumo innecesario de tokens.

Cosas que el modelo ahora hace demasiado, así que debes limitarlas

Alcance de las tareas.

Delegación a subagentes.

Conservadurismo en las revisiones de código.

Cada una necesita ahora una nueva instrucción que probablemente no exista en tu biblioteca actual, porque ese comportamiento antes no formaba parte del modelo.

Controles que se han desacoplado y necesitan volver a ajustarse

El nivel de effort ya no controla la longitud de la respuesta.

Los niveles de effort fueron recalibrados, por lo que reutilizar una configuración anterior es incorrecto por definición.

Y el razonamiento, que ahora está activado de forma predeterminada, puede producir nuevos artefactos de salida cuando decides desactivarlo.

Esto es lo que hace que esta migración sea diferente de prácticamente todas las notas de migración de modelos anteriores.

Antes te decían que cambiaras un parámetro.

Esta vez te están diciendo que cambies tu propio criterio sobre cómo debe ser un buen prompt.

¿Qué hace ahora el modelo sin necesidad de que se lo pidas?

Empecemos por el cambio que probablemente pueda ahorrarte más dinero.

Opus 5 verifica su propio trabajo sin necesidad de que se lo indiques, y la guía de prompting es bastante clara sobre las consecuencias.

Instrucciones como «incluye un paso final de verificación para cualquier tarea que no sea trivial» o «utiliza un subagente para verificar el resultado» pueden provocar una verificación excesiva.

Eliminarlas reduce el gasto innecesario de tokens sin que se produzca una pérdida de calidad. Esto está verificado.

La guía extiende exactamente la misma recomendación a lo que denomina legacy harness scaffolding: el andamiaje heredado dentro de la capa de orquestación.

Es decir, no se refiere únicamente a lo que escribiste dentro del prompt. También incluye pasos independientes de verificación que hayas incorporado en la lógica de orquestación de tu sistema.

La autocorrección entra en la misma categoría.

El modelo detecta y corrige sus propios errores, de modo que instrucciones como «comprueba nuevamente tu respuesta» o «vuelve a verificar antes de responder» se acumulan sobre un comportamiento que ya está ocurriendo.

El resultado puede ser más coste sin una mejora real de la respuesta. También está verificado.

Ahora viene la parte que convierte este consejo en un argumento mucho más serio.

La propia system card de Anthropic documenta qué ocurre cuando la autoverificación funciona sin límites a gran escala.

Durante tareas abiertas de investigación biológica, Opus 5 llegó a quedarse atrapado verificando repetidamente su propio trabajo y terminó abandonando campañas de diseño de proteínas de 24 horas a mitad de ejecución. Está verificado.

Es decir, el propio proveedor está describiendo a su modelo estrella fallando por verificar demasiado.

Si tu prompt le dice que verifique todavía más, estás empujándolo justamente en la dirección de ese fallo.

La narración del progreso completa esta primera familia de cambios.

El modelo tiende a explicar con facilidad lo que está haciendo durante trabajos agénticos. Anuncia qué está a punto de hacer y, durante sesiones con agentes, genera más contenido por mensaje que modelos anteriores. Esto también está verificado.

Si tu capa de orquestación contiene una regla como «después de cada tres llamadas a herramientas, resume el progreso», ese andamiaje puede haberse vuelto redundante frente al comportamiento incorporado en el propio modelo.

Piensa en el prompt de un agente como si fuera el conjunto de instrucciones permanentes que entregas a una nueva persona que entra a trabajar en tu equipo.

Opus 5 llegó haciendo ya por sí solo tres de las cosas que tus instrucciones permanentes siguen exigiéndole.

De pronto, esas órdenes empiezan a parecer insistencia innecesaria.

El modelo las cumple, porque está entrenado para hacerlo.

Y tú terminas pagando dos veces por el mismo comportamiento.

Si solo recuerdas una cosa de esta sección, que sea esta:

Cada instrucción del tipo «verifica tu trabajo» dentro de tu biblioteca puede haberse convertido ahora en una factura, no en una medida de seguridad.

¿Qué hace ahora demasiado?

La segunda familia de cambios es más complicada, porque exige instrucciones que probablemente nunca habías necesitado escribir.

Opus 5 puede ampliar el alcance de una tarea.

Puede añadir pasos que no fueron solicitados y aplicar su propio criterio sobre lo que considera que debería incluir la tarea. Esto está verificado.

La solución recomendada en la guía de prompting es introducir explícitamente disciplina sobre el alcance.

Entrega exactamente lo que se solicitó y con el alcance previsto.

Toma por tu cuenta las decisiones rutinarias necesarias.

Si consideras que la solicitud contiene un posible error, indícalo brevemente.

Y después continúa realizando la tarea solicitada en lugar de ampliarla silenciosamente.

Puedes observar ese mismo comportamiento en algunas de las declaraciones utilizadas durante el lanzamiento, aunque allí aparece presentado como una ventaja.

Un ingeniero principal de uno de los clientes que tuvo acceso anticipado describe cómo el modelo cuestionó un diseño propuesto y mantuvo su objeción incluso después de que él insistiera.

Finalmente, el modelo redujo su objeción a una única pregunta y propuso una solución intermedia. Esta información procede del proveedor.

El criterio propio y la expansión del alcance son dos caras del mismo comportamiento.

Una puede mejorar tu producto.

La otra puede terminar reescribiendo tu ticket.

La delegación es el segundo punto, y su evolución resulta especialmente reveladora.

Opus 4.7 generaba menos subagentes que Opus 4.6.

Opus 5, en cambio, vuelve a delegar con más facilidad que modelos anteriores.

Ambos comportamientos están verificados.

La recomendación cambió de dirección dos veces en aproximadamente ocho meses.

Ahora la solución consiste en indicar explícitamente en qué escenarios está justificada la delegación o establecer un límite determinista sobre cuántos agentes pueden lanzarse.

El tercer punto es uno que yo pondría en la pared de cualquier equipo que trabaje con revisiones automáticas de código.

Si tu prompt de revisión dice «reporta únicamente problemas de alta gravedad» o «sé conservador», Opus 5 puede seguir esa instrucción literalmente y reportar menos problemas.

Esto está verificado.

La recomendación de Anthropic es pedirle que reporte todo lo que encuentre y realizar el filtrado en una segunda pasada.

Detente un momento a pensar en lo que acaba de ocurrir.

La instrucción original se escribió para reducir falsos positivos en un modelo que generaba demasiados.

El nuevo modelo encuentra errores reales con una tasa elevada y produce pocos falsos positivos.

Por lo tanto, esa misma instrucción ahora puede estar suprimiendo descubrimientos que sí querías recibir.

Tu prompt defensivo se convirtió en el problema.

Y probablemente nada dentro de tu suite de pruebas te avisará, porque una revisión que simplemente reporta menos resultados puede seguir pasando todos tus tests.

¿Qué controles dejaron de significar lo mismo?

El parámetro effort es uno de los lugares donde reutilizar configuraciones anteriores puede provocar errores silenciosos.

Para Opus 4.7 y Opus 4.8, la recomendación de Anthropic era comenzar utilizando xhigh en tareas de programación y trabajos agénticos.

Para Opus 5, la recomendación es comenzar en high, que además es el valor predeterminado, y utilizar low y medium con mucha más libertad como controles principales del coste de tokens y del tiempo de respuesta siempre que tus evaluaciones indiquen que la calidad se mantiene.

Esto está verificado.

El punto de partida recomendado bajó un nivel en una sola generación.

Si eso fuera todo, simplemente estaríamos hablando de ajustar una configuración.

Pero aquí aparece la verdadera tarea de migración.

La cantidad de tokens asignada internamente a cada nivel de effort cambia en Opus 5. También está verificado.

La etiqueta permaneció.

Su significado interno cambió.

Una carga de trabajo configurada en xhigh porque una evaluación realizada con Opus 4.8 indicaba que era la mejor opción ahora está ejecutándose con una configuración que nunca has probado, aunque el nombre te resulte familiar.

Por eso la documentación recomienda realizar una nueva evaluación completa en lugar de reutilizar directamente la configuración anterior.

Hay otros dos detalles más pequeños que también merece la pena tener presentes.

Configurar effort como high es exactamente equivalente a no enviar el parámetro. Está verificado.

Eso significa que buena parte de las configuraciones explícitas de effort que probablemente existen en muchas bases de código no están haciendo nada.

Además, cambiar el nivel de effort entre solicitudes no conserva los prefijos almacenados en caché.

Por eso la documentación establece ahora una recomendación clara: elige un nivel al inicio de una sesión con caché y mantenlo constante durante esa sesión.

Esto también está verificado.

Después tenemos un control que directamente dejó de hacer lo que muchas personas creían que hacía.

El effort controla el volumen de razonamiento, no la longitud visible de la respuesta.

En Opus 5, reducir el effort no reduce de forma confiable la extensión de la respuesta. Está verificado.

Si estabas utilizando effort como control de verbosidad, ya no puedes confiar en ese comportamiento.

La sustitución es una instrucción explícita sobre la longitud.

En realidad, necesitas dos.

Las respuestas visibles para el usuario son, por defecto, más extensas que en modelos Opus anteriores.

Y, de forma independiente, los archivos que el modelo escribe en disco también tienden a ser más largos.

Ambos comportamientos están verificados.

La verbosidad de una conversación y la longitud de un entregable escrito pasan a ser dos instrucciones distintas, no una sola.

El último elemento de esta lista es una auténtica trampilla.

El razonamiento está activado de forma predeterminada en Opus 5 y solo puede desactivarse cuando el effort está configurado en high o en un nivel inferior.

Combinar razonamiento desactivado con xhigh o max devuelve un error 400.

Esto se valida de manera independiente en cada solicitud y está verificado.

Si decides desactivar el razonamiento, pueden aparecer dos tipos de artefactos.

El modelo puede escribir una llamada a una herramienta como texto visible en lugar de emitir una llamada estructurada.

En ese caso, la herramienta nunca se ejecuta y el texto filtrado permanece dentro del historial de la conversación, contaminando potencialmente los turnos posteriores.

También puede ocurrir que etiquetas internas aparezcan directamente en la respuesta visible.

Ambos comportamientos están verificados.

La mitigación es bastante contraintuitiva.

Una regla dentro del prompt de sistema que indique al modelo que «no piense» puede aumentar la filtración de etiquetas internas.

Además, las instrucciones que mencionan específicamente los nombres de esas etiquetas son menos eficaces que una instrucción general que prohíba mostrar etiquetas internas.

Esto está verificado.

La propia recomendación de Anthropic es dejar de desactivar el razonamiento y utilizar effort bajo en su lugar, porque el razonamiento activado con effort bajo obtiene mejores resultados que el razonamiento desactivado con un coste similar.

Si recuerdas una sola cosa de esta sección, que sea esta:

La etiqueta de effort sobrevivió a la actualización.

La calibración que existe detrás de esa etiqueta no.

Y ningún error te avisará.

¿Qué puede romperse en producción si ignoras todo esto?

Nada de lo anterior necesariamente genera una excepción.

Y esa es precisamente la característica operativa más peligrosa de esta migración.

Todos estos modos de fallo pueden ser silenciosos, caros y capaces de superar tus pruebas.

La verificación excesiva puede parecer simplemente una factura un poco más grande.

La expansión del alcance puede parecer que el modelo está intentando ayudarte.

Una revisión de código que está suprimiendo hallazgos puede parecer simplemente que tu base de código está muy limpia.

Hay tres métricas que deberían estar en algún dashboard durante esta semana.

La primera es tokens por tarea completada, no tokens por solicitud.

La verificación excesiva y la delegación agresiva inflan todo el bucle de ejecución, no necesariamente cada turno individual.

La segunda es el número de subagentes lanzados.

El comportamiento predeterminado de delegación cambió, y un límite solo existe si tú lo configuraste.

La tercera es la cantidad de hallazgos detectados por cada pasada de revisión antes y después de modificar tus prompts.

Esa puede ser la única forma de descubrir que la lógica de tu revisión se ha invertido.

Existe además un cuarto punto que no tiene que ver directamente con el comportamiento del modelo, pero podría arruinarle la semana a más de un equipo.

Opus 5 presenta dos regresiones funcionales frente a Opus 4.8:

web fetch no está disponible.

Y Priority Tier tampoco está soportado.

Ambos puntos están verificados.

La propia lista de migración de Anthropic indica que, si tu organización tiene un compromiso relacionado con Priority Tier, debes planificar la capacidad de forma independiente, porque Opus 4.8 todavía conserva esa funcionalidad.

El modelo del que te están recomendando migrar es, al mismo tiempo, el que mantiene tu garantía de capacidad.

Existe además un dato relacionado con cumplimiento que puede decidir qué modelo utilizar incluso antes de abrir cualquier benchmark.

Fable 5 y Mythos 5 requieren una retención de datos de 30 días, están clasificados como Covered Models y no están disponibles bajo configuraciones de retención cero de datos.

Una solicitud a Fable 5 realizada desde una organización cuya configuración de retención no cumpla ese requisito devuelve un error 400.

Esto está verificado.

Opus 5, en cambio, no exige un requisito general de retención de datos para poder acceder al modelo. Esta información procede del proveedor.

Para una empresa regulada, esto deja de ser una comparación de precios.

Fable no es caro.

Simplemente puede ser inaccesible.

Opus 5 se convierte en el primer modelo de ese nivel de capacidad que determinadas organizaciones pueden utilizar realmente.

Eso cambia por completo el argumento de «capacidad cercana a la frontera por la mitad del precio» para cualquier empresa que opere bajo una política de retención cero de datos.

¿Por qué la capa de orquestación está ahora acoplada a la versión del modelo?

Aléjate un poco de estos ocho cambios y observa el patrón.

Anthropic no se limitó a lanzar un modelo mejor.

También publicó un documento que te explica cuáles de tus propios artefactos de ingeniería dejan de tener sentido con ese nuevo modelo.

Y todos esos artefactos viven en la capa de orquestación:

Prompts.

Andamiaje.

Pasos de verificación.

Políticas de delegación.

Configuraciones de effort.

Sigue un único comportamiento a través de tres versiones y el patrón resulta difícil de ignorar.

La delegación a subagentes disminuyó de Opus 4.6 a Opus 4.7.

Después volvió a aumentar de Opus 4.7 a Opus 5.

La recomendación sobre effort pasó de utilizar xhigh como punto de partida en 4.7 y 4.8 a comenzar en high en Opus 5.

Además, las asignaciones internas de tokens fueron recalibradas.

La longitud de las respuestas cambió en Opus 4.7.

Después volvió a cambiar en Opus 5 y, además, quedó desacoplada del effort.

Un harness o capa de orquestación optimizada específicamente para cualquiera de esos puntos puede quedar mal ajustada en la siguiente versión.

La admisión más clara de este problema probablemente sea una herramienta.

Anthropic lanzó una skill de Claude Code específicamente para realizar esta migración.

Ejecutas un comando y la herramienta aplica el cambio del identificador del modelo, modifica los parámetros incompatibles, sustituye configuraciones de prefill y ajusta la calibración del effort a lo largo de tu base de código.

Después te entrega una lista de elementos que debes verificar manualmente.

Esto está verificado.

No construyes un agente para realizar tu propia migración a menos que esperes que esa migración sea suficientemente grande y que tenga que repetirse.

Aquí aparece la lectura incómoda para cualquiera que, como yo, esté convencida de que la ventaja duradera de un sistema de IA vive en su capa de orquestación y no únicamente en los pesos del modelo.

Sigo creyendo que es así.

Pero esa capa de orquestación ahora tiene un problema de acoplamiento con la versión que los propios pesos del modelo no tienen.

Cada mejora de comportamiento incorporada al modelo elimina algún patrón compensatorio que antes habías añadido a tu infraestructura.

Los equipos que ganen durante el próximo año probablemente no serán aquellos que tengan la capa de orquestación más elaborada.

Serán aquellos capaces de simplificarla más rápido cuando el propio modelo absorba una de sus capas.

Trata tu biblioteca de prompts como una dependencia que tiene su propio calendario de versiones.

Porque eso es exactamente en lo que se ha convertido.

Fíjala.

Versiona los cambios.

Compárala con las notas de comportamiento del proveedor cada vez que cambies de modelo.

Y reserva presupuesto y tiempo para realizar nuevas evaluaciones exactamente igual que lo harías al actualizar un framework.

El briefing del lunes

Esto es lo que debes decirle a tu equipo, en el mismo orden en que probablemente te lo preguntará.

Elimina

Busca en toda la biblioteca de prompts instrucciones relacionadas con verificación, autocomprobación, volver a verificar y resúmenes obligatorios de progreso.

Elimínalas de los flujos que utilicen Opus 5.

Revisa también la capa de orquestación, no únicamente las cadenas de texto de tus prompts.

Los pasos independientes de verificación implementados dentro de la orquestación también cuentan.

Limita

Añade instrucciones explícitas sobre el alcance para tareas que deben permanecer acotadas.

Define una política clara de delegación o establece un límite estricto sobre el número de subagentes que pueden lanzarse.

Reescribe los prompts conservadores utilizados en revisiones de código.

Pide al modelo que reporte todo y filtra los resultados en una segunda pasada.

Recalibra

Ejecuta una evaluación completamente nueva de los niveles de effort en lugar de reutilizar configuraciones anteriores.

Añade instrucciones explícitas sobre la longitud de las respuestas de chat y utiliza una instrucción diferente para los entregables escritos.

Audita cualquier solicitud que desactive el razonamiento, porque desactivar el razonamiento utilizando xhigh o max ahora devuelve un error 400.

Vuelve a establecer tu línea base

Mide tokens por tarea completada antes y después de realizar los cambios.

No te limites a medir tokens por solicitud.

Después comprueba si Priority Tier o web fetch aparecen en alguna de las cargas de trabajo que estabas a punto de migrar.

Preguntas frecuentes

¿Debería reescribir mis prompts hoy mismo?

Primero elimina antes de reescribir.

Quitar las instrucciones de verificación y autocomprobación es el cambio de menor riesgo de toda la lista.

Es una recomendación directa de Anthropic y puede reducir inmediatamente el consumo de tokens.

Guarda las nuevas instrucciones relacionadas con alcance y delegación para después de haber medido una línea base.

Esas instrucciones añaden complejidad y merecen estar respaldadas por evidencia.

¿Se aplica todo esto también a Sonnet 5?

No directamente.

Cada nota de comportamiento incluida en este artículo procede específicamente de documentación relacionada con Opus 5.

Además, ambos modelos presentan diferencias importantes.

Sonnet 5 permite utilizar razonamiento desactivado con cualquier nivel de effort.

No admite mensajes de sistema en mitad de una conversación.

Y sigue teniendo web fetch.

Consulta siempre la documentación específica de tu modelo en lugar de generalizar el comportamiento de otro.

Esa es, precisamente, una de las principales lecciones de todo este artículo.

¿Qué deberían modificar primero quienes utilizan Claude Code?

La misma lista de elementos que debes eliminar, pero aplicada a las instrucciones de tu proyecto en lugar de únicamente a los prompts de API.

Anthropic incluye una herramienta de migración dentro de Claude Code que gestiona los cambios de identificador del modelo, modificaciones incompatibles de parámetros y recalibración del effort a lo largo de una base de código.

Después devuelve una lista de comprobaciones manuales.

Empieza por ahí.

Pero considera esa lista como el comienzo del trabajo, no como el final.

Recapitulación y un experimento

Hay tres ideas que merece la pena conservar.

La primera es que Opus 5 llegó acompañado de una lista de instrucciones tuyas que ahora debes eliminar.

La más importante está relacionada con la verificación.

El modelo ahora verifica por sí mismo y la propia system card documenta situaciones en las que termina verificando demasiado.

La segunda es que los comportamientos que cambiaron de dirección —delegación, calibración del effort y control de longitud— pertenecen todos a la capa de orquestación.

Eso significa que tu harness está acoplado a la versión del modelo de una manera que fijar simplemente el identificador del modelo no puede proteger.

La tercera es que prácticamente todos los fallos asociados con esta migración son silenciosos.

No necesariamente tendrás una excepción.

No necesariamente aumentará tu tasa de errores.

Tus tests pueden seguir pasando.

El experimento que merece la pena hacer esta semana puede realizarse en una tarde.

Elige un prompt de producción que contenga una instrucción de verificación o autocomprobación.

Ejecuta veinte tareas representativas utilizando Opus 5 con esa instrucción.

Después ejecuta otras veinte tareas equivalentes eliminándola.

Mantén constante el nivel de effort para conservar estable la caché.

Mide los tokens consumidos por tarea completada y evalúa la calidad utilizando tus propios criterios.

No midas únicamente tokens por solicitud.

Si la afirmación de Anthropic se cumple, deberías obtener la misma calidad con un coste menor.

Y habrás medido directamente el beneficio de eliminar esas instrucciones antes de que tus competidores terminen siquiera de leer los gráficos de benchmarks.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.