En una sola semana de abril de 2026, Anthropic lanzó Claude Opus 4.7, presentó un nuevo producto llamado Claude Design y añadió Routines, una función capaz de ejecutar tareas incluso cuando tu computadora portátil está cerrada.

Ese mismo día, OpenAI llevó Codex un paso más allá con agentes paralelos capaces de hacer clic y escribir directamente en tu Mac.

Esto ya es normal. Abril de 2026 ha sido calificado como uno de los meses con mayor cantidad de lanzamientos de modelos de lenguaje de la historia. Aproximadamente entre el 65 % y el 70 % del código empresarial está siendo escrito por IA. Más del 50 % de las empresas describe su proceso de adopción de inteligencia artificial como un «caos sin ningún tipo de control».

Y, aun así, el recurso para desarrolladores con más estrellas de todo este sector no es un framework, un plugin ni un modelo.

Son cuatro frases dentro de un archivo Markdown.

Un repositorio de GitHub. 60 000 estrellas.

Sin dependencias, sin API y sin proceso de compilación.

Solo un archivo CLAUDE.md con cuatro directrices de comportamiento derivadas de algo que Andrej Karpathy publicó en enero. Lo que 60 000 desarrolladores decidieron guardar como favorito revela mucho más sobre el verdadero cuello de botella de la programación asistida por IA que cualquier anuncio de producto realizado esta semana.

El fin de semana pasado dediqué tiempo a migrar mi propio archivo CLAUDE.md para que funcionara mejor con la actualización más reciente de Claude Code. Tenía cuarenta y siete reglas, cuidadosamente acumuladas durante meses. El agente ignoró la mitad de ellas e inventó convenciones que yo nunca había escrito. Fue entonces cuando encontré este repositorio. Y también cuando comprendí que el problema no eran mis reglas, sino la cantidad de reglas que había creado.

Lo que Karpathy realmente diagnosticó

En enero de 2026, Andrej Karpathy publicó un hilo que tuvo un impacto diferente al de la mayoría de los comentarios sobre inteligencia artificial. No estaba anunciando nada. Estaba describiendo qué se había roto.

En aproximadamente seis semanas, entre noviembre y diciembre de 2025, había pasado de programar manualmente el 80 % del tiempo, con un 20 % de asistencia de agentes, a hacer exactamente lo contrario: 80 % mediante agentes y 20 % mediante correcciones manuales. Lo calificó como «fácilmente el cambio más grande en aproximadamente dos décadas de programación». Pero el hilo no tenía un tono de celebración. Era un diagnóstico.

Los modelos no estaban fallando al escribir código. Estaban fallando al aplicar criterio.

«Los modelos hacen suposiciones incorrectas en tu nombre y simplemente continúan trabajando basándose en ellas, sin comprobar nada».

Karpathy identificó el problema más profundo:

«No gestionan su confusión, no buscan aclaraciones, no exponen inconsistencias, no presentan ventajas y desventajas y no cuestionan las decisiones cuando deberían hacerlo».

Les pides «exportar los datos de los usuarios» y el agente supone que deben exportarse en JSON, los guarda en el disco, incluye todos los campos y omite la paginación. Nunca se detiene para decir: «No estoy seguro de qué formato deseas». Simplemente elige una opción y continúa.

De ahí surge la Línea 1.

«Les encanta complicar demasiado el código y las API, y llenar todo de abstracciones innecesarias».

En palabras de Karpathy, los modelos:

«Implementan una construcción inflada de más de 1 000 líneas cuando 100 serían suficientes».

Pides una calculadora de descuentos y recibes un patrón Strategy con clases base abstractas, un enum, una configuración mediante dataclass y 40 líneas de preparación. El agente construye pensando en los requisitos del futuro, en lugar de resolver el problema actual.

Esto se corresponde directamente con la Línea 2.

«Todavía modifican o eliminan comentarios y código que no comprenden suficientemente como efectos secundarios, aunque no tengan ninguna relación con la tarea».

Le pides al agente que corrija un error y el pull request también cambia todas las comillas simples por comillas dobles, añade anotaciones de tipos que no solicitaste y reescribe código cercano. La solución necesitaba tres líneas. El cambio contiene cuarenta.

La Línea 3 existe precisamente por esto.

El hilo tuvo una gran repercusión porque no era prescriptivo. Karpathy no ofreció soluciones. Describió los modos de fallo con tanta claridad que, pocos días después, alguien los tradujo en un archivo CLAUDE.md de cuatro líneas y lo publicó en GitHub.

Pero existe una cuarta línea que va más allá de la disciplina y se relaciona con algo que el propio Karpathy ya había insinuado:

«Los modelos de lenguaje son excepcionalmente buenos repitiendo ciclos hasta alcanzar objetivos específicos. No les digas qué deben hacer. Dales criterios de éxito y observa cómo trabajan».

Esa es la Línea 4. Y es lo que convierte todo esto en algo más que una simple guía de estilo.

Las nueve secciones que todo DESIGN.md necesita

Lo que 70 000 desarrolladores guardaron como favorito, lo que Google publicó como código abierto y por qué un simple archivo Markdown supera a toda tu cadena de herramientas de diseño.

levelup.gitconnected.com

Las cuatro líneas

Aquí están. Esta es la sección completa de comportamiento de un archivo CLAUDE.md que 55 000 desarrolladores consideraron suficientemente valiosa como para darle una estrella:

1. No hagas suposiciones. No ocultes la confusión. Expón las ventajas y desventajas.
2. Escribe la cantidad mínima de código necesaria para resolver el problema. Nada especulativo.
3. Modifica únicamente lo imprescindible. Limpia solamente el desorden que tú mismo hayas creado.
4. Define criterios de éxito. Repite el proceso hasta verificar el resultado.

Eso es todo. Cada línea se corresponde directamente con uno de los modos de fallo descritos por Karpathy.

Presiona Enter o haz clic para ver la imagen en tamaño completo

Las cuatro líneas: la base completa de comportamiento para tu archivo CLAUDE.md

Analicemos por qué funciona cada una. Los ejemplos de antes y después que aparecen a continuación están adaptados del archivo EXAMPLES.md del repositorio, que incluye explicaciones completas de cada principio.

Piensa antes de programar: no hagas suposiciones, no ocultes la confusión y expón las ventajas y desventajas

Este principio corrige una de las frustraciones más comunes relacionadas con los agentes de programación: hacen suposiciones cuando deberían hacer preguntas.

Sin esta línea, esto es lo que sucede cuando le dices a un agente: «Añade una función para exportar los datos de los usuarios».

def export_users(format='json'):    users = User.query.all()    if format == 'json':        with open('users.json', 'w') as f:            json.dump([u.to_dict() for u in users], f)    return f"Exported {len(users)} users"

El agente supuso que el formato sería JSON. Supuso que debía exportar a todos los usuarios. Supuso que debía generar un archivo en el disco. Supuso qué campos debía incluir. Nunca mencionó ninguna de estas decisiones. Simplemente eligió y continuó trabajando.

Con este principio, la primera respuesta del agente sería algo parecido a esto:

Antes de implementarlo, necesito aclarar algunos puntos:

1. Alcance: ¿debo exportar a todos los usuarios o solo a un subconjunto filtrado?
2. Formato: ¿una descarga en JSON, un archivo CSV o un endpoint de API?
3. Campos: ¿qué campos del usuario deben incluirse? Algunos podrían contener información sensible.
4. Volumen: ¿cuántos usuarios existen? Esto podría afectar al enfoque que se utilice.

Cuatro preguntas en lugar de cuatro suposiciones. El código se escribe después de obtener las respuestas, no antes.

La razón por la que esto es más importante de lo que parece es que los modelos de lenguaje no exteriorizan su incertidumbre de manera natural. Han sido entrenados para completar contenido, no para detenerse. Cada token de sus datos de entrenamiento impulsa la respuesta hacia delante. Detenerse y decir «No estoy seguro» va en contra de la forma en que estos modelos aprendieron a generar texto.

Esta línea obliga al modelo a adoptar un comportamiento para el que tiene capacidad, pero que no utiliza de manera predeterminada. No añade una función nueva. Modifica un comportamiento predeterminado.

La simplicidad primero: escribe la cantidad mínima de código necesaria para resolver el problema, sin nada especulativo

Este principio elimina las abstracciones prematuras. Sin él, pides «una función para calcular un descuento» y obtienes algo como esto:

class DiscountStrategy(ABC):    @abstractmethod    def calculate(self, amount: float) -> float:        passclass PercentageDiscount(DiscountStrategy):    def __init__(self, percentage: float):        self.percentage = percentage    def calculate(self, amount: float) -> float:        return amount * (self.percentage / 100)class FixedDiscount(DiscountStrategy):    # ... 20 líneas adicionalesclass DiscountCalculator:    def __init__(self, config: DiscountConfig):        # ... 15 líneas adicionales de configuración

Una clase base abstracta. El patrón Strategy. Una configuración mediante dataclass. Más de cuarenta líneas para realizar una operación aritmética.

Con este principio:

def calculate_discount(amount: float, percent: float) -> float:    return amount * (percent / 100)

Una función. Una línea de lógica. Si más adelante necesitas el patrón Strategy, podrás refactorizar el código en ese momento. No ahora. No de manera especulativa.

Esta es la idea que la mayoría de los artículos no menciona: la versión excesivamente complicada no es necesariamente incorrecta. Sigue patrones de diseño reales. Un ingeniero sénior podría utilizar el patrón Strategy dentro de un gran sistema de facturación.

El problema es el momento en que se utiliza.

Las abstracciones prematuras tienen un coste acumulativo: más código significa una mayor superficie para que aparezcan errores, más carga cognitiva para los revisores y más resistencia cuando sea necesario cambiar de dirección. El agente construye pensando en requisitos que todavía no existen y que quizá nunca lleguen a existir.

El buen código resuelve con sencillez el problema de hoy. No intenta resolver prematuramente el problema de mañana.

La prueba del ingeniero sénior incluida en el archivo original lo resume perfectamente:

«¿Un ingeniero sénior diría que esto está demasiado complicado?».

En caso afirmativo, simplifícalo.

Presiona Enter o haz clic para ver la imagen en tamaño completo

Diagrama del autor: Antes y después de aplicar las cuatro líneas a la corrección de un error real

Cambios quirúrgicos: modifica únicamente lo imprescindible y limpia solamente tu propio desorden

Este principio protege tus diferencias de código. Le pides al agente que corrija un error por el que un correo electrónico vacío provoca un fallo en el validador. Sin este principio, el cambio se vería así:

- if not user_data.get('email'):+ email = user_data.get('email', '').strip()+ if not email:      raise ValueError("Email required")- if '@' not in user_data['email']:+ if '@' not in email or '.' not in email.split('@')[1]:      raise ValueError("Invalid email")- if not user_data.get('username'):+ username = user_data.get('username', '').strip()+ if not username:      raise ValueError("Username required")+ if len(username) < 3:+     raise ValueError("Username too short")+ if not username.isalnum():+     raise ValueError("Username must be alphanumeric")

La corrección del error consistía en gestionar correctamente un correo electrónico vacío. Sin embargo, el agente también «mejoró» la validación del correo, añadió comprobaciones sobre la longitud del nombre de usuario, incorporó una restricción para permitir únicamente caracteres alfanuméricos y cambió los nombres de las variables.

Nada de eso había sido solicitado.

Con este principio, el cambio es quirúrgico:

- if not user_data.get('email'):+ email = user_data.get('email', '')+ if not email or not email.strip():      raise ValueError("Email required")- if '@' not in user_data['email']:+ if '@' not in email:      raise ValueError("Invalid email")

Cada línea modificada se relaciona directamente con el error reportado. Nada más.

La verdadera ventaja no es únicamente la limpieza, sino la posibilidad de auditar el resultado.

Cuando el cambio realizado por un agente contiene cuarenta líneas y solamente tres están relacionadas con la solicitud original, no puedes confiar en las otras treinta y siete sin revisarlas una por una. No se trata de una molestia menor. Es un impuesto de revisión aplicado a cada fragmento de código generado por inteligencia artificial.

Los cambios quirúrgicos hacen que el resultado de la IA pueda revisarse a la velocidad que realmente necesitas. Cuanto menor sea el cambio, más rápido podrás confiar en él, fusionarlo y continuar con el trabajo.

El archivo original añade un matiz sutil, pero importante: cuando TUS cambios crean elementos huérfanos, como importaciones no utilizadas o variables muertas, debes eliminarlos. Sin embargo, no debes modificar código muerto que ya existía anteriormente, salvo que te lo pidan.

Tu desorden, tu limpieza. El desorden de los demás, su decisión.

Ejecución orientada a objetivos: define criterios de éxito y repite el proceso hasta verificar el resultado

Los tres primeros principios funcionan como barreras de protección. Limitan el comportamiento. Este principio es diferente. Desbloquea una capacidad.

Es el principio que convierte la observación de Karpathy en una ventaja práctica. Karpathy se dio cuenta de que los modelos de lenguaje son «excepcionalmente buenos repitiendo ciclos hasta alcanzar objetivos específicos».

El problema no es que los agentes no puedan iterar. El problema es que les damos instrucciones imprecisas, en lugar de objetivos verificables.

Sin este principio, dices: «Corrige el sistema de autenticación», y el agente responde:

Corregiré el sistema de autenticación mediante los siguientes pasos:

1. Revisar el código.
2. Identificar los problemas.
3. Realizar mejoras.
4. Probar los cambios.

Un plan impreciso. Sin criterios de éxito. Sin verificación. Cambiará algo y lo considerará terminado.

Con este principio, la misma solicitud se transforma:

1. Escribir una prueba: al cambiar la contraseña, la sesión anterior debe quedar invalidada.
   → Verificación: la prueba falla y reproduce el error.
2. Implementar la invalidación de sesiones cuando se cambie la contraseña.
   → Verificación: la prueba se supera correctamente.
3. Comprobar casos límite: múltiples sesiones y cambios simultáneos.
   → Verificación: las pruebas adicionales se superan.
4. Comprobar regresiones: las pruebas existentes de autenticación deben seguir funcionando.
   → Verificación: toda la suite de pruebas se ejecuta correctamente.

Cada paso contiene una comprobación. El agente puede repetir el proceso de forma independiente porque sabe cómo se ve un resultado terminado. Los criterios de éxito sólidos sustituyen la necesidad de supervisión constante.

Esto es lo que diferencia este principio de los otros tres: pensar antes de programar, priorizar la simplicidad y realizar cambios quirúrgicos son formas de disciplina. Evitan comportamientos negativos.

La ejecución orientada a objetivos es una ventaja. Desbloquea un comportamiento para el que el agente ya es bueno, pero que no se activa sin una estructura adecuada en el prompt.

Los tres primeros principios hacen que el agente resulte menos molesto. El cuarto lo hace más capaz. Y esta diferencia importa. La disciplina ofrece rendimientos decrecientes. La ventaja se acumula.

Una advertencia: estos ejemplos muestran tareas sencillas dentro de un solo archivo. Me gustaría comprobar cómo se comportan las cuatro líneas en un monorepositorio de 100 000 líneas, con varios equipos y dependencias entrelazadas.

Los proyectos de un solo desarrollador son el caso sencillo. La pregunta más difícil es si unas directrices de comportamiento pueden escalar por sí solas hasta la complejidad que tienen la mayoría de las bases de código empresariales.

La paradoja de la configuración

El instinto natural cuando un agente de IA se comporta incorrectamente es añadir más reglas.

No utilices punto y coma. Añade siempre gestión de errores. Sigue la convención de nombres del repositorio. Da prioridad a los patrones funcionales. Utiliza el modo estricto de TypeScript.

Este instinto ha producido un ecosistema de una magnitud impresionante. Un popular conjunto de herramientas de GitHub enumera 135 agentes, 35 habilidades seleccionadas, más de 400 000 habilidades disponibles en un marketplace, 176 plugins y 42 comandos.

Otro ofrece 30 agentes especializados y 136 habilidades.

Actualmente existen al menos cinco formatos de configuración que compiten entre sí:

• CLAUDE.md
• AGENTS.md
• .cursorrules
• copilot-instructions.md
• .windsurfrules

Incluso existe una herramienta para convertir reglas entre diferentes formatos.

El ecosistema cuenta con más opciones de configuración que ingenieros tienen la mayoría de los equipos.

Este es el problema: no escala de la forma que cabría esperar.

Claude Code limita cada archivo de reglas a 6 000 caracteres y el conjunto combinado de reglas a 12 000 caracteres. Esos límites existen por una razón. A partir de cierto punto, añadir reglas no produce agentes más disciplinados, sino agentes confundidos.

La propia documentación de Anthropic lo expresa claramente:

«Para cada línea, pregúntate: “¿Eliminar esta línea provocaría que Claude cometiera errores?”. Si la respuesta es no, elimínala».

Piensa en ello como la incorporación de un nuevo empleado. Puedes entregarle un manual de cincuenta páginas que cubra todos los escenarios posibles. O puedes explicarle cuatro principios que la empresa realmente aplica y confiar en que utilice su criterio.

El manual termina guardado en un cajón. Los principios se utilizan.

Esa es la paradoja de la configuración: más reglas parecen ofrecer un mayor control, pero, una vez establecida la base de comportamiento, las reglas adicionales añaden ruido que compite con la señal.

Las 55 000 estrellas no son un voto a favor del minimalismo como elección estética. Son un voto a favor de la idea de que las restricciones de comportamiento superan a las listas de funciones.

Las cuatro líneas funcionan porque determinan cómo piensa el agente, no solamente qué hace. Pueden transferirse entre proyectos, lenguajes y tipos de problemas.

Una regla como «utiliza el modo estricto de TypeScript» se aplica a una tecnología concreta. «No hagas suposiciones» se aplica a todo.

Qué debes incluir realmente en tu archivo

El camino más rápido consiste en instalar directamente el archivo desde el repositorio que inició todo esto.

Opción A: plugin de Claude Code — recomendado

Desde Claude Code, añade el marketplace e instala el plugin:

/plugin marketplace add forrestchang/andrej-karpathy-skills/plugin install andrej-karpathy-skills@karpathy-skills

Esto hace que las directrices estén disponibles automáticamente en todos tus proyectos.

Opción B: descargar directamente el archivo

Para un proyecto nuevo:

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

Para un proyecto existente, añádelo al final de tu archivo actual:

echo "" >> CLAUDE.mdcurl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

El archivo completo amplía cada uno de los cuatro principios mediante subpuntos y ejemplos. Sin embargo, el núcleo sigue siendo esas cuatro frases. Todo lo demás son explicaciones adicionales.

Una vez establecida la base de comportamiento, añade una pequeña capa de contexto específico del proyecto. No reglas sobre cómo programar, sino contexto que el agente no puede deducir leyendo tus archivos.

Comandos de compilación

El agente necesita saber cómo ejecutar tu proyecto:

## Project- Build: `npm run build`- Test: `npm test`- Lint: `npm run lint -- --fix`

Convenciones que el código no muestra

Decisiones que no son visibles dentro del código existente:

## Conventions- API errors return { error: string, code: number }, never throw- All dates stored as UTC, displayed in user's timezone- Feature flags live in config/flags.ts, not inline

Lecciones aprendidas de errores anteriores

Recordatorios de una sola línea sobre cosas que ya provocaron problemas:

## Watch out- The payments service timeout is 30s, not the default 5s- Don't import from /internal -- it breaks the public API build

Presiona Enter o haz clic para ver la imagen en tamaño completo

Diagrama del autor: Anatomía de un archivo CLAUDE.md. Base de comportamiento más una pequeña capa específica del proyecto.

Eso es todo. La base de comportamiento obtenida del repositorio, los comandos de compilación, algunas convenciones y quizá una advertencia.

La prueba que debes aplicar a cada línea adicional que quieras incluir después de las cuatro principales es la siguiente:

«¿Eliminar esta línea provocaría que el agente cometiera un error del que no podría recuperarse?».

Si la respuesta es no, no la incluyas.

Qué NO debes incluir en el archivo

No incluyas descripciones generales de la arquitectura que el agente pueda deducir leyendo el código, guías de estilo que pueda inferir a partir de los patrones existentes, listas de dependencias que pueda encontrar en package.json ni documentación a la que ya pueda acceder desde el repositorio.

El agente lee tu base de código. No dupliques información que ya se encuentra allí.

Cuándo cuatro líneas no son suficientes

Estas directrices gestionan correctamente la capa de comportamiento. Pero el comportamiento no es la única capa.

Refactorizaciones complejas de múltiples archivos

Cuando estás reestructurando un módulo completo, moviendo funciones entre archivos y actualizando cadenas de importación, el agente necesita un contexto arquitectónico que las restricciones de comportamiento no pueden proporcionar.

«No hagas suposiciones» no será suficiente si el agente desconoce qué archivos dependen de otros.

Para las grandes refactorizaciones, debes añadir una breve sección de arquitectura a tu archivo CLAUDE.md o dividir el trabajo en tareas más pequeñas y bien delimitadas que el agente pueda gestionar una por una.

Sectores regulados

Si trabajas en sanidad, tecnología financiera o cualquier sector con requisitos de cumplimiento normativo, cuatro líneas de comportamiento no cubren reglas como «nunca registrar información personal identificable» o «todos los cambios en la API requieren una revisión de seguridad».

Las barreras de protección específicas de cada sector son una cuestión diferente de las directrices de comportamiento. Añádelas junto con las cuatro líneas, no en sustitución de ellas.

Consistencia a escala de equipo

El archivo CLAUDE.md de un solo desarrollador es relativamente sencillo. Conseguir que veinte ingenieros compartan las mismas normas de comportamiento para sus agentes es un problema de coordinación, no de configuración.

Aquí es donde formatos como AGENTS.md, que pueden incorporarse al repositorio y no dependen de una herramienta específica, empiezan a ser importantes.

Las cuatro líneas son un punto de partida para los equipos, pero estos también deben acordar qué reglas específicas del proyecto se añadirán sobre esa base.

Portabilidad entre herramientas

Estas directrices fueron escritas específicamente para Claude Code. Cursor, Copilot y Codex tienen modos de fallo similares, pero no idénticos.

Los principios pueden transferirse. «No hagas suposiciones» es un buen consejo independientemente del agente que utilices. Sin embargo, la redacción específica y el grado en que cada agente responde a ella variarán según la herramienta.

Si utilizas Cursor, tendrás que adaptar estas reglas al formato .cursorrules y comprobar si el agente las interpreta de la misma forma.

Una observación honesta adicional: las 60 000 estrellas son una señal de que la idea ha tenido repercusión, no una prueba de su eficacia.

No disponemos de estudios rigurosos que comparen el rendimiento antes y después de aplicar estas directrices y que demuestren exactamente cuánto mejoran la calidad de los resultados.

Un sitio afirma haber conseguido un 94 % de precisión con las directrices de Karpathy, pero sería necesario revisar su metodología antes de considerar esa cifra como definitiva.

Lo que sí tenemos es un fuerte consenso anecdótico procedente de una gran población de desarrolladores. Es significativo, pero no equivale a un estudio controlado.

El cuello de botella del comportamiento

Que un archivo de texto tenga 60 000 estrellas revela algo que los anuncios de producto no muestran: el cuello de botella de la programación asistida por IA nunca fue la capacidad, sino el comportamiento.

Los modelos pueden escribir código. Llevan bastante tiempo siendo capaces de hacerlo.

Lo que todavía no pueden hacer de manera fiable es decidir cuándo deben dejar de escribir, qué preguntas deben hacer antes de comenzar, cuánto código deben modificar y cómo comprobar que realmente han terminado.

Esos son problemas de comportamiento, no problemas de inteligencia. Y los problemas de comportamiento no se resuelven únicamente haciendo que el modelo sea más inteligente. Se resuelven explicándole al modelo cómo debe actuar.

Por eso cuatro frases superaron a todo un ecosistema de plugins, agentes y habilidades.

No porque ese ecosistema sea incorrecto. No lo es. Pero está intentando resolver la capa de capacidad mientras la capa de comportamiento continúa siendo la principal restricción.

Cada mejora del modelo ayuda. Sin embargo, mientras los agentes no puedan gestionar de manera fiable su propia incertidumbre, limitar el alcance de sus cambios y verificar su propio trabajo, las cuatro líneas seguirán aportando más valor por carácter que cualquier anuncio de nuevas funciones.

Esto es lo que realmente cambiaría mañana en mi flujo de trabajo: abriría mi archivo CLAUDE.md, eliminaría todas las reglas que el agente pudiera deducir leyendo la base de código, añadiría las cuatro líneas de comportamiento si todavía no estuvieran allí y evaluaría cada regla nueva que quisiera incluir mediante una sola pregunta:

«¿Esta regla determina cómo piensa el agente o solamente qué hace?».

Si solamente determina qué hace, probablemente no debería estar en el archivo.

Para profundizar más, el archivo EXAMPLES.md del repositorio contiene explicaciones completas de código antes y después de aplicar cada principio, incluidos patrones de verificación con múltiples pasos para la Línea 4.

Los modelos seguirán volviéndose más inteligentes. Las herramientas continuarán siendo más potentes. El cuello de botella seguirá siendo el comportamiento hasta que los modelos aprendan a gestionar su propio criterio.

Y, hasta que eso suceda, cuatro frases dentro de un archivo Markdown seguirán superando al ciclo constante de lanzamientos de productos.

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.

Los resultados de las pruebas de referencia parecen sólidos. Los precios son competitivos. Si solo lees los titulares, pensarías que esto se trata de la calidad del modelo.

Pero no es así.

Gemini 3.1 Pro, Claude Opus 4.6, GPT-5.3-Codex y ahora GPT-5.4: cuatro modelos de frontera en un solo mes. GPT-5.x ha tenido cuatro lanzamientos en cuatro meses. El ritmo de lanzamientos es, en sí mismo, la señal. El escalado del preentrenamiento llegó a un límite, los modelos se están volviendo cada vez más intercambiables y la guerra se trasladó una capa más arriba: quién logra apropiarse de tu flujo de trabajo.

Este artículo reúne las observaciones del día después de una desarrolladora que utiliza ambos modelos.

Resumen rápido

• GPT-5.4 unifica programación, razonamiento y uso de computadoras en un solo modelo, pero la mejora en la prueba de programación es de apenas 2.1 puntos. Los avances realmente importantes están en el uso de computadoras —27.7 puntos adicionales en OSWorld— y en la eficiencia de tokens —Tool Search permite ahorrar un 47%—.
• El rápido ritmo de lanzamientos no es una señal de grandes descubrimientos. Es una señal de que el escalado del preentrenamiento se estancó y todos los laboratorios pasaron a lanzar con mayor rapidez mejoras en la capa de producto.
• Los modelos se están volviendo intercambiables. El mismo protocolo MCP y el mismo formato SKILL.md funcionan ahora en Claude Code, Codex CLI, Gemini CLI y Cursor. La competencia se trasladó por encima de la capa del modelo.
• Claude Code pasó de generar 0 dólares a alcanzar 2,500 millones de dólares en ingresos en nueve meses y posee el 54% del mercado empresarial de programación. GPT-5.4 es un contraataque directo frente a esta situación.
• OpenAI apuesta por una unificación amplia en la capa del modelo: un solo modelo que lo haga todo. Anthropic apuesta por una especialización profunda en la capa del entorno de ejecución: agentes nativos de terminal, subagentes y más de 9,000 complementos. Son capas diferentes y problemas diferentes.
• La decisión sensata para una desarrolladora es distribuir las tareas según su complejidad, no según la lealtad a una marca. Utiliza el modelo GPT-5.4 cuando necesites velocidad. Utiliza el entorno de ejecución de Claude Code cuando necesites profundidad. Espera a que existan pruebas independientes antes de tomar decisiones de infraestructura.

Qué incorpora realmente GPT-5.4

OpenAI lanzó GPT-5.4 el 5 de marzo de 2026 y lo describió como «nuestro modelo de frontera más capaz y eficiente para el trabajo profesional». Hay tres variantes disponibles: GPT-5.4 estándar, GPT-5.4 Thinking —orientado al razonamiento y disponible en ChatGPT— y GPT-5.4 Pro —máximo rendimiento mediante la API, con un precio de 30 dólares por millón de tokens de entrada y 180 dólares por millón de tokens de salida—.

Las funciones principales parecen una respuesta directa a los productos de programación de Anthropic.

• El uso nativo de computadoras es la incorporación más llamativa. GPT-5.4 obtiene un 75.0% en OSWorld-Verified, lo que representa un aumento de 27.7 puntos frente al 47.3% de GPT-5.2, y supera el nivel de referencia humano del 72.4%. El modelo puede manejar computadoras tanto mediante código de Playwright como con comandos directos de ratón y teclado a partir de capturas de pantalla. Ningún modelo anterior de propósito general de OpenAI incluía esta capacidad de manera integrada.
• Tool Search es una mejora estructural de eficiencia para la API. En lugar de cargar desde el principio todas las definiciones de las herramientas —consumiendo miles de tokens—, GPT-5.4 recibe una lista ligera de herramientas y recupera las definiciones completas cuando las necesita. En 250 tareas de la prueba MCP Atlas de Scale, con 36 servidores MCP habilitados, esta función redujo el uso total de tokens en un 47% sin disminuir la precisión. Si utilizas ecosistemas grandes de herramientas, esto supone una reducción real de costos.
• El contexto de un millón de tokens ya está disponible de forma experimental en Codex, aunque las solicitudes que superen los 272,000 tokens se facturan al doble de la tarifa.

Imagen del autor — Variantes del modelo GPT-5.4: precios, funciones y disponibilidad de un vistazo.

Esto es lo que realmente indican las pruebas de referencia y cómo se compara GPT-5.4 con Claude Opus 4.6 y Gemini 3.1 Pro:

El patrón es claro, y no consiste en que «un modelo gane en todo». GPT-5.4 lidera en uso de computadoras, ejecución en terminal y tareas profesionales. Opus 4.6 lidera en programación y razonamiento visual. Gemini 3.1 Pro lidera en razonamiento científico y abstracto. Ningún modelo domina en todas las categorías.

La parte relacionada con la programación es la más reveladora. En SWE-Bench Verified —la prueba más relevante para las tareas complejas de programación para las que los desarrolladores utilizan Claude Code, el modelo Opus 4.6 obtiene un 80.8%. El modelo GPT-5.4 ni siquiera publica una puntuación en Verified, y su variante Pro con un 57.7% en SWE-Bench Pro queda muy por detrás de Opus. Esa diferencia a nivel de modelo es importante, pero recuerda que la posición competitiva de Claude Code también se encuentra en su capa de ejecución subagentes, MCP y hooks, no solamente en el modelo subyacente.

El precio es competitivo en la versión estándar: 2.50 dólares por millón de tokens de entrada y 15 dólares por millón de tokens de salida, frente a los 5 y 25 dólares de Claude Opus 4.6. La variante Pro es una historia diferente: con un precio de 30 y 180 dólares, cuesta más de siete veces lo que cuesta la versión estándar y es considerablemente más cara que Opus.

Lo que todavía no se ha verificado es que todas estas pruebas fueron publicadas por OpenAI. A 6 de marzo de 2026, no existen resultados independientes de terceros en Arena.ai ni en Artificial Analysis. Conviene interpretar estas cifras como orientativas hasta que exista una validación independiente.

Por qué los lanzamientos se producen tan rápido

GPT-5.1 en noviembre. GPT-5.2 en diciembre. GPT-5.3-Codex en febrero. GPT-5.4 en marzo. Cuatro versiones incrementales en cuatro meses. Mientras tanto, Anthropic lanzó Claude 4.5 y 4.6. Google lanzó Gemini 3 y 3.1. Solo durante febrero se lanzaron Gemini 3.1 Pro, Claude Opus 4.6 y GPT-5.3-Codex. Ahora GPT-5.4 llegó a principios de marzo. Cuatro modelos de frontera en aproximadamente un mes.

Este ritmo no es normal. Y no se debe a que los laboratorios hayan realizado cuatro descubrimientos revolucionarios consecutivos.

Imagen del autor — Los tres paradigmas de escalado: el preentrenamiento llegó a rendimientos decrecientes y la industria se orientó hacia el posentrenamiento y el cómputo durante la inferencia.

La verdadera causa es que el escalado del preentrenamiento llegó a un punto de rendimientos decrecientes. El modelo interno de próxima generación de OpenAI —Orion— mostró avances mucho menores que el salto de GPT-3 a GPT-4. Según algunos informes, el equipo de Gemini de Google obtuvo «resultados decepcionantes» en su siguiente proceso de entrenamiento. Una investigación de la Universidad de California en Berkeley —Snell y colaboradores— confirmó lo que los laboratorios ya observaban internamente: en tareas fáciles y de dificultad media, dedicar más capacidad de cómputo durante la inferencia suele producir mejores resultados que dedicarla al preentrenamiento.

Ilya Sutskever, antiguo científico jefe de OpenAI, lo expresó sin rodeos:

«La década de 2010 fue la era del escalado. Ahora volvemos a estar en la era del asombro y el descubrimiento».

Por eso, los laboratorios cambiaron de dirección. No hacia una sola novedad, sino hacia tres:

1. Aprendizaje por refuerzo durante el posentrenamiento: aprendizaje por refuerzo aplicado después del preentrenamiento para perfeccionar capacidades específicas, como el razonamiento, la programación y el uso de herramientas.
2. Cómputo durante la inferencia: dedicar más capacidad de cómputo a «pensar durante más tiempo» en el momento de la inferencia, en lugar de entrenar modelos más grandes.
3. Capacidades de los agentes: uso de computadoras, búsqueda de herramientas y flujos de trabajo de varios pasos; funciones pertenecientes a la capa de producto que no requieren un nuevo modelo base.

Esta es la verdad contraintuitiva: todas las funciones destacadas de GPT-5.4 son innovaciones aplicadas durante la inferencia. Tool Search ahorra tokens durante la inferencia. El uso de computadoras ejecuta ciclos de captura de pantalla → acción durante la inferencia. El modo Thinking amplía el razonamiento durante la inferencia. La ventana de contexto de un millón de tokens procesa más datos durante la inferencia. Ninguna de estas funciones necesitó un modelo base fundamentalmente más grande o inteligente; necesitaron una mejor capa de producto a su alrededor.

Esto explica el rápido ritmo de lanzamientos. Cuando el ciclo principal de innovación pasa de «entrenar un modelo más grande» —un ciclo de 18 meses— a «lanzar una mejor capa de producto» —un ciclo de semanas o meses—, es posible publicar nuevas versiones con mucha más frecuencia. Cada lanzamiento representa un movimiento en la capa de producto, no un avance revolucionario en el entrenamiento.

La presión financiera aumenta todavía más la velocidad. OpenAI recaudó 110,000 millones de dólares con una valoración de 840,000 millones en febrero de 2026, mientras proyectaba pérdidas de 14,000 millones de dólares para ese año. En ese mismo mes, los ingresos anualizados de Anthropic alcanzaron los 14,000 millones de dólares, después de crecer diez veces interanualmente durante tres años consecutivos. La carrera por la cuota de mercado no espera al siguiente proceso de preentrenamiento.

Los ingenieros de OpenAI se marchan a Anthropic en una proporción de ocho a uno. La tasa de retención de OpenAI es del 67%, frente al 80% de Anthropic. Cuando el talento abandona tu empresa y los inversionistas necesitan pruebas de que existe impulso, aceleras los lanzamientos, independientemente de que tengas o no un avance revolucionario en el entrenamiento que presentar.

La conclusión sincera es esta: deja de tratar cada lanzamiento como un salto radical en las capacidades. Trátalo como una nueva iteración del producto. Los modelos no se están volviendo considerablemente más inteligentes por cada dólar invertido en entrenamiento. Se están volviendo considerablemente más eficientes a la hora de utilizar lo que ya saben.

La verdadera guerra está una capa más arriba

Si los modelos se están volviendo intercambiables y las pruebas de referencia están convergiendo, ¿hacia dónde se desplazó la competencia?

Sigue el dinero. Claude Code pasó de no generar ingresos a alcanzar aproximadamente 2,500 millones de dólares anualizados en unos nueve meses. Claude posee el 54% del mercado empresarial de programación, más del doble que el 21% de OpenAI. Anthropic también superó a OpenAI en la cuota general del mercado empresarial de modelos de lenguaje de gran tamaño: 32% frente a 25%, mientras que OpenAI poseía un 50% apenas dos años antes.

El hecho de que GPT-5.4 apunte directamente a Claude Code no es una estrategia centrada en la calidad del modelo. Es una estrategia para recuperar cuota de mercado.

La convergencia en torno a MCP es la prueba más clara. Anthropic creó el Model Context Protocol en noviembre de 2024. Para marzo de 2025, OpenAI ya lo había adoptado en Agents SDK, Responses API y la aplicación de escritorio de ChatGPT. En diciembre de 2025, ambas empresas cofundaron la Agentic AI Foundation bajo la Linux Foundation para administrar MCP como un estándar compartido. Google, Microsoft, Amazon y decenas de empresas se incorporaron como miembros.

Cuando un competidor adopta tu protocolo y después cofunda contigo una organización para mantenerlo, la competencia ya no está en la capa del protocolo. Se ha trasladado por encima de ella.

Las habilidades cuentan la misma historia. En diciembre de 2025, Anthropic publicó la especificación Agent Skills como un estándar abierto. OpenAI adoptó el mismo formato SKILL.md para Codex CLI. Una misma habilidad puede ejecutarse ahora en Claude Code, Codex CLI, Gemini CLI, Cursor y Windsurf. Solo en SkillsMP hay más de 350,000 habilidades indexadas. El ecosistema de complementos de Claude Code ha crecido hasta superar los 9,000 paquetes.

El modelo subyacente se está convirtiendo en una pieza de infraestructura intercambiable. La diferenciación se encuentra ahora en:

• Quién posee el ecosistema más completo: Claude Code cuenta con más de 9,000 complementos y 5.2 millones de instalaciones en VS Code, frente a los 4.9 millones de Codex.
• Quién dispone del mejor entorno de ejecución de agentes: subagentes, hooks, Agent Teams y modelos de permisos.
• Quién se apropia del flujo de trabajo de los desarrolladores: una vez que un equipo construye su forma de trabajar alrededor de los servidores MCP, los hooks y las convenciones de CLAUDE.md de una herramienta, los costos de cambiar a otra plataforma son reales.

Esto no es una observación teórica. Ya puede apreciarse en la adopción. Aunque Claude Code se publicó varios meses después que Codex CLI, lidera en instalaciones de VS Code —5.2 millones frente a 4.9 millones— y en valoraciones —4.0 frente a 3.4 en una escala de cinco puntos—. La barrera competitiva del ecosistema se está formando ahora mismo.

La verdadera conclusión es esta: la próxima vez que se lance un modelo nuevo y sus resultados parezcan impresionantes, pregúntate si modifica el entorno de ejecución de agentes, el ecosistema o la capacidad de apropiarse del flujo de trabajo. Si solo mejora las puntuaciones del modelo, su impacto competitivo será menor de lo que sugiere el comunicado de lanzamiento.

Dos apuestas, dos arquitecturas

Si la capa del modelo se está volviendo intercambiable y la capa del protocolo es compartida, ¿por qué Claude Code y Codex CLI se sienten tan diferentes al utilizarlos? Porque se construyeron sobre filosofías arquitectónicas fundamentalmente distintas.

La apuesta de OpenAI con GPT-5.4

Consiste en consolidarlo todo dentro de un único modelo: la programación de GPT-5.3-Codex, el razonamiento de la serie O, el uso de computadoras de Operator y Tool Search para mejorar la eficiencia. Un modelo unificado, basado primero en la nube y eficiente en el uso de tokens.

El mensaje para nosotras es este: no necesitas pensar qué modelo utilizar; GPT-5.4 se encarga de todo. La lógica empresarial: 900 millones de usuarios semanales, una posible salida a bolsa durante el cuarto trimestre de 2026 y una estrategia de plataforma que se expande mediante la amplitud de sus capacidades.

La apuesta de Anthropic con Claude Code

Consiste en profundizar en la capa de los agentes. El modelo —Opus 4.6— es excelente, pero no es el producto. El producto es el entorno de ejecución nativo de terminal: subagentes que delegan tareas con sus propias instrucciones y permisos, Agent Teams para coordinar en paralelo varias sesiones, servidores MCP que incorporan en tiempo real contexto procedente de Jira, Google Docs y Slack, y un ecosistema de más de 9,000 complementos.

La lógica empresarial: el 85% de los ingresos procede de empresas, posee el 54% del mercado de programación y espera alcanzar un flujo de caja positivo para 2027.

Estas herramientas no compiten sobre el mismo eje. Una está optimizada para la amplitud: hacer adecuadamente todo dentro de un único modelo. La otra está optimizada para la profundidad: realizar tareas complejas de ingeniería de software de manera excepcional mediante una capa de agentes muy completa.

La diferencia se manifiesta en el uso diario. Codex CLI es de código abierto —está escrito en Rust—, es rápido y cuenta con un modelo claro de permisos en tres niveles: sugerir, editar automáticamente y automatización completa. Le asignas una tarea y la ejecuta rápidamente.

Claude Code requiere una mayor inversión inicial: archivos CLAUDE.md, configuración de hooks y preparación de subagentes. Sin embargo, una vez configurado, puede gestionar en un solo flujo de trabajo funcionalidades que abarcan varios archivos y afectan al frontend, el backend, la base de datos y la documentación.

Las culturas de ingeniería para las que están optimizadas también son diferentes. Codex CLI encaja con equipos que buscan velocidad, poca fricción y un «becario rápido» para realizar iteraciones rápidas. Claude Code encaja con equipos que necesitan un «desarrollador sénior» para el razonamiento arquitectónico, las refactorizaciones complejas y la comprensión profunda de una base de código.

El planteamiento sincero es que no se trata de preguntar «¿cuál es mejor?», sino «¿qué problema estás intentando resolver?».

Una señal que conviene observar es la convergencia. Codex CLI incorporó recientemente compatibilidad con MCP y un sistema de habilidades. Claude Code incorporó recientemente el modo /fast y optimizaciones de velocidad. Ambos se están desplazando hacia las fortalezas del otro. La pregunta para 2026 es si la división arquitectónica se profundizará o si ambas herramientas terminarán haciendo lo mismo y solo se diferenciarán por la dependencia de sus respectivos ecosistemas.

Existe un punto ciego en ambas filosofías que merece ser mencionado. Tanto OpenAI como Anthropic presentan el mundo bajo la premisa de que «necesitas nuestro modelo de frontera». Sin embargo, la mayoría de las aplicaciones del mundo real —clasificación, resumen, extracción, chat orientado al cliente y canalizaciones de datos estructurados— no necesitan un modelo de frontera.

Los modelos más pequeños, especializados y de pesos abiertos suelen ofrecer una latencia menor, costos más bajos, un control de implementación más estricto y una calidad equivalente en tareas con un alcance bien definido. La batalla entre GPT-5.4 y Claude Code en el ámbito de los agentes de programación es real, pero solo representa una parte de un panorama mucho más amplio, en el que la respuesta correcta suele ser un modelo más pequeño y ajustado específicamente para el trabajo, no el modelo más grande disponible.

Dónde gana realmente cada uno y por qué «el mejor modelo» es la pregunta equivocada

Esta es la verdad incómoda que no encontrarás en el marketing de OpenAI ni en el de Anthropic: ningún modelo gana en todo. Ni GPT-5.4, ni Opus 4.6, ni Gemini 3.1 Pro. Las pruebas de referencia lo dejan claro: cada modelo lidera en categorías diferentes y las diferencias suelen encontrarse dentro del margen de error.

Pero existe una segunda capa que las pruebas de referencia no representan en absoluto: el entorno de ejecución, es decir, la capa de agentes situada sobre el modelo. Aquí es donde la conversación se vuelve confusa.

La gente afirma que «Claude Code gana en las refactorizaciones de varios archivos». Esto se debe parcialmente al modelo Opus 4.6, pero principalmente al entorno de ejecución de Claude Code: los subagentes, los hooks y el contexto proporcionado mediante MCP. Separar estas dos capas es importante porque el modelo se está volviendo intercambiable. El entorno de ejecución no.

Ventajas a nivel de modelo: GPT-5.4

• Eficiencia de tokens. Utiliza aproximadamente cuatro veces menos tokens en tareas idénticas. Con un precio de 2.50 y 15 dólares por millón de tokens, frente a los 5 y 25 dólares de Opus 4.6, la diferencia de costos es real para los equipos con grandes volúmenes de uso.
• Uso de computadoras. Obtiene un 75% en OSWorld. Es una capacidad integrada directamente en GPT-5.4, no una función del entorno de ejecución.
• Velocidad en tareas sencillas. La inferencia es entre tres y cinco veces más rápida para correcciones rápidas, scripts y prototipos. Se trata de rendimiento a nivel de modelo.

Ventajas a nivel de modelo: Opus 4.6

• Programación compleja. Obtiene un 80.8% en SWE-Bench Verified. El propio modelo razona mejor cuando trabaja con bases de código compuestas por varios archivos.
• Razonamiento visual. Obtiene un 85.1% en MMMU Pro, la puntuación más alta de los tres modelos de frontera.
• Razonamiento arquitectónico profundo. En las tareas donde la exhaustividad importa más que la velocidad, el razonamiento extendido de Opus 4.6 produce resultados más confiables.

Ventajas a nivel de modelo: Gemini 3.1 Pro

• Razonamiento científico. Obtiene un 94.3% en GPQA Diamond, la puntuación más alta de los tres.
• Razonamiento abstracto. Obtiene un 77.1% en ARC-AGI-2.
• Ventana de contexto. Un millón de tokens de forma nativa, sin facturación doble en los primeros 272,000 tokens.

Ventajas a nivel del entorno de ejecución: Codex CLI

• Código abierto. Una base de código escrita en Rust que puede auditarse y ampliarse.
• Integración nativa con GitHub. Revisión automática de solicitudes de incorporación de cambios, integración con CI/CD y diseño orientado al flujo de trabajo de GitHub.
• Poca fricción. Un modelo de permisos con tres niveles —sugerir, editar automáticamente y automatización completa— y una configuración mínima.

Ventajas a nivel del entorno de ejecución: Claude Code

• Orquestación de agentes. Cinco tipos de subagentes, Agent Teams para ejecutar sesiones en paralelo y hooks para controlar el ciclo de vida. Ningún otro entorno de programación iguala este nivel de profundidad.
• Ecosistema MCP. Más de 9,000 complementos y más de 350,000 habilidades indexadas. Jira, Slack, Google Docs y Confluence pueden utilizarse como contexto en tiempo real durante una sesión.
• Apropiación del flujo de trabajo empresarial. Convenciones de CLAUDE.md, permisos específicos para cada herramienta y una configuración profunda. Una vez implementado, el costo de cambiar a otra plataforma es real.

Las áreas de empate son cada vez mayores: programación general en archivos individuales, tareas estándar de razonamiento y revisión de código en solicitudes de incorporación de cambios pequeñas. En estos casos, los modelos están tan cerca que las preferencias personales y la compatibilidad con el ecosistema importan más que las pruebas de referencia.

En 2026, con tres modelos de frontera cuyas diferencias se encuentran dentro del margen de error, la apuesta inteligente está en la capa de orquestación que sea capaz de utilizarlos a todos.

Al ampliar todavía más la perspectiva, la propia tabla comparativa revela el cambio estructural: los modelos se están volviendo intercambiables en tiempo real.

Hace dieciocho meses, elegías un modelo y construías todo alrededor de él. Hoy, los equipos inteligentes con los que hablo están haciendo algo diferente: distribuyen las tareas entre diferentes modelos según lo que cada uno hace mejor.

• ¿Un script rápido? GPT-5.4.
• ¿Una refactorización compleja? Opus 4.6 mediante el entorno de ejecución de Claude Code.
• ¿Síntesis de una investigación? Gemini 3.1 Pro con su ventana de contexto de un millón de tokens.

Cada modelo funciona como un motor especializado, no como una solución universal.

Pero esto es lo que la tabla comparativa de modelos de frontera no muestra: la mayoría de las aplicaciones en producción no necesitan ningún modelo de frontera.

El caso de uso de los agentes de programación —en el que se centra este artículo— sí se beneficia realmente de los modelos más grandes y capaces. El razonamiento entre varios archivos, la planificación arquitectónica y las refactorizaciones complejas llevan al límite las capacidades de los modelos. Sin embargo, cuando sales de la burbuja de los agentes de programación, el panorama cambia por completo.

La clasificación, el resumen, la extracción, las canalizaciones de datos estructurados, el chat orientado al cliente, la moderación de contenidos y la traducción son tareas que se ejecutan a gran escala en entornos de producción y funcionan mejor con modelos más pequeños y especializados.

Modelos de pesos abiertos. Modelos ajustados. Modelos optimizados para ofrecer una menor latencia, costos más bajos y mayor flexibilidad de implementación, en lugar de estar optimizados para obtener mejores puntuaciones en las pruebas de referencia.

Un modelo de 7,000 millones de parámetros correctamente ajustado, que ejecute una tarea específica de extracción con una latencia de 10 milisegundos y un costo de 0.10 dólares por millón de tokens, superará en ese caso de uso a un modelo de frontera que cueste 25 dólares por millón de tokens. No lo superará en las pruebas de referencia, sino en las métricas que realmente importan en producción: costo por consulta, latencia en el percentil 99 y control de implementación.

La tesis de que los modelos se están volviendo intercambiables va más allá de los tres grandes. No se trata solamente de «GPT-5.4 frente a Opus 4.6 frente a Gemini 3.1 Pro». Se trata de «modelos de frontera para tareas de frontera y modelos especializados para todo lo demás».

Los equipos que construyen los sistemas de producción más sólidos no están eligiendo entre OpenAI y Anthropic. Están construyendo arquitecturas independientes del modelo, en las que un modelo de frontera se encarga del razonamiento difícil y un modelo más pequeño gestiona el 80% de las tareas que no necesitan ese nivel de capacidad.

Este es el desenlace lógico de la tendencia descrita en la sección 3. Si todos los modelos de frontera convergen hacia capacidades similares —y lo están haciendo—, la pregunta «¿cuál es el mejor modelo?» deja de ser útil.

La respuesta siempre es: «¿Para qué?». Y para la mayoría de las cargas de trabajo en producción, la respuesta no es el modelo más grande disponible.

Los equipos que están obteniendo más valor actualmente no son leales a un único modelo ni a un único entorno de ejecución. Están construyendo flujos de trabajo independientes del modelo, en los que el entorno de ejecución de agentes dirige cada tarea hacia el modelo que mejor pueda resolverla. MCP y SKILL.md hacen que esto sea posible en la capa del protocolo. La capa del entorno de ejecución hace que sea práctico.

Este es el verdadero cambio. No consiste en afirmar que «GPT-5.4 acabó con Claude Code» o que «Claude Code sigue siendo el rey». El cambio es este: la era de un único modelo que lo domine todo está terminando. La era de la distribución inteligente de tareas está comenzando. Y los entornos de ejecución que ganarán serán aquellos que permitan realizar esa distribución sin fricciones, no los que insistan en que su modelo es el único que necesitas.

Lo que realmente cambiaría en mi flujo de trabajo

Después de todas estas pruebas de referencia, diagramas de arquitectura y teorías sobre la transformación de los modelos en productos intercambiables, ¿qué haría realmente de manera diferente a partir del lunes?

La respuesta breve es que dejaría de utilizar una sola herramienta para todo.

Esta es la versión sincera de mi configuración actual y de los cambios que realizaría, separando las decisiones relacionadas con el modelo de las decisiones relacionadas con el entorno de ejecución.

Lo que mantendría en Claude Code —ventajas del entorno de ejecución—

• Funcionalidades que afectan a varios archivos. Cualquier tarea que afecte al frontend, el backend, las pruebas y la documentación al mismo tiempo. Aquí es donde la arquitectura de subagentes de Claude Code demuestra su valor. No se trata solamente del modelo Opus 4.6, sino del entorno de ejecución coordinando cambios en 12 archivos durante una sola sesión y utilizando una configuración adecuada de CLAUDE.md. El entorno de Codex CLI todavía no puede orquestar ese proceso.
• Sesiones con un uso intensivo de MCP. Cuando necesito que el contexto de Jira, los hilos de Slack y los documentos de Google Docs se incorporen a una sesión de programación, el ecosistema de más de 9,000 complementos de Claude Code no es una comodidad opcional: es una parte esencial de la infraestructura. Esta es una ventaja del entorno de ejecución, no del modelo.
• Decisiones arquitectónicas. Planificación de migraciones, análisis de dependencias y conversaciones como «¿deberíamos dividir este servicio?». En este caso intervienen ambos factores: la exhaustividad del modelo Opus 4.6, con un costo de 25 dólares por millón de tokens de salida, y la gestión profunda del contexto de Claude Code.

Lo que trasladaría a GPT-5.4 y Codex CLI —ventajas del modelo y compatibilidad del entorno—

• Scripts rápidos y correcciones puntuales. El modelo GPT-5.4 es entre tres y cinco veces más rápido. Para solicitudes como «escribe un script de Bash que limpie estos archivos de registro» o «corrige este error de desfase de una unidad», la ventaja de velocidad del modelo es real y encaja con el entorno de ejecución de Codex CLI, que ofrece poca fricción.
• Revisión de solicitudes de incorporación de cambios pequeñas y medianas. El menor costo en tokens —una ventaja del modelo— y la integración nativa de Codex CLI con GitHub —una ventaja del entorno de ejecución— convierten esta combinación en una opción mejor para gestionar grandes volúmenes.
• Tareas de automatización informática. Pruebas de interfaces gráficas, cumplimentación de formularios y automatización de aplicaciones de escritorio. El modelo GPT-5.4 obtiene un 75% en OSWorld. Esta es una verdadera capacidad a nivel de modelo que el entorno de ejecución nativo de terminal de Claude Code no ofrece directamente.

Lo que no necesita ningún modelo de frontera

• API de producción para clasificar, extraer o resumir. Si estás ejecutando una canalización de datos que extrae campos estructurados de documentos, un modelo más pequeño y correctamente ajustado será más rápido, económico y fácil de implementar que cualquier modelo de frontera. No utilices un modelo de 15 dólares por millón de tokens para una tarea que puede resolverse con uno de 0.10 dólares.
• Chat orientado a clientes dentro de dominios limitados. Un modelo de pesos abiertos correctamente ajustado y conectado a una base de conocimiento especializada suele ofrecer una latencia menor y una consistencia mayor que un modelo de frontera que lo sabe todo, pero tarda tres segundos en responder.
• Moderación de contenidos, traducción y generación de resultados estructurados. Estos problemas ya están resueltos en el nivel de los modelos más pequeños. Los modelos de frontera añaden costos sin mejorar la calidad.

Este es el aspecto que el planteamiento «GPT-5.4 frente a Claude Code» omite por completo. Sí, los agentes de programación necesitan el razonamiento de los modelos de frontera. Sin embargo, la mayor parte del software que estás construyendo mediante esos agentes atenderá a los usuarios utilizando modelos más pequeños y especializados. La arquitectura debería reflejarlo: modelos de frontera para el desarrollo y modelos con el tamaño adecuado para la producción.

Lo que observaría antes de comprometerme

1. Pruebas de referencia independientes. Todos los números de este artículo proceden de los propios proveedores o de informes iniciales de terceros. Quiero ver los resultados de GPT-5.4 en Aider, BigCodeBench y LiveCodeBench antes de confiar plenamente en las cifras.
2. Costo de los tokens a gran escala. Una eficiencia cuatro veces mayor suena excelente, pero ¿se mantiene en las tareas complejas o solamente en las sencillas? La clave está en la distribución de los resultados.
3. Madurez de MCP en Codex CLI. Es una función nueva. La implementación de MCP en Claude Code lleva meses utilizándose y probándose en situaciones reales. Hay que darle un trimestre.

La verdad incómoda es que la era de la lealtad a una sola herramienta ha terminado. Utilizar un único modelo y un único entorno de ejecución para todo porque «es el mejor» significa renunciar a una parte del rendimiento.

Los equipos que veo lanzando productos con mayor rapidez a principios de 2026 ya están utilizando configuraciones híbridas. Eligen el modelo adecuado para cada tarea —GPT-5.4 para la velocidad, Opus 4.6 para la profundidad y Gemini 3.1 Pro para la investigación— y el entorno de ejecución adecuado para cada flujo de trabajo —Codex CLI para la velocidad y la integración nativa con GitHub, y Claude Code para una orquestación profunda—.

Hay algo que yo no haría: migrar un flujo de trabajo existente de Claude Code a GPT-5.4 basándome en un artículo publicado el mismo día del lanzamiento.

Las pruebas de referencia necesitan una verificación independiente. La compatibilidad con MCP necesita probarse en producción. Las afirmaciones sobre la eficiencia de los tokens necesitan validarse en situaciones reales y con tareas complejas, no mediante demostraciones cuidadosamente seleccionadas.

Construye una arquitectura híbrida. Distribuye el trabajo según el tipo de tarea. Espera a disponer de datos independientes antes de apostar por completo por cualquier opción.

Ese es el consejo sincero.

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.

Menos tokens y, de alguna manera, ¡más precisión! De hecho, hay todo un estudio que lo respalda.

Resulta que Claude Code nos está cobrando por palabras de cortesía como "Por supuesto". ¡Y eso no es código ni nos soluciona la vida! Frases como "Claro, con gusto te ayudo con eso" o "Lo más probable es que el problema que estás experimentando se deba a..." nos están costando dinero real.

La prueba de fuego

Para quitarme la duda, tomé el mismo error de un elemento de interfaz de usuario en Unity y le pedí a Claude Code que lo explicara dos veces:

• Claude Code por defecto: 1,252 tokens.
• Con la solución mágica: 410 tokens.

La misma corrección. La misma respuesta. La única gran diferencia es que la primera versión se gastó 800 tokens adicionales en pura palabrería innecesaria.

La solución es increíblemente sencilla

Existe un plugin gratuito en GitHub con más de 13,000 estrellas que hace que Claude hable... ¡como un cavernícola! Un truco simple que empieza a cuidar tu bolsillo de inmediato. Y no es broma, el Día de los Inocentes ya pasó hace rato.

Para instalarlo, solo corres esto:

Bash

claude plugin marketplace add JuliusBrussee/caveman
claude plugin install caveman@caveman

¡Y listo! Una instalación superfácil. Después, ejecutas /caveman y el modo cavernícola quedará activado.

¿Cómo se ve Claude en "modo cavernícola"?

Antes de activarlo:

"¡Claro! Estaré encantado de ayudarte con eso. Lo más probable es que el problema que estás experimentando se deba a que tu middleware de autenticación no está validando correctamente la fecha de vencimiento del token. Déjame revisarlo y proponerte una solución".

Después de activarlo:

"Error en middleware de autenticación. Comprobación de vencimiento del token usa < en lugar de <=. Solución:"

Esto no solo te ahorra dinero. Seamos sinceras, ¿cuál de las dos versiones es más rápida y fácil de leer?

La parte que me sorprendió (¡y por completo!)

Es natural pensar que si usamos menos tokens, los resultados serán peores, ¿verdad? Pues nos equivocamos.

Un estudio titulado "Las restricciones de brevedad invierten las jerarquías de rendimiento en los modelos de lenguaje" descubrió justo lo contrario: ¡las respuestas breves mejoraron la precisión en un 26% en las pruebas de rendimiento!

Las respuestas largas no son más inteligentes; simplemente son más caras.

Elige tu nivel de "cavernícola"

Tienes tres opciones para elegir qué tan directa quieres que sea la comunicación:

• Lite (/caveman lite): Recorta un poco el contenido, pero conserva la gramática y mantiene un tono profesional.
• Full (/caveman full): El modo predeterminado. Elimina artículos y usa frases fragmentadas. Va al grano.
• Ultra (/caveman ultra): Lo abrevia TODO. Una palabra es suficiente.

(Dato curioso: También hay un modo de chino clásico para máxima compresión. Otra razón por la que debí haber prestado más atención a las clases de idiomas).

Un extra para optimizar al máximo

Hay otra herramienta complementaria genial llamada caveman-compress.

Como el archivo CLAUDE.md se carga en cada sesión, puede volverse carísimo porque pagas por cada token cada vez que inicias. Este plugin reescribe el contenido de forma ultraeficiente, pero te deja una copia de respaldo que los humanos podemos leer sin problemas. Quienes lo usan reportan ahorros de casi el 45%. ¡Puntazo a favor de optimizar los tokens de entrada!

Mis resultados y cómo empezar

Yo ya instalé el plugin y ahora activo /caveman en todas mis sesiones; me fascina lo conciso que es. Además, desde que comprimo mi archivo CLAUDE.md con esta herramienta, alcanzo mi límite de uso con mucha menos frecuencia.

Si tienes unos minutos libres hoy, te súper recomiendo probarlo:

• Si tienes 5 minutos: Instala el plugin con los comandos de arriba y úso siempre.
• Si tienes 15 minutos: Prueba el modo /caveman ultra en tu próxima sesión y mira cómo baja tu consumo.
• Si tienes 30 minutos: Corre caveman-compress en tu archivo CLAUDE.md para ahorrarte ese 45% extra.

El plugin es completamente gratis y fue creado por Julius Brussee. Date una vuelta por su repositorio de GitHub y déjale una estrella, ¡se lo súper merece!

Nota: No tengo ninguna afiliación con Claude ni con el proyecto Caveman. ¡Solo soy una desarrolladora feliz compartiendo un gran tip de ahorro!

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.

Imagínate esto: son las 11 de la noche de un martes. Estás mirando fijamente un mensaje de error que se siente inquietantemente familiar: Connection refused on port 5432. Ya has estado ahí. Sabes perfectamente que lo resolviste en algún momento, pero... ¿dónde?, ¿cuándo? El mensaje del commit solo dice un vago “fixed db connection”. Stack Overflow te ofrece doce respuestas diferentes y tu asistente de IA te sugiere con entusiasmo soluciones que ya probaste hace una hora.

Esto es la amnesia de la IA en acción, y te está costando bastante más de lo que crees.

Todos los asistentes de programación con IA comparten la misma limitación frustrante: lo olvidan absolutamente todo entre sesiones. Empiezas un nuevo chat y Claude no sabe que ayer pasaste 45 minutos descubriendo que tu entorno de staging usa el puerto 5433, no el 5432. No recuerda que elegiste PostgreSQL en lugar de MongoDB por la experiencia existente de tu equipo. No puede recordar que el error “connection refused” siempre significa que la VPN se desconectó. O, peor aún, empieza a usar una nueva librería de NLP o de gráficos cuando todo el proyecto ya utiliza otra infraestructura y tú ya habías decidido cuál querías. Entonces te ves en la necesidad de explicarlo otra vez. Y otra vez.

¿Todo ese conocimiento ganado con tanto esfuerzo? Desaparece. Cada. Una. De. Las. Veces.

Descubrí una solución sencilla mientras veía un video de YouTube sobre cómo mantener Claude Code actualizado con el contexto del proyecto. El creador enlazaba pequeños archivos Markdown desde su CLAUDE.md para hacer un seguimiento impecable de decisiones, bugs y datos clave. En ese instante tuve un momento de total claridad: ¿y si pudiera crear una skill que gestionara esto de forma automática?

Esa idea se convirtió en project-memory, una de las primeras skills que escribí para Claude Code. A pesar de ser notablemente simple —menos de 300 líneas—, de verdad me ha ahorrado horas y horas de trabajo. Este tutorial te muestra cómo construir tu propia skill de memoria de proyecto y, lo que es aún más importante, cómo pensar en la creación de skills diseñadas para resolver problemas reales.

Es importante destacar que Claude Code ya no es el único jugador en el tablero. Codex, GitHub Copilot y OpenCode han anunciado soporte para Agentic Skills. Incluso existe ya un marketplace de agentic skills compatible con Gemini, Aidr, Qwen Code, Kimi K2 Code, Cursor y más; sumando más de 14 plataformas y contando, con un instalador universal de agentic skills (skilz). A lo largo de esta guía, usaré “Claude” y “agente de programación” de forma intercambiable, tal como cuando decimos “hazme un Xerox” en lugar de “sácame una copia”. Para lo que vale, en mis propios flujos de trabajo prefiero Claude Code, OpenCode y Gemini CLI.

El verdadero coste de la amnesia de la IA

Déjame pintarte una escena que quizás reconozcas a la perfección:

Mes 1: El descubrimiento

• Error: CORS policy blocked request from localhost:3000
• Acción: 2 horas depurando, probando configuraciones de proxy, cambios de headers y reescrituras en nginx.
• Solución: Añadir la configuración de proxy a package.json.

Mes 6: El déjà vu

• Error: CORS policy blocked request from localhost:3000
• Desarrollador: "Esto me suena... ¿cómo lo arreglamos aquella vez?"
• Acción: Busca commits antiguos, revisa Stack Overflow otra vez, le pregunta a Claude (que no tiene memoria).
• Resultado: 1 hora para redescubrir exactamente la misma solución de configuración de proxy.

¿Te suena familiar? Aquí está la verdad incómoda: los asistentes de código con IA en realidad empeoran esta situación en lugar de mejorarla. Sin memoria:

• Cada nueva sesión de chat empieza desde cero conocimiento.
• Cada bug se siente como si lo estuvieras resolviendo por primera vez.
• Las soluciones se “redescubren” repetidamente —en una ocasión resolví el mismo problema de CORS cuatro veces en seis meses—.
• No se acumula aprendizaje con el tiempo, ni para ti ni para tu asistente de IA.

El coste oculto es enorme. Si gastas tan solo 30 minutos por semana resolviendo otra vez problemas que ya habías solucionado, estamos hablando de 26 horas al año. A una tasa estimada de 100 dólares por hora, representan 2.600 dólares de tiempo desperdiciado por cada desarrollador.

Pero... ¿y si tu asistente de IA pudiera recordar?

¿Qué es una Agent Skill de Claude Code?

Antes de adentrarnos en project-memory, entendamos qué son realmente las skills. Si alguna vez has querido enseñarle a Claude un flujo de trabajo específico o darle conocimiento profundo de un dominio, las skills son la respuesta ideal.

Una agent skill es simplemente una carpeta que contiene un archivo SKILL.md y recursos de apoyo opcionales. El archivo SKILL.md consta de dos partes esenciales:

1. YAML frontmatter: Metadatos que le dicen a Claude exactamente cuándo activar la skill.
2. Cuerpo en Markdown: Las instrucciones detalladas que Claude sigue cuando la skill está activa.

Piensa en las skills como “modos expertos” reutilizables que puedes instalar. Cuando indicas “configura la memoria del proyecto”, Claude no se limita a adivinar qué quieres decir; carga instrucciones específicas y probadas minuciosamente para esa tarea.

Anatomía de la estructura de una Agent Skill

Estructura del archivo SKILL.md mostrando YAML frontmatter con nombre y descripción, y cuerpo en Markdown con secciones para Overview, When to Use, Core Capabilities, Examples y Success Criteria.

Las skills normalmente pueden vivir en dos ubicaciones estratégicas:

Guarda skills en tu directorio home de usuario ~/.claude/skills/. Estas están disponibles globalmente en todos los proyectos y son para skills de propósito general como revisión de código o documentación. Luego puedes tener skills específicas de proyecto que viven en .claude/skills/. Estas son locales solo para ese proyecto: flujos de trabajo específicos del proyecto y convenciones del equipo. Digo normalmente porque puedes tener skills empresariales, skills compartidas a nivel de monorepo, etc. Y también depende de qué proveedor estés usando: ~/.codex/skills/, ~/.config/opencode/skill/, ~/.gemini/skills/, .claude/skills/, .codex/skills/, .opencode/skills/, solo por nombrar algunas.

💡 Un pequeño truco: ejecuta ls ~/.claude/skills/ para ver qué herramientas tienes ya instaladas. Si el directorio todavía no existe, se creará de forma automática cuando instales tu primera skill.

Cómo funciona la activación de skills

Cuando haces una petición, Claude Code sigue un patrón de revelación progresiva para escribir agentic skills. Solo carga lo que necesita, en el momento preciso en que lo necesita. Esto mantiene las interacciones sumamente rápidas mientras te da acceso a capacidades potentes bajo demanda.

Diagrama de flujo de activación de skills que muestra tres fases: Discovery —escanear directorios, cargar metadatos—, Matching —comprobar si la petición coincide con una skill— y Execution —cargar SKILL.md, seguir instrucciones, completar la tarea—.

La idea clave es hermosa por su eficiencia: Claude escanea los directorios de skills y lee únicamente los metadatos —nombre y descripción— hasta que encuentra una coincidencia. Solo en ese momento carga las instrucciones completas. Esto significa que puedes tener decenas de skills instaladas sin ralentizar en lo absoluto tus interacciones habituales.

Ahora que comprendemos la mecánica, veamos cómo project-memory la pone en práctica.

La Agent Skill de Project Memory

La skill project-memory crea un sistema de conocimiento estructurado dentro de docs/project_notes/ con cuatro archivos especializados. Cada uno cumple un propósito muy claro para preservar y recuperar el conocimiento del proyecto.

Estructura de archivos de memoria

Estructura de archivos de memoria de proyecto que muestra la carpeta docs/project_notes/ con bugs.md, decisions.md, key_facts.md e issues.md, además de los archivos de configuración CLAUDE.md y AGENTS.md.

Cada archivo de memoria cumple un rol específico en la captura de conocimiento del proyecto. Por ejemplo, bugs.md actúa como una base de datos de bugs buscable, donde entradas como “BUG-018: Pulumi state drift — run pulumi refresh — yes” documentan tanto el problema como su solución, evitando pérdidas de tiempo futuras cuando el mismo problema reaparece. Uso esto para hacer seguimiento de problemas recurrentes del proyecto. El archivo decisions.md rastrea elecciones arquitectónicas mediante ADRs —Architectural Decision Records—, como “ADR-012: Use D3.js for all charts (team expertise)”, asegurando consistencia y evitando decisiones tecnológicas conflictivas más adelante. Mientras tanto, key_facts.md sirve como referencia rápida para detalles esenciales del proyecto como “Staging API: https://api.staging.example.com:8443”, eliminando las conjeturas sobre puertos y URLs. Por último, issues.md mantiene un registro cronológico de trabajo con entradas como “TICKET-456: Implemented user auth — 2024-01-15”, creando una pista de auditoría que conecta el trabajo completado con tickets y fechas específicos.

Permíteme desglosar cómo funciona minuciosamente cada sección de esta skill.

Parte 1: El frontmatter de la Agent Skill —el “cuándo” de tu skill—

YAML

---
name: project-memory
description: Set up and maintain a structured project memory system in docs/project_notes/
  that tracks bugs with solutions, architectural decisions, key project facts, and work
  history. Use this skill when asked to "set up project memory", "track our decisions",
  "log a bug fix", "update project memory", or "initialize memory system".
---

El campo description es absolutamente crítico; me atrevería a decir que es la parte más importante de tu skill. Le indica a Claude con precisión cuándo activarla. Fíjate en las frases específicas de activación incluidas: “set up project memory”, “track our decisions”, “log a bug fix”. Cuando pronuncias cualquiera de estas, Claude reconoce la coincidencia y despliega las instrucciones completas (puedes ver la skill completa al final del artículo).

💡 Una recomendación de diseño: cuando escribas tus propias descripciones de skills, incluye de 3 a 5 frases específicas que usarías de forma natural en el día a día. Prueba la activación con variaciones como: “help me track decisions” vs “set up decision tracking” vs “I want to log our architectural choices”.

Parte 2: Cuándo usar esta Agent Skill —disparadores contextuales—

Markdown

## When to Use This Skill

Invoke this skill when:
- Starting a new project that will accumulate knowledge over time
- The project already has recurring bugs or decisions that should be documented
- The user asks to "set up project memory" or "track our decisions"
- Encountering a problem that feels familiar ("didn't we solve this before?")
- Before proposing an architectural change (check existing decisions first)

Esta sección refuerza los disparadores y ayuda a Claude a comprender el contexto más amplio en el que la memoria resulta verdaderamente útil. La frase “¿no resolvimos esto antes?” es especialmente poderosa, pues captura el momento exacto de frustración donde la memoria llega al rescate.

Parte 3: Instrucciones de configuración inicial —el “qué” de tu Agent Skill—

Markdown

## Core Capabilities

### 1. Initial Setup - Create Memory Infrastructure

When invoked for the first time in a project, create the following structure:

docs/
└── project_notes/
    ├── bugs.md         # Bug log with solutions
    ├── decisions.md    # Architectural Decision Records
    ├── key_facts.md    # Project configuration and constants
    └── issues.md       # Work log with ticket references

**Directory naming rationale:** Using `docs/project_notes/` instead of `memory/`
makes it look like standard engineering organization, not AI-specific tooling.

Esta decisión de diseño es más profunda de lo que parece a simple vista: haz que la memoria luzca como documentación normal. Si creas archivos en carpetas como ai-memory/ o claude-context/, el equipo de desarrollo tenderá a verlo como un simple accesorio de la IA y terminará ignorándolo. En cambio, guardarlo en docs/project_notes/ le da el estatus de documentación estándar de ingeniería que cualquiera puede —y debe— actualizar, use o no asistencia de IA.

Parte 4: Formatos de entradas de memoria —conocimiento estructurado—

La skill define formatos consistentes para cada tipo de entrada. La consistencia es clave porque Claude puede analizar formatos estructurados de forma sumamente fiable, incluso meses después:

Comparación lado a lado del formato de entrada de bugs.md —Issue, Root Cause, Solution, Prevention— y el formato ADR de decisions.md —Context, Decision, Alternatives, Consequences—.

El campo Prevention en el registro de bugs es un verdadero tesoro. Transforma los problemas cotidianos de simples “cosas que arreglamos” a “lecciones que aprendimos”. Así, dentro de seis meses, Claude podrá advertirte elegantemente antes de que vuelvas a caer en la misma trampa.

Parte 5: Protocolos de memoria para CLAUDE.md —la verdadera magia—

Aquí es donde reside el verdadero poder. La skill configura tu CLAUDE.md para que el asistente sea consciente de la memoria por defecto:

Markdown

### 2. Configure CLAUDE.md - Memory-Aware Behavior

Add or update the following section in the project's `CLAUDE.md` file:

## Project Memory System

### Memory-Aware Protocols

**Before proposing architectural changes:**
- Check `docs/project_notes/decisions.md` for existing decisions
- Verify the proposed approach doesn't conflict with past choices

**When encountering errors or bugs:**
- Search `docs/project_notes/bugs.md` for similar issues
- Apply known solutions if found
- Document new bugs and solutions when resolved

**When looking up project configuration:**
- Check `docs/project_notes/key_facts.md` for credentials, ports, URLs
- Prefer documented facts over assumptions

Una vez que estos protocolos quedan establecidos en CLAUDE.md, Claude revisará de manera automática los archivos de memoria antes de tomar decisiones o sugerirte código. Ya no tendrás que acordarte de decirle "revisa el registro de bugs"; se convierte, de forma orgánica, en su comportamiento por defecto.

Impacto en el mundo real: el interés compuesto del conocimiento

Déjame compartir contigo algunos ejemplos muy concretos de cómo la memoria transforma nuestros flujos de trabajo cotidianos.

Resolución de bugs con memoria

Diagrama comparativo que muestra la resolución de bugs sin memoria —45 minutos depurando desde cero— frente a con memoria —5 minutos buscando una solución conocida en bugs.md—.

Personalmente he desperdiciado demasiadas horas persiguiendo problemas que ya había visto en el pasado, por lo que estimar 45 minutos se queda bastante corto frente al ahorro potencial real. Y no es solo el tiempo; es la frustración que te ahorras.

Ejemplo 1: Velocidad de resolución de bugs —números reales—

El escenario real fue el siguiente: El 20 de octubre me encontré con un error de desviación de estado de Pulumi durante un despliegue. El mensaje de error era bastante críptico: error: update failed. Tras 45 minutos de intensa depuración revisando permisos IAM, cambios recientes y probando diferentes estrategias, descubrí la solución: ejecutar pulumi refresh --yes para sincronizar el archivo de estado.

Lo documentamos de inmediato como BUG-018:

Markdown

### 2024-10-20 - BUG-018: Pulumi State Drift During Deploy

**Issue**: Deploy failed with cryptic "update failed" error after manual GCP console changes
**Root Cause**: Pulumi state file out of sync with actual infrastructure after teammate made console changes
**Solution**: Run `pulumi refresh --yes` before deploy to sync state
**Prevention**: Add `pulumi refresh --yes` to CI/CD pipeline before deploys; document that manual console changes require refresh

Tan solo dos días después, el 22 de octubre, volvió a aparecer exactamente el mismo error. Esta vez, el flujo fue una seda:

1. Le comenté a Claude la situación del error.
2. Claude revisó ágilmente bugs.md y localizó el registro BUG-018.
3. Me sugirió de inmediato ejecutar pulumi refresh --yes.
4. Problema resuelto en solo 5 minutos.

El resultado: Redujimos el tiempo de 45 a solo 5 minutos. Una espectacular reducción del 89% en el tiempo de resolución.

Ejemplo 2: Consistencia arquitectónica —evitando el aumento del bundle—

Sin memoria:

• Usuario: "Añade un gráfico de barras al dashboard."
• Claude: "Perfecto, añadiré Chart.js para el gráfico de barras. Déjame instalarlo..."
• Resultado: Tamaño del bundle +85 KB, dependencias duplicadas para gráficos y estilos inconsistentes.

Con memoria:

• Usuario: "Añade un gráfico de barras al dashboard."
• Claude: (Revisando silenciosamente decisions.md...) "Veo que en el ADR-012 decidimos usar D3.js para todos los gráficos dado que el equipo tiene experiencia en ella y ya se encuentra en el bundle. Crearé el gráfico de barras usando D3 para mantener la consistencia."
• Resultado: Reutilización de la infraestructura existente, estilo impecable y cero aumento innecesario del bundle.

Esta clase de consistencia se acumula de manera hermosa. Una sola decisión bien documentada sobre una librería te evita docenas de conflictos de dependencias en el futuro.

El efecto del interés compuesto

Línea de tiempo de interés compuesto del conocimiento que muestra la progresión desde el primer encuentro —2 horas depurando—, a la documentación, al segundo encuentro —5 minutos—, al tercero —2 minutos—, hasta el consejo preventivo.

La captura de conocimiento devuelve beneficios con un interés compuesto asombroso. Observa la progresión en el diagrama: para el cuarto encuentro, Claude no solo arregla el bug, sino que lo previene: “Veo que estás a punto de hacer un cambio que antes causó problemas de desviación de estado. ¿Te gustaría que ejecute pulumi refresh primero?”

Tu proyecto se vuelve sustancialmente más fácil de mantener con el tiempo. Ese es el verdadero valor de la persistencia de contexto.

Multiplataforma: el estándar Agent Skill

Aquí viene una de las características más potentes: project-memory no está limitada en exclusiva a Claude Code. Sigue el estándar abierto Agent Skill Standard (agentskills.io), lo que significa que la misma skill funciona a la perfección en más de 14 asistentes de programación con IA. También incluye instrucciones nativas para mantener actualizado tu archivo AGENTS.md.

¿Por qué es esto tan valioso? En los equipos es normal que coexistan diferentes herramientas. Un desarrollador puede adorar Claude Code, otra prefiere Cursor y un tercero se siente más cómodo con GitHub Copilot. Con skills estandarizadas, absolutamente todo el equipo comparte la misma memoria central del proyecto.

Diagrama que muestra cómo Agent Skill Standard permite que una skill funcione en Claude Code, Codex, Gemini, Cursor y más.

Instalación multiplataforma

Diagrama de instalación de skills multiplataforma que muestra GitHub y el marketplace SkillzWave como fuentes, la CLI skilz como instalador, distribuyendo a Claude Code, Codex, Gemini, Cursor, Copilot y más agentes de IA.

Gracias a que las agent skills se han vuelto maravillosamente multiplataforma, podemos usar instaladores universales muy cómodos. Puedes obtenerlas desde GitHub o desde el marketplace de agentes SkillzWave utilizando la CLI open source skilz:

Bash

# Instalación de la CLI
pip install skilz

# Instalar para Claude Code de forma global (disponible en todos tus proyectos)
skilz install -g https://github.com/SpillwaveSolutions/project-memory

# Instalar exclusivamente para un proyecto específico
skilz install -g https://github.com/SpillwaveSolutions/project-memory --project

# Instalar para otros asistentes del equipo
skilz install -g https://github.com/SpillwaveSolutions/project-memory --agent codex
skilz install -g https://github.com/SpillwaveSolutions/project-memory --agent gemini
skilz install -g https://github.com/SpillwaveSolutions/project-memory --agent cursor
skilz install -g https://github.com/SpillwaveSolutions/project-memory --agent opencode

El mismo conocimiento, perfectamente accesible desde cualquier herramienta que decidas usar. Cuando documentas una solución en Claude Code, tu compañera que usa Cursor o Gemini se beneficiará de ese valioso contexto al día siguiente.

Visualización de project-memory en el marketplace Skillz con instrucciones de instalación para varias plataformas de agentes de programación.

Seguridad: lo que jamás debes guardar

Esta sección es de lectura obligatoria y crítica antes de que comiences a utilizar la memoria del proyecto.

El archivo key_facts.md está diseñado para ser una consulta sumamente cómoda de la configuración de tu proyecto. Sin embargo, sabemos que la comodidad a veces coquetea con el riesgo si bajamos la guardia. Nunca guardes secretos en tus archivos de memoria. Recuerda que son archivos Markdown versionados que cualquiera con acceso al repositorio de Git podrá leer.

🚫 La zona de peligro (Nunca lo guardes aquí)

• Credenciales de autenticación: Contraseñas, claves de API, tokens de acceso o secretos personales.
• Claves de cuentas de servicio: Archivos JSON de GCP/AWS, claves privadas o credenciales de cuentas de servicio.
• Secretos OAuth: Secretos de cliente, refresh tokens o configuraciones de aplicaciones.
• Credenciales de bases de datos: Cadenas de conexión que expongan contraseñas explícitas.
• Secretos de infraestructura: Claves SSH privadas, accesos de VPN o credenciales de red.

La zona segura (Totalmente bienvenido)

• Hostnames y URLs: Dominios públicos o de desarrollo como api.staging.example.com o https://api.example.com/v1.
• Números de puerto: Estándares como PostgreSQL (5432) o Redis (6379).
• Identificadores de proyecto: IDs de proyectos en GCP, cuentas de AWS o nombres similares que no sean sensibles.
• Correos de cuentas de servicio: Identidades como service-account@project.iam.gserviceaccount.com.
• Nombres de entornos: Etiquetas claras como staging, production o dev.
• Endpoints públicos: Cualquier URL de API accesible.
• Valores de configuración: Ajustes de timeouts, reintentos o feature flags.

🔑 Dónde deben vivir realmente los secretos

• Archivos .env (siempre incluidos en tu .gitignore): Lo ideal para desarrollo local (DATABASE_PASSWORD=secret123).
• Gestores de secretos en la nube: Para producción siempre debemos apoyarnos en herramientas como GCP Secret Manager, AWS Secrets Manager o Azure Key Vault.
• Variables de CI/CD: Configuraciones protegidas en GitHub Actions, GitLab CI/CD, etc.
• Gestores de contraseñas de equipo: Espacios compartidos y seguros como 1Password, LastPass o Bitwarden.

💡 Una pequeña tarea proactiva: tómate dos minutos para buscar en tu estructura actual términos como password, secret, key o token. Si encuentras algo comprometido, muévelo de inmediato a un lugar seguro y rota las credenciales. Vivimos en una sociedad civilizada y tenemos reglas de seguridad. :)

Errores comunes —y cómo evitamos caer en ellos—

Después de implementar project-memory en docenas de proyectos y guiar a muchos equipos en su adopción, he notado ciertos patrones de tropiezos comunes. Te los comparto para que puedas saltártelos:

Error 1: El pueblo fantasma de la documentación

• El problema: Instalas el sistema con muchísimo entusiasmo, creas tres entradas iniciales y no lo vuelves a tocar. Meses después, los archivos están obsoletos y ya no sirven.
• La solución: Integra las actualizaciones de memoria de forma orgánica en tu flujo de trabajo diario, no en tu lista de pendientes pendientes. Al resolver un bug, dile a Claude: “Registra esto en bugs.md”. Al cerrar una discusión técnica: “Añade un ADR para esta decisión”. Hazlo un reflejo intuitivo.
• Nota avanzada: He desarrollado también una skill avanzada que divide las tareas entre un agente arquitecto, un agente de código y un humano al mando. Esta herramienta instala un hook en Claude o un plugin en OpenCode que escanea automáticamente los logs en segundo plano buscando patrones de decisiones, bugs o datos clave que se te hayan pasado registrar, automatizando el mantenimiento.

Error 2: La entrada del tamaño de una novela

• El problema: Las notas de bugs se transforman en extensos ensayos de varias páginas y los ADRs detallan cada pequeña discusión del canal de Slack. Nadie los lee porque consumen demasiado tiempo.
• La solución: Cada entrada debe poder escanearse con la mirada en menos de 30 segundos. Apóyate de forma estricta en el formato estructurado (Issue, Root Cause, Solution, Prevention). Si necesitas profundizar, simplemente añade un enlace a un documento independiente.

Error 3: El archivo para todo

• El problema: Toda la información comienza a acumularse en key_facts.md hasta volverlo un monolito ilegible de 500 líneas.
• La solución: Respeta el propósito de cada uno de los cuatro archivos: los bugs van en bugs.md, las decisiones arquitectónicas en decisions.md, las configuraciones limpias en key_facts.md y el historial en issues.md. Si el archivo de datos clave supera las 100 líneas, es muy probable que estés camuflando decisiones de diseño como simples datos.

Error 4: La trampa del déjà vu

• El problema: Te topas con ese instante frustrante de: "Yo sé que ya vi este error antes, sé que lo solucionamos, pero no recuerdo cómo", y terminas gastando media hora redescubriendo el hilo negro.
• La solución: Esto es precisamente lo que este sistema viene a erradicar. Ante la menor sensación de familiaridad, tu primer comando debe ser: “Revisa el archivo bugs.md”. El conocimiento tribal o institucional del equipo queda así plasmado al alcance de una consulta rápida, facilitando enormemente el onboarding de nuevos integrantes.

Construyendo tus propias Agent Skills

La skill project-memory es un excelente lienzo que demuestra principios fundamentales de diseño que puedes aplicar a cualquier herramienta que decidas programar en el futuro:

1. Resuelve un punto de dolor real: Comienza a diseñar skills solo cuando notes que te repites demasiado explicándole el mismo contexto a Claude, buscando la misma información una y otra vez, o deseando fervientemente que la IA "simplemente supiera" un detalle de tu arquitectura. Antipatrón: No construyas soluciones para problemas hipotéticos; si no has sentido la frustración del problema, difícilmente darás con la ergonomía de la solución.
2. Mantén un enfoque único (Una skill = Un propósito): Evita la tentación de concebir una "super skill" monolítica. Las herramientas pequeñas y modulares son infinitamente más mantenibles. project-memory gestiona contexto; code-review analiza calidad. Manténlo así de limpio.
3. Diseña disparadores naturales: Añade descripciones conversacionales que usarías de forma cotidiana al hablar con tu asistente ("log this bug", "update key facts"). Evita tecnicismos innecesarios como "initialize documentation subsystem".
4. Usa plantillas visuales claras: Claude responde de manera mucho más fiel ante ejemplos visuales estructurados que ante instrucciones abstractas en prosa. Bríndale siempre una estructura de ejemplo limpia.

Pruébalo tú misma

¿Lista para añadir persistencia de memoria a tus flujos de trabajo? Puedes dejarlo todo listo en menos de cinco minutos siguiendo este inicio rápido:

Bash

# Instala la CLI universal
pip install skilz

# Instala la skill de project-memory de manera global
skilz install https://github.com/SpillwaveSolutions/project-memory

Luego, simplemente abre Claude Code en cualquiera de tus repositorios y dile de manera natural:

"Set up project memory for this project"

Claude se encargará de desplegar toda la infraestructura en docs/, configurar los protocolos en tu CLAUDE.md y dejar el entorno listo para usar. Si deseas ser ultra específica, también puedes indicarle:

"Set up project memory for this project using the project memory skill"O directamente invocarla con: "/project-memory-skill Set up project memory for this project"

La herramienta está diseñada para actualizar tanto CLAUDE.md como AGENTS.md de forma nativa, ya que suelo alternar bastante entre Claude Code y OpenCode en mis flujos diarios de ingeniería.

El reto de tu primera semana

No intentes documentar todo el historial de tu empresa el primer día. Te sugiero un acercamiento gradual y elegante:

• Día 1: Configura la infraestructura de memoria de tu proyecto.
• Día 2: Añade un dato clave a key_facts.md (ese puerto o URL que siempre olvidas).
• Día 3: Registra un bug real en bugs.md inmediatamente después de solucionarlo.
• Día 4: Redacta un pequeño registro de decisión arquitectónica (ADR) en decisions.md.
• Día 5: Pon a prueba el sistema. Pregúntale a Claude sobre el contexto que guardaste en los días previos.

Para el quinto día experimentarás ese maravilloso momento de revelación cuando Claude recuerde con total precisión un detalle que conversaron a inicios de la semana. Ahí es cuando el valor se vuelve tangible.

Ideas de evolución: haciendo la memoria aún mejor

Aunque la estructura actual resuelve de forma brillante el problema central, siempre hay espacio para la sofisticación y la mejora incremental:

1. Generación automática de Tabla de Contenidos: A medida que los archivos crecen más allá de las 50 o 100 entradas, la navegación estructurada se vuelve vital tanto para los desarrolladores humanos como para las búsquedas semánticas de la IA. Implementar una sección de índices dinámicos al inicio de los Markdown agiliza enormemente el descubrimiento parcial de información.
2. Archivado automatizado de registros históricos: Un bug solucionado hace dos años puede generar ruido innecesario en la ventana de contexto actual. Mover de forma automática las entradas antiguas de bugs.md o issues.md hacia archivos históricos como bugs-archive-2025.md mantendrá tu memoria principal ligera, limpia y optimizada. (Nota: los ADRs y los datos clave no se archivan, pues su valor histórico permanece intacto).
3. Detección inteligente multiagente: Hacer que la skill detecte de forma proactiva qué asistentes conviven en el repositorio y configure simultáneamente archivos como CLAUDE.md, GEMINI.md o AGENT.md según las necesidades exactas del equipo.

La belleza de este sistema modular de skills es que nos permite añadir toda esta sofisticación de manera progresiva y sin romper la funcionalidad que ya está operando hoy.

Conclusión: empieza pequeño, acumula rápido

La skill project-memory es intencionadamente minimalista: una carpeta bien estructurada con un SKILL.md y un puñado de plantillas que no superan las 300 líneas en su totalidad. Sin embargo, representa una inversión de altísimo retorno que te ahorrará docenas de horas al eliminar depuraciones redundantes, asegurar la consistencia del diseño arquitectónico y blindar el conocimiento de tu equipo frente a los reinicios de sesión.

A veces, un archivo Markdown estructurado con elegancia y unos protocolos de equipo claros valen más que la automatización más compleja del mercado.

Te extiendo el reto: instala project-memory hoy mismo. Documenta una sola decisión, un bug y una URL esta semana. Descubre el placer de trabajar con una IA que finalmente posee memoria. Tu yo del futuro, esa que no tendrá que solucionar el mismo problema de CORS por quinta vez, te lo agradecerá enormemente.

Recursos útiles

• Project Memory Agent Skill en GitHub: Accede al código fuente completo y ejemplos prácticos.
• Project Memory Agent Skill en el Marketplace de SkillzWave: Instrucciones detalladas de instalación.
• Agent Skill Standard: Especificaciones formales del estándar multiplataforma.
• SkillzWave Marketplace: Explora e instala soluciones diseñadas por la comunidad.
• Repositorio de la CLI skilz: Guías de uso, instalación y código fuente del instalador universal.

¿Has construido alguna skill interesante para solucionar algún dolor de cabeza en tus desarrollos? Me encantaría leerte en los comentarios y conocer lo que estás creando.

#AI #Claude #ClaudeCode #DeveloperTools #Productivity #SoftwareDevelopment #Programming #AICodingAssistant #DevOps #TechTutorial #CodingTips #AITools

Sobre el autor

Rick Hightower es un ejecutivo tecnológico e ingeniero de datos con una trayectoria distinguida liderando el desarrollo de soluciones avanzadas de Machine Learning e Inteligencia Artificial dentro de organizaciones financieras de la lista Fortune 100. Su experiencia equilibra la rigurosidad de los frameworks teóricos con la implementación práctica a escala empresarial.

Rick es el creador de la CLI universal de instalación skilz —compatible con Gemini, Claude Code, Codex y Cursor, entre otros— y cofundador del mayor marketplace de agentic skills a nivel global. Puedes conectar con él a través de sus perfiles profesionales en LinkedIn o Medium para profundizar en estrategias de IA empresarial.

Extensiones y recursos de la comunidad

La comunidad activa alrededor de Claude Code ha diseñado un ecosistema de extensiones sumamente potentes. Te comparto algunas de las soluciones más destacadas desarrolladas por Spillwave Solutions:

Skills de Integración Empresarial

• Notion Uploader/Downloader Agent Skill: Sincroniza contenido Markdown e imágenes directamente con tus espacios de Notion.
• Confluence Agent Skill: Sube y descarga documentación técnica con Confluence de forma transparente.
• JIRA Integration Agent Skill: Creación, lectura y gestión avanzada de tickets de JIRA manejando de forma precisa los campos requeridos.
• Nota: Recientemente diseñé una aplicación de escritorio llamada Agent Skill Viewer, ideal para evaluar la seguridad, enlaces y utilidad de tus herramientas de automatización.

Agentes de Desarrollo Avanzado

• Architect Agent Skill: Eleva Claude Code a un "Modo Arquitecto", permitiéndole coordinar múltiples proyectos y delegar subtareas de desarrollo a otras instancias especializadas de la IA.
• Project Memory Agent Skill: Nuestra solución central para preservar datos críticos, bugs y decisiones arquitectónicas entre sesiones de ingeniería de software.

Visualización y Diseño Técnico

• Design Doc Mermaid Agent Skill: Diseñada especialmente para concebir diagramas de flujo y secuencias Mermaid con acabado profesional para tus documentaciones.
• PlantUML Agent Skill: Genera y extrae diagramas PlantUML directamente desde tu código fuente o archivos Markdown.
• Image Generation Agent Skill: Conexión nativa con Gemini Banana para la creación de assets de diseño e imágenes de documentación.
• SDD Agent Skill: Una guía completa para implementar la metodología de desarrollo guiado por especificaciones (Spec-Driven Development) usando el Spec-Kit de GitHub.
• PR Reviewer Agent Skill: Automatiza por completo la revisión de Pull Requests en GitHub integrando la CLI gh. Analiza criterios de seguridad, cobertura de pruebas y mantenibilidad según los estándares de la industria, generando feedback estructurado listo para aprobación.

Integración de Modelos

• Gemini Agent Skill: Permite delegar de forma elegante tareas específicas hacia los modelos multimodales de Google para flujos colaborativos de IA.

Puedes explorar todo el catálogo de soluciones a medida y automatizaciones impulsadas por IA visitando la página principal de Spillwave Solutions. Encontrarás un sinfín de artículos sobre context engineering y arquitectura en mi blog personal. ¡Asegúrate de seguirme en Medium para no perderte ninguna actualización!

Archivo Markdown completo de la skill

Markdown

---
name: project-memory
description: Set up and maintain a structured project memory system in docs/project_notes/ that tracks bugs with solutions, architectural decisions, key project facts, and work history. Use this skill when asked to "set up project memory", "track our decisions", "log a bug fix", "update project memory", or "initialize memory system". Configures both CLAUDE.md and AGENTS.md to maintain memory awareness across different AI coding tools.
---

# Project Memory
 
## Table of Contents

- [Overview](#overview)
- [When to Use This Skill](#when-to-use-this-skill)
- [Core Capabilities](#core-capabilities)
  - [1. Initial Setup - Create Memory Infrastructure](#1-initial-setup---create-memory-infrastructure)
  - [2. Configure CLAUDE.md - Memory-Aware Behavior](#2-configure-claudemd---memory-aware-behavior)
  - [3. Configure AGENTS.md - Multi-Tool Support](#3-configure-agentsmd---multi-tool-support)
  - [4. Searching Memory Files](#4-searching-memory-files)
  - [5. Updating Memory Files](#5-updating-memory-files)
  - [6. Memory File Maintenance](#6-memory-file-maintenance)
- [Templates and References](#templates-and-references)
- [Example Workflows](#example-workflows)
- [Integration with Other Skills](#integration-with-other-skills)
- [Success Criteria](#success-criteria)

## Overview

Maintain institutional knowledge for projects by establishing a structured memory system in `docs/project_notes/`. This skill sets up four key memory files (bugs, decisions, key facts, issues) and configures CLAUDE.md and AGENTS.md to automatically reference and maintain them. The result is a project that remembers past decisions, solutions to problems, and important configuration details across coding sessions and across different AI tools.

## When to Use This Skill

Invoke this skill when:

- Starting a new project that will accumulate knowledge over time
- The project already has recurring bugs or decisions that should be documented
- The user asks to "set up project memory" or "track our decisions"
- The user wants to log a bug fix, architectural decision, or completed work
- Encountering a problem that feels familiar ("didn't we solve this before?")
- Before proposing an architectural change (check existing decisions first)
- Working on projects with multiple developers or AI tools (Claude Code, Cursor, etc.)

## Core Capabilities

### 1. Initial Setup - Create Memory Infrastructure

When invoked for the first time in a project, create the following structure:

docs/
└── project_notes/
    ├── bugs.md         # Bug log with solutions
    ├── decisions.md    # Architectural Decision Records
    ├── key_facts.md    # Project configuration and constants
    └── issues.md       # Work log with ticket references

Motivo del nombre del directorio: usar docs/project_notes/ en lugar de memory/ hace que parezca una organización estándar de ingeniería, no tooling específico de IA. Esto aumenta la adopción y el mantenimiento por parte de desarrolladores humanos.

Contenido inicial de archivos: copia las plantillas del directorio references/ de esta skill:
- Usa references/bugs_template.md para el bugs.md inicial.
- Usa references/decisions_template.md para el decisions.md inicial.
- Usa references/key_facts_template.md para el key_facts.md inicial.
- Usa references/issues_template.md para el issues.md inicial.
Cada plantilla incluye ejemplos de formato y consejos de uso.

### 2. Configure CLAUDE.md - Memory-Aware Behavior

Add or update the following section in the project's `CLAUDE.md` file:

## Project Memory System

This project maintains institutional knowledge in `docs/project_notes/` for consistency across sessions.

### Memory Files

- **bugs.md** - Bug log with dates, solutions, and prevention notes
- **decisions.md** - Architectural Decision Records (ADRs) with context and trade-offs
- **key_facts.md** - Project configuration, credentials, ports, important URLs
- **issues.md** - Work log with ticket IDs, descriptions, and URLs

### Memory-Aware Protocols

**Before proposing architectural changes:**
- Check `docs/project_notes/decisions.md` for existing decisions
- Verify the proposed approach doesn't conflict with past choices
- If it does conflict, acknowledge the existing decision and explain why a change is warranted

**When encountering errors or bugs:**
- Search `docs/project_notes/bugs.md` for similar issues
- Apply known solutions if found
- Document new bugs and solutions when resolved

**When looking up project configuration:**
- Check `docs/project_notes/key_facts.md` for credentials, ports, URLs, service accounts
- Prefer documented facts over assumptions

**When completing work on tickets:**
- Log completed work in `docs/project_notes/issues.md`
- Include ticket ID, date, brief description, and URL

**When user requests memory updates:**
- Update the appropriate memory file (bugs, decisions, key_facts, or issues)
- Follow the established format and style (bullet lists, dates, concise entries)

### Style Guidelines for Memory Files

- **Prefer bullet lists over tables** for simplicity and ease of editing
- **Keep entries concise** (1-3 lines for descriptions)
- **Always include dates** for temporal context
- **Include URLs** for tickets, documentation, monitoring dashboards
- **Manual cleanup** of old entries is expected (not automated)

### 3. Configure AGENTS.md - Multi-Tool Support

Si el proyecto tiene un archivo AGENTS.md —usado para flujos de agentes o proyectos multiherramienta—, añade los mismos protocolos de memoria. Esto asegura consistencia tanto si usas Claude Code, Cursor, GitHub Copilot u otras herramientas de IA.
- Si AGENTS.md existe: añade la misma sección “Project Memory System” que arriba.
- Si AGENTS.md no existe: pregunta al usuario si quiere crearlo. Muchos proyectos usan múltiples herramientas de IA y se benefician de protocolos de memoria compartidos.

### 4. Searching Memory Files

When encountering problems or making decisions, proactively search memory files:

**Search bugs.md:**
```bash
# Look for similar errors
grep -i "connection refused" docs/project_notes/bugs.md

# Find bugs by date range
grep "2025-01" docs/project_notes/bugs.md

Search decisions.md:

Bash

# Check for decisions about a technology
grep -i "database" docs/project_notes/decisions.md

# Find all ADRs
grep "^### ADR-" docs/project_notes/decisions.md

Search key_facts.md:

Bash

# Find database connection info
grep -A 5 "Database" docs/project_notes/key_facts.md

# Look up service accounts
grep -i "service account" docs/project_notes/key_facts.md

Use Grep tool for more complex searches:

• Search across all memory files: Grep(pattern="oauth", path="docs/project_notes/")
• Context-aware search: Grep(pattern="bug", path="docs/project_notes/bugs.md", -A=3, -B=3)

¡Entendido! Vamos a limpiar todo ese bloque de código residual y a transformarlo en la versión en español con ese toque profesional, sofisticado y sutilmente femenino que unifica todo el blog. Al igual que antes, mantendremos toda la estructura intacta y las secciones técnicas completamente detalladas.

5. Actualización de archivos de memoria

Cuando el usuario solicite actualizaciones o cuando estés documentando problemas resueltos, actualiza el archivo de memoria correspondiente con total precisión:

Añadir un registro de bug:

Markdown

### YYYY-MM-DD - Breve descripción del bug
- **Issue**: Qué salió mal
- **Root Cause**: Por qué sucedió
- **Solution**: Cómo se solucionó
- **Prevention**: Cómo evitarlo en el futuro

Añadir una decisión (ADR):

Markdown

### ADR-XXX: Título de la decisión (YYYY-MM-DD)

**Contexto:**
- Por qué se necesitaba la decisión
- Qué problema resuelve

**Decisión:**
- Qué opción fue elegida

**Alternativas consideradas:**
- Opción 1 -> Por qué se rechazó
- Opción 2 -> Por qué se rechazó

**Consecuencias:**
- Beneficios
- Trade-offs (Cosas que se ceden)

Añadir datos clave (Key Facts):

• Organiza de forma impecable por categorías (Proyecto GCP, Base de datos, API, Desarrollo local, etc.).
• Utiliza listas con viñetas para una lectura rápida y clara.
• Incluye detalles específicos tanto para los entornos de producción como de desarrollo.
• Añade URLs directas para una navegación sin fricciones.
• Nota: Recuerda consultar siempre references/key_facts_template.md para repasar las pautas de seguridad sobre lo que NO debes almacenar.

Añadir un registro de historial de trabajo:

Markdown

### YYYY-MM-DD - TICKET-ID: Breve descripción
- **Status**: Completado / En progreso / Bloqueado
- **Description**: Resumen de 1 o 2 líneas
- **URL**: https://jira.company.com/browse/TICKET-ID
- **Notes**: Cualquier contexto importante o advertencia

6. Mantenimiento de los archivos de memoria

Limpia periódicamente las entradas antiguas:

• Responsabilidad manual: El usuario es completamente responsable de las limpiezas manuales (aquí prescindimos de automatizaciones intrusivas).
• Rotación del registro de bugs: Elimina las entradas de bugs muy antiguas (más de 6 meses) que ya no sean relevantes para el estado actual del stack.
• Archivo del registro de trabajo: Archiva el trabajo completado en issues.md una vez que supere los 3 meses de antigüedad.
• Preserva las decisiones: Mantén intactos todos los registros históricos de ADR; son ligeros y aportan un valor incalculable para comprender la evolución del software.
• Actualización de infraestructura: Modifica proactivamente key_facts.md en el instante preciso en que cambie la configuración del proyecto.

Resolución de conflictos:

• Si propones un camino que entre en conflicto con decisions.md, tómate un momento para explicar por qué se justifica reabrir esa decisión pasada.
• Asegúrate de actualizar la entrada de la decisión principal si la elección tecnológica a largo plazo cambia.
• Añade siempre la fecha de revisión con total claridad para mostrar la evolución arquitectónica.

Plantillas y referencias

Esta skill incluye archivos de plantilla estructurados en el directorio references/ para garantizar un formato perfecto en todo tu equipo:

• references/bugs_template.md – Estructura limpia para el registro de bugs con ejemplos del mundo real.
• references/decisions_template.md – Formato estándar de ADR con ejemplos arquitectónicos.
• references/key_facts_template.md – Organización de datos esenciales acompañada de estrictas directrices de seguridad.
• references/issues_template.md – Formato de historial de trabajo diario con marcadores de posición para tickets.

Cuando comiences a desplegar la infraestructura inicial de memoria, simplemente copia estas plantillas directamente en docs/project_notes/ y personalízalas para adaptarlas al diseño único de tu proyecto.

Flujos de trabajo de ejemplo

Escenario 1: Encontrarse con un bug familiar

• Usuario: "Estoy recibiendo un error 'connection refused' desde la base de datos."
• Acción del agente interno: Escanea automáticamente docs/project_notes/bugs.md buscando la palabra "connection".
• Resultado: Localiza una solución histórica: "Use AlloyDB Auth Proxy on port 5432".
• Resolución: Aplica la solución conocida de inmediato, evitando tener que depurar desde cero.

Escenario 2: Proponer un cambio arquitectónico

• Pensamiento del agente interno: "El usuario podría beneficiarse de usar SQLAlchemy para las migraciones."
• Acción del agente interno: Revisa meticulosamente docs/project_notes/decisions.md antes de actuar.
• Resultado: Encuentra el ADR-002 que estipula que el equipo ya eligió explícitamente Alembic para mantener la alineación técnica.
• Resolución: Utiliza elegantemente Alembic en su lugar, manteniendo la consistencia del proyecto sin esfuerzo.

Escenario 3: El usuario solicita una actualización de memoria

• Usuario: "Añade esa solución de CORS a nuestro registro de bugs."
• Acción del agente interno: Lee docs/project_notes/bugs.md para capturar el contexto actual.
• Resultado: Agrega una nueva entrada impecable detallando la fecha, la causa raíz, la solución y el mecanismo de prevención.
• Resolución: Confirma con amabilidad y gracia al usuario que la adición fue un éxito.

Escenario 4: Buscar la configuración del proyecto

• Pensamiento del agente interno: "Necesito establecer una conexión con la base de datos."
• Acción del agente interno: Consulta docs/project_notes/key_facts.md antes de asumir cualquier parámetro.
• Resultado: Identifica la sección dedicada a la Configuración de la Base de Datos.
• Resolución: Extrae de forma segura las cadenas y parámetros de conexión documentados, dejando a un lado las conjeturas.

Consejos para una gestión efectiva de la memoria

1. Sé proactiva: Revisa los archivos de memoria antes de proponer soluciones o cambios de código.
2. Sé concisa: Mantén las entradas breves (de 1 a 3 líneas para las descripciones).
3. Incluye fechas: Añade siempre fechas precisas para conservar el contexto temporal.
4. Enlaza tu documentación: Incluye URLs directas a tickets, documentos de referencia y dashboards de monitoreo.
5. Sé selectiva: Céntrate en problemas recurrentes o verdaderamente instructivos, no es necesario registrar cada pequeño error tipográfico.

Integración con otras skills

La skill project-memory se complementa de forma hermosa con otras herramientas de tu entorno:

• requirements-documenter: Requisitos -> Decisiones (los ADRs sirven como referencia para los requisitos del proyecto).
• root-cause-debugger: Diagnóstico de bugs -> Registro de bugs (documenta las soluciones inmediatamente después de los arreglos).
• code-quality-reviewer: Problemas de calidad -> Decisiones (registra formalmente los estándares de calidad acordados).
• docs-sync-editor: Cambios de código -> Datos clave (actualiza las notas en el momento en que cambie la configuración).

Cuando utilices estas herramientas en conjunto, considera la actualización de los archivos de memoria como una acción de cierre natural y orgánica.

Criterios de éxito

Esta skill se considera desplegada correctamente cuando:

• Existe el directorio docs/project_notes/ albergando los cuatro archivos de memoria limpios.
• El archivo CLAUDE.md incluye formalmente la sección “Project Memory System” junto con sus protocolos.
• El archivo AGENTS.md refleja estos mismos protocolos (si el archivo existe o si lo solicitaste expresamente).
• Los archivos de memoria siguen con absoluta fidelidad el formato de las plantillas y las guías de estilo estipuladas.
• El asistente de IA comprueba minuciosamente los archivos de memoria antes de sugerir cualquier cambio.
• Puedes solicitar actualizaciones de memoria con total fluidez (por ejemplo, “add this to bugs.md”).
• Los archivos de memoria lucen como documentación de ingeniería estándar y profesional, alejándose por completo de parecer artefactos generados artificialmente por una IA.

---

```markdown
## Consejos para una gestión efectiva de memoria

1. **Sé proactiva**: revisa los archivos de memoria antes de proponer soluciones.
2. **Sé concisa**: mantén las entradas breves —1 a 3 líneas para descripciones—.
3. **Incluye fechas**: siempre incluye fechas para contexto temporal.
4. **Incluye enlaces**: añade URLs a tickets, documentación y dashboards de monitoreo.
5. **Sé selectiva**: enfócate en problemas recurrentes o instructivos, no en cada bug.

## Integración con otras skills

La skill `project-memory` complementa otras herramientas a la perfección:
- **requirements-documenter**: Requisitos -> Decisiones —los ADRs referencian requisitos—.
- **root-cause-debugger**: Diagnóstico de bugs -> Registro de bugs —documentar soluciones después de los arreglos—.
- **code-quality-reviewer**: Problemas de calidad -> Decisiones —documentar estándares de calidad—.
- **docs-sync-editor**: Cambios de código -> Datos clave —actualizar cuando cambia la configuración—.

Cuando utilices estas skills juntas, considera actualizar los archivos de memoria como una acción natural de seguimiento.

## Criterios de éxito

Esta skill está desplegada correctamente cuando:
- Existe el directorio `docs/project_notes/` con los cuatro archivos de memoria limpios.
- `CLAUDE.md` incluye la sección “Project Memory System” con todos sus protocolos.
- `AGENTS.md` incluye los mismos protocolos —si el archivo existe o el usuario lo solicitó—.
- Los archivos de memoria siguen de forma impecable el formato de la plantilla y las guías de estilo.
- El asistente de IA revisa minuciosamente los archivos de memoria antes de proponer cualquier cambio.
- El usuario puede pedir de forma fluida actualizaciones de memoria —por ejemplo, “add this to bugs.md”—.
- Los archivos de memoria parecen documentación estándar de ingeniería, alejándose por completo de lucir como artefactos de IA.

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 pensamiento adaptativo está activado. Los presupuestos manuales desaparecieron. La facturación cambió por completo.

Hace poco vimos una lista con 6 consejos sobre cómo mejorar el uso de la herramienta, pero se omitió por completo una conversación vital: los cambios que rompieron flujos de trabajo enteros y que llegaron de la mano con esta nueva versión.

Esto es lo que no nos contaron.

3 cambios que rompen tu flujo de trabajo

Anthropic acaba de lanzar Opus 4.7. También publicaron una guía de migración, esa que la mayoría de las personas probablemente no va a leer.

Sin embargo, hay 3 cambios críticos que necesitamos conocer ahora mismo:

• budget_tokens ahora devuelve un error 400.
• El nuevo tokenizador está cobrando un 35% más de tokens.
• Los tokens de pensamiento están ocultos por defecto.

Veamos en detalle cada uno de ellos.

1. budget_tokens está roto

Si tu código tiene esta configuración:

JSON

thinking={"type": "enabled", "budget_tokens": 32000}

En Opus 4.7 eso ahora devuelve un error 400. No hubo aviso previo de obsolescencia; simplemente comenzó a fallar.

Esto representa un verdadero dolor de cabeza cuando se trabaja con Opus a gran escala. Los presupuestos de pensamiento, que utilizábamos para mantener el control de los costes, desaparecieron por completo.

Este es el reemplazo que debes implementar:

JSON

thinking={"type": "adaptive"}
output_config={"effort": "xhigh"}

Los niveles de esfuerzo disponibles ahora son: low, medium, high, xhigh —nuevo—, y max.

Debes tener en cuenta que el pensamiento adaptativo está desactivado por defecto en Opus 4.7. Esto significa que el modelo se ejecutará sin procesar pensamientos previos. Te sugiero tener muchísimo cuidado al actualizar el nombre del modelo de 4.6 a 4.7; la configuración por defecto ahora es bastante más deficiente.

2. El tokenizador ahora usa más tokens

Todo esto ocurre al mismo precio por token y con la misma ventana de contexto de 1 millón —no, lamento decir que eso no aumentó—.

Sin embargo, el nuevo tokenizador consume 1,35 veces más tokens para el mismo texto. Además, muchos reportes sugieren que el modelo se ve más afectado por la degradación del contexto.

Así que, en la práctica, nos encontramos con que el precio subió, pero la experiencia desde nuestro lado no ha mejorado demasiado. No nos dejemos engañar por los benchmarks internos del tipo “confía en mí, bro”.

Otras tres cosas enormes que ahora debemos considerar son:

• Cualquier presupuesto de contexto que hayas dejado codificado de forma fija ahora es erróneo.
• Cualquier estimación de tokens del lado del cliente ahora es incorrecta.
• Tu factura de la API será más alta por el mismo prompt de siempre.

3. Los tokens de pensamiento siguen ocultos

Este punto sigue siendo especialmente incómodo. De hecho, escribí una publicación reciente sobre esto.

En Opus 4.6, hasta hace poco, el contenido de pensamiento se mostraba por defecto como “resumido”. En Opus 4.7, ahora aparece por defecto como “omitido”. Los bloques de pensamiento se muestran vacíos en la respuesta, pero aun así los pagas por completo.

“Se te sigue cobrando por todos los tokens de pensamiento. Omitirlos reduce la latencia, no el coste.”

Eso viene directamente de las especificaciones de Anthropic. El resultado es que tu factura incluirá tokens que ya ni siquiera puedes ver.

La recuperación en contexto largo acaba de caer por un precipicio

En los benchmarks MRCR v2 con 1 millón de tokens, los resultados hablan por sí solos:

• Opus 4.6: 78,3%
• Opus 4.7: 32,2%

Estamos hablando de una regresión de 46 puntos en un benchmark que la propia Anthropic publicó.

Lo que los desarrolladores están reportando realmente

La respuesta general de la comunidad ha sido bastante dura. Incluso Opus 4.7 está confesando abiertamente que inventa información.

Otros patrones que están apareciendo en el uso real:

Alucina compañeros de trabajo y personas aleatorias.

Démoslo por terminado por hoy.

Preferencias configuradas que están siendo completamente ignoradas.

Anthropic aumentó los límites de uso, aparentemente

Tras la ola de reacciones negativas, Anthropic anunció un “aumento permanente de los límites de uso”.

Sin embargo, me mantengo muy escéptica con esto, ya que todavía no han compartido números ni porcentajes concretos. Pero supongamos que aumentan los límites entre 1,0 y 1,35 veces; bueno, eso simplemente equilibraría el nuevo consumo de pensamiento. Así que... ¿disfrútalo? Creo que no hay mucho que celebrar.

Lo que dijo Boris —y lo que no dijo—

A pesar de todo, vale la pena leer el hilo de Boris para entender su perspectiva:

• Modo automático para ejecuciones largas sin supervisión.
• Skill /fewer-permission-prompts para reducir los bucles de aprobación.
• Resúmenes para volver a sesiones largas.
• Modo enfoque para ocultar el trabajo intermedio.
• Ajuste de esfuerzo —recomienda empezar en xhigh para programación—.
• Darle a Claude una forma de verificar su propio trabajo.

Sin embargo, no esperes actualizar el modelo y que el flujo de trabajo de Boris funcione por arte de magia.

Empieza haciendo esto

Si tienes 5 minutos: busca budget_tokens en tu base de código. Configura el esfuerzo en xhigh para tareas de programación. Si usas Claude Code, configúralo también en el nivel más alto.

Si tienes 15 minutos: lee con calma las notas de lanzamiento de Anthropic y la guía de migración.

NOTA

Me encanta usar Claude Code y Claude en mi día a día. Sin embargo, estos movimientos recientes realmente me están poniendo nerviosa, y sé que no soy la única. Casi todas las personas con las que he hablado últimamente han notado una caída notable en el rendimiento, justo en el mismo momento en que nos piden que nos subamos al tren del hype.

No estoy afiliada a Anthropic ni a Claude. Todas las opiniones expresadas aquí son completamente mías.

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 alguna vez le has pedido a Claude que cree una presentación y te ha devuelto algo que parece un trabajo escolar de 2010, créeme que no eres el único.

Pulsa Enter o haz clic para ver la imagen a tamaño completo.

Eso es lo que ocurre cuando usas Claude sin Skills.

Skills es una función que te permite crear instrucciones reutilizables para que Claude siga tus estándares: los colores de tu marca, tu formato, tu forma de hacer las cosas; en definitiva, nada más de resultados genéricos generados por IA.

Esto fue lo que obtuve cuando probé el mismo prompt, pero usando una skill que sigue las directrices de marca de Anthropic. Acertó con los colores, el diseño, todo.

Pulsa Enter o haz clic para ver la imagen a tamaño completo.

Esa es la diferencia que marcan las Skills.

De esa misma forma, puedes usar skills para crear flujos de trabajo personalizados, ahorrar horas en tareas repetitivas, generar contenido que siga las directrices de marca de tu empresa, estilos de gráficos, elección de tipografías, principios de diseño visual y mucho más.

He buscado por todo internet para encontrar las mejores Claude Skills, para que tú no tengas que hacerlo. En esta guía veremos:

Cómo usar Claude Skills

Las 11 mejores Claude Skills para presentaciones, marketing, negocios, etc.

Cómo instalar rápidamente las Claude Skills

Cómo usar Claude Skills

Para trabajar con Skills, primero activa esta función.

Ve a Settings → Capabilities → Turn on Skills.

Pulsa Enter o haz clic para ver la imagen a tamaño completo.

No necesitas tener conocimientos técnicos para crear una skill. Claude tiene un creador de skills integrado que las construye por ti. Así es como puedes activar el creador de skills:

Ve a preferences en la barra lateral izquierda.

Haz clic en “Skills”.

Selecciona “skill-creator”.

Activa skill-creator y déjalo siempre encendido.

Pulsa Enter o haz clic para ver la imagen a tamaño completo.

En la sección Skills, verás skills creadas por Anthropic.

Si activas la skill brand-guidelines y pruebas el prompt de abajo, obtendrás diapositivas con los colores, el diseño y demás elementos de Anthropic, como en el ejemplo que mostré antes.

create a quick presentation on claude skills. use anthropic brand guidelines

Hay dos formas de usar una skill.

Puedes hacer clic en los tres puntos y pulsar “Try in chat”, o simplemente dejar que Claude decida qué skill debe usar. En mi experiencia, Claude es bastante bueno relacionando tu solicitud con la skill adecuada. Solo asegúrate de saber qué hace cada una de tus skills instaladas para poder formular tus prompts de acuerdo con ello.

Comprueba si Claude eligió la skill correcta leyendo las primeras líneas de la respuesta.

Consejo profesional: puedes convertir cualquier chat de Cowork en una skill reutilizable. Solo tienes que hacer clic en la flecha desplegable del nombre de tu chat y seleccionar “Turn into skill”.

Las mejores Claude Skills

Hay muchas skills disponibles. Estas son las mejores que encontré.

Skills para presentaciones y elementos visuales

1) Slide Deck Builder

• Problema: Crear una presentación lleva mucho más tiempo del que debería. Y no es el diseño lo que te ralentiza. Es todo lo que viene antes: decidir qué decir, en qué orden, qué merece su propia diapositiva, qué necesita más contexto. Ahí es donde se va el tiempo. Te quedas mirando una diapositiva en blanco y, de alguna manera, desaparece una hora.
• La Skill: Le das una idea aproximada: unas cuantas frases, un tema, lo que tengas. Convierte eso en una secuencia completa de diapositivas que ya tiene sentido, aplica el estilo visual que hayas definido y te devuelve un primer borrador real.
• Por qué funciona: Se salta las dos partes que te matan el tiempo: definir la estructura y hacer que parezca algo presentable. En lugar de empezar desde cero, empiezas mejorando algo que ya tiene forma.

2) Explainer Graphic

• Problema: Hay temas que simplemente no terminan de encajar cuando los lees. Lees toda la explicación, llegas al final y, de alguna forma, nada se queda. Así que la lees otra vez. Y luego otra.
• La skill: Le das un concepto, cualquier cosa que resulte difícil de explicar solo con palabras. Lo convierte en una explicación HTML con analogías simples, pasos visuales y secciones cortas fáciles de seguir.
• Por qué funciona: Cambiar el formato, pasar de un muro de texto a una explicación visual paso a paso, a veces es todo lo que hace falta. Es el mismo concepto, pero una experiencia completamente diferente.

Skills para marketers y propietarios de negocios

3) Branded Carousel Generator

• Problema: Convertir tus ideas en contenido para redes sociales es una cosa. Convertirlas en contenido que realmente parezca de tu marca es otra. La mayoría de las personas terminan atrapadas entre dos malas opciones: reutilizar una plantilla genérica que no encaja, o pasar demasiado tiempo ajustando cada publicación para intentar que se vea consistente.
• La Skill: Esta skill toma tu contenido y lo convierte en un carrusel de marca. No es una publicación genérica dividida en diapositivas. Es un carrusel construido alrededor de tu material, con un estilo que se siente como algo que realmente publicarías y que podrías volver a publicar la semana siguiente sin empezar desde cero.

4) Brand Applicator

• Problema: Terminas un documento y, técnicamente, está hecho. El texto está ahí. La estructura funciona. Pero algo sigue sintiéndose mal. La marca. Una tipografía equivocada. Colores que no coinciden. Sin logotipo. Parece un borrador incluso cuando no lo es.
• La Skill: Le entregas tus reglas de marca, como tipografías, colores y logotipos, y las aplica automáticamente a tu documento. El resultado se ve coherente con el resto de los activos de tu empresa. No como algo que armaste con prisas justo antes de una fecha límite.
• Por qué funciona: La mayoría de las personas deja esta parte para el final. Y luego la hacen con prisa, se la saltan o envían algo que no se ve tan pulido como el trabajo que contiene. Esto se encarga por ti del último tramo del proceso. No del pensamiento. No de la escritura. Solo de la parte que hace que algo parezca un entregable real en lugar de un borrador de trabajo.

5) Market Competitors

• Problema: La investigación de competidores suele terminar siempre igual. Miras unas cuantas páginas, detectas algunos patrones, escribes algo en algún sitio y luego sigues adelante sin convertir nada de eso en algo que realmente puedas usar. La investigación ocurrió. El resultado útil, no.
• La Skill: market-competitors toma una web o una entrada de mercado y la convierte en un informe de inteligencia competitiva. No son notas dispersas. Es un entregable estructurado, del tipo que sí puedes consultar cuando estás tomando decisiones de posicionamiento.
• Por qué funciona: El análisis competitivo solo es útil si conduce a alguna parte. La mayoría de las veces no lo hace, porque la investigación nunca recibe un formato. Se queda en una pestaña, en un documento o en tu cabeza hasta que algo más urgente toma el control. Esto le da un formato. Y eso es lo que convierte una observación en algo sobre lo que puedes actuar.

Skills para operaciones de negocio

6) Workflow Visualizer

• La Skill: Workflow Visualizer convierte un proceso, sistema empresarial o configuración operativa en un mapa visual interactivo. Fases, activadores, componentes, herramientas conectadas: todo en un solo lugar, mostrando cómo encajan entre sí en lugar de simplemente enumerar qué son.
• Por qué funciona: Una lista de pasos te dice qué existe. Un mapa te dice cómo funciona. Esa diferencia importa cuando necesitas explicar el sistema a otra persona, encontrar dónde se está rompiendo algo o descubrir qué mejorar sin tocar accidentalmente algo que no deberías.

7) Contract Reviewer

• Problema: Leer un contrato rápido es fácil. Leerlo bien es otra cosa. Lo difícil no es la extensión, sino saber qué buscar. La cláusula que suena bien hasta que algo sale mal. La protección que debería estar ahí, pero no está. El término que es estándar hasta que deja de serlo.
• La Skill: Subes el contrato y lo desglosa en lo que realmente importa. Términos clave, señales de alerta, advertencias intermedias, protecciones faltantes y aquello sobre lo que quizá quieras negociar antes de firmar.
• Por qué funciona: No sustituye a un abogado. Hace algo más útil para la mayoría de las personas: te dice dónde prestar atención primero. Solo eso ya cambia la forma en que abordas el documento. En lugar de leer cada línea con la misma preocupación, sabes exactamente dónde ir más despacio y dónde puedes relajarte.

8) Decision Council

• Problema: Algunas decisiones son demasiado importantes como para mirarlas desde un solo ángulo. El verdadero riesgo no siempre es tomar la decisión equivocada. A veces es tomar una decisión demasiado rápido, sin suficiente oposición, sin que nadie haga la pregunta incómoda, sin una tensión real entre distintas perspectivas.
• La Skill: Decision Council ejecuta múltiples perfiles expertos al mismo tiempo, cada uno analizando tu decisión desde un ángulo diferente. Después los reúne en una recomendación sintetizada con próximos pasos claros. Primero obtienes un choque estructurado de puntos de vista y luego la respuesta.

9) Quick Research

• Problema: Investigar se vuelve caótico muy rápido. Empiezas con una pregunta. Eso te lleva a otra fuente, luego a una opinión distinta, después a tres páginas más de contexto que ni siquiera sabes si necesitas. Cuando terminas, tienes muchas pestañas abiertas y ninguna imagen clara.
• La skill: Le das un tema y comprime todo en un informe estructurado. La usé para desglosar una nueva actualización de Claude Cowork. Resumen, funciones, requisitos, ventajas, desventajas, precios y la conclusión real. Todo en un solo lugar, ya organizado.

Skills para construir sin código

10) Frontend Design

• Problema: Muchas interfaces generadas por IA técnicamente funcionan. Pero no parecen hechas con cuidado. El código corre bien, pero el resultado se siente como algo ensamblado en cinco segundos y que nadie volvió a mirar. Diseño genérico, tipografías por defecto, nada que parezca deliberado.
• La Skill: Frontend Design es una skill oficial de Claude Code que empuja el resultado hacia algo más preparado para producción. Mejor tipografía. Decisiones visuales más sólidas. Interfaces que realmente parecen diseñadas por alguien que tomó decisiones, en lugar de simplemente aceptar lo primero que salió.

11) Implement Design

• Problema: Pasar de Figma a código suena sencillo hasta que realmente lo intentas. Ahí es cuando empiezan a aparecer los pequeños desajustes. El espaciado está ligeramente mal. Los componentes se alejan del original. Y el resultado final se parece, pero cualquiera que haya trabajado en el diseño puede notar que no está bien.
• La Skill: Implement Design es una skill pública de Figma para traducir diseños a código listo para producción con una fidelidad visual mucho más ajustada. Esta skill le da a Claude una forma más estructurada de pasar del diseño a la implementación, para que la distancia entre lo que se diseñó y lo que se construye sea lo más pequeña posible.

Cómo instalar las skills

Sigue los pasos de abajo cuando quieras añadir una skill a Claude, ya sea un archivo .zip o un archivo skill.md.

Customize → Skills → “+” → Create skill → Upload a skill → Upload your .zip or skill.md file

Si el archivo .zip contiene múltiples skills, como ocurre con algunos de los archivos compartidos en esta guía, tendrás que añadir el .zip a plugins:

Customize → Personal plugins → “+” → Create plugin → Upload plugin → Upload your file

Una cosa más

Ahora tienes 11 skills que pueden ahorrarte horas cada semana.

Pero las skills funcionan mejor cuando realmente sabes usar bien Claude: los prompts, los flujos de trabajo, la configuración que hace que todo encaje.

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.

Leí un artículo en Mashable la semana pasada que me enfadó tanto que tuve que quedarme un buen rato en silencio, ardiendo por dentro, antes de poder escribir sobre ello de una manera que me pareciera responsable y adecuada. A veces, simplemente estoy muy cansada. Absolutamente agotada, hasta los huesos, del mundo en el que vivimos hoy y de los usos que algunas personas le están dando a la IA.

¿Has oído hablar de Secret Desires? Es una web donde adultos mantienen conversaciones “picantes” con acompañantes de IA. Funciona desde el navegador, como Character.ai, solo que es únicamente para adultos. Pero bueno, son adultos, ¿verdad? Si quieren tener una conversación subir de tono con una IA, pueden hacer lo que quieran, ¿no?

Ese fue el razonamiento que utilizó Sam Altman cuando anunció que ChatGPT introduciría conversaciones picantes con verificación de edad este diciembre.

• Los adultos deben ser tratados como adultos, ¿verdad?
• Hay que dejar que los adultos hagan lo que quieran, ¿verdad?

Si entras en la web de Secret Desires, tienen una lista de acompañantes entre los que elegir. Puedes explorar hombres, mujeres o ambos. Los acompañantes van desde versiones realistas hasta anime, todos de dieciocho años en adelante. Si no ves una novia o un novio cuyo aspecto te guste, no pasa nada: puedes crear el tuyo propio.

Vi “crea el tuyo propio” y pensé en el proceso de creación de un avatar. Elige el color del pelo, elige el color de los ojos. A veces me sorprende darme cuenta de lo ingenua que todavía puedo ser. Es como si, por mucho que aprenda, siguiera siendo capaz de quedarme impactada por la forma en que algunos seres humanos tratan a otros.

La realidad detrás de la pantalla

Secret Desires sufrió una filtración de datos que dejó expuestos casi dos millones de imágenes y vídeos. Al parecer, habían dejado sus contenedores de almacenamiento en la nube vulnerables y abiertos al público. Lo descubrió 404 Media.

Al revisar casi dos millones de imágenes y vídeos, los periodistas aprendieron mucho sobre cómo los usuarios estaban utilizando realmente la web. ¿Sabes qué encontraron? Muchísimas víctimas que no sospechaban nada.

Secret Desires se lanzó a principios de 2024 y lleva casi dos años funcionando. Hasta hace poco, tenían una función llamada intercambio de rostro. Sí, significa exactamente lo que estás pensando. Los usuarios podían tomar una foto de cualquier mujer e “intercambiarla” para convertirla en el rostro de su acompañante de IA. Su acompañante adulta.

Los acompañantes de Secret Desires pueden chatear, enviar mensajes de texto, vídeos y mensajes de voz, e incluso hablar por teléfono.

Al revisar los archivos, 404 Media encontró imágenes sexuales de todo tipo de mujeres: desde celebridades y artistas famosas hasta mujeres que no son figuras públicas de ninguna manera y que apenas tienen presencia digital. Veían una foto inocente, como un selfi o una foto de redes sociales. ¿Andrés y después? La IA generaba fotos y vídeos explícitos a partir de esa imagen.

La gente podía subir las fotos que quisiera. Piénsalo un momento, ¿vale?

Encontraron una foto de una representante estatal dando un discurso en público, fotos de mujeres tomadas hace años con teléfonos plegables antiguos y BlackBerrys, capturas de Snapchat y más. Simplemente fotos aleatorias de mujeres. Una de las fotos era de una joven posando con orgullo con su título universitario. Algunos nombres de archivo incluían el nombre y apellido completos de las mujeres.

Una mujer sin presencia digital tuvo su foto del anuario del instituto convertida en pornografía. Algunos archivos parecían ser de personas “muy jóvenes” y tenían nombres de archivo que incluían términos como “17 años”.

Solo hay una razón por la que todas esas fotos estaban en la carpeta de “intercambio de rostro”. Los usuarios de Secret Desires las subieron para crear imágenes y vídeos explícitos. Usaron esas fotos como modelo para sus “acompañantes adultas”.

La epidemia del "desnudo" digital

Usar fotos de mujeres y niñas sin su consentimiento no es algo nuevo. Existen aplicaciones para desnudar o quitar la ropa que permiten a los usuarios subir una foto y la herramienta “desviste” a la persona. Las imágenes que generan son sorprendentemente precisas.

La IA generativa fue entrenada prácticamente con todo lo que existe en internet, incluyendo millones, quizá miles de millones, de imágenes explícitas e ilícitas. Así que la IA puede mirar una foto de una mujer completamente vestida y hacerse una idea bastante aproximada de cómo se vería bajo la ropa.

El Institute for Strategic Dialogue (ISD) encontró treinta y un programas distintos para desnudar personas activos en internet. Ni siquiera hace falta entrar en la dark web para encontrarlos. Esas treinta y una webs recibieron, en conjunto, veintiún millones de visitas al mes, con hasta cuatro millones de visitas en un solo mes.

Están ganando miles de millones. La mayor parte de su tráfico proviene de Twitter, pero también se pueden encontrar en Google y Bing.

Las webs de “nudify” promocionan esto como algo “divertido”. Diviértete, mira cómo se vería alguien desnudo. Estudiantes las usan para desnudar a sus compañeras de clase, y un psiquiatra infantil fue encarcelado por crear imágenes y vídeos de pacientes menores.

El Institute for Strategic Dialogue (ISD) tiene varios nombres para la práctica de desnudar a mujeres y niñas sin consentimiento. Además de “deepfake”, lo llaman:

• NCSII: Difusión no consentida de imágenes íntimas.
• IBSA: Abuso sexual basado en imágenes.
• NCIIMM: Imágenes íntimas no consentidas y material manipulado.
• TFGBV: Violencia de género facilitada por la tecnología.

¿Ese último término? Eso es exactamente lo que es. Violencia de género basada en tecnología. ¿Hace falta que diga que el noventa y nueve por ciento de las personas que aparecen en fotos y vídeos deepfake son mujeres y niñas?

Las "novias de IA" y el control absoluto

Las imágenes y los vídeos ya son suficientemente graves. La idea de que cualquier hombre al azar pueda tomar una foto de una mujer y crear imágenes y vídeos que parezcan realistas es aterradora y provoca un trauma profundo en las víctimas.

Pero ¿las novias de IA? Eso lo lleva a un nivel completamente distinto. Porque ahora es interactivo. Ella hace lo que tú le dices que haga. Y nunca dice que no.

Secret Desires publica anuncios en YouTube en los que promociona la posibilidad de crear versiones sexualizadas de personas reales.

“Las chicas de IA nunca dicen que no”, dice una novia de IA en un vídeo corto de YouTube. “Puedo parecerme a tu celebridad favorita, a esa chica del gimnasio, a tu personaje de anime soñado o a cualquiera con quien fantasees”.

Hará cualquier cosa que le pidas. Incluso hará un vídeo si se lo pides.

No sé cómo procesar eso sin romper a llorar. La idea de que cualquier hombre pueda crear una cuenta y, por 19,99 dólares al mes, cualquier mujer haga todo lo que él le pida y cree vídeos para él. Y puede estar basada en una mujer real. Puede chatear, puede enviar mensajes, puede enviar fotos y vídeos haciendo cualquier cosa que él le pida. Incluso puede llamarlo por teléfono.

Todo lo que necesitan es una foto. Y si él tiene un fragmento de su voz, también hablará con su voz.

Secret Desires tiene un modo de clonación de voz, en el que los usuarios pueden subir un archivo de audio, y la herramienta clona esa voz para usarla en su novia de IA. Hacer cualquier cosa que le pidas y crear vídeos subidos de tono para ti si los quieres. Llamarte, susurrarte al teléfono.

Me gustaría que al menos un hombre me explicara cómo eso puede estar bien.

La complicidad y el vacío legal

En la investigación de 404 Media, enlazaron a un hilo de Reddit donde los usuarios se quejaban de que la función de intercambio de rostro había desaparecido.

Un usuario dijo que había subido una foto de su esposa y que los vídeos eran geniales. Me quedé horrorizada, preguntándome si su esposa sabía que había hecho eso. Si ella lo sabía, entonces bueno, eso queda entre ellos. Pero ¿tuvo ella alguna posibilidad de opinar al respecto?

Otro usuario preguntó qué otros programas tenían intercambio de rostro. Alguien enumeró otros ocho sitios. Ocho. Un tercer usuario escribió para decir: “Gente, este hilo aparece en una noticia, así es como lo encontré”. Debajo había una serie de comentarios eliminados. Eliminado, eliminado, eliminado.

La gente no elimina comentarios si cree que lo que está haciendo está bien.

Según un grupo de Discord para usuarios de Secret Desires, el “intercambio de rostro” seguía siendo una función de pago a fecha del 3 de noviembre, pero a fecha del 11 de noviembre ya no aparecía como una función de pago. Sin embargo, siguen promocionando la clonación de voz y la posibilidad de “crear tu propia” novia para conversaciones picantes.

El Institute for Strategic Dialogue (ISD) dice que a menudo estas webs desaparecen después de la cobertura mediática, pero simplemente vuelven a aparecer con otro nombre.

ONU Mujeres dice que este tipo de abuso digital puede trasladarse a la vida real y escalar hasta convertirse en acoso o violencia física. Dicen que detenerlo es urgente. Lo que no dicen es cómo. Salvo mediante regulación, no conozco ninguna forma de detenerlo.

Después de encontrar las imágenes accesibles públicamente y revisarlas, 404 Media contactó con Secret Desires para solicitar un comentario. Una hora después, la filtración fue corregida y los archivos dejaron de estar accesibles públicamente.

Ni siquiera se molestaron en responder.

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.

Aprendí esto de la forma más estúpida.

Cuando cambié a Cursor, luego a Windsurf y ahora a Antigravity, me enganché a la velocidad. Abría una ventana de chat, escribía una frase poco precisa y veía cómo todo el código aparecía mágicamente. Yo no estaba programando. Solo estaba aprobando automáticamente todo lo que la herramienta soltaba.

Se sentía genial, hasta que mi comprensión de la tecnología empezó a deteriorarse. Podía sentir cómo mis habilidades se iban apagando. Me convirtió en un impostor dentro de mi propio campo.

Pulsa Enter o haz clic para ver la imagen en tamaño completo.

Los usuarios que no sean miembros de Medium pueden hacer clic aquí para leer gratis.

¿Qué demonios es la programación mediante prompts?

Con los editores de código con IA tomando el control, la programación pasó de escribir código a dar prompts como:

“Crea una aplicación en React para reseñas de restaurantes”.

La herramienta construye todo: la estructura, las pruebas y las notas de despliegue. ¿Necesitas una funcionalidad? Pregunta. ¿Una corrección? Pregunta. ¿Un tema diferente? Pregunta otra vez.

Tú das el prompt. La herramienta programa. Eso es programación mediante prompts.

¿En qué se diferencia la programación mediante prompts del vibe coding?

La diferencia es pequeña, pero importante.

El vibe coding es aleatorio y reactivo. Los principiantes lo hacen porque no saben lo que quieren.

La programación mediante prompts se siente controlada. Llegas con un plan.

Pero sigues entregando tu pensamiento a una máquina que no entiende tu dominio, tus restricciones ni tu criterio.

Y como los desarrolladores con experiencia son quienes más hacen esto, el daño es más profundo.

Por qué la programación mediante prompts es peligrosa

Piensa en los ingenieros senior que pasaron a puestos de gestión hace años. Una vez fueron desarrolladores sólidos, pero sus instintos se fueron debilitando porque dejaron de tocar código.

La programación mediante prompts te empuja hacia ese mismo deterioro, solo que más rápido. Dejas de razonar sobre los problemas. Dejas de entender la estructura. Dejas de pensar en código.

Tu cerebro es bueno descartando cualquier cosa que considera innecesaria. Teniendo eso en cuenta, delegar tu pensamiento en la IA se vuelve todavía más peligroso.

La solución no es dejar la IA. La solución es la disciplina.

La mejor forma de usar la IA

Este es el método que realmente detuvo ese deterioro en mi caso.

Piensa el problema antes de tocar la herramienta. Escribe primero las reglas, las restricciones y los casos límite. Si no puedes describir el problema, no puedes juzgar la solución.

Usa la IA solo después de que ya conozcas la forma de la respuesta. Deja que la herramienta acelere lo que ya has diseñado, no que invente cosas que tú no has pensado.

Revisa cada resultado como si viniera de una persona recién incorporada al equipo. Despacio, con cuidado, línea por línea. Tu criterio se mantiene afilado cuando permaneces en el asiento del revisor.

Este proceso simple es la “mejor forma”.

Basándome en el método anterior, he adoptado los siguientes hábitos para proteger mis habilidades.

1. Escribe las reglas antes de pedir ayuda a la IA

Anota primero los requisitos, los casos límite y las restricciones. Incluso una lista pequeña evita que la herramienta tenga que adivinar. Añadir un par de pruebas unitarias desde el principio también le da a la IA suficiente contexto para mantenerse precisa.

2. No confíes en cambios grandes sin una lectura cuidadosa

Cuando la herramienta genera un diff enorme, ve más despacio. Léelo como si estuvieras revisando una pull request de alguien nuevo en el equipo. Entiende cada cambio antes de pulsar “aplicar”.

3. Usa la IA para lo aburrido, no para funcionalidades importantes

Deja que se encargue del boilerplate, la estructura inicial de pruebas, conversiones de archivos o formatos, explicaciones y ayuda rápida con expresiones regulares. Evita usarla para componentes completos, grandes refactorizaciones o cualquier cosa vinculada a la lógica de negocio. Eso siempre tarda más en corregirse después.

4. Usa la IA solo en código que realmente entiendes

Antes de pedirle a la herramienta que modifique un archivo, revísalo tú mismo por encima. Aprende el flujo y detecta cualquier helper o patrón especial. Una vez que entiendas la forma del código, deja que la IA te ayude.

5. Deja que la IA apoye tu depuración, no que la dirija

Haz la depuración tú mismo. Cuando tengas una teoría, pregúntale a la IA si el código coincide con ella o si se te está escapando algo. Debe validar tu pensamiento, no reemplazarlo.

6. No aceptes el autocompletado a ciegas

Si una sugerencia no es lo que esperabas, detente y léela. Si algo parece raro, recházalo. Acepta solo las sugerencias que puedas anticipar. Esto por sí solo evita muchísimos errores pequeños.

Sigo usando IA todos los días. Simplemente mantengo el control

Sigo usando IA todos los días. Simplemente mantengo el control.

Las herramientas son poderosas una vez que tomas el mando. Cursor sigue siendo mi editor principal. Windsurf gestiona bien bases de código grandes. Antigravity es rápido y fiable.

Pero nunca olvido el momento en que las cosas empezaron a deteriorarse, cuando me di cuenta de que estaba aprobando código que no entendía por completo. Ese fue el punto de inflexión.

La fantasía de que la IA construya todo por ti es la trampa.

Lo que funciona es simple:

1. Pensar primero el problema.
2. Usar la IA solo después de saber lo que quieres.
3. Revisar cada cambio como si viniera de una persona recién incorporada a tu equipo.

Esto mantiene la velocidad sin permitir que tus habilidades vuelvan a deteriorarse.

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 semana pasada, alguien en tu feed publicó que estaba “emocionado por construir agentes IA este fin de semana”. Cuarenta y siete likes. Emojis de fuego. “¡Me encanta esa mentalidad de crecimiento!” Lo miraste y sentiste algo que no supiste nombrar. No era celos. No era inspiración. Era algo más cercano al reconocimiento. Como cuando reconoces una máscara porque tú llevas puesta la misma.

Nadie está emocionado por aprender frameworks de agentes un sábado. Están asustados por lo que pasa si no lo hacen.

Probablemente tú también tengas tu propia versión de esto. Una pestaña del navegador que llevas semanas queriendo abrir. Un curso que guardaste durante una oferta y nunca empezaste. Un hilo de Slack sobre “AI readiness” que leíste por encima y cerraste. La admisión silenciosa de que no sabes lo suficiente para seguir siendo relevante, y la admisión todavía más silenciosa de que guardar el recurso te hizo sentir que estabas haciendo algo al respecto.

Levantas sistemas, llevas años escribiendo código en producción. Según casi cualquier criterio razonable, sabes lo que haces.

Y aun así.

Esa pestaña sigue ahí. Brillando tenuemente. Un talismán contra la obsolescencia.

La misma actividad, dos significados distintos

Al principio de tu carrera, aprendías un framework porque realmente te emocionaba. Un nuevo modelo mental para construir interfaces. Te quedabas despierto hasta tarde no porque estuvieras ansiosa, sino porque no podías parar. Aprender se sentía como construir. Como añadir habitaciones a una casa que apenas estabas empezando a habitar.

Ahora abres una pestaña de un curso porque tu empresa inició una iniciativa de “AI readiness”. Técnicamente no es obligatorio. Solo un mensaje de Slack desde dirección hablando de “mantenernos por delante de la curva” y una hoja compartida donde puedes registrar tus horas de upskilling. Voluntario, por supuesto. Igual que las negociaciones salariales son “voluntarias”.

La diferencia importa porque la industria no la reconoce. Cada charla en conferencias, cada publicación en LinkedIn, cada iniciativa corporativa de aprendizaje trata todo el aprendizaje como si fuera la misma especie. Crecimiento. Desarrollo. Curiosidad. Da igual si eres un recién graduado explorando su primer lenguaje, alguien cambiando de carrera usando Coursera para escapar de un trabajo sin futuro o un veterano de 15 años intentando demostrar que no es un dinosaurio: todo queda archivado bajo la misma bandera aspiracional.

Pero el cuerpo sí conoce la diferencia. La curiosidad se siente como inclinarse hacia delante. La defensa se siente como tensarse.

Quiero dejar algo claro: para algunas personas, estas plataformas realmente cambian vidas. El desarrollador autodidacta que usó una beca de Coursera para pasar de data entry a ingeniería, la persona que cambió de carrera aprendiendo Python con tutoriales gratuitos en YouTube. Eso es real. Eso importa. Esto no va sobre esas personas. Va sobre un sistema que toma esas historias y las usa como marketing para algo completamente distinto: la máquina de ansiedad perpetua que les dice a profesionales con experiencia que su década de trabajo podría caducar el próximo trimestre.

Lo que compraste vs. lo que recibiste

Aquí es donde la economía empieza a aclarar las cosas.

La tasa promedio de finalización de MOOCs está por debajo del 10% para quienes usan el plan gratuito, y algunos estudios la sitúan tan baja como el 3%. Más de nueve de cada diez personas que se inscriben en un curso online nunca lo terminan. Compran acceso. No compran conocimiento. Compran la sensación de progreso, igual que una membresía de gimnasio el 2 de enero compra la sensación de estar en forma.

Del lado corporativo no es mejor. Un estudio de Gartner de 2014 encontró que el 45% de la formación corporativa califica como “scrap learning”: contenido que los empleados completan pero nunca aplican en el trabajo. Ese curso de Kubernetes que viste a doble velocidad durante tus descansos para almorzar… cuando llegue la evaluación de desempeño, conservarás el certificado y casi nada del conocimiento.

La industria del upskilling no vende conocimiento. Vende la sensación de estar haciendo algo, y hasta esa sensación tiene una tasa de finalización del 3%.

La habilidad que caduca vs. la habilidad que se acumula

Esta es la parte de la que nadie habla, porque hablar de ella rompería el modelo de negocio.

No todas las habilidades se deprecian al mismo ritmo. Tu conocimiento de un framework específico tiene una vida media de aproximadamente dos o tres años. React hooks, configuraciones de Kubernetes, la API del framework de agentes que aprendiste el mes pasado: los detalles que aprendiste este trimestre estarán parcialmente obsoletos el año que viene y serán mayormente irrelevantes dentro de tres. Esto no es un fallo del aprendizaje. Es la naturaleza del conocimiento de implementación. Está diseñado para caducar.

Tu capacidad para depurar un sistema que nunca habías visto antes tiene una vida media medida en décadas. El criterio arquitectónico, el instinto para detectar dónde la complejidad te explotará más adelante, la capacidad de leer un codebase y entender no solo qué hace sino por qué alguien lo construyó así: esas son habilidades duraderas. Se acumulan con la experiencia en lugar de depreciarse con el tiempo.

Piensa en el SRE de tu equipo que ha pasado ocho años manteniendo vivo un sistema de pagos a través de migraciones, adquisiciones y failovers casi catastróficos. Que sabe dónde se esconde cada fragilidad. Que puede diagnosticar fallos en cascada por la forma de una gráfica de latencia igual que un cardiólogo lee un electrocardiograma. Ahora imagina a su manager preguntándole qué está haciendo para “mantenerse actualizado con IA”. Toda su carrera es una habilidad duradera. El sistema que lo evalúa no puede verla.

La industria del upskilling no tiene producto para ese tipo de expertise. No puedes empaquetarlo en un curso de seis semanas con certificado. Se desarrolla lentamente, durante años construyendo y manteniendo sistemas reales, mediante el doloroso proceso de ver envejecer tus propias decisiones arquitectónicas y aprender cuáles resistieron. No hay atajos. No hay ofertas con 90% de descuento.

Así que la industria te vende el tipo perecedero. Una y otra vez. React hoy, frameworks de agentes mañana, cualquier herramienta que aparezca el próximo trimestre. Cada curso aborda una habilidad con una vida útil de dos años, lo que significa que necesitarás otro curso dentro de dos años. Y otro después. El modelo de negocio depende de que tu conocimiento expire.

Tu conocimiento de React tiene una vida media de unos dos años. Tu capacidad para depurar un sistema que nunca habías visto tiene una vida media de décadas. La industria te cobra trimestralmente por lo primero y no tiene ni idea de cómo poner precio a lo segundo.

Debería decir lo obvio: a veces sí necesitas la habilidad perecedera. A veces el nuevo framework es la herramienta correcta y aprenderlo es la decisión correcta. Andar por la industria descubriendo tus bases tiene esta parte cruel: te están diciendo que lo perecedero es lo único importante antes de que hayas tenido tiempo de desarrollar algo duradero. El sistema está valorando tu potencial en cero mientras exige que pagues precio completo por mantenerte “actualizado”.

El problema no es aprender cosas nuevos. El problema es una economía que trata las habilidades perecederas y las duraderas como si fueran intercambiables, les pone el mismo precio en contratación y luego actúa sorprendida cuando ingenieros con experiencia sienten que están corriendo en el mismo sitio. Las habilidades duraderas te convierten en un mal cliente. Las habilidades perecederas te convierten en una suscripción.

La confesión que sigo editando

Debería ser honesta sobre algo, y más honesta de lo que suelo ser.

Construyo sistemas de IA. Sé lo que estas herramientas pueden y no pueden hacer. Y aun así también lo siento. La presión de demostrar que estoy al día. El impulso de publicar sobre el último framework en LinkedIn no porque haya aprendido algo significativo, sino porque la keyword importa más que el conocimiento. Lo sé, y aun así lo he hecho.

He visto a ingenieros que respeto ser evaluados por si “adoptaron herramientas IA” en lugar de por si construyeron sistemas que funcionaban. He visto rúbricas de desempeño que recompensan completar cursos y penalizan el tipo de expertise profunda y silenciosa que mantiene vivos los sistemas de producción. La rúbrica mide cumplimiento, no capacidad. Recompensa lo perecedero e ignora lo duradero. Y quienes rellenan esas rúbricas lo saben. Aprietan la mandíbula y marcan casillas porque la alternativa sería admitir que el sistema que están aplicando está roto.

Lo sé porque he estado en ambos lados de esa mesa. La sensación es la misma: estás actuando competencia en lugar de practicarla.

La única pregunta que te dice todo

La próxima vez que estés a punto de abrir un curso, un tutorial o un proyecto de fin de semana con un nuevo framework, hazte una sola pregunta:

¿Voy a usar esto en los próximos seis meses o lo estoy aprendiendo porque tenerlo en mi perfil me hace sentir más segura?

Lo primero es inversión. Lo segundo es un pago mínimo sobre una deuda que sigue creciendo.

Si la respuesta es “lo voy a usar”, apréndelo. Apréndelo de verdad. Construye algo real con ello. Eso no es ansiedad. Eso es oficio.

Si la respuesta es “me hace sentir más segura”, cierra la pestaña. Dedica esa hora a leer el codebase que ya mantienes. Comprende el sistema que ya posees. Construye la habilidad duradera que ningún curso puede enseñar y ningún certificado puede demostrar. Esa cosa que te convierte en la persona de la sala que dice “esto se va a romper en seis meses” y tiene razón.

La industria del upskilling no puede venderte eso. Precisamente por eso tiene valor.

Deuda de competencia

Esa pestaña sigue abierta.

Algunas mañanas abro el navegador y ahí está, entre Jira y Slack, brillando con la paciencia particular de las cosas que saben que ya han ganado. Algún día haré clic. No porque el curso vaya a enseñarme algo duradero. No porque vaya a hacerme significativamente mejor en el trabajo que realmente importa. Sino porque la economía de las credenciales exige pruebas de vigencia, y la vigencia es precisamente lo que expira.

En algún lugar, alguien está genuinamente emocionado con los agentes IA, quedándose despierto hasta tarde porque las posibilidades se sienten eléctricas. No por una evaluación de desempeño. No por un mensaje de Slack desde dirección. Sino porque la tecnología en sí le parece interesante. Esa sensación todavía existe. La mayoría simplemente ya no puede alcanzarla a través de la ansiedad.

Así es como he empezado a llamarlo: deuda de competencia. La acumulación de certificaciones perecederas mientras tus habilidades duraderas se atrofian por abandono. Cada hora invertida en un curso que te enseña la API del momento es una hora no invertida en comprender el sistema que llevas manteniendo tres años. Cada certificado es un pago mínimo sobre una deuda que sigue creciendo. Te sientes productiva. Tu perfil parece actualizado. Y debajo de eso, las habilidades que realmente te harían irremplazable están acumulando intereses silenciosamente en la dirección equivocada.

La industria nos enseñó a llamar a esto crecimiento.

La rúbrica fue diseñada para medirlo.

La palabra que todos estábamos buscando era depreciació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.

Hace un año y medio, compartí 7 herramientas de línea de comandos que mejoraron mi experiencia en la terminal. Con más de 20k lecturas, ese blog se convirtió en un éxito instantáneo y muchos lectores comenzaron a usar esas herramientas en sus propios flujos de trabajo diarios. También recibí una gran cantidad de sugerencias para seguir mejorando mi experiencia en la terminal.

Desde entonces, las cosas han cambiado muchísimo. En 2026, con la IA irrumpiendo en el mundo de la ingeniería de software, estamos presenciando un cambio de paradigma. Ya no solo desarrollamos código y lo desplegamos, ahora colaboramos con agentes y automatizamos tareas utilizando IA.

Y la terminal no ha sido una excepción. Se están lanzando numerosas herramientas CLI construidas sobre capacidades de IA. Esto desbloquea utilidades que eran imposibles hace solo unos pocos años.

La terminal se está convirtiendo lentamente en una cabina impulsada por IA.

Hoy voy a compartir siete herramientas CLI potenciadas por IA que potenciarán tu terminal igual que hicieron con la mía. Si estás listo, ¡vamos allá!

1. Aider — El programador en pareja con IA estándar de la industria

Aider es probablemente la herramienta más potente de esta lista. Te permite programar en pareja con LLMs (como GPT-4o, Claude 3.5 o modelos locales mediante Ollama) directamente desde tu terminal.

A diferencia de un simple chat, Aider edita tus archivos en vivo y crea automáticamente commits de Git con mensajes descriptivos para cada cambio que realiza. Mapea todo el contexto de tu repositorio para entender exactamente cómo un cambio en un archivo afecta a otro.

• El factor “Wow”: literalmente puedes decir “Refactoriza la lógica para usar JWT” y ver cómo edita 5 archivos y hace commit de los cambios antes de que termines tu café.

También soporta la funcionalidad “Voice-to-Code”, mediante la cual puedes hablarle a Aider sobre tu código y pedir mejoras o correcciones de bugs.

Así es como puedes empezar con Aider.

Bash

python -m pip install aider-install
aider-install

# Cambiar directorio hacia tu codebase
cd /to/your/project

# DeepSeek
aider --model deepseek --api-key deepseek=<key>

# Claude 3.7 Sonnet
aider --model sonnet --api-key anthropic=<key>

# o3-mini
aider --model o3-mini --api-key openai=<key>

¡Para más detalles revisa su sitio web!

2. Gemini CLI — El Shell Agéntico de Google

Si quieres potencia IA de alto nivel sin una suscripción, Gemini CLI es actualmente el rey de los planes gratuitos. Te da acceso directo desde la terminal a Gemini 3 Flash y Pro.

Está construido para tareas “Agénticas”. Puede ejecutar comandos, explorar tu sistema de archivos y corregir errores en tiempo real.

Con una interfaz increíble directamente dentro de la CLI, Gemini CLI es una de las herramientas imprescindibles para probar en 2026.

Además de eso, proporciona acceso a todas las herramientas IA que ofrece Google como generación de vídeo, Deep Research y Notebook LM.

Gemini CLI puede instalarse usando npm.

Bash

npm install -g @google/gemini-cli

¡Para más métodos de instalación, consulta su sitio web!

3. Atuin — Tu historial del shell, pero con “Cerebro”

Recordar un comando que ejecutaste hace tres semanas solía ser un juego de history | grep. Atuin reemplaza el historial de tu shell con una base de datos SQLite buscable que se sincroniza entre tus máquinas.

En la era de la IA, Atuin ha evolucionado. Ahora soporta búsqueda semántica y descubrimiento de comandos impulsado por IA. En lugar de recordar el flag exacto, puedes buscar la “intención” de lo que hiciste.

Instala Atuin en tu máquina usando el siguiente comando curl.

Bash

curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh

Para más información visita su sitio web.

4. ShellGPT (sgpt) — La navaja suiza de los shells con IA

A veces no necesitas un programador en pareja completo como Aider. Solo necesitas una respuesta rápida. ShellGPT es una herramienta ligera que lleva ChatGPT (o cualquier API compatible) a tu pipeline.

Puedes canalizar logs directamente hacia él:

Bash

cat error.log | sgpt "explain this error"

o pedirle que genere scripts shell sobre la marcha. Incluso puede generar mensajes de commit de Git basados en tus cambios staged.

Para empezar con shell-gpt, usa pip.

Bash

pip install shell-gpt

# Generar un comando y ejecutarlo
sgpt --shell "find all large files in /var/log"

5. Warp — Entorno de desarrollo agéntico

Warp es el entorno de desarrollo agéntico, construido para programar con múltiples agentes IA. Warp lleva la terminal al siglo XXI con una interfaz moderna y funcionalidades de edición de código. Usa el agente integrado SOTA Oz de Warp, o ejecuta agentes CLI como Claude Code, Codex o Gemini CLI.

• Plan gratuito: Warp es gratis para individuos e incluye una cantidad generosa de solicitudes IA mensuales.

6. Goose — El agente open-source de “Vibe Coding”

Goose es tu agente IA ejecutándose en tu máquina, capaz de automatizar tareas complexes de desarrollo de principio a fin. Más allá de simples sugerencias de código, Goose puede construir proyectos completos desde cero, escribir y ejecutar código, depurar errores, orquestar workflows e interactuar con APIs externas — de forma autónoma.

Diseñado para máxima flexibilidad, Goose funciona con cualquier LLM y soporta configuración multi-modelo para optimizar rendimiento y costes, se integra perfectamente con servidores MCP y está disponible tanto como aplicación de escritorio como CLI — convirtiéndose en el asistente IA definitivo para desarrolladores que quieren moverse más rápido y centrarse en la innovación.

Para instalar Goose en Mac, usa el siguiente comando brew.

Bash

brew install block-goose-cli

Para más métodos de instalación, consulta su sitio web.

7. OpenCode — La alternativa Privacy-First

Si estás trabajando en proyectos sensibles donde no puedes enviar código a un proveedor cloud, OpenCode es tu mejor amigo. Es una herramienta impulsada por la comunidad que hace increíblemente fácil cambiar entre más de 75 proveedores LLM diferentes, incluyendo modelos completamente locales.

Está diseñada para desarrolladores que quieren la experiencia de “Agente” sin vendor lock-in.

Estas son algunas formas de empezar a usar OpenCode:

Bash

# YOLO
curl -fsSL https://opencode.ai/install | bash

# Gestores de paquetes
npm i -g opencode-ai@latest        # o bun/pnpm/yarn
scoop install opencode             # Windows
choco install opencode             # Windows
brew install anomalyco/tap/opencode # macOS y Linux (recomendado, siempre actualizado)
brew install opencode              # macOS y Linux (fórmula oficial brew, menos actualizada)
sudo pacman -S opencode            # Arch Linux (Estable)
paru -S opencode-bin               # Arch Linux (Última versión desde AUR)
mise use -g opencode               # Cualquier SO
nix run nixpkgs#opencode           # o github:anomalyco/opencode para la última rama dev

Las herramientas que están apareciendo en 2026 tratan sobre autonomía. Integrando herramientas como Aider y Gemini CLI, no solo estás writing más rápido, estás pensando más rápido.

La barrera entre tener una idea y desplegar código nunca ha sido tan fina. Elige uno de estos agentes, dale una tarea y bienvenido a la era del desarrollo impulsado por IA.

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.

Seis palabras. Eso fue lo que publicó Peter Steinberger —el tipo detrás de OpenClaw, 190.000 estrellas en GitHub, recién reclutado por Sam Altman— en X el mes pasado. Y mi reacción inmediata fue hacerle una captura de pantalla y enviársela a tres amigos developers con un “TE LO DIJE” en mayúsculas.

Llevo años desarrollando en Ubuntu.

Cada herramienta que uso a diario es una CLI.

Supabase CLI, Vercel CLI, Docker, git, n8n — todo mi stack funciona y cobra vida desde una terminal. Cuando los servidores MCP empezaron a ser tendencia el año pasado, confieso que probé algunos. Funcionaban, es verdad. También consumían el 40% de mi ventana de contexto, fallaban aleatoriamente de la nada y añadían una dependencia absurda para algo que yo ya podía hacer perfectamente con un one-liner y un pipe.

Así que cuando el desarrollador open-source más prolífico de 2026 dice que las CLIs son la verdadera interfaz entre los agentes de IA y el mundo —y OpenAI está lo suficientemente de acuerdo como para ir a buscarlo y contratarlo— quizá sea momento de detenerse y prestar atención.

TL;DR: Los servidores MCP inflan tu ventana de contexto, añaden dependencias frágiles y resuelven un problema que no existe si tus herramientas ya son CLIs 😂 Peter Steinberger construyó ~10 CLIs personalizadas para OpenClaw y OpenAI lo contrató por ello.

Puedes usar exactamente este patrón hoy mismo con Claude Code (documentando CLIs en CLAUDE.md), conectarlas a OpenClaw como skills o construir tu propio agente autónomo con la API tool_use de Anthropic. Las CLIs son la interfaz nativa entre agentes IA y el mundo real. Las GUIs son para humanos. Las APIs son para servicios. Las CLIs son para agentes.

MCP vs CLI de un vistazo

Para poner las cartas sobre la mesa, vale la pena mirar frente a frente cómo se comportan ambas arquitecturas cuando un modelo de lenguaje intenta interactuar con ellas:

El caso contra MCP (y por qué el tipo de OpenClaw está de acuerdo con mi terminal)

Vamos a ordenar las formas en que un agente IA puede interactuar con herramientas externas. De peor a mejor, para que se entienda el panorama.

Las GUIs están obviamente descartadas en el primer segundo. No le pedirías jamás a tu pipeline de CI/CD que haga clics en un navegador para desplegar. La misma lógica aplica a los agentes. Sigamos.

Las APIs REST y SDKs funcionan, no lo voy a negar. Pero cada servicio tiene su propio flujo de autenticación, su propio formato de respuesta y su propio manejo de errores. Acabas escribiendo toneladas de código wrapper para cada bendita integración. Está bien para un backend SaaS convencional, pero es un exceso absoluto para un agente que solo necesita comprobar si tienes emails nuevos en la bandeja de entrada.

MCP —el Model Context Protocol— se suponía que iba a ser la solución definitiva a esto. Un protocolo estándar para conectar agentes con herramientas. Suena idílico y genial en teoría. ¿En la práctica? Cada servidor MCP que añades vuelca todo su esquema de golpe en la ventana de contexto de tu agente. Descripciones de herramientas, listas interminables de parámetros, declaraciones de capacidades —todo. Antes siquiera de que el agente empiece a pensar un solo segundo sobre tu petición real, ya se ha consumido un 30–40% del contexto en puro boilerplate de MCP.

Peter Steinberger lo probó. Construyó soporte para ello. Después creó MCPorter —una herramienta que literalmente convierte servidores MCP de nuevo en CLIs. Porque así de equivocado cree que está el formato.

Sus palabras exactas sobre lo único bueno que aportó MCP al ecosistema son para enmarcar:

“Lo único bueno de MCP fue que las empresas empezaron a abrir algunas APIs.”

Brutal. Y dolorosamente preciso. El protocolo en sí fue simplemente un desvío —las APIs que forzó a existir son el verdadero regalo de toda esta fiebre.

Las CLIs ganan por goleada porque son lo opuesto a todo ese bloat. Una CLI te ofrece:

• Cero overhead de contexto. Tu agente no necesita cargar un esquema pesado en memoria. Lee una página de documentación rápida (o ejecuta un comando --help) y ya conoce todos los comandos disponibles al instante.
• Composable. Puedes encadenar la salida de una CLI a otra con total naturalidad. goplaces search "coffee" --json | jq '.[0].address' —intenta hacer eso con un servidor MCP y me cuentas la frustración.
• Testeable en 2 segundos. Abres una terminal, ejecutas el comando tú misma y ves qué pasa en tiempo real. No hay servidor que levantar, ni handshake de protocolo que validar, ni conexiones WebSocket de las que depender.
• Salida estructurada gratis. Añades un flag --json y tu agente obtiene datos parseables de inmediato, sin ninguna capa extra de serialización caprichosa.
• Una sola llamada exec. Eso es todo lo que necesita un agente para usar una CLI. Sin middleware, sin protocolo, sin procesos en background consumiendo RAM valiosa solo por el hecho de existir.

El ejército de CLIs que llamó la atención de OpenAI

Y esto, de verdad, no es una simple preferencia teórica o un romance con la pantalla negra de la terminal.

Steinberger construyó todo el ecosistema de OpenClaw alrededor de CLIs. Aproximadamente una docena de ellas, cada una enfocada en una tarea ultraespecífica:

• goplaces para exprimir Google Maps.
• imsg para interactuar con iMessage.
• bird para conectar con X/Twitter.
• wacli para gestionar WhatsApp.
• gog para domar Gmail y Google Calendar.
• camsnap para interactuar con cámaras de seguridad.
• peekaboo para screenshots de macOS combinadas con visión IA.
• summarize para resumir de forma impecable vídeos y podcasts.

Cada una sigue rigurosamente el mismo patrón: hace una sola cosa bien, soporta --json y tiene un --help ridículamente claro.

Pasó la mayor parte de un año construyendo este ejército de CLIs. Y después, OpenAI fue y lo contrató. Sam Altman no reclutó a un ingeniero que hacía dashboards bonitos ni interfaces complejas —reclutó al tipo que demostró que bash es la mejor interfaz posible para que los agentes operen. Saca tus propias conclusiones.

Usar CLIs ahora mismo para construir más rápido (sin necesidad de OpenClaw)

No necesitas desplegar OpenClaw para empezar a beneficiarte de esto hoy mismo. Si usas Claude Code, Codex o cualquier agente con acceso a la shell, ya tienes toda la infraestructura que necesitas en tus manos.

El truco que la mayoría no termina de entender: tu agente ya puede llamar CLIs de forma nativa. Pero no conoce TUS CLIs específicas hasta que se lo dices explícitamente. Basta con dejar un archivo de texto bien estructurado en la raíz:

El archivo CLAUDE.md (raíz de tu proyecto)

Markdown

## CLIs disponibles

### Supabase
- `supabase db push` - aplicar migraciones al remoto
- `supabase functions deploy <name>` - desplegar edge function
- `supabase db dump --data-only` - exportar datos de producción
- `supabase migration new <name>` - crear nuevo archivo de migración

### Vercel
- `vercel deploy --prod` - desplegar a producción
- `vercel env pull .env.local` - sincronizar variables de entorno
- `vercel logs <url> --follow` - seguir logs de producción

### Específicas del proyecto
- `./scripts/check-mrr.sh` - devuelve JSON con MRR actual, registros y churn
- `./scripts/seed-demo.sh` - reinicia entorno demo con datos de ejemplo

Eso es todo lo que hace falta. Claude Code lee CLAUDE.md al inicio de cada sesión. La próxima vez que le digas “despliega a producción y comprueba si cambió el MRR”, ya sabe exactamente qué comandos ejecutar tras bambalinas. Sin plugins, sin servidor MCP intermedio, sin un archivo de configuración con 47 claves anidadas que te rompa la cabeza.

Para Codex, es el mismo concepto pero el archivo se llama AGENTS.md. Para Cursor, se llama .cursorrules. Nombre distinto, mismo patrón exacto.

Pero el verdadero movimiento inteligente es empezar a construir tus propias CLIs. Y antes de que cierres esta pestaña pensando “no tengo tiempo para construir herramientas CLI desde cero” —estamos hablando de escribir apenas 20–30 líneas de código. En serio.

Y hay un nivel aún más profundo que simplemente envolver servicios externos. La CLI que más importa es la que está dentro de tu propia app, compartiendo la misma capa de negocio que tu dashboard principal. Expliqué por qué deberías tratar esa CLI como el verdadero kernel de tu stack después de auditar dos de mis propias apps y encontrar una diferencia de velocidad de desarrollo de 1.8x a favor de este enfoque.

Para lograr que tus herramientas CLI sean un deleite para cualquier agente, solo tienes que seguir tres reglas esenciales:

1. Salida estructurada con --json

Tu agente no puede parsear cómodamente una tabla bonita llena de caracteres decorativos y líneas. Necesita JSON limpio.

JavaScript

#!/usr/bin/env node
// scripts/check-mrr.js
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY)
const args = process.argv.slice(2)
const jsonMode = args.includes('--json')

const { data } = await supabase
  .from('subscriptions')
  .select('plan, status, created_at')

const active = data.filter(s => s.status === 'active')
const mrr = active.reduce((sum, s) => sum + (s.plan === 'pro' ? 29 : 9), 0)

const today = data.filter(s => 
  new Date(s.created_at).toDateString() === new Date().toDateString()
)

const stats = {
  mrr,
  active_subscriptions: active.length,
  signups_today: today.length,
  timestamp: new Date().toISOString()
}

if (jsonMode) {
  console.log(JSON.stringify(stats))
} else {
  console.log(`MRR: $${mrr}`)
  console.log(`Active: ${active.length}`)
  console.log(`Signups today: ${today.length}`)
}

2. Un --help que realmente explique las cosas

Los agentes leen el --help con la misma atención con la que los humanos leemos un buen README. Si tu menú de ayuda es vago o confuso, tu agente empezará a alucinar flags que no existen.

Bash

$ ./check-mrr.js --help

Usage: check-mrr [options]

Check current SaaS metrics from Supabase.

Options:
  --json     Output as JSON (default: human-readable)
  --period   Filter: today | week | month (default: today)
  --help     Show this message

3. Exit codes impecables y limpios

0 significa éxito absoluto. 1 (o cualquier otro número) significa error. Tu agente usa este estándar de la industria para decidir qué paso dar a continuación.

Aprendí esto por las malas a las 2 AM, viendo cómo mi script de deploy fallaba silenciosamente en la terminal mientras Claude seguía diciéndome con toda la calma del mundo: “Deployment successful”. Tardé 20 minutos de frustración en darme cuenta de que el script se estaba tragando los errores y seguía devolviendo un código 0 alegremente, pero me estoy desviando del tema.

Una vez que tienes unas cuantas CLIs diseñadas bajo este estándar, algo cambia en tu flujo de trabajo. Dejas de pedirle a Claude Code que escriba queries complejas de Supabase a mano; empiezas a decirle simplemente: “comprueba mis métricas y, si los registros han caído más de un 20% respecto a ayer, redacta un mensaje para Slack al equipo”. Claude encadena las CLIs, procesa la lógica interna y actúa firmemente sobre el resultado. Eso ya no es simple autocompletado de código. Eso es un agente autónomo de verdad.

El patrón que hace que esto escale: CLI + Skill Doc

Aquí está lo que Steinberger entendió muy pronto y que la mayoría de los desarrolladores todavía no ha interiorizado: una CLI sin documentación clara es completamente inútil para un agente.

Tu agente no puede explorar una CLI interactiva mediante prueba y error para ver qué pasa, como haría un humano curioso. Necesita saber de antemano qué comandos existen, qué flags están disponibles y cuál es la estructura exacta de la salida. Por eso cada una de las CLIs del ecosistema OpenClaw incluye un archivo SKILL.md —un documento estructurado que actúa como manual de instrucciones directo para el modelo.

El patrón es redondo: binario CLI + skill doc = capacidad autónoma.

La CLI se encarga del trabajo sucio. El skill doc le enseña al agente cómo invocarla adecuadamente. Juntos forman una unidad autocontenida que cualquier agente puede heredar. Steinberger las llama “skills”. El concepto es exactamente el mismo da igual si decides llamarlo skill, tool o “ese script bash que escribió Dave el martes pasado para salir del paso”.

Y lo mejor es que no necesitas OpenClaw para usar este patrón en tu día a día. De hecho, conceptualmente ya lo estás haciendo cuando escribes un CLAUDE.md para documentar tus herramientas. La diferencia es que Steinberger estandarizó este formato y construyó una capa de distribución masiva encima: ClawHub, que ya cuenta con más de 3.000 skills listas para explorar e instalar.

¿La parte realmente interesante? Puedes robar tranquilamente cualquiera de esas skills para tu propia configuración. Cada skill de ClawHub es simplemente una CLI que puedes instalar de forma independiente (brew install steipete/tap/goplaces, npm install -g @steipete/oracle, etc.) y un archivo SKILL.md que puedes leer. No necesitas para nada el runtime de OpenClaw. Instalas el binario en tu máquina, pegas los comandos relevantes en tu CLAUDE.md y Claude Code podrá usarlos inmediatamente.

Markdown

# En tu CLAUDE.md — robado directamente de ClawHub

## goplaces (Google Maps CLI)
- `goplaces search "coffee near me" --open-now --json` - buscar lugares
- `goplaces search "pizza" --lat 40.8 --lng -73.9 --radius-m 3000 --json` - búsqueda geolocalizada
- `goplaces details <place_id> --json` - detalles completos con reseñas
- `goplaces resolve "Soho, London" --json` - geocodificar un lugar

Requires: GOOGLE_PLACES_API_KEY env var

## summarize (CLI para resumir vídeos/podcasts/web)
- `summarize --url "https://youtube.com/watch?v=xxx" --json` - resumir un vídeo
- `summarize --url "https://some-blog.com/post" --json` - resumir una página web
- `summarize --url "https://podcast.fm/ep42" --cli claude --json` - elegir qué modelo usar

Ahí tienes a goplaces y summarize —dos herramientas del propio Steinberger— ejecutándose dentro de Claude Code sin rastro ni dependencia de OpenClaw. Solo un binario instalado y un documento de texto que le da contexto al modelo.

Por eso el enfoque CLI escala de una forma que MCP nunca logrará. Un servidor MCP es un proceso vivo en ejecución que necesita mantenimiento, configuración, handshake de protocolo y espacio valioso en la ventana de contexto. Una skill CLI es un binario estático y un archivo de texto explicativo. Uno necesita infraestructura dedicada; el otro solo necesita un brew install y 10 líneas bien escritas de markdown.

Conectando CLIs a OpenClaw

Si ya estás ejecutando OpenClaw en tu entorno, convertir una CLI propia en una skill lista para tus agentes te llevará apenas unos 5 minutos.

El sistema funciona con una simplicidad tremenda: cada skill tiene un archivo SKILL.md que describe minuciosamente qué hace la CLI, cómo se instala en el sistema y qué comandos están disponibles. El agente procesa ese archivo y asimila la herramienta al instante.

YAML

---
name: check-mrr
description: Check SaaS metrics (MRR, signups, churn) from Supabase.

metadata:
  openclaw:
    requires:
      env:
        - SUPABASE_URL
        - SUPABASE_KEY
      bins:
        - node
    primaryEnv: SUPABASE_URL
---

# check-mrr

Get current SaaS metrics from production Supabase.

## Install

npm install -g @yourhandle/check-mrr

## Commands

- `check-mrr --json` - full metrics as JSON
- `check-mrr --period week` - metrics for the current week
- `check-mrr --period month` - monthly overview

## Output format (--json)

{
  "mrr": 1247,
  "active_subscriptions": 89,
  "signups_today": 3,
  "timestamp": "2026-02-17T10:30:00Z"
}

Publícalo en ClawHub (clawhub publish) y cualquiera que use OpenClaw podrá instalar tu skill en segundos. Pero el verdadero valor está en lo que puedes hacer en local: combínalo con un cron job y tu agente comprobará tus métricas de negocio cada mañana de forma autónoma, enviándote un WhatsApp detallado si nota algo extraño o algún comportamiento anómalo.

JSON

// In openclaw.json

{
  "cron": [
    {
      "schedule": "0 8 * * *",
      "message": "Run check-mrr --json. If signups_today is 0 or mrr dropped more than 5% from yesterday, alert me on WhatsApp with a summary. Otherwise just log it.",
      "channel": "whatsapp"
    }
  ]
}

Ese es el loop completo y perfecto. El cron activa el agente en el servidor, el agente lee la skill configurada, ejecuta la CLI en la terminal, interpreta el JSON devuelto y decide con criterio qué acción tomar. Ningún dashboard aburrido que tener que revisar manualmente cada mañana. Ninguna fatiga por notificaciones innecesarias en tu teléfono. El agente usa su propio criterio —el mismo patrón que Steinberger utiliza meticulosamente en todo su ecosistema.

El directorio de ClawHub ya tiene más de 3.000 skills de terceros desarrolladas bajo esta estructura. goplaces para búsquedas geográficas, himalaya para gestionar emails vía IMAP, bird (a pesar de todo 😭) para X/Twitter, sonoscli para domar tus altavoces desde la consola… todo un ejército a tu disposición. Las instalas, el agente las aprende y están listas para rodar.

Construyendo tu propio agente (el patrón OpenClaw, sin OpenClaw)

Vale, ¿y si no quieres meterte en el ecosistema de OpenClaw? Quizá prefieres algo mucho más ligero, más personalizado a tus flujos diarios o simplemente disfrutas la gloria de construir tus propias herramientas desde cero. (Te entiendo perfectamente. Yo lo self-hosteo absolutamente todo en mis servidores. Es una enfermedad hermosa).

El patrón principal para lograr esto es absurdamente simple: un script Node básico que llama a la API de Anthropic configurando tool_use, mapea los nombres de las herramientas devueltas a ejecuciones reales en la CLI y mantiene el bucle activo hasta que el agente considera que ha terminado la tarea.

JavaScript

import Anthropic from '@anthropic-ai/sdk'
import { execSync } from 'child_process'

const client = new Anthropic()

// Tus CLIs declaradas como tools legibles para el modelo
const tools = [
  {
    name: "check_mrr",
    description: "Get current SaaS metrics (MRR, active subs, signups today)",
    input_schema: {
      type: "object",
      properties: {
        period: { type: "string", enum: ["today", "week", "month"], default: "today" }
      }
    }
  },
  {
    name: "deploy_production",
    description: "Deploy latest commit to Vercel production. Returns deploy URL.",
    input_schema: {
      type: "object",
      properties: {}
    }
  },
  {
    name: "send_slack",
    description: "Send a message to a Slack channel",
    input_schema: {
      type: "object",
      properties: {
        channel: { type: "string" },
        message: { type: "string" }
      },
      required: ["channel", "message"]
    }
  }
]

// Mapear de forma limpia nombres de tools a comandos reales de la CLI
function executeTool(name, input) {
  const commands = {
    check_mrr: `node ./scripts/check-mrr.js --json --period ${input.period || 'today'}`,
    deploy_production: `vercel deploy --prod --yes 2>&1`,
    send_slack: `curl -X POST -H 'Authorization: Bearer ${process.env.SLACK_TOKEN}' \
      -H 'Content-Type: application/json' \
      -d '{"channel":"${input.channel}","text":"${input.message}"}' \
      https://slack.com/api/chat.postMessage`
  }
  
  try {
    const result = execSync(commands[name], { encoding: 'utf-8', timeout: 30000 })
    return result
  } catch (err) {
    return JSON.stringify({ error: err.message, exitCode: err.status })
  }
}

// El loop core de nuestro agente
async function runAgent(task) {
  let messages = [{ role: "user", content: task }]
  
  while (true) {
    const response = await client.messages.create({
      model: "claude-sonnet-4-5-20260514", // usando la última versión estable del modelo
      max_tokens: 4096,
      system: "You are an autonomous agent. Use the available tools to complete tasks. Be concise in your reasoning.",
      tools,
      messages
    })

    // Si Claude terminó su trabajo y quiere responder, salimos del bucle
    if (response.stop_reason === "end_turn") {
      const text = response.content.find(b => b.type === 'text')
      return text?.text || 'Done.'
    }

    // Si Claude determina que necesita usar herramientas, las ejecutamos secuencialmente
    const toolBlocks = response.content.filter(b => b.type === 'tool_use')

    if (toolBlocks.length === 0) break

    messages.push({ role: "assistant", content: response.content })

    const toolResults = toolBlocks.map(block => ({
      type: "tool_result",
      tool_use_id: block.id,
      content: executeTool(block.name, block.input)
    }))

    messages.push({ role: "user", content: toolResults })
  }
}

// Ejecución inicial de prueba
const result = await runAgent(
  "Check our MRR. If it's above $1000, deploy to production and notify #team on Slack with the metrics. If it's below, just send a warning to Slack."
)

console.log(result)

~80 líneas de código estructurado. Ese es, literalmente, tu propio mini-OpenClaw personal. El agente tiene la capacidad de decidir de forma autónoma qué herramientas llamar y en qué orden lógico según la tarea exacta que le encomiendes. Añadir una nueva CLI a su arsenal te llevará apenas 30 segundos —añades una definición limpia de la tool, una línea en tu mapa de comandos exec y listo para rodar.

Para la parte de automatización autónoma desatendida, simplemente envuelve el script en un cron clásico de tu sistema:

Bash

# crontab -e

0 8 * * * cd /home/deploy/my-agent && node agent.js "Morning check: metrics, deploy if stable, notify team"

0 20 * * * cd /home/deploy/my-agent && node agent.js "End of day: summarize signups, flag any anomalies to Slack"

También tienes la opción de ejecutarlo como un servicio nativo de systemd acompañado de un timer, o meterlo directamente dentro de un contenedor Docker aislado en tu propio servidor doméstico. Mismo resultado final, diferentes sabores de devops según tus manías.

GitHub Actions es otra alternativa fantástica si lo que buscas es una infraestructura líquida con coste y mantenimiento cero. Un workflow programado que se encarga de levantar el entorno, instalar tus CLIs locales en el runner temporal e invocar la API de Anthropic:

YAML

name: Daily Agent Run

on:
  schedule:
    - cron: '0 8 * * *'

jobs:
  agent:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'

      - run: npm install @anthropic-ai/sdk

      - run: node agent.js "Morning routine"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
          SUPABASE_KEY: ${{ secrets.SUPABASE_KEY }}

Completamente gratis para repositorios públicos, y dispones de 2.000 minutos al mes en repositorios privados. Nada mal para mantener un agente operativo diario que apenas tarda 30 segundos en completar su ejecución.

¿Y n8n dónde queda en todo esto?

Sé bien que es tentador intentar orquestar tus CLIs directamente desde paneles visuales como n8n, utilizando su nodo nativo Execute Command o envolviendo tus scripts en pequeñas instancias locales de FastAPI.

Pero, siendo completamente sincera, para este caso de uso específico esa arquitectura suele generar bastante más fricción que el enfoque limpio con scripts de código. n8n es una absoluta maravilla cuando necesitas orquestar flujos de trabajo visuales complejos, con 15 pasos distintos e integraciones complejas de branching —pero no aporta valor real para un flujo directo de “ejecuta una CLI concreta en la terminal y deja que el LLM decida el camino según el resultado”.

Si de todas formas quieres profundizar en cómo ejecutar código personalizado dentro de ese entorno, hace poco escribí una guía completa sobre cómo llamar scripts Python desde n8n que cubre detalladamente toda la configuración con Docker + FastAPI.

Qué significa todo esto para ti

La tendencia de la industria está clara y se mueve rápido.

Los builders más rápidos y productivos en el espacio actual de los agentes de IA no están perdiendo el tiempo apilando servidores MCP complejos ni peleándose con adaptadores de protocolo rebuscados. Están escribiendo CLIs pequeñas, afiladas como bisturís, y dejando que sus agentes las invoquen con total libertad.

Peter Steinberger lo demostró con creces a escala real con OpenClaw. OpenAI lo validó de la forma más rotunda posible extendiéndole un contrato de trabajo. Y tú puedes empezar hoy mismo a aplicar esta filosofía con un simple archivo CLAUDE.md bien estructurado y un script en Node de apenas 20 líneas.

El stack tecnológico de fondo no importa en absoluto. Ya sea OpenClaw, Claude Code, Codex o tu propio loop de agente personalizado —el patrón maestro permanece idéntico. Envuelve tus herramientas cotidianas en CLIs limpias. Documéntalas con mimo para tu agente. Y deja que el LLM se encargue de toda la orquestación pesada.

Un último apunte para cerrar: este artículo aborda las CLIs como la interfaz perfecta para que los agentes llamen herramientas externas. La otra mitad vital de la ecuación es la CLI que decides construir dentro de tu propia aplicación, donde se convierte en el kernel definitivo que permite a Claude Code desplegar features completas mientras tú descansas. Diferente superficie de ataque, pero compartiendo exactamente la misma capa de ingeniería.

Añade una CLI robusta a tu app o prepárate para que Claude Code te esté haciendo ping en Slack por cada pequeña funcionalidad que necesite.

Tu terminal llevaba siendo la interfaz de IA perfecta todo este tiempo. La mayoría simplemente todavía no se había dado cuenta del potencial que tenía guardado en su pantalla negra.

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 un año y medio, compartí 7 herramientas de línea de comandos que mejoraron mi experiencia en la terminal. Con más de 20k lecturas, ese blog se convirtió en un éxito instantáneo y muchos lectores comenzaron a usar esas herramientas en sus propios flujos de trabajo diarios. También recibí una gran cantidad de sugerencias para seguir mejorando mi experiencia en la terminal.

Si aún no lo has leído, ¡te dejo el enlace aquí!

💡 Lectura recomendada: ¡Estas 7 herramientas de línea de comandos me volaron la cabeza! Advertencia: Estas utilidades de línea de comandos son seriamente adictivas — levelup.gitconnected.com

Desde entonces, las cosas han cambiado muchísimo. En 2026, con la IA irrumpiendo en el mundo de la ingeniería de software, estamos presenciando un cambio de paradigma. Ya no solo desarrollamos código y lo desplegamos, ahora colaboramos con agentes y automatizamos tareas utilizando IA.

Y la terminal no ha sido una excepción. Se están lanzando numerosas herramientas CLI construidas sobre capacidades de IA. Esto desbloquea utilidades que eran imposibles hace solo unos pocos años.

La terminal se está convirtiendo lentamente en una cabina impulsada por IA.

Hoy voy a compartir siete herramientas CLI potenciadas por IA que potenciarán tu terminal igual que hicieron con la mía. Si estás listo, ¡vamos allá!

1. Aider — El programador en pareja con IA estándar de la industria

Aider es probablemente la herramienta más potente de esta lista. Te permite programar en pareja con LLMs (como GPT-4o, Claude 3.5 o modelos locales mediante Ollama) directamente desde tu terminal.

A diferencia de un simple chat, Aider edita tus archivos en vivo y crea automáticamente commits de Git con mensajes descriptivos para cada cambio que realiza. Mapea todo el contexto de tu repositorio para entender exactamente cómo un cambio en un archivo afecta a otro.

• El factor “Wow”: literalmente puedes decir “Refactoriza la lógica para usar JWT” y ver cómo edita 5 archivos y hace commit de los cambios antes de que termines tu café.

También soporta la funcionalidad “Voice-to-Code”, mediante la cual puedes hablarle a Aider sobre tu código y pedir mejoras o correcciones de bugs.

Así es como puedes empezar con Aider.

Bash

python -m pip install aider-install
aider-install

# Cambiar directorio hacia tu codebase
cd /to/your/project

# DeepSeek
aider --model deepseek --api-key deepseek=<key>

# Claude 3.7 Sonnet
aider --model sonnet --api-key anthropic=<key>

# o3-mini
aider --model o3-mini --api-key openai=<key>

¡Para más detalles revisa su sitio web!

2. Gemini CLI — El Shell Agéntico de Google

Si quieres potencia IA de alto nivel sin una suscripción, Gemini CLI es actualmente el rey de los planes gratuitos. Te da acceso directo desde la terminal a Gemini 3 Flash y Pro.

Está construido para tareas “Agénticas”. Puede ejecutar comandos, explorar tu sistema de archivos y corregir errores en tiempo real.

Con una interfaz increíble directamente dentro de la CLI, Gemini CLI es una de las herramientas imprescindibles para probar en 2026.

Además de eso, proporciona acceso a todas las herramientas IA que ofrece Google como generación de vídeo, Deep Research y Notebook LM.

Gemini CLI puede instalarse usando npm.

Bash

npm install -g @google/gemini-cli

¡Para más métodos de instalación, consulta su sitio web!

3. Atuin — Tu historial del shell, pero con “Cerebro”

Recordar un comando que ejecutaste hace tres semanas solía ser un juego de history | grep. Atuin reemplaza el historial de tu shell con una base de datos SQLite buscable que se sincroniza entre tus máquinas.

En la era de la IA, Atuin ha evolucionado. Ahora soporta búsqueda semántica y descubrimiento de comandos impulsado por IA. En lugar de recordar el flag exacto, puedes buscar la “intención” de lo que hiciste.

Instala Atuin en tu máquina usando el siguiente comando curl.

Bash

curl --proto '=https' --tlsv1.2 -LsSf https://setup.atuin.sh | sh

Para más información visita su sitio web.

4. ShellGPT (sgpt) — La navaja suiza de los shells con IA

A veces no necesitas un programador en pareja completo como Aider. Solo necesitas una respuesta rápida. ShellGPT es una herramienta ligera que lleva ChatGPT (o cualquier API compatible) a tu pipeline.

Puedes canalizar logs directamente hacia él:

Bash

cat error.log | sgpt "explain this error"

o pedirle que genere scripts shell sobre la marcha. Incluso puede generar mensajes de commit de Git basados en tus cambios staged.

Para empezar con shell-gpt, usa pip.

Bash

pip install shell-gpt

# Generar un comando y ejecutarlo
sgpt --shell "find all large files in /var/log"

5. Warp — Entorno de desarrollo agéntico

Warp es el entorno de desarrollo agéntico, construido para programar con múltiples agentes IA. Warp lleva la terminal al siglo XXI con una interfaz moderna y funcionalidades de edición de código. Usa el agente integrado SOTA Oz de Warp, o ejecuta agentes CLI como Claude Code, Codex o Gemini CLI.

• Plan gratuito: Warp es gratis para individuos e incluye una cantidad generosa de solicitudes IA mensuales.

6. Goose — El agente open-source de “Vibe Coding”

Goose es tu agente IA ejecutándose en tu máquina, capaz de automatizar tareas complexes de desarrollo de principio a fin. Más allá de simples sugerencias de código, Goose puede construir proyectos completos desde cero, escribir y ejecutar código, depurar errores, orquestar workflows e interactuar con APIs externas — de forma autónoma.

Diseñado para máxima flexibilidad, Goose funciona con cualquier LLM y soporta configuración multi-modelo para optimizar rendimiento y costes, se integra perfectamente con servidores MCP y está disponible tanto como aplicación de escritorio como CLI — convirtiéndose en el asistente IA definitivo para desarrolladores que quieren moverse más rápido y centrarse en la innovación.

Para instalar Goose en Mac, usa el siguiente comando brew.

Bash

brew install block-goose-cli

Para más métodos de instalación, consulta su sitio web.

7. OpenCode — La alternativa Privacy-First

Si estás trabajando en proyectos sensibles donde no puedes enviar código a un proveedor cloud, OpenCode es tu mejor amigo. Es una herramienta impulsada por la comunidad que hace increíblemente fácil cambiar entre más de 75 proveedores LLM diferentes, incluyendo modelos completamente locales.

Está diseñada para desarrolladores que quieren la experiencia de “Agente” sin vendor lock-in.

Estas son algunas formas de empezar a usar OpenCode:

Bash

# YOLO
curl -fsSL https://opencode.ai/install | bash

# Gestores de paquetes
npm i -g opencode-ai@latest        # o bun/pnpm/yarn
scoop install opencode             # Windows
choco install opencode             # Windows
brew install anomalyco/tap/opencode # macOS y Linux (recomendado, siempre actualizado)
brew install opencode              # macOS y Linux (fórmula oficial brew, menos actualizada)
sudo pacman -S opencode            # Arch Linux (Estable)
paru -S opencode-bin               # Arch Linux (Última versión desde AUR)
mise use -g opencode               # Cualquier SO
nix run nixpkgs#opencode           # o github:anomalyco/opencode para la última rama dev

Las herramientas que están apareciendo en 2026 tratan sobre autonomía. Integrando herramientas como Aider y Gemini CLI, no solo estás writing más rápido, estás pensando más rápido.

La barrera entre tener una idea y desplegar código nunca ha sido tan fina. Elige uno de estos agentes, dale una tarea y bienvenido a la era del desarrollo impulsado por IA.

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.

Uno se pasa el día copiando y pegando archivos, atrapado en la rutina. El otro, simplemente conecta herramientas y deja que la magia fluya.

Mientras uno chatea, el otro construye.

La verdadera diferencia tiene nombre propio: MCP, o Model Context Protocol. Si estás lista para que tu IA empiece a trabajar de verdad para ti, estas son las ocho herramientas MCP que deberías integrar en tu flujo ahora mismo.

#8 — Vercel

Imagina que despliegas una aplicación y, de repente, falla. Lo habitual sería salir de tu editor, abrir Vercel, navegar por los deployments, revisar logs y jugar a los detectives para encontrar el error.

Con el servidor MCP de Vercel, tu IA se conecta directamente a tus despliegues. Solo necesitas un prompt:

“Obtén los logs del último deployment. ¿Por qué falló el build?”

La IA rescatará los logs, identificará el error exacto y te propondrá la solución. Te mantienes enfocada, dentro de tu flujo de trabajo, sin distracciones.

• Coste: El plan Hobby es gratuito; el plan Pro comienza en 20 USD por usuario.

#7 — Docker

Este MCP resuelve ese drama universal: “En mi máquina funciona, pero en CI no”. En lugar de perder horas comparando variables de entorno o adivinando qué imagen base falló, Docker MCP entra en acción.

Requiere Docker Desktop 4.48 o superior y permite que tu IA inspeccione el contenedor directamente.

“¿Por qué este contenedor falla en CI, pero no localmente?”

Ahora la IA puede revisar el histórico del build, la caché de capas y las sutiles diferencias del entorno. La incertidumbre desaparece.

• Coste: La mayoría de las configuraciones son self-hosted u open source; solo pagas por tu propia infraestructura.

#6 — Apify

Cada vez que necesitas datos de una web, terminas construyendo un scraper que, seamos sinceras, tarde o temprano se romperá porque el layout cambió o el selector se movió.

Apify MCP Server elimina todo ese estrés dándote acceso a más de 2.000 "actores" (scrapers mantenidos).

“Encuentra todas las empresas de IT en mi ciudad usando Google Maps. Exporta nombre, web y teléfono en un CSV.”

Y listo. Así de elegante.

• Coste: 5 USD de crédito gratis al mes; planes de pago desde unos 49 USD.

#5 — Playwright

Este es uno de mis imprescindibles. Si Apify recopila datos, Playwright ejecuta acciones. Le da a tu IA un navegador con el que puede interactuar: hacer clic, escribir, desplazarse o gestionar descargas.

¿Necesitas entrar en un dashboard antiguo con verificación en dos pasos y descargar un informe diario? Playwright puede encargarse.

• Coste: Es gratuito y corre localmente o en CI. Una joya para la automatización real.

#4 — Ref

Seguro que te ha pasado: le preguntas a la IA sobre una librería y se pierde en miles de líneas de documentación innecesaria. El exceso de contexto a veces es ruido.

Ref permite que la IA haga preguntas ultra-específicas. En lugar de pedirle que lea toda la documentación de Playwright, puedes ser directa:

“¿Cuáles son los parámetros de page.waitForSelector?”

Recibes la firma de la función y la explicación, sin distracciones.

• Coste: Gratis para documentación pública; planes de pago para indexar archivos privados.

#3 — File System MCP

Sin esto, tu IA está ciega; solo conoce el código que tú decides pegarle. No entiende las dependencias ni sabe qué archivos importan a cuáles.

Con File System MCP, la IA obtiene una visión integral de tu proyecto.

“Encuentra componentes que no se estén utilizando.”

Al escanear toda la carpeta src, la IA comprende relaciones estructurales, no solo fragmentos aislados. Es la clave para realizar cambios a nivel de arquitectura.

• Coste: Gratuito y de ejecución local.

#2 — Exa

Google fue diseñado para humanos y SEO; Exa está diseñado para la IA. Busca por significado y devuelve resultados estructurados que tu modelo puede procesar de inmediato.

Si necesitas soluciones actualizadas:

“Encuentra discusiones sobre esta race condition en React en 2026.”

Te traerá el issue de GitHub relevante y la solución técnica real, saltándose el ruido comercial.

• Coste: Incluye 1.000 solicitudes gratuitas; los planes de pago inician sobre los 50 USD mensuales.

#1 — Sequential Thinking

A veces las IA son demasiado impulsivas y responden antes de reflexionar. Sequential Thinking las obliga a planificar: dividir el problema, cuestionar supuestos y definir pasos antes de escribir una sola línea de código.

No es para scripts sencillos; es para lógica seria, diseño de sistemas y debugging complejo. Es la diferencia entre una respuesta rápida y una respuesta de ingeniería.

• Coste: Gratuito y open source.

De chatear a construir

Con estas herramientas conectadas, dejas de ser una simple usuaria que pega contexto para convertirte en una arquitecta que orquesta sistemas. El cambio es total: de los snippets aislados a la conciencia completa del proyecto.

El protocolo MCP no es solo una funcionalidad; es lo que separa a una IA que solo habla de una IA que realmente trabaja.

¿Has descubierto alguna herramienta que vaya a cambiar tu día a día? Si es así, no olvides dejar un poco de cariño.

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.

Lanzaste un chatbot el trimestre pasado. Entiende muy bien la intención del cliente. Genera respuestas útiles y bien formateadas. Tu PM lo llamó “mágico” durante la demo. Entonces un cliente pide un reembolso. El chatbot responde:

“¡Lo procesaré por ti!”

Y no hace absolutamente nada. Generó una frase segura sobre procesar un reembolso, pero sin procesarlo realmente. No tiene acceso a tu base de datos de pedidos. No puede llamar a tu API de reembolsos. Ni siquiera puede comprobar si la ventana de devolución sigue abierta. Simplemente… habla.

El cliente hace una captura de pantalla, la publica en X, y ahora tu VP de Customer Success le está escribiendo al CEO. Acabas de chocar con el muro que tarde o temprano encuentra todo equipo que construye sobre LLMs: el modelo puede razonar sobre qué hacer, pero no puede hacerlo. No tiene manos.

Un agente de IA le da manos. Pero ¿qué significa eso realmente? ¿Y por qué todo el mundo, desde OpenAI hasta tu CEO, sigue diciendo que 2026 será “el año del agente”? Vamos a desglosarlo juntas.

El resumen rápido

Un agente de IA es un sistema de software que usa un LLM como “cerebro” para razonar sobre una tarea, decidir qué herramientas usar y ejecutar acciones en bucle hasta completar el trabajo. Un LLM sin agente es como un ingeniero senior que solo puede hablar. Puede diagnosticar el problema en una pizarra, pero no puede tocar el servidor. Un agente le da una terminal.

El bucle principal es simple: Pensar → Actuar → Observar → Repetir

El agente razona, llama a una función, revisa el resultado y decide si debe seguir trabajando o entregar una respuesta. El agente de Klarna gestionó dos tercios de todos los chats de atención al cliente y redujo el tiempo de resolución de 11 minutos a menos de 2. Luego tuvieron que volver a contratar humanos. Las tareas limitadas funcionan. El juicio abierto, no tanto.

El LLM rara vez es el problema. Deloitte encontró que solo alrededor de 1 de cada 10 organizaciones tiene agentes en producción. Lo que los mata suele ser otra cosa: autenticación, gestión de errores, trazabilidad, cumplimiento normativo.

Vamos a entrar en detalle.

Este artículo fue publicado hace unos días en The AI Engineer, una newsletter gratuita que nos convierte a las ingenieras en perfiles peligrosos con IA. No llegues tarde la próxima vez → https://theaiengineer.substack.com

Antes de los agentes, existían chatbots bastante buenos

Para entender por qué importan los agentes, primero hay que entender qué había antes. Y por qué dejó de ser suficiente. Un chatbot tradicional, de los de antes de los LLMs, era básicamente un árbol gigante de if/else:

• Cliente dice “reembolso” → mostrar política de reembolsos.
• Cliente dice “horarios” → mostrar horario comercial.

Luego llegaron los LLMs, y los chatbots mejoraron muchísimo entendiendo lo que querías decir. Podías escribir: “Oye, me llegó la talla equivocada y quiero devolverlo” y el LLM entendía que querías hacer una devolución, aunque nunca hubieras usado la palabra “devolución”. Fue una mejora enorme.

Un LLM es como un ingeniero senior que solo puede hablar. Puede depurar tu sistema en una pizarra, pero no puede entrar por SSH al servidor, ejecutar una consulta ni subir el fix. Mucho razonamiento. Cero ejecución. Un agente es lo que ocurre cuando le das una terminal a ese ingeniero.

El ingeniero sin terminal

Así se ve esto por dentro. Un chatbot LLM normal, sin herramientas y sin framework de agentes. Cliente: “Quiero un reembolso del pedido #4821. Devolví el producto hace dos días.”

Lo que hace el LLM:

1. Entiende la intención: solicitud de reembolso.
2. Genera una respuesta que suena útil: “¡Con gusto te ayudo con tu reembolso! Déjame revisar el pedido #4821.”

Pero no puede revisar realmente el pedido #4821. No tiene acceso a tu base de datos de pedidos. No sabe si la devolución fue recibida. No sabe si la ventana de reembolso sigue abierta. Entonces hace una de dos cosas: alucina detalles (“Tu reembolso de 47,99 dólares ha sido procesado”) aunque no tenga ni idea del importe del pedido. O delega: “Por favor, contacta con nuestro equipo de soporte en support@company.com”.

Los problemas concretos son estos:

• No tiene acceso a datos en tiempo real. El conocimiento del LLM está congelado en el momento de entrenamiento. No conoce el estado del pedido de tu cliente, tu inventario actual ni tu política de reembolsos, que actualizaste el jueves pasado.
• No tiene capacidad para ejecutar acciones. Incluso si el LLM entiende perfectamente la situación, no puede llamar a tu API de reembolsos, actualizar un registro en la base de datos ni enviar un email de confirmación. Es texto que entra y texto que sale. Nada más.
• No puede razonar a través de múltiples pasos. Las tareas complejas requieren comprobar una cosa, usar ese resultado para decidir el siguiente paso y encadenar varias operaciones. Una llamada única a un LLM es un disparo de una sola vez. No tiene un mecanismo para pausar, ir a buscar más información y volver.

Alerta de confusión: “Pero ChatGPT puede navegar por internet y ejecutar código.” Sí, porque ChatGPT es un agente. Cuando lo ves buscar en la web, está usando herramientas mediante un bucle de agente. El LLM base que hay debajo no puede hacer nada de eso por sí solo.

Llegados a este punto, probablemente estés pensando: “Vale, entonces ¿cómo le das al LLM acceso a herramientas y le permites razonar en bucle?”. Eso es exactamente lo que es un agente de IA.

Cómo funcionan realmente los agentes de IA

Un agente de IA existe precisamente por los problemas anteriores. Así funciona. La idea central es muy simple. En vez de llamar una vez al LLM y devolver el resultado, pones al LLM dentro de un bucle: El bucle del agente de IA: el LLM razona, actúa usando herramientas, observa resultados y repite el proceso hasta que la tarea queda completada. Ese es todo el concepto.

Veámoslo con el ejemplo del reembolso. El cliente dice: “Reembolsa el pedido #4821.” El primer movimiento del agente es pensar: “Necesito buscar este pedido antes de hacer nada.” Entonces actúa llamando a: order_lookup("4821"). Observa el resultado: estado del pedido: "returned", total: 47.99, ventana de devolución: abierta. Vuelve a pensar: “La devolución está confirmada y la ventana sigue abierta, así que debo procesar el reembolso.” Actúa otra vez llamando a: process_refund("4821", 47.99). Observa el resultado: reembolso completado, número de referencia: RF-9920. Piensa una vez más: “Ya tengo todo lo necesario.” El agente sale del bucle y responde al cliente: “Tu reembolso de 47,99 dólares para el pedido #4821 ha sido procesado, referencia RF-9920. Deberías verlo reflejado en 3 a 5 días laborables.”

Dos bucles. Dos llamadas a herramientas. Una tarea completa gestionada de principio a fin sin que un humano la toque. Eso es todo. El agente alterna entre razonar y ejecutar hasta que tiene lo que necesita. Este patrón tiene un nombre en la literatura de investigación: ReAct, de Reasoning + Acting, propuesto en un paper de 2023 de Yao et al. Si has visto algún framework de agentes como LangChain, LlamaIndex, CrewAI o la Assistants API de OpenAI, ya has visto este patrón. Todos implementan alguna variación de este bucle por debajo.

Los tres componentes

Todo agente tiene tres partes:

1. El cerebro: LLM. Hace el razonamiento. Decide qué hacer después, interpreta resultados y gestiona casos límite. Por eso la calidad del modelo importa más en agentes que en chatbots. Un chatbot con un modelo débil da una respuesta mediocre. Un agente con un modelo débil llama a la herramienta equivocada, recibe un resultado confuso y entra en espiral. Cada paso del bucle es una decisión. Y el modelo toma todas esas decisiones.
2. Las herramientas. Son funciones que el agente puede llamar: consultas a bases de datos, llamadas API, búsqueda web, ejecución de código, operaciones con archivos. Cualquier cosa que puedas envolver en la firma de una función, el agente puede usarla. Esa es la parte importante. El agente no necesita saber cómo funcionan tus herramientas internamente. Lee una descripción de cada herramienta (nombre, parámetros, qué devuelve) y decide cuándo llamarla. Buenas descripciones de herramientas crean buenos agentes. Descripciones vagas crean agentes que alucinan llamadas a herramientas.
3. La memoria o estado. Es el contexto activo de la conversación y de las acciones ejecutadas hasta el momento. Sin esto, el agente olvidaría qué acaba de consultar entre un paso y otro. En el ejemplo del reembolso, la memoria es lo que permite que el agente recuerde que el estado del pedido era "returned" cuando llega al segundo paso. Suena obvio, pero gestionar qué recuerda el agente y qué olvida se convierte en un problema real de ingeniería cuando las conversaciones son largas o abarcan varias sesiones.

El cerebro es el ingeniero. Las herramientas son la terminal. La memoria es cómo lleva registro de lo que ya intentó.

Una mirada más profunda

El paper original de ReAct, de Yao et al., mostró que combinar trazas de razonamiento con uso de herramientas superaba tanto al prompting puro de chain-of-thought como a la toma de acciones pura en tareas como respuesta a preguntas y verificación de hechos. La idea clave: las trazas de razonamiento ayudan al modelo a recuperarse de errores y evitar alucinar llamadas a herramientas.

Ejemplo mínimo de un agente en Python con LangChain:

Python

from langchain.agents import create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import tool

@tool
def order_lookup(order_id: str) -> dict:
    """Look up an order by ID. Returns status, total, and return window."""
    return db.orders.find_one({"id": order_id})

@tool
def process_refund(order_id: str, amount: float) -> dict:
    """Process a refund for a given order."""
    return payments.refund(order_id=order_id, amount=amount)

agent = create_react_agent(
    model=ChatOpenAI(model="gpt-4"),
    tools=[order_lookup, process_refund],
    prompt="You are a customer service agent for Acme Corp..."
)

# The agent loops internally until it has a final answer
result = agent.invoke({"input": "Refund order #4821"})

Eso son unas 15 líneas de código. Me sorprendió mucho la primera vez que monté esto: la función create_react_agent gestiona por ti el bucle Pensar → Actuar → Observar. Tú solo defines las herramientas y el prompt. Si estás pensando: “Eso no puede ser todo”, tienes razón. El bucle son 15 líneas. Las otras 10.000 líneas son gestión de errores, autenticación y asegurarte de que no reembolse pedidos que nunca existieron.

¿Te gusta esta explicación? The AI Engineer publica tres ediciones como esta cada semana: explicaciones de conceptos, comparativas de herramientas y casos reales de producción. Los suscriptores las reciben 10 días antes de que lleguen a Medium. Acceso anticipado → https://theaiengineer.substack.com

Quién está construyendo realmente con esto

Vamos a aterrizarlo en la realidad de producción. Klarna apostó fuerte por agentes de IA para atención al cliente a principios de 2024. Su agente gestionó 2,3 millones de conversaciones en su primer mes, cubrió dos tercios de todos los chats de clientes y redujo el tiempo medio de resolución de 11 minutos a menos de 2. Para el tercer trimestre de 2025, el agente estaba haciendo el trabajo equivalente a 853 empleados a tiempo completo y había ahorrado 60 millones de dólares. Luego tuvieron que volver a contratar agentes humanos. Los clientes estaban recibiendo respuestas genéricas y demasiado plantilladas en problemas complejos: disputas de facturación con varios pedidos, políticas de reembolso en casos límite, cualquier cosa que exigiera juicio entre varios sistemas.

Lección de ingeniería: Klarna enrutó todo por el mismo camino de agente sin una escalación adecuada para consultas complejas. Las preguntas simples funcionaban muy bien. El razonamiento multi-paso sobre entradas ambiguas no tanto. La capa de routing que decide qué debería intentar resolver el agente importa tanto como el agente en sí.

Los agentes de código probablemente son la categoría más madura. GitHub Copilot, Cursor y Claude Code usan el mismo bucle: Pensar → Actuar → Observar. La diferencia es que sus herramientas son acceso al sistema de archivos, comandos de terminal y runners de tests. Describes un bug. El agente lee tu codebase, escribe un fix, ejecuta los tests, ve qué falla y vuelve a intentarlo.

Shopify Sidekick es un agente que permite a los merchants gestionar sus tiendas usando lenguaje natural: analizar segmentos de clientes, actualizar productos, crear descuentos, generar reportes. Combina el bucle de agente con RAG para traer datos vivos de productos y clientes al contexto. Debajo del capó, Shopify construyó jueces impulsados por LLM para evaluar las decisiones de Sidekick, calibrándolas contra juicio humano hasta que los niveles de acuerdo se acercaran a referencias humano-con-humano. También construyeron un simulador de merchants que reproduce conversaciones reales contra cambios candidatos del sistema antes de desplegarlos.

Qué puede salir mal y qué está sobrevendido

• Alucinaciones en llamadas a herramientas. A veces los agentes invocan herramientas que no existen o pasan argumentos que no tienen sentido. Esto es especialmente común con modelos más pequeños. Sin fine-tuning o buenos ejemplos few-shot, el rendimiento puede caer incluso por debajo del prompting básico con chain-of-thought.
• Errores compuestos. Cada paso en el bucle del agente tiene una pequeña probabilidad de fallar. Encadena cinco pasos y has compuesto esas tasas de error. La parte peligrosa es que la respuesta final sigue viéndose pulida. No te das cuenta de que el paso cinco salió mal hasta que un usuario lo reporta. Los mejores modelos frontier completan correctamente alrededor del 24% de las tareas reales de trabajo de conocimiento en el primer intento.
• La brecha de gobernanza. Gartner predice que más del 40% de los proyectos de IA agéntica serán descartados para 2027. Los LLMs funcionan bien. El problema es todo lo que los rodea: gestión de identidad, trazabilidad, gestión de errores, cumplimiento normativo.
• La brecha del hype. La frase “el año del agente” lleva circulando desde 2024, y seguimos mayormente en modo piloto. El informe Tech Trends 2025 de Deloitte encontró que solo alrededor de 1 de cada 10 organizaciones tiene agentes en producción, con otro 38% ejecutando pilotos. La tecnología funciona. La preparación organizacional, no tanto.

Si alguien te dice que los agentes de IA van a automatizar todo tu negocio para el cuarto trimestre, pregúntale cómo fue su último piloto de IA. Dicho eso, el agente limitado y bien definido sí está generando valor hoy en dominios acotados: gestionar reembolsos, clasificar tickets, buscar en codebases, resumir investigación. El patrón que funciona es claro: herramientas bien definidas y humanos en el bucle para casos límite.

Lo único que debes recordar

Un agente de IA no hace que el LLM sea más inteligente. La inteligencia ya estaba ahí. El agente le da agencia: una terminal para actuar sobre lo que ya sabe.

Para profundizar:

• Cursor vs Claude Code: comparación directa entre los dos agentes de código más capaces. ¿Cuál encaja mejor con tu flujo de trabajo?
• Qué es RAG: los agentes suelen usar RAG para acceder a conocimiento externo. Si has escuchado “RAG” por todas partes, esto explica por qué.
• Qué es MCP: el nuevo estándar para conectar LLMs con herramientas. Piensa en ello como el USB-C para modelos de IA.

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.

¿Alguna vez te has planteado conectar WhatsApp Business a la API oficial de Meta pero te ha frenado el temor a perder la cercanía de tu aplicación móvil o el control de tu número de siempre? Es una duda estratégica muy común cuando buscamos elevar el nivel de nuestra comunicación.

En este artículo, exploraremos el MÉTODO COEXISTENCIA: una arquitectura que te permite mantener la App de WhatsApp Business activa en tu dispositivo mientras integras la potencia de la API oficial. Así, podrás desplegar un chatbot de IA que gestione tu negocio 24/7 de forma impecable, oficial y con una fluidez sorprendente.

Lo que analizaremos hoy:

• → La API oficial de WhatsApp (WABA): Cómo funciona el estándar de comunicación de Meta.
• → App vs. API: Diferencias clave para una toma de decisiones inteligente.
• → El Método Coexistencia: El arte de usar ambas herramientas con un mismo número.
• → Configuración en Meta Business Manager: Un paso a paso pulido y sin fricciones.
• → Integración de IA: Cómo dotar de criterio a tu cuenta para automatizar con calidad.
• → Seguridad: Los 3 errores críticos que debemos evitar para proteger nuestra cuenta.

1. BuilderBot.cloud: Tu centro de operaciones

Antes de entrar en el ecosistema de Meta, necesitamos preparar el entorno donde residirá la inteligencia de tu bot. En BuilderBot.cloud puedes experimentar esta tecnología con una prueba de 7 días, diseñada para que explores todas las funcionalidades sin compromisos iniciales.

Al crear un "Nuevo Proyecto", definiremos un Flow o flujo de conversación. Mi recomendación es establecer un Evento General; de este modo, cualquier interacción recibirá una respuesta coherente y sofisticada, independientemente de la complejidad de la consulta.

2. El diseño del Agente de IA

Aquí es donde nos alejamos de los menús rígidos para crear una experiencia conversacional fluida:

• Selección del modelo: Podemos optar por GPT-4 Nano o Claude para obtener respuestas rápidas y con un tono natural.
• Contexto Dinámico: Si posees un sitio web, basta con vincular la URL. La IA procesará la información de tu página (servicios, catálogos, horarios) para responder con una precisión absoluta.
• Refinamiento: Utiliza el simulador interno para pulir el prompt hasta que la IA proyecte exactamente la imagen profesional que tu marca requiere.

3. Implementación en Meta: El paso a paso técnico

Para activar el Método Coexistencia, nos dirigiremos a la sección de Publicar y seleccionaremos WhatsApp Business API:

1. Sincronización con Meta: Inicia el proceso vinculando tu cuenta de Facebook. Es un paso directo y transparente.
2. Gestión del Porfolio: Selecciona tu activo de negocio. No es estrictamente necesario que esté verificado para comenzar a operar.
3. Registro del Número: Introduce los datos de identidad de tu marca y el número de WhatsApp Business que deseas potenciar.
4. Vinculación QR: Este es el punto clave. Escanea el código QR desde tu App de WhatsApp Business, tal como lo harías para una sesión de escritorio. Esta "coexistencia" es lo que permite que tu app móvil siga activa.
5. Activación: Tras unos 60 segundos de procesamiento, Meta confirmará la integración.

Un apunte sobre la verificación: Si el panel indica "No verificado", no hay de qué preocuparse. Simplemente significa que no posees la insignia azul, pero tu infraestructura oficial está totalmente operativa.

4. Puesta en marcha (Rocket Mode)

Al activar el icono del cohete (Verificar e Iniciar), tu sistema entrará en línea. Un detalle de gran valor es que, mientras la IA procesa la respuesta, el cliente verá el indicador de "Escribiendo...", lo que aporta una sensación de atención personalizada y profesionalismo.

5. Protocolos de seguridad: Evitando bloqueos

Como responsables de nuestra infraestructura digital, debemos observar ciertas reglas de oro de Meta:

1. Calidad sobre cantidad: Evita el envío de mensajes masivos no solicitados. La API premia la relevancia.
2. Uso de Plantillas: Para retomar el contacto después de 24 horas de inactividad, el uso de plantillas oficiales es obligatorio.
3. Actualización de Contexto: Asegúrate de que la información que nutre a tu IA sea veraz y esté al día para garantizar una experiencia de usuario impecable.

Conclusión

El Método Coexistencia representa el equilibrio perfecto entre la automatización de alto nivel y el control personal. Es la herramienta ideal para quienes buscamos eficiencia sin sacrificar la calidad en el trato. Te invito a descubrir cómo esta integración puede transformar la dinámica de tu negocio.

Recursos mencionados:→ https://builderbot.cloud/

¿Deseas implementar un caso de uso específico o tienes dudas sobre la configuración? Estaré encantado de acompañarte en el proceso a través de nuestra comunidad. Es momento de que la tecnología trabaje a tu servicio.

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.