Chemaclass - developer-tools

Recorta la Factura de Tokens

2026-06-26T00:00:00+00:00

Toda sesión agéntica quema tokens en dos direcciones a la vez. El agent te responde, y la terminal escupe su output. Las dos cosas pasan por el mismo context window, y las dos tienen fugas.

Estira la sesión lo suficiente y chocas con el muro. Las respuestas empeoran y la factura sube.

Mismo modelo. Mismos prompts. Factura más ligera.

Abre cualquier transcripción de sesión y los bloques más grandes no son tus prompts:

Respuestas del agent: cháchara, vacilaciones, repeticiones, “Sure! Happy to help…”.
Output de herramientas: logs de npm install, muros de texto de git status, volcados de grep con rutas completas.

Las dos herramientas de abajo atacan una de esas cosas cada una. Caveman se ocupa de lo que el agent responde. RTK se ocupa de lo que la shell manda de vuelta.

Caveman recorta la salida #

Caveman es un Agent Skill. Ejecuta /caveman full una vez y el agent deja de rellenar sus respuestas: sin artículos, sin relleno, sin cháchara. Los fragmentos están bien, y los términos técnicos se mantienen exactos.

Instalación:

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

Lo que muere:

Artículos: a, an, the.
Rellenos: just, really, basically, actually, simply.
Cháchara: sure, of course, happy to.
Vacilaciones: might, perhaps, it depends.

Lo que sobrevive:

Bloques de código, errores exactos, rutas de archivo, comandos.
Avisos de seguridad y operaciones destructivas (el skill se aclara solo).

Modo normal:

Sure! I’d be happy to help you with that. The issue you’re experiencing is likely caused by an off-by-one error in your token expiry check. The middleware compares the current time using < when it should really be using <=. Here’s the fix:

Modo caveman:

Bug in auth middleware. Token expiry check use < not <=. Fix:

Mismo fix, y el bloque de código que viene después es idéntico. Lo único que encoge es la prosa de alrededor, hasta más o menos un cuarto.

Hay tres niveles: lite, full y ultra. Empieza en full, porque ultra se lee como un telegrama. Si una respuesta te queda demasiado seca, escribe normal mode y se relaja.

El agent no pierde inteligencia cuando le quitas la cháchara.

RTK recorta la entrada #

RTK (Rust Token Killer) envuelve los comandos que ejecuta tu agent. Un hook reescribe git status como rtk git status por detrás, así que no hay nada extra que teclear ni overhead que notar.

Instalación:

brew install rtk
rtk init -g # instala el hook que reescribe los comandos

Si más tarde rtk gain da error, se ha colado otra herramienta con el mismo nombre; instala desde el repo.

La versión envuelta quita el ruido antes de que llegue al agent: códigos de color, separadores repetidos, banners de npm install, timestamps verbosos.

Aquí tienes el mismo git status, en crudo y luego envuelto:

$ rtk proxy git status
On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
 (use "git add <file>..." to include in what will be committed)
 content/blog/new-draft.md

nothing added to commit but untracked files present (use "git add" to track)

$ rtk git status
* main...origin/main
? Untracked: 1 file
 content/blog/new-draft.md

La misma información en la mitad de líneas. En un repo con movimiento la diferencia solo crece, porque decenas de untracked files, pistas de rama y líneas de instrucciones colapsan en un solo bloque pequeño.

rtk gain # ver cuántos tokens te ha ahorrado
rtk gain --history # desglose por comando
rtk discover # escanea tu historial de agente buscando ganancias

RTK reporta 60-90% menos tokens en los comandos de desarrollo habituales. Ejecuta rtk gain tras un uso real para ver tu propio número.

Nunca toca el payload, solo el ruido a su alrededor, así que los errores y los stack traces salen exactamente como son. Si algún filtro alguna vez se come algo que de verdad necesitas, sáltatelo en esa llamada con rtk proxy <cmd>.

El output que tú no lees sigue siendo output que el modelo tiene que leer.

Por qué la combinación suma #

Por separado, cada herramienta ayuda un poco. Júntalas y el efecto se multiplica, porque atacan mitades distintas del mismo bucle. Un turno va así: tú escribes el prompt, el agent piensa, ejecuta un comando, la terminal responde, el agent lo lee y luego te contesta. RTK encoge la mitad de la terminal y Caveman encoge la respuesta, así que cada turno sale más barato y caben más en una misma ventana.

Aquí está la prueba real, en un plan de 100 $/mes. Antes de añadirlas llegaba al límite semanal continuamente, a veces con un solo proyecto. Ahora corro varios proyectos en paralelo y el límite casi no aparece. El plan no se hizo más grande; las sesiones se hicieron más pequeñas.

Instálalas una vez y olvídate #

Las dos instalaciones son globales, y las haces una sola vez. A partir de ahí sigues escribiendo git status, grep y npm install igual que siempre. El hook los reescribe por ti y Caveman se activa solo, así que no hay hábitos nuevos que aprender.

¿No sabes por dónde empezar? Elige la fuga que más te duela ahora mismo. Si el problema son las respuestas largas en cada arreglo, empieza por Caveman. Si son las inundaciones de output de grep y npm install, empieza por RTK. Añade la otra cuando te apetezca, que no se estorban entre sí.

No mejoraste el modelo. Dejaste de malgastar su atención.

Skills por Encima de Agents

2026-05-19T00:00:00+00:00

La gente compara agentes de código. Claude Code, Codex, Gemini CLI. Cuál es más listo, más rápido, más barato. Los benchmarks salen nuevos cada mes.

Pregunta equivocada.

Tras un año metiendo agentes en proyectos reales, lo que más cambió las cosas no fue el agente. Fueron los skills que le escribí.

Los agentes son un commodity #

Todo agente de código tiene la misma forma. Un modelo de lenguaje, un runtime, acceso al filesystem. Leer, razonar, escribir. Generalista por diseño.

Dos equipos usan el mismo agente. Uno entrega código limpio y testado. El otro entrega basura que parece buena. Mismo modelo. Distinta enseñanza.

El modelo es el motor. Los skills son el mapa. Sin mapa, con un motor potente te pierdes antes.

Inteligencia no es experiencia #

¿Quién lleva tus impuestos? ¿Un genio con 300 de IQ que nunca leyó una ley fiscal, o un asesor con 20 años presentando declaraciones?

El asesor sabe qué deducciones aplican, qué declaraciones necesita tu negocio, qué errores te marcan. No es inteligencia. Es experiencia.

Los agentes de IA tienen el mismo hueco. Un modelo razona sobre código y escribe soluciones. No conoce tus capas hexagonales. No sabe que las entidades de dominio nunca deben importar código de framework. No sabe que cada feature empieza con un test que falla.

Los skills cierran ese hueco.

Los skills cargan contexto bajo demanda #

Un skill es un fichero markdown en .claude/skills/. Un procedimiento, un patrón, un trozo de conocimiento del dominio. Markdown con frontmatter.

La clave está en cómo se cargan. El agente lee solo nombres y descripciones al arrancar. Carga el skill entero cuando la tarea encaja. Sigue los enlaces a las referencias solo cuando necesita profundizar.

Esa carga bajo demanda es lo que hace que los skills escalen. Veinte skills casi no cuestan hasta que uno encaja con la tarea. Los agentes especializados, en cambio, cargan sus instrucciones enteras cada vez que arrancan. Más agentes, más coste fijo.

.claude/skills/
 code-review/
 SKILL.md # instrucciones principales
 reference/
 solid-checklist.md # ejemplos SOLID detallados
 test-patterns.md # guías de calidad de tests

El SKILL.md:

---
description: "Revisar cambios de código por violaciones de SOLID, calidad de tests y alineación de arquitectura"
allowed-tools: Read, Grep, Glob
argument-hint: "[fichero o PR]"
---

# Code Review

Revisa cambios de código contra las convenciones del proyecto.

## Pasos

1. Leer el diff o los ficheros indicados
2. Revisar arquitectura: la capa de dominio no importa framework, la infraestructura se mantiene delgada
3. Revisar principios SOLID (ver reference/solid-checklist.md para patrones)
4. Revisar calidad de tests: los tests verifican comportamiento, no detalles de implementación
5. Señalar problemas con el principio concreto violado y una propuesta de fix

## Output

Para cada issue encontrado:
- Fichero y línea
- Qué está mal (qué principio o convención)
- Cómo sería el fix

El agente ve la descripción en la lista de skills. Pides un review, carga SKILL.md. Necesita un patrón SOLID, lee la referencia. Dos niveles, bajo demanda.

Skills vs agentes especializados #

Ya cubrí los agentes especializados: workers aislados con su propio prompt y conjunto de herramientas. Buenos para trabajo en paralelo y fronteras de contexto limpias.

Los agentes especializados son toscos. Un agente, un rol, un prompt fijo. Si quieres tres tipos de calidad de review, o escribes tres agentes o metes todo en uno.

Los skills son finos. Un agente, muchos skills. El skill correcto se carga para la tarea. El contexto se mantiene pequeño. La calidad se mantiene alta.

Regla práctica:

Usa un skill cuando necesitas un procedimiento o patrón. De phel-lang: /gh-issue (de issue a PR), /commit (commit convencional), /refactor-check (review SOLID).
Usa un agente cuando necesitas aislamiento. De phel-lang: tdd-coach (pairing de TDD), clean-code-reviewer (review de PR), domain-architect (exploración de arquitectura).

La mayoría de necesidades son skills, no agentes.

Los agentes te dan velocidad. Los skills te dan calidad. Si tienes que elegir uno primero, elige skills.

Los skills son tu ventaja #

Los modelos mejoran cada mes. El mejor de este año es la base del siguiente. Las familias grandes convergen. Aparece una herramienta mejor, cambias.

Tus skills no cambian con la herramienta. Codifican tu dominio, tus convenciones, tu arquitectura. Viven en tu repo. Viajan con tu código. Apuntas un modelo nuevo a la librería y eres productivo desde el día uno.

El agente es reemplazable. Tus skills no.

Empieza con el primer prompt repetido #

No necesitas 20 skills el día uno.

Cero. Luego uno.

La señal es la repetición. La segunda vez que tecleas el mismo contexto, ahí tienes un skill esperando. Sácalo a un fichero markdown. La próxima sesión, el agente ya lo sabe.

Ejemplo concreto. En phel-lang, cada sesión pegaba el mismo brief: lee la issue #N, crea la rama según las etiquetas, TDD, abre el PR. A la tercera lo saqué a un skill /gh-issue. Ahora tecleo /gh-issue 142 y el agente coge la issue, crea fix/... o feat/... según las etiquetas, escribe primero el test que falla, implementa, abre el PR. Un fichero markdown. La sesión ya no empieza desde cero.

No lo escribas desde cero. Pídele al agente: “Lee este proyecto y escribe un skill mínimo de code review basado en lo que veas.” Escanea, recoge convenciones, redacta v1. Tú lo ajustas. Añades lo que le faltó. Cortas lo que no aplica. Afinas la descripción.

El segundo skill suele venir de un error. El agente rompe una convención. Escribe un skill que enseñe el camino correcto. No volverá a pasar.

Los skills se acumulan. Cada uno sube el listón. Un fichero markdown, quizá 50 líneas. Beneficio para siempre.

Quien no escribe skills se pasa la vida re-explicando lo que “realmente quiere”. Cada sesión desde cero. No es problema de herramienta. Es problema de gestión del conocimiento.

El agente sale el año que viene. El skill se queda para siempre.

Escribe el skill una vez. Cada sesión a partir de ahí empieza donde acabó la anterior.

Los Niveles de Adopción de la IA

2026-05-01T00:00:00+00:00

La mayoría de empresas ya usa IA, pero pocas saben en qué punto están de la escalera de adopción. En un extremo, copias código a ChatGPT. En el otro, los agentes abren PRs mientras duermes. Más allá, la IA llega a gente que nunca tocó una terminal. Este post mapea el camino.

De dónde venimos #

Usar IA para programar era tener una segunda pestaña. Escribes una función, te atascas, pegas el error en el chat, pegas la respuesta de vuelta y rezas para que funcione. Lento, torpe, desconectado de tu código.

GitHub Copilot, sobre el Codex inicial de OpenAI, metió sugerencias dentro del editor, y a menudo se equivocaba con mucha seguridad. Estaba entrenado con código público, y el código público medio no es gran cosa. Tampoco sabía nada de tu dominio, tus convenciones ni tu arquitectura. Era autocompletado que a veces acertaba.

La primera generación de herramientas de IA para programar te daba un loro entrenado con todo internet. Fluido, seguro, y diciendo cosas que no tenían sentido en tu código.

Esto era vibe-coding en su primera forma: tú ponías el vibe pegando contexto y la IA rellenaba código que parecía correcto. Compilaba lo suficiente para parecer útil, y se rompía lo suficiente para parecer peligroso.

La generación de los IDEs #

El siguiente paso era obvio: si la IA necesita contexto, dale el editor entero.

Cursor, Windsurf y otros IDEs parecidos metieron el modelo dentro de tu flujo de programación. El asistente podía leer archivos, seguir imports y ver más de una función a la vez. El vibe-coding pasó a ser una conversación con tu proyecto, y la productividad subió. Por un momento pareció el final del juego.

No lo era. Editar archivos es solo una parte del trabajo. El resto es correr tests, leer logs, abrir ramas, revisar diffs y entender qué hace ya el código. Los asistentes que solo vivían en el editor te ayudaban a escribir más rápido, pero no sabían llevar una tarea de “arregla este bug” a “PR listo para revisar.”

El salto agéntico #

OpenAI lanzó Codex como agente en la nube: le das una tarea, trabaja en una rama y tú vuelves a un PR. Anthropic sacó Claude Code, un agente de CLI en tu terminal, sobre tu repo, con tus herramientas.

Este fue el gran salto, y no porque los modelos fueran más listos. Lo que cambió fue la unidad de trabajo. Dejaste de promptear línea a línea y empezaste a delegar tareas: lee el ticket, escribe el cambio, corre los tests, explica lo que hiciste. Un agente no necesita que lo lleves de la mano. Necesita un objetivo y el contexto adecuado.

El salto de asistente a agente no es una mejora de velocidad. Es un cambio en la descripción del puesto. Pasas de escribir código a dirigir trabajo.

Claude Code casi no necesita setup. Sin lock-in de editor. Apúntalo a tu repo, suelta una carpeta .claude con reglas y convenciones, y se adapta. Lo conté en Dentro de la Carpeta .claude.

El modelo que eliges importa más que antes. Los modelos frontera de hoy están muy por delante de los de hace un año. La distancia entre “puede esbozar una función” y “puede refactorizar un módulo con criterio” se cerró más rápido de lo esperado, y sigue cerrándose mientras Claude, Codex y Gemini se empujan mutuamente cada mes. Los precios también se están acercando, lo cual es una forma educada de decir que todos copian al primero que acierta con la versión sostenible.

Agentes con casa propia #

El siguiente salto no fueron modelos más listos, fueron agentes con su propia máquina.

OpenClaw es el ejemplo más claro. Es un gateway open source que corres en tu propio hardware (Mac Mini, portátil viejo, VPS), un agente siempre encendido conectado a tus apps de mensajería, archivos y calendario. Tú pones el cerebro: Opus, GPT o un modelo local vía Ollama. Cuando un proveedor aprieta límites o sube precios, cambias. El setup es tuyo.

Un agente de programación vive dentro de un repo durante una tarea. Un agente estilo OpenClaw vive en tu vida, a lo largo de días y herramientas. Sauron es el mío. Revisa mis PRs, abre issues, escribe código, saca contribuciones a open source y me lleva la contraria cuando estoy a punto de obsesionarme con algo. Cualquier cosa que yo pueda hacer en un ordenador, él también la hace, solo que más rápido. Deja de ser una herramienta que abres y pasa a ser un sitio donde trabajas.

Un agente de programación es un compañero al que invitas a una tarea. Un agente gateway es un compañero que vive en una máquina y aparece cada día.

Los proveedores cambian planes y límites más rápido de lo que nadie puede seguir, así que la gente monta setups que no dependen de un solo proveedor. El logo del modelo importa menos cada trimestre, y la arquitectura alrededor importa más.

IA más allá de los desarrolladores #

La IA para programar fue la historia más ruidosa porque los desarrolladores hablamos alto. La historia más grande es que las herramientas agénticas están llegando a gente que nunca escribió una línea de código.

El modo agente de ChatGPT y Cowork de Claude son los ejemplos obvios: una IA que lee tus documentos, rellena tus hojas de cálculo, redacta tus slides y corre código por ti en segundo plano. Claude Design salió el 17 de abril y tumbó la acción de Figma más de un 7% el día del lanzamiento. El pitch es sencillo: describe lo que quieres, consigue un prototipo que funciona y pásaselo a Claude Code para llevarlo a producción. Un flujo que antes necesitaba un diseñador, un PM, un ingeniero de frontend y tres rondas de revisión queda comprimido en una conversación.

Lovable, v0, Canva y la propia Figma están bajo presión para repensar su posicionamiento. Si Claude Design “mata” a alguno es la pregunta equivocada. La correcta es qué pasa cuando hacer un prototipo usable baja de “contrata un diseñador” a “descríbelo en voz alta.”

Las empresas que lo sienten primero no son las herramientas de diseño. Son los negocios pequeños que no podían pagar diseño, los founders montando un pitch deck a las tantas de la noche, los PMs probando una idea antes de convocar una reunión. Habrá una minoría de casos donde alguien sí hubiera pagado a un diseñador y ahora no lo hace, y ese coste es real. Pero en la mayoría, la IA no reemplazó a nadie: rellenó un hueco donde nunca iba a haber uno.

Los niveles de adopción de la IA #

Cada empresa con la que hablo está en algún punto de esta escalera. Los niveles no van de cuánto pagas en licencias, sino de cuán metida está la IA en cómo se hace el trabajo, y no solo en ingeniería.

Nivel 0: Negación #

Postura a nivel empresa. Nada de IA, oficialmente. Algunas personas usan ChatGPT en su portátil personal y no lo mencionan. A la dirección le preocupan las fugas de propiedad intelectual, o no lo ha puesto como prioridad. La conversación se queda en “deberíamos mirarlo algún día.”

El riesgo aquí no es la tecnología, es el tiempo. Cada mes en el Nivel 0 es un mes en el que tu competencia aumenta su ventaja.

Nivel 1: Productividad personal #

Adopción individual. La IA se tolera, quizá hasta se anima. Cada uno la usa a su manera: ChatGPT en una pestaña, Copilot en el IDE, Claude para lo más peliagudo, una herramienta de diseño para los mockups. La producción sube, pero el know-how se queda dentro de cada cabeza. Dos ingenieros, dos PMs o dos diseñadores del mismo equipo sacan resultados muy distintos porque promptean distinto.

La mayoría de empresas están aquí a principios de 2026. Es una mejora real frente al Nivel 0, y es donde nace el mito de “la IA te da velocidad”. Como ya defendí antes, velocidad sin dirección compartida es caos más rápido.

Nivel 2: Prácticas compartidas #

El equipo acuerda cómo usar la IA: convenciones compartidas, prompts que la gente reutiliza, reglas en el repo, un criterio común sobre cuándo fiarse del output y cuándo discutirlo. Las code reviews pillan los errores de IA igual que pillan los humanos, y las design reviews también. Se exigen tests tanto si escribió el código una persona como si lo escribió un modelo.

Este es el primer nivel en el que la IA pasa a ser una capacidad de equipo en vez de un hábito personal. Techo más alto, suelo más alto. La gente nueva se pone al día más rápido porque los prompts y las reglas capturan cómo trabaja el equipo.

Nivel 3: Herramientas con contexto #

El equipo invierte en contexto: archivos de reglas, convenciones, docs de arquitectura que los agentes pueden leer y servidores MCP que conectan a los agentes con las bases de datos, APIs y herramientas internas que necesitan. La IA deja de ser un asistente genérico y se parece más a un compañero que se ha leído los docs de onboarding.

A este nivel, la calidad depende menos del modelo y más del contexto que lo rodea. Un modelo más flojo con buen contexto le gana a un modelo frontera sin él. Una buena documentación y una arquitectura limpia rinden el doble: ayudan tanto a humanos como a agentes.

Nivel 4: Equipos de agentes #

En vez de un asistente, tienes un escuadrón: un coach de TDD, un revisor de clean code, un arquitecto de dominio, alguien que mantiene la documentación. Fuera de ingeniería, la misma idea aplica con agentes de research, diseño y ops. Cubrí el lado de desarrollo en Construye tu Propio Equipo de Agentes, y el leverage es real.

Los humanos dejan de competir con la IA en velocidad y empiezan a dirigirla. Revisas, decides y marcas el listón. Los agentes se encargan de teclear, y cada vez más de pensar. El pair programming con una persona sigue ganando en los trade-offs complejos, pero siempre tienes un agente disponible para el resto.

A nivel empresa, el organigrama, los roles y los procesos siguen siendo los de antes. Lo que cambia es que cada persona produce mucho más, y eso se nota en los resultados del equipo. El Nivel 4 multiplica el output dentro de la estructura existente. El Nivel 5 cambia la estructura.

Nivel 5: Flujos nativos de IA #

El cambio final es sobre cómo funciona la empresa. Los procesos se diseñan alrededor de los agentes en vez de encajarlos a la fuerza. Los tickets se redactan para que un agente pueda actuar sobre ellos, y las revisiones asumen que parte del trabajo lo escribió una máquina. Las decisiones de arquitectura tienen en cuenta lo que los agentes hacen bien y lo que no. Incluso cambia la contratación: un IC senior en el Nivel 5 se parece más a un tech lead orquestando un equipo mixto de personas y agentes que a un contribuidor individual clásico.

Pocas empresas están del todo aquí en 2026, pero la dirección es lo bastante evidente como para que ignorarla sea, en sí misma, una decisión.

No subes de nivel comprando mejores herramientas. Subes cambiando cómo se organiza y se revisa el trabajo.

La IA no te está robando el trabajo #

Sigo oyendo a gente contar esto como una historia de despidos. Ese encuadre es vago.

La revolución industrial no acabó con el trabajo. Acabó con tipos concretos de trabajo y creó otros. Los que más perdieron se negaron a reciclarse. Los que más ganaron aprendieron a manejar las máquinas nuevas en lugar de competir con ellas.

El patrón es el mismo. La IA no te quita el trabajo, está cambiando en qué consiste tu trabajo. Un desarrollador que aprende a dirigir agentes entrega más que uno que se niega. Una diseñadora que hace diez versiones antes de comer con Claude Design diseña más que una que sigue abriendo Figma desde cero. Un PM que envía prototipos prioriza mejor que uno que escribe specs que nadie lee.

La IA no reemplaza al trabajador con habilidades. Reemplaza al trabajador que cree que la habilidad es un activo fijo en vez de un objetivo móvil.

Con la formación, el modelo y el setup adecuados para tu contexto, la IA te da 10x de velocidad sin perder calidad. Lo he visto, y no es marketing. Pero el 10x solo aparece cuando ya sabes qué es “bueno”. Sin esa base, la IA produce encantada 10x más de trabajo mediocre.

Esa es la versión honesta de la promesa: la IA puede producir basura diez veces más rápido, y trabajo excelente diez veces más rápido. Cuál te toca depende de ti.

A dónde cambia tu atención #

Dejas de pensar primero en los detalles y empiezas a pensar en la dirección: qué estamos construyendo, para quién, con qué forma y con qué trade-offs. Los agentes hacen luego la mayor parte de la implementación mientras tú proteges la calidad y la coherencia.

Esto suena a buenas noticias para quien prefiera la arquitectura a teclear, y lo es. Pero hay una trampa: solo puedes trabajar en el nivel alto si conoces el nivel bajo lo bastante bien como para pillar las desviaciones. Cuando el agente produce algo sutilmente mal (un test que pasa por la razón equivocada, un refactor que cambia el comportamiento bajo carga, un diseño que se rompe en móvil), necesitas verlo al instante. Si no puedes, no estás dirigiendo. Estás dando el visto bueno a lo que aparezca.

La IA te deja dedicar más tiempo a la dirección, pero solo si ya te ganaste el derecho a ignorar los detalles. Ese derecho se gana dominándolos antes.

Por qué importa la escalera #

Veo equipos que se saltan niveles y fracasan. Un equipo salta del Nivel 1 al Nivel 4 porque la dirección leyó un post sobre escuadrones de agentes, y los agentes producen montañas de código malo porque nadie acordó qué significa calidad. Los agentes no son el problema. Lo es la base que falta.

La escalera es un orden que importa. Prácticas compartidas antes que context engineering, context engineering antes que equipos de agentes, y equipos de agentes antes que flujos nativos de IA. Cada nivel se construye sobre el anterior, igual que el clean code se construye sobre el naming y el naming sobre saber qué estás modelando.

Las empresas que van a ganar los próximos años no son las que tienen el mayor presupuesto en IA. Son las que suben esta escalera con intención, un nivel cada vez, sin saltarse las partes que parecen aburridas.

Por dónde empezar #

En Nivel 0 o 1, el siguiente paso no es comprar más licencias. Es decidir, como equipo, cómo usar estas herramientas. Escríbelo, commitéalo al repo y revísalo cada pocos meses a medida que las herramientas cambian.

En Nivel 2 o 3, mira dónde falta contexto. ¿Qué no sabe tu IA de tu codebase, tu producto o tu marca que una persona recién contratada aprendería la primera semana? Escríbelo. Una tarde de reglas y docs te rinde durante meses.

Más arriba, la pregunta se invierte. Dejas de preguntarte “¿cómo uso mejor la IA?” y empiezas a preguntarte “¿cómo tiene que cambiar mi equipo para que la IA amplifique lo que ya hacemos bien?” Esa es una pregunta de liderazgo, no de tooling.

La IA va rápido, pero el trabajo de adoptarla sigue siendo lento y humano. Las herramientas son la parte fácil. La parte difícil es decidir qué es “bueno”, escribirlo y sostener la línea.

La IA puede ejecutar, pero no sabe a dónde vas. Puede producir, pero no sabe qué vale la pena producir. Esa parte sigue siendo nuestra. La velocidad es un regalo, la dirección es una responsabilidad. Del ingeniero en solitario del Nivel 1 a la organización nativa de IA del Nivel 5, la misma verdad se mantiene: el humano supervisa, entiende y da sentido. La máquina hace el resto.

Cuando se relaje el hype (y se relajará), la pregunta no va a ser “¿usaste IA?”, todo el mundo lo habrá hecho. La pregunta va a ser “¿a qué nivel, y con qué dirección?”

Dentro de la Carpeta .claude

2026-04-17T00:00:00+00:00

Cada proyecto en el que trabajo tiene una carpeta .claude/ en la raíz. Commiteada en git, como el resto del código.

Esa carpeta convierte Claude Code de un asistente genérico en un compañero que conoce tu proyecto. Quien clone el repo hereda el mismo setup.

El agentic coding es tan bueno como el contexto que le das al agente. La carpeta .claude/ es donde vive ese contexto.

La carpeta .claude, de un vistazo #

.claude/
├── CLAUDE.md # onboarding del proyecto
├── settings.json # permisos, hooks, env
├── skills/ # procedimientos reutilizables (slash commands)
├── rules/ # convenciones por glob
├── hooks/ # scripts que reaccionan a eventos
└── agents/ # roles especializados

Seis capas, una carpeta. Contexto, seguridad, procedimientos, barandillas, automatización, especialistas.

Los cimientos #

CLAUDE.md: donde todo empieza #

Claude Code lee CLAUDE.md en cada arranque. El doc de onboarding.

En Phel, el mío cubre el pipeline del compilador (Lexer → Parser → Analyzer → Emitter), la estructura de módulos, convenciones y comandos clave.

Un ~/.claude/CLAUDE.md global aplica a todos tus proyectos. El archivo de proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

Cada byte viaja en cada prompt. Mantenlo corto. Si pasa de una pantalla, mueve el detalle a rules/ o skills/.

Un buen CLAUDE.md es un buen doc de onboarding. Cuanto mejor sea, menos te repites.

settings.json: seguridad antes que potencia #

Antes de darle más poder al agente, bloquea lo que nunca debe hacer.

.claude/settings.json contiene tres cosas: permissions (allow/deny), hooks (comandos por evento) y env (variables). Un settings.local.json gitignoreado mantiene las configuraciones personales aparte.

{
 "permissions": {
 "allow": [
 "Bash(composer:*)",
 "Bash(./bin/phel:*)",
 "Bash(git:*)",
 "Bash(gh:*)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(sudo:*)"
 ]
 }
}

Allow desbloquea el flujo. Deny marca la línea que el agente no puede cruzar, aunque se lo pidas con buena cara.

Los permisos son el suelo. Todo lo demás se construye sobre una base segura.

Procedimientos y barandillas #

Skills: procedimientos que puedes ejecutar #

Siguiente dolor tras onboarding: la repetición. Los skills lo resuelven.

Un skill es un archivo markdown en .claude/skills/, un procedimiento que invocas con una barra:

/gh-issue <número>: de issue a rama, plan TDD, PR.
/commit: fix, análisis, tests, commit convencional.
/refactor-check: SOLID, naming, olores de arquitectura.
/release [version]: changelog, PHAR, tag, release.

Prompt directo: “arregla el issue #42”. El agente improvisa. Distinto cada vez.
Rule: “usa conventional commits”. Da forma al resultado, no al procedimiento.
Skill: “/gh-issue 42”. El procedimiento es la instrucción.

Los skills convierten conocimiento tribal en pasos ejecutables por cualquiera.

Los skills capturan qué hacer. Las rules capturan qué no hacer.

Rules: las barandillas #

CLAUDE.md se lee en cada sesión. Las rules solo cuando aplican. Los archivos en .claude/rules/ apuntan a áreas del código con patrones glob: el agente carga solo lo que corresponde, manteniendo el contexto ligero.

Archivos de rules en Phel:

compiler.md: pipeline estricto de 4 fases, sin atajos.
php.md: PER 3.0, clases final, readonly, patrón Gacela.
phel.md: kebab-case, defn- privadas, :doc/:example obligatorios.
integration-tests.md: secciones --PHEL-- / --PHP-- en fixtures.

Las rules del compilador no se activan al editar código Phel. Las rules de Phel no se activan al editar infraestructura PHP.

Las rules no son sugerencias. Viajan con el código: un cambio de convención y su rule viajan en el mismo commit. Sin drift, sin wikis desactualizadas.

Automatización y delegación #

Hooks: automatización en los bordes #

Las rules dicen al agente qué hacer. Los hooks se aseguran de que ocurra aunque el agente olvide.

Comandos shell disparados por eventos de Claude Code (PreToolUse, PostToolUse, Stop), conectados vía settings.json. En Phel, PreToolUse bloquea ediciones a archivos críticos (build/release.sh, .github/*, composer.lock). PostToolUse auto-formatea PHP vía php-cs-fixer.

{
 "hooks": {
 "PreToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/protect-files.sh" }]
 }],
 "PostToolUse": [{
 "matcher": "Edit|Write",
 "hooks": [{ "type": "command", "command": ".claude/hooks/format-php.sh" }]
 }]
 }
}

Las rules son lo que el agente debe saber. Los hooks son lo que el sistema impone de todas formas.

Agents: roles especializados #

Todo lo anterior da forma a un solo agente. Los agents añaden especialistas a los que el agente principal puede delegar, cada uno con sus propias herramientas, permisos y modelo. La pieza más avanzada. La recomiendo de última.

Algunos de Phel:

Explorer (Sonnet, solo lectura): archivos, mapeo de estructura.
Clean Code Reviewer: SOLID y naming en diffs.
TDD Coach: imposición red-green-refactor.
Domain Architect: límites de módulos, pipeline del compilador.
Debugger: errores del compilador en todas las fases.

Cada agente corre en su propia ventana de contexto: la sesión principal se mantiene limpia mientras el especialista profundiza. La ganancia no es solo coste, es foco. Un agente con solo read y grep no puede reescribir tu código por error.

El modelo correcto para el trabajo correcto. Rápido y barato para explorar. Profundo y cuidadoso para arquitectura.

Empieza pequeño, crece con la fricción #

No construyas todo esto el primer día.

El orden, guiado por fricción real:

Empieza con CLAUDE.md.
Bloquea permisos en settings.json.
La primera vez que te repitas, escribe un skill.
La primera vez que el agente rompa una convención, añade una rule.
La primera vez que algo malo casi se commitee, añade un hook.
La primera vez que un generalista no encaje, define un especialista.

Cada paso soluciona un problema que realmente tuviste. No uno que imaginaste.

El setup crece desde la fricción real, no desde el diseño anticipado.

Commitea la carpeta. Compártela. Cuando alguien se una, su sesión hereda todo.

Trata .claude/ como infraestructura. Versiónala. Revísala. Hazla evolucionar con el código.

MCP: Dándole a tu Agente IA el Contexto Adecuado

2026-01-11T00:00:00+00:00

Los asistentes de código con IA modernos son muy buenos entendiendo contexto. Modelos como Claude Opus con ventanas de contexto amplias (unos 200k tokens) pueden tener porciones sustanciales de tu código en mente, razonar sobre arquitectura y mantener coherencia en conversaciones largas. No el proyecto entero en codebases grandes, pero sí lo suficiente para trabajar bien.

Pero entender no es lo mismo que acceder.

La IA puede razonar sobre el esquema de tu base de datos si lo pegas. Puede sugerir cambios a archivos que compartes. Conoce patrones del código que le muestras. La limitación no es la inteligencia, sino el alcance.

Ahí entra MCP.

Lo que MCP habilita #

La IA moderna puede entender tu código cuando lo compartes. Pero entender y actuar son cosas distintas.

Muchos asistentes integrados en IDEs como VS Code Copilot o Cursor ya acceden a los archivos de tu proyecto mediante su propio indexado. El acceso a archivos no es nuevo. Lo que MCP aporta es estandarización. En lugar de que cada herramienta construya su propia integración, MCP ofrece un protocolo común. Configuras un servidor una vez, y cualquier cliente compatible con MCP puede usarlo. Es portable, configurable, y va más allá de archivos: bases de datos, APIs y herramientas personalizadas.

MCP transforma a la IA de interlocutor a participante activo en tu entorno de desarrollo.

Con MCP le das a la IA acceso directo a herramientas y recursos. Puede leer archivos, ejecutar comandos, consultar bases de datos, obtener documentación. La inteligencia siempre estuvo ahí. MCP le da manos.

Qué es realmente MCP #

MCP es un protocolo, no un producto. Un estándar abierto que define cómo los agentes de IA pueden conectarse a fuentes de datos y herramientas externas. Piensa en ello como un puente entre el modelo de IA y tu entorno de desarrollo.

La arquitectura es simple: los servidores MCP exponen capacidades y los clientes de IA las consumen. Claude Desktop y Claude Code soportan MCP oficialmente, y cada vez más herramientas adoptan el protocolo.

Por ejemplo, en Claude Code puedes añadir servidores a un archivo .mcp.json en la raíz de tu proyecto. Claude Code lee este archivo al abrir el proyecto e inicia los servidores configurados automáticamente:

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": { "GITHUB_TOKEN": "tu-token" }
 },
 "postgres": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-postgres"],
 "env": { "DATABASE_URL": "postgresql://localhost/mydb" }
 }
 }
}

Cada servidor le da a la IA diferentes capacidades:

filesystem: Leer y navegar los archivos de tu proyecto. La IA puede explorar tu código, verificar patrones existentes y entender la estructura de directorios antes de sugerir cambios.
github: Acceder a issues, pull requests y metadatos del repositorio. Pídele a la IA que resuma los issues abiertos, revise comentarios de PRs o entienda en qué trabaja tu equipo.
postgres: Consultar tu base de datos directamente. La IA puede inspeccionar tu esquema, ejecutar consultas de lectura y entender tu modelo de datos sin que copies definiciones de tablas.

Distintas herramientas, mismo protocolo. Configuras una vez, y cualquier cliente compatible con MCP puede usar estos servidores.

Dónde destaca MCP #

Trabajando con tu código #

El beneficio más inmediato es el acceso al sistema de archivos. La IA puede navegar tu proyecto, leer archivos fuente, entender tu estructura de directorios. Cuando sugiere código, puede verificar patrones existentes primero.

La integración con Git va más allá. La IA puede ver tu historial de commits, entender qué cambió recientemente y sugerir modificaciones alineadas con la evolución de tu código.

El acceso al esquema de base de datos significa que la IA entiende tu modelo de datos. No hace falta explicar relaciones entre tablas o tipos de columnas. Ve la estructura y genera consultas que funcionan de verdad.

Documentación y conocimiento #

Conecta tu documentación interna y la IA conocerá las decisiones de tu equipo. Especificaciones de API, documentos de arquitectura, guías de código. Todo disponible como contexto.

Aquí es donde MCP empieza a notarse. La IA ya no genera código genérico. Genera código que encaja en tu proyecto.

La mejor asistencia de IA viene de entender no solo qué construyes, sino cómo lo construye tu equipo.

Integraciones externas #

La integración con GitHub permite que la IA lea issues, entienda discusiones de PRs y vea el contexto más amplio de en qué trabaja tu equipo. Slack u otras herramientas de comunicación pueden aportar aún más contexto sobre decisiones en curso.

Las integraciones personalizadas te permiten conectar herramientas internas específicas de tu flujo de trabajo. El protocolo es extensible por diseño.

Usando MCP efectivamente #

MCP amplifica lo que conectes. Si tu documentación está desactualizada, la IA usará información desactualizada. Si tu código es desordenado, la IA aprenderá patrones desordenados.

Es el efecto espejo que mencioné en La IA te da velocidad, no calidad. La IA refleja el contexto que le das. Buen contexto da resultados útiles. Mal contexto produce basura que suena convincente.

Darle a la IA acceso a tu código no reemplaza tu responsabilidad de mantenerlo. Hace que la buena higiene sea más valiosa.

Algunas prácticas que ayudan:

Conecta solo lo que la IA necesita. Más contexto no siempre es mejor. Contexto enfocado sí.
Mantén tu documentación actualizada. Si la IA lee tus docs, esos docs importan más que antes.
Revisa tu configuración MCP de vez en cuando. A medida que tu proyecto evoluciona, también debería hacerlo tu configuración de contexto.
Empieza pequeño. Uno o dos servidores. Ve qué funciona. Expande desde ahí.

La seguridad también importa. Sé intencional sobre lo que expones. Los servidores MCP pueden acceder a información sensible. Trátalos como cualquier otra decisión de control de acceso.

Lo que viene #

MCP es la base. Pero el ecosistema construye encima.

Flujos de trabajo agénticos. Herramientas como Claude Code y Cursor funcionan en “modo agente” donde la IA planifica y ejecuta tareas de múltiples pasos de forma autónoma. Lee archivos, hace cambios, ejecuta tests, corrige errores. Los servidores MCP son las manos. El bucle del agente es el cerebro que decide qué hacer.

Skills y comandos personalizados. Claude Code introdujo skills: comandos slash personalizados que encadenan herramientas MCP en flujos reutilizables. /deploy, /test, /review. Los defines una vez y se convierten en parte de tu toolkit de desarrollo.

Protocolo A2A. El protocolo Agent-to-Agent de Google. Mientras MCP conecta IA con herramientas, A2A conecta agentes de IA entre sí. Múltiples agentes especializados colaborando en tareas complejas. Un agente escribe código, otro lo revisa, un tercero ejecuta tests.

El patrón es claro: la IA está pasando de asistente a colaborador. De responder preguntas a ejecutar flujos de trabajo. MCP le dio a la IA acceso a tu entorno. Lo que viene es IA que sabe usar ese acceso de forma autónoma.

La pregunta está cambiando de “¿a qué puede acceder la IA?” a “¿qué debería decidir la IA por su cuenta?”

El juicio humano no desaparece. Se mueve hacia arriba. En lugar de revisar cada línea que escribe la IA, diseñamos el contexto y los límites que moldean lo que produce.

Ese sigue siendo nuestro trabajo. Y vale la pena hacerlo bien.