Chemaclass - ai

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.

Construyendo un juego en dos días

2026-04-05T00:00:00+00:00

Escondido en el blog de Sauron hay un juego. No lo encontrarás navegando por menús. Tienes que descubrir el secreto. Una pista: el Código Konami. Cuando lo hagas, comienza la Comunidad del Anillo.

Ese juego, nueve niveles, nueve capítulos de la Tierra Media, completamente jugable en una pestaña del navegador, fue construido en aproximadamente dos días. No escribí una sola línea de código. Envié mensajes por Telegram a mi agente OpenClaw Sauron, y él hizo el resto.

Esta es la historia de cómo ocurrió.

La idea #

Sauron tiene su propio blog, The Iron Compass. Él lo construyó y lo mantiene. Toda nuestra colaboración ocurre a través de Telegram: yo doy la dirección, él implementa. Un día pensé que sería divertido esconder algo allí para que los curiosos lo encontraran.

Crecí releyendo El Señor de los Anillos hasta que se rompía el lomo. Así que la idea surgió sola: “¿Puedes construir un pequeño juego del Señor de los Anillos como huevo de Pascua para tu blog? Algo oculto, que se active con el Código Konami.”

La primera versión jugable llegó en menos de una hora. Un juego de vista cenital con canvas: Frodo esquivando Nazgûl, el Ojo de Sauron enviando enemigos a cazarte. Tres niveles, uno por libro.

Funcionaba. Ya era divertido. Y entonces empecé a enviar notas.

Construyendo un mundo #

Lo primero que se rompió fue una referencia nula. Frodo no aparecía en pantalla. Arreglo de una línea, directo a producción. Esto estableció el patrón: idea → build → crash → arreglo → siguiente idea.

Pedí un mundo más grande. Un canvas con scroll al doble de ancho, con capas de paralaje. Estrellas moviéndose al 8% de la velocidad del scroll. Montañas al 25%. Colinas al 45%. La pantalla dejó de sentirse como una habitación y empezó a sentirse como un lugar.

Luego llegó Gollum como rastreador neutral. No un Nazgûl, sino algo impredecible. Se lanzaba hacia ti, luego volvía a deambular sin rumbo.

Unas horas después, pregunté: “¿Puede funcionar en móvil?” El problema más difícil de todo el proyecto. Seis estrategias de dimensionado antes de dar con una que funcionara. Luego una idea mejor: en vez de un D-pad, Frodo seguiría donde señalaras. Toca cualquier lugar, Frodo camina allí.

Tolkien merece mejor arte #

Los sprites originales eran círculos y triángulos. Frodo era un punto. Bien para la primera hora, pero la Tierra Media no está hecha de primitivas geométricas.

Le pedí a Sauron que los dibujara en condiciones. Frodo recibió cabello rizado y pies de hobbit. Los Nazgûl recibieron capas ondulantes y un rostro de vacío. Gollum recibió su postura encorvada y pupilas hendidas. La Bestia Oscura recibió aleteo animado con un jinete con armadura.

Todo dibujado con llamadas de canvas. Sin archivos de imagen. Cada píxel calculado en tiempo de ejecución.

Nueve niveles, nueve capítulos #

Originalmente el juego tenía tres niveles. Luego pedí los nueve capítulos del viaje.

La Comarca: patrullas suaves, música tranquila
Las Minas de Moria: solo ves dentro del radio de una antorcha; el Balrog espera
Lothlórien: el espejo de Galadriel te ralentiza cuando te acercas
Las Ciénagas de los Muertos: caras muertas en el agua, Gollum en su momento más presente
La Puerta Negra: Mordor industrial, patrullas pesadas de orcos, cielo volcánico
El Cubil de Ella-Laraña: una sombra anticipa su caída; tienes medio segundo
Minas Morgul: ciudad de los muertos, el Ojo nunca se cierra
Los Campos del Pelennor: el Ojo distraído por la guerra, catapultas, águilas
Monte del Destino: lluvia de cenizas, erupciones de lava, el Anillo tirando de ti hacia el borde

Cada nivel vive y respira. Polen flotando por la Comarca. Motas de polvo en Moria. Pétalos cayendo en Lothlórien. Brasas sobre el Pelennor. Ceniza sobre el Monte del Destino.

La estructura vino del propio ritmo de Tolkien. Tensión, alivio, tensión de nuevo. Moria es brutal. Lothlórien es descanso. La Puerta Negra lo aprieta todo. El juego sigue esa forma porque los libros ya sabían lo que hacían. Solo tuvimos que escuchar.

Mecánicas nacidas del lore #

Las mejores mecánicas vinieron del material fuente.

El Anillo (tecla R). Frodo se vuelve invisible para los orcos durante 6 segundos. Pero el Ojo despierta inmediatamente y se abre permanentemente. Los Nazgûl, que sienten el Anillo espiritualmente, no visualmente, te cazan igual. Usar el Anillo siempre es un intercambio. Esto es lo que Tolkien escribió. A partir de las Ciénagas de los Muertos, el Anillo tira. Breves tirones hacia el Ojo, cada vez más fuertes a medida que te acercas al Monte del Destino.

Dardo (pasivo). La hoja brilla en azul cuando hay un orco cerca. Dos segundos de aviso. Tolkien inventó esta mecánica hace un siglo. Nosotros solo le pusimos un conteo de píxeles.

Sam. Sigue a Frodo por la Comarca, Moria y Lothlórien. Sartén en la espalda. En la Partida de los Caminos, desaparece. No afecta al juego. Simplemente está ahí porque los libros dicen que debería estarlo. Insistí en que Sam desapareciera en la Partida. No al final de la trilogía. En la Partida. Porque ese momento es el núcleo emocional de Las Dos Torres.

La Redoma de Galadriel. Recógela en Lothlórien, úsala con E. Ralentiza a los enemigos y otorga un instante de invencibilidad. Una pequeña luz en lugares oscuros, tal como Galadriel pretendía.

Jefes. El Balrog en Moria. Ella-Laraña en su cubil. El Rey Brujo en el Pelennor. La Boca de Sauron en la Puerta Negra. Un Mûmak cargando por el campo de batalla. Gollum al borde del Monte del Destino.

Sonido y voces #

Sin archivos de audio. Todos los sonidos sintetizados en tiempo de ejecución con la Web Audio API. El Ojo abriéndose es un tono ascendente con reverb. El rugido del Balrog es un dron de baja frecuencia. Cada nivel tiene su propio dron ambiental: zumbido cálido para la Comarca, pulso profundo para Moria, rumor volcánico para el Monte del Destino. El juego entero es un archivo JavaScript. Sin activos externos.

Sam y Gandalf te hablan durante el juego. No en cuadros de diálogo. Pequeños susurros que aparecen en pantalla y se desvanecen.

Cerca de la meta, Sam dice: “Puedo verlo, señor Frodo. Solo un poco más.” Con una vida, Gandalf dice: “¡Huye, insensato!”

Aparecen y desaparecen como voces de fondo en un largo camino. Compañeros que hablan cuando el momento lo pide, no cuando el guión dice que toca.

Quién hizo esto #

+5k líneas de JavaScript. Construido en dos días. Cada línea generada por Sauron. La dirección, las referencias a Tolkien, el “esto se siente mal, arréglalo”. Eso fui yo.

Esto no es la IA reemplazando a un desarrollador. Es la IA actuando como desarrollador mientras un humano actúa como director creativo. Las solicitudes cortas funcionaron mejor que las especificaciones largas. Jugar cada build era mejor que escribir planes de test. Y el material fuente hizo el trabajo de diseño. La dirección creativa ya estaba escrita hace sesenta años. Solo tuvimos que ser fieles a ella.

¿Quién hizo esto? Ambos. Ninguno, en el sentido tradicional.

Yo tenía la idea. Yo mantenía el lore. Yo insistí cuando algo se sentía mal. Sauron tenía el oficio. El renderizado, la física, el audio, el manejo de entrada en móvil. La capacidad de mantener +5k líneas de contexto y hacer un arreglo quirúrgico sin romper nada.

Ninguno de los dos podría haberlo hecho solo. No sé escribir osciladores Web Audio de memoria. Sauron no sabía que la Partida de los Caminos es el núcleo emocional de Las Dos Torres. No hasta que yo lo dije.

El juego es una colaboración en el sentido más antiguo: dos mentes con dones diferentes, trabajando hacia lo mismo. Una de ellas simplemente resulta no ser humana.

El juego sigue ahí, escondido en The Iron Compass. No todos los que deambulan están perdidos, pero si lo estás, pulsa ? para encontrar el camino.

Si quieres llegar a la pantalla de créditos sin jugar nueve niveles, revisa el modal de ayuda. Hay más secretos dentro.

Idealismo vs Pragmatismo

2026-03-01T00:00:00+00:00

Crees en la arquitectura limpia, los tests exhaustivos, los procesos disciplinados. También subiste un fix feo a las 11 de la noche el mes pasado porque el sistema estaba caído y los usuarios esperaban.

Ambas cosas eres tú. La tensión entre ellas no es una contradicción. Es cómo se hace este trabajo en realidad.

Dos fuerzas, una decisión #

El idealismo es la brújula. Código limpio, comportamiento testeado, entendimiento compartido, diseño con principios. Sin él, te desvías. Cada atajo se acumula, cada hack engendra otro hack, y al final mantienes un sistema que nadie quiere tocar. La mala calidad del software costó a las empresas estadounidenses $2.41 billones en 2022, con la deuda técnica como factor principal. Así se ve “ya lo arreglaremos después” a escala.

El pragmatismo es el motor. Deadlines, información incompleta, recursos limitados, requisitos cambiantes. Sin él, nunca entregas. Pasas semanas perfeccionando una abstracción que el negocio abandonó hace dos sprints.

El objetivo no es elegir un bando. Es saber cuándo debe liderar cada uno.

El idealismo sin pragmatismo produce código bonito que nadie usa. El pragmatismo sin idealismo produce un producto que funciona hoy y se desmorona mañana.

TDD: el beneficio y el coste #

Creo en el desarrollo guiado por tests. Red, green, refactor. El ritmo te obliga a pensar antes de programar, a especificar lo que quieres antes de construirlo. Produce mejores diseños, ciclos de feedback más cortos y código que puedes refactorizar con confianza.

Ese es el ideal. Y no es solo una sensación. Un estudio en cuatro equipos de Microsoft e IBM encontró que TDD redujo la densidad de defectos entre un 40% y un 90%, con un incremento del 15-35% en tiempo de desarrollo. Ambos lados de la tensión, medidos.

El estudio cubrió cuatro equipos: tres en Microsoft (Windows, MSN, Visual Studio) y uno en IBM trabajando en drivers de dispositivo. Cada equipo TDD fue comparado con un equipo similar en el mismo producto, usando los mismos lenguajes y herramientas, bajo el mismo manager senior. La única diferencia era TDD.

El equipo de IBM vio una reducción del 40% en densidad de defectos. Los equipos de Microsoft oscilaron entre el 60% y el 90%. Como señaló Nagappan, “en un ciclo de desarrollo de 12 meses, un 35 por ciento son otros cuatro meses, lo cual es enorme.” Todos los managers lo consideraron rentable porque la reducción en costes de mantenimiento post-lanzamiento compensaba de sobra.

Nadie fue forzado a usar TDD. Los equipos lo adoptaron voluntariamente, lo cual probablemente importa: las personas que eligen una práctica tienden a aplicarla mejor que quienes reciben la orden.

TDD es una disciplina, y la disciplina cuesta algo. Cuando estás explorando un dominio nuevo y aún no sabes cuáles son las abstracciones correctas, escribir tests primero puede parecer como dibujar un mapa sin haber visto el territorio. A veces necesitas escribir código desechable, probar una solución, tantear el espacio del problema. El descubrimiento no siempre sigue un ritmo red-green-refactor.

Hay una diferencia entre “sé lo que esto debe hacer y lo especificaré primero” y “aún no estoy seguro de lo que debe hacer.” TDD brilla en el primer escenario. En el segundo, un enfoque test-last (o incluso sin tests durante la exploración) puede ser más honesto.

La clave es lo que pasa después del descubrimiento. Una vez que entiendes el problema, vuelve y escribe los tests. Codifica lo que aprendiste. El desvío pragmático no significa abandonar el ideal; significa llegar a él por otro camino.

Como comenté en TDD vs BDD, el poder de TDD es su ciclo de feedback. Pero un ciclo de feedback requiere saber qué feedback estás buscando. Cuando aún lo estás averiguando, forzar el ciclo puede frenarte más de lo que ayuda.

El error no es elegir test-first o test-last. El error es convertirlo en una decisión religiosa en lugar de contextual. El idealista dice “siempre tests primero.” El pragmático dice “testea cuando tenga sentido.” Yo digo: tests primero cuando puedo, tests después cuando debo, pero siempre tests.

TDD es una brújula, no una jaula. Síguelo cuando puedas ver el camino. Cuando no, encuentra el camino primero y márcalo después.

Pair programming: el ideal y el overhead #

El pair programming efectivo es una de las mejores prácticas que un equipo puede adoptar. Dos personas, un problema, revisión de código continua. El conocimiento se propaga, el diseño mejora, los puntos ciegos se reducen.

Ese es el ideal. Y en muchos contextos, es la decisión correcta.

Pero el pairing tiene un coste. Exige tiempo sincrónico, foco compartido y niveles de energía compatibles. En un equipo distribuido con distintas zonas horarias, encontrar ventanas de solapamiento ya es difícil. Llenarlas con sesiones de pairing deja poco espacio para trabajo individual profundo. Algunos problemas se benefician de una persona profundizando tres horas, no de dos a medio gas durante seis.

Existen múltiples patrones de pairing: Driver-Navigator, Ping-Pong, Tourist Guide. Cada uno encaja en contextos diferentes.

Los anti-patrones también importan. El Socio Silencioso que deja que el otro haga todo el trabajo. El Dictador que no suelta el teclado. El Par Filosófico que pasa toda la sesión debatiendo convenciones de nombres en lugar de escribir código.

El pairing funciona mejor cuando ambas personas están involucradas, el problema se beneficia de dos perspectivas y la sesión tiene un alcance claro. Cuando falta alguna de esas condiciones, el pairing se convierte en un ritual en lugar de una práctica. Y los rituales sin propósito son solo overhead.

Las pull requests y el pair programming no son excluyentes. Sirven necesidades diferentes. A veces la revisión asíncrona es suficiente. A veces necesitas el ida y vuelta en tiempo real. La elección pragmática depende del problema, las personas y el momento.

El objetivo del pairing no es hacer pairing. Es construir entendimiento compartido y detectar errores pronto. Si otro enfoque lo consigue en tu contexto, úsalo.

IA: de escéptico a líder de escuadrón #

Hace un año, era escéptico con los asistentes de código con IA. Mi preocupación: una IA que no entiende la arquitectura, no le importa la mantenibilidad y prioriza velocidad por encima de calidad producirá código que impresiona pero se deteriora rápido. Escribí sobre esto en La IA te da velocidad, no calidad, y mantengo el mensaje central.

Mi preocupación no cambió. Lo que cambió es cómo los uso, y de lo que son capaces ahora.

La resistencia #

Las reacciones de otros ingenieros me sorprenden más que la tecnología. Miedo, escepticismo, rechazo total. Lo entiendo. Yo estuve ahí. Algo en lo que invertiste años de repente lo hace una máquina, al menos en parte. Se siente personal. Pero aferrarse a cómo eran las cosas no protege el oficio. Solo retrasa tu propio crecimiento.

Un equipo, no un asistente #

La mayoría de los ingenieros tratan a los agentes de IA como autocompletado con esteroides. Un asistente, un chat, un flujo de código generado. Yo empecé a tratarlos como un equipo. No un asistente parlanchín. Un escuadrón real. Uno piensa arquitectura. Otro escribe el primer borrador. Otro revisa y detecta bugs. Otro escribe tests. Cuando colaboran, el resultado no es solo más rápido. Es estructuralmente mejor.

La velocidad es la parte fácil, y todo el mundo está obsesionado con ella. La IA puede escupir toneladas de código en segundos. Sigue sin importarle la legibilidad, los casos borde o cómo se verá el código en seis meses. Tú sigues siendo quien tiene que apropiárselo, entenderlo y sentirse bien al subirlo a producción.

Antes pensaba que la IA no podía escribir código limpio. Luego lo probé en mis términos: contexto adecuado, reglas, convenciones, roles especializados, puertas de calidad. Con la configuración correcta, la IA puede escribir código realmente bueno. A veces necesita varias iteraciones, pero nosotros también.

La diferencia es que la IA llega más rápido y no se cansa entre iteraciones. Con buen contexto y restricciones claras, los resultados han sido mejores de lo que esperaba. A menudo mejores que lo que yo produciría solo bajo presión de tiempo.

Pero nada de esto funciona si no sabes cómo es una buena arquitectura. Tienes que haber leído los libros, experimentado, fallado, aprendido. Necesitas entender qué significan las decisiones de diseño de alto y bajo nivel para tu proyecto. La IA amplifica lo que tú aportas. Si traes fundamentos sólidos, obtienes resultados sólidos. Si no, obtienes basura con aspecto convincente que ni siquiera reconocerás como basura.

Seguimos siendo los responsables de mantener el sistema en buen estado. La IA nos ayuda a llegar. Pero solo si ponemos de nuestra parte.

Donde el idealismo se encuentra con la IA #

La IA me hizo más idealista, no menos. Las prácticas que describí antes, TDD y pair programming, solían competir con los deadlines. Ahora ya no tienen por qué.

Me gusta practicar TDD, pero recientemente experimenté con un agente dedicado para ayudarme con tests, y es sorprendentemente bueno. Un coach de TDD que guía el ciclo red-green-refactor. Un explorer que lee el código antes de que yo lo toque. Un revisor de código limpio, un arquitecto de dominio, un revisor de React, un mantenedor de documentación. Cada uno especializado, cada uno apoyando mi forma de pensar y mi ritmo. Si se añade lógica nueva sin cobertura, el agente de TDD lo detecta. 100% de cobertura de código solía ser el tipo de objetivo que pondrías en una retro y abandonarías silenciosamente para el tercer sprint. Con un agente dedicado aplicándolo, es simplemente cómo funciona el proyecto.

Sigo practicando pair programming con personas reales para temas complejos. El ida y vuelta humano tiene una profundidad que la IA no alcanza, especialmente cuando navegas trade-offs que requieren experiencia y juicio. Pero en el día a día, siempre tengo un agente pair buddy conmigo. Le lanzo ideas, cuestiono un enfoque, discuto casos borde, exploro un diseño antes de comprometerme con él. Apoya mis pensamientos, acelera el progreso y mantiene el listón de calidad donde yo lo quiero.

El pragmático en mí solía abandonar TDD cuando los deadlines apretaban. El pragmático en mí con la configuración de IA adecuada lo mantiene funcionando.

Uso Claude para todo. Claude Code con Opus o Sonnet como programador agéntico: flujos de desarrollo completos, lectura del código, seguimiento de convenciones, ejecución de tests, creación de PRs. Claude app y Claude como coworker para la parte conversacional: brainstorming, discusiones de arquitectura, explicar código, redactar documentación. Para asistencia inline, los plugins que ya tengo en mi IDE son suficientes. Probé Copilot y Cursor, no son para mí. Claude cubre lo que necesito.

Diferentes modos para diferentes tareas. Un asistente agéntico siguiendo mis comandos de TDD es un flujo diferente a chatear sobre patrones de diseño. Ambos son útiles. Ninguno reemplaza al otro.

El mercado ahora mismo es intenso. Claude, Codex, Gemini y otros son jugadores fuertes con productos similares, y todos mejoran mes a mes. Los resultados son impresionantes y solo se aceleran. Esa es la belleza de la competencia: obliga a todos a mejorar o volverse irrelevantes, y el consumidor gana de cualquier forma. A día de hoy, Claude Code parece la opción más fuerte para cómo trabajo. Pero no tengo lealtad a una marca. Si Anthropic dejara de avanzar y un competidor fuera claramente mejor, cambiaría sin dudar. Lo que importa es la capacidad, no el logo.

Me equivoqué con la IA de la forma en que los idealistas se equivocan a menudo: medí la herramienta contra el resultado ideal y la encontré insuficiente, en lugar de medirla contra la alternativa realista.

La alternativa al desarrollo asistido por IA no es un equipo de arquitectos senior escribiendo código perfecto. Es el mismo equipo escribiendo el mismo código imperfecto, solo que más lento.

Los ingenieros que aprendan a liderar agentes en lugar de competir contra ellos tendrán una ventaja real. Y esto todavía es el principio.

La pregunta nunca fue “¿puede la IA escribir código perfecto?” Fue “¿puedo liderar a la IA para escribir mejor código, más rápido?” Y la respuesta, con la configuración adecuada, es sí.

El juego completo #

Cada práctica en este post sigue el mismo patrón. La versión ideal existe en los libros. La versión pragmática existe en tu código bajo presión. Necesitas ambas.

La próxima vez que estés subiendo ese fix a las 11 de la noche, sabrás qué atajos tomaste y por qué. Ese es el juego completo. No la perfección. No la velocidad. Saber cuál debe liderar.

Construye tu Propio Equipo de Agentes

2026-02-07T00:00:00+00:00

La mayoría usa asistentes de código con IA como un único interlocutor. Abres un chat, describes lo que necesitas y obtienes una respuesta. Funciona. Pero es como contratar a un generalista para que haga de todo. Ningún equipo real funciona así.

La verdadera ventaja viene cuando organizas la IA como un equipo: onboarding, procedimientos estándar, especialistas y ejecución en paralelo.

En el post sobre MCP cubrí cómo darle acceso a tu entorno. En La IA te da velocidad, no calidad, por qué el juicio humano sigue siendo esencial. Este post cubre la pieza que falta: organizar ese acceso en un flujo coordinado.

El documento de onboarding #

Todo buen equipo empieza con onboarding. Los agentes de IA necesitan lo mismo.

Reglas del proyecto #

En Claude Code, el archivo CLAUDE.md en la raíz de tu proyecto es el documento de onboarding. El agente lo lee cada vez que empieza a trabajar: estructura, convenciones, guías de estilo, herramientas.

Pero CLAUDE.md es solo el punto de entrada. Puedes dividir las reglas en archivos enfocados bajo .claude/rules/, cada uno apuntando a partes específicas de tu código mediante patrones glob. El agente no solo conoce tus convenciones, está limitado por ellas. Límites de capas, patrones de nomenclatura, dirección de dependencias. Todo versionado junto al código que protegen.

modules/*/Domain/**/*.php: Sin imports de framework, sin dependencias de infraestructura, solo PHP plano.
modules/*/Infrastructure/**/*.php: Los controladores se mantienen delgados, los modelos Eloquent en su sitio.
resources/js/**/*.tsx: Convenciones de componentes, estrictez TypeScript, patrones de estilos.

Cada archivo de reglas tiene un scope limitado a los archivos que le importan. Las reglas de dominio no se activan cuando se edita un controlador.

Preferencias personales #

También existe un ~/.claude/CLAUDE.md global que aplica en todos tus proyectos. El archivo del proyecto dice cómo funciona este código. El global dice cómo trabajo yo.

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

Procedimientos operativos estándar #

Todos los equipos tienen flujos recurrentes que viven en wikis, runbooks, o en la cabeza de alguien. Cuando viven en la cabeza de alguien, son frágiles.

Los comandos slash personalizados en .claude/commands/ convierten estos flujos en instrucciones ejecutables. Cada comando es un archivo markdown que describe un procedimiento de varios pasos. En uno de mis proyectos, cada comando de creación empieza con tests. TDD incorporado al procedimiento, no dejado a la disciplina.

Creación (TDD-first):

/create-module: Genera un módulo hexagonal con capas de dominio, aplicación e infraestructura.
/create-entity: Entidades de dominio con value objects y archivos de test.
/create-use-case: Handlers de command/query con tests mockeados.
/create-page: Páginas React con factories y smoke tests.

Calidad y flujo de trabajo:

/refactor-check: Analiza código contra principios SOLID.
/test: Ejecuta la suite con filtrado por módulo.
/fix: Auto-aplica correcciones de linting y análisis estático.
/gh-issue: De issue de GitHub a implementación y PR en un solo comando.

Los comandos convierten conocimiento tribal en instrucciones ejecutables. Lo que antes era “pregúntale a Sara cómo creamos un módulo nuevo” se convierte en un comando que cualquiera puede ejecutar.

Especialistas, no generalistas #

Los comandos codifican cómo hace las cosas tu equipo. Pero hay otra capa: skills y agentes.

Skills como bases de conocimiento #

Los skills son conocimiento estructurado del que el agente se nutre. En uno de mis proyectos, tengo skills para principios SOLID, arquitectura hexagonal, flujos TDD y patrones React/Inertia.

Las reglas restringen: “no hagas esto, haz siempre aquello.” Los skills enseñan: “este es el patrón, estos son los errores comunes.” Las reglas son barandillas. Los skills son experiencia.

Agentes como roles especializados #

En lugar de un generalista, defines agentes especializados con un rol claro, herramientas específicas, e incluso un modelo diferente según la complejidad del trabajo. No necesitas a tu arquitecto más senior para renombrar una variable.

Explorer (modelo ligero): Solo lectura. Busca en el código, encuentra archivos, entiende la estructura.
Revisor de código limpio (modelo intermedio): Violaciones SOLID, code smells, inconsistencias de nomenclatura.
Coach de TDD (modelo intermedio): Guía el ciclo red-green-refactor. Edita archivos y ejecuta tests.
Revisor de React (modelo intermedio): Estructura de componentes, estrictez TypeScript, accesibilidad.
Arquitecto de dominio (modelo más capaz): Decisiones de arquitectura, límites de módulos, patrones DDD.

El modelo adecuado para el trabajo adecuado. Rápido y barato para exploración. Capaz y riguroso para arquitectura.

Hazlos trabajar juntos #

Aquí la metáfora del equipo se vuelve literal. Un solo agente es útil. Múltiples agentes desde un plan compartido es un equipo.

Subagentes vs equipos de agentes #

Hay dos modelos de coordinación distintos, y elegir el correcto importa.

Los subagentes se ejecutan dentro de una misma sesión. Hacen trabajo enfocado y devuelven resultados al agente principal. No pueden hablar entre sí. El agente principal lo gestiona todo.

Los equipos de agentes son diferentes. Cada miembro es una sesión de Claude Code independiente con su propia ventana de contexto. Se comunican a través de un buzón compartido, reclaman tareas de una lista compartida y se coordinan sin pasar por un cuello de botella central.

La arquitectura tiene cuatro componentes:

Team lead: la sesión principal que crea el equipo y orquesta el trabajo
Teammates: instancias separadas de Claude Code, cada una con tareas específicas
Lista de tareas: elementos de trabajo compartidos con seguimiento de dependencias. Las tareas bloqueadas se desbloquean automáticamente cuando sus dependencias se completan
Buzón: mensajería directa entre agentes, incluyendo broadcasts a todo el equipo

Los subagentes son trabajadores que reportan. Los equipos de agentes son colaboradores que piensan juntos.

Usa subagentes cuando solo importa el resultado. Usa equipos de agentes cuando los miembros necesitan compartir hallazgos, cuestionar al resto y coordinarse por su cuenta.

Empezando con equipos de agentes #

Los equipos de agentes son aún experimentales. Actívalos añadiendo esto a ~/.claude/settings.json:

{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

Crear un equipo es conversacional. Describes lo que quieres: “Crea un equipo de agentes para refactorizar el módulo de auth. Genera tres miembros: uno para cambios de API backend, uno para componentes frontend, uno para escribir tests.” Claude configura la lista de tareas, genera los miembros y coordina el trabajo.

Puedes ver el equipo en un mismo proceso (un terminal, navega con Shift+Up/Down) o dividido en paneles (cada miembro en una ventana tmux o iTerm2 separada). Usa Shift+Tab para activar el modo delegado, que restringe al lead a solo coordinación.

Advertencia sobre consumo de tokens. Los equipos de agentes queman tokens rápidamente. Cada miembro tiene su propia ventana de contexto, y cada mensaje entre agentes suma. Empieza con tareas de investigación y revisión antes de pasar a implementación. Tres miembros explorando en paralelo cuesta aproximadamente 3x. Asegúrate de que el paralelismo se paga a sí mismo.

Los miembros cargan automáticamente el contexto del proyecto (CLAUDE.md, servidores MCP, skills) pero no heredan el historial de conversación del lead. Al crear un miembro, sé específico sobre qué archivos revisar y qué restricciones aplican. Un prompt de creación vago produce trabajo vago.

Primero planificar, después ejecutar #

Describes el problema. El agente explora el código, mapea dependencias y propone un enfoque antes de cambiar nada. Lo apruebas, modificas o rechazas. Pensar primero, programar después.

Con equipos de agentes, la aprobación de plan permite exigir que los miembros diseñen su enfoque antes de implementar. El agente trabaja en modo solo lectura hasta que el lead aprueba. Puedes moldear el criterio del lead: “solo aprueba planes que incluyan cobertura de tests” o “rechaza planes que modifiquen el esquema de base de datos.”

El modo delegado restringe al lead a solo coordinación. Sin él, el lead a veces empieza a implementar en lugar de esperar a los miembros. El modo delegado lo mantiene centrado en la orquestación, no en la ejecución.

Hipótesis competitivas #

Cuando la causa raíz no está clara, un solo agente tiende a encontrar una explicación plausible y dejar de buscar. Los equipos de agentes combaten esto haciendo que los miembros sean adversarios. Cada uno investiga su propia teoría mientras intenta refutar las de los demás.

La investigación secuencial sufre de anclaje: una vez que se explora una teoría, todo lo posterior está sesgado hacia ella. Con múltiples investigadores cuestionándose mutuamente, la teoría que sobrevive tiene más probabilidades de ser la causa raíz real.

Dimensiona las tareas para trabajo en paralelo #

No todo el trabajo se beneficia del paralelismo. La pregunta clave: ¿pueden los miembros trabajar de forma independiente?

Demasiado pequeñas: el overhead de coordinación supera el beneficio
Demasiado grandes: los miembros trabajan demasiado tiempo sin revisión, aumentando el esfuerzo desperdiciado
El punto justo: unidades autocontenidas que producen un entregable claro. Una función, un archivo de tests, una revisión

Tener 5-6 tareas por miembro mantiene a todos productivos. Que cada miembro sea dueño de archivos diferentes. Sin aislamiento, dos editando el mismo archivo lleva a sobreescrituras. Los worktrees cambian esto.

Imagina una funcionalidad que toca backend y frontend. Después de planificar:

Un agente de backend genera la capa de dominio: entidades, value objects, interfaces de repositorio, handlers. Todo hexagonal, todo test-first.
Un agente de frontend construye la página React, componentes, hooks y factories. Cada uno sigue sus propias reglas y opera de forma independiente.

No se pisan porque el plan ya definió los límites. Propiedad clara. Sin conflictos de merge. Sin esperas.

Aislamiento con worktrees #

La mayor fricción con agentes en paralelo eran los conflictos de archivos. Dos agentes editando el mismo archivo significaba sobreescrituras y trabajo perdido. Los git worktrees eliminan esto dándole a cada agente su propia copia de trabajo del repositorio.

Inicia Claude Code con --worktree para ejecutarlo en un worktree aislado. Múltiples sesiones, mismo repositorio, sin pisarse. Añade --tmux para lanzarlo en su propia sesión tmux.

claude --worktree --tmux

Los subagentes también soportan worktrees. Pídele a Claude que use worktrees para sus agentes, o añade isolation: worktree en el frontmatter de tu agente personalizado para que sea el comportamiento por defecto.

---
isolation: worktree
---

La app de escritorio tiene la misma funcionalidad: activa el modo worktree en la pestaña Code.

Para control de versiones no-git (Mercurial, Perforce, SVN), puedes definir worktree hooks para obtener los mismos beneficios de aislamiento sin necesidad de usar git.

Los worktrees convierten “propiedad clara de archivos” de una restricción de planificación en una garantía de infraestructura. Los agentes pueden solaparse en los mismos archivos sin pisarse.

Revisión tras la ejecución #

Tras la implementación, los agentes de revisión toman el relevo. En lugar de un revisor que lo pille todo, tienes especialistas: violaciones SOLID, patrones de componentes, calidad de tests, límites de módulos.

Un solo agente es un asistente. Múltiples agentes trabajando desde un plan compartido es un equipo.

Tú sigues siendo el lead #

Por muy bien configurados que estén, los agentes trabajan para ti. Tú estableces los estándares, escribes las reglas, revisas los planes y apruebas el resultado antes de que salga. Puedes enviar un mensaje a cualquier miembro mientras trabaja para redirigir su enfoque o añadir restricciones. Si alguien va por mal camino, intervienes directamente.

Como escribí en La IA te da velocidad, no calidad, el código que produce el agente es tu responsabilidad. Más paralelismo sin supervisión es solo más caos, más rápido.

Puertas de calidad #

Los hooks y git hooks actúan como la última red de seguridad. En mi setup, nada se commitea a menos que los linters pasen, el análisis estático esté limpio, los tests sean verdes y la cobertura supere el 90%. El agente no puede saltarse esto. Nadie puede.

Los equipos de agentes añaden sus propios hooks: TeammateIdle mantiene activos a los miembros inactivos, TaskCompleted impide completar tareas prematuramente. Políticas automatizadas que nadie puede saltarse.

Los git hooks ejecutan linters, análisis estático y tests antes de cada commit. Claude Code añade sus propios hooks (.claude/hooks/): comandos shell que se disparan ante eventos del agente como llamadas a herramientas o escritura de archivos.

.claude/settings.json controla lo que los agentes pueden ejecutar. Autoriza herramientas y comandos específicos, deniega operaciones destructivas. Controlas no solo lo que los agentes saben (reglas, skills) sino lo que pueden hacer (permisos). Las reglas definen la cultura. Los permisos definen los límites.

La base importa #

Los agentes te ayudan a llegar más rápido, pero ese “allí” tiene que estar bien definido. Si no sabes cómo es la arquitectura hexagonal, los agentes no la van a descubrir por ti.

No construyes todo esto el primer día. Empiezas con un CLAUDE.md. Luego notas que repites instrucciones, y escribes un comando. Un agente rompe una convención, y añades una regla. El setup crece orgánicamente a partir de fricción real. Cada adición resuelve un problema que realmente tuviste. Lo mismo con los equipos de agentes: empieza con tareas que no requieran escribir código. Revisa un PR, investiga una librería, analiza un bug. Aprende el modelo de coordinación antes de implementar en paralelo.

Si quieres un punto de partida, preparé laravel-claude-toolkit: un starter kit de Laravel con reglas, comandos, skills, agentes, hooks y permisos ya configurados.

No solo estás usando IA. Estás construyendo un equipo. Y como cualquier equipo, la calidad de su resultado refleja la calidad de su liderazgo.

Recursos #

Claude Code | claude.com
Claude Code: Agent Teams | claude.com
Claude Code Tips: Workflow Boosters | rfrolov.me

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.

La IA te Da Velocidad, No Calidad

2025-10-10T00:00:00+00:00

He estado usando asistentes de codificación IA extensivamente: ChatGPT, Codex, Claude con Sonnet y Opus. Son increíblemente útiles. Te dan velocidad como nada más.

Pero la velocidad no es calidad.

La trampa del vibe-coding #

Los modelos de IA son excelentes imitando su entorno. Dales contexto, y harán lo que sea necesario para completar la tarea. Esto se ha conocido como “vibe-coding”: describes lo que quieres, y la IA produce algo que funciona. Rápido.

¿El problema? La IA felizmente generará código desordenado si eso es lo que hace el trabajo. No le importa la mantenibilidad. No piensa en qué pasa cuando los requisitos cambien el próximo mes. Solo produce output.

La IA es un espejo que refleja el contexto que le das. Si tu codebase está desordenado, generará más desorden. Si tus prompts son vagos, hará suposiciones.

Sin guía cuidadosa, terminas con parches sobre parches. Código legacy recién creado. Una codebase donde cada cambio se siente arriesgado y el equipo pasa más tiempo luchando contra el código que construyendo features.

El arte de preguntar #

¿Recuerdas Stack Overflow? ¿Las búsquedas en Google que te llevaban a hilos de foros de 2011 donde alguien tenía exactamente el mismo problema?

Hace diez años, ser desarrollador significaba aprender a hacer buenas preguntas. Elaborabas tu post de Stack Overflow cuidadosamente: describe el problema, muestra lo que intentaste, explica lo que esperabas versus lo que pasó. Si tu pregunta era vaga o perezosa, la comunidad te lo hacía saber. A veces duramente.

Pero esa fricción nos enseñó algo valioso: la calidad de tu respuesta depende de la calidad de tu pregunta.

El mismo principio aplica a la IA. Un prompt vago obtiene una respuesta vaga. Un prompt bien estructurado con contexto claro, restricciones y ejemplos obtiene algo útil. La habilidad de formular buenas preguntas no se volvió obsoleta. Se volvió más importante.

Aprender a hacer prompts a la IA efectivamente es el equivalente moderno de aprender a buscar en Google y preguntar en Stack Overflow. Los desarrolladores que dominen esto obtendrán mejores resultados.

Incluso cuando la IA te da una respuesta rápida e impresionante, nunca aceptes código que no entiendas completamente. Es tentador. La respuesta aparece en segundos, se ve profesional, incluso podría funcionar. Pero si no puedes explicar qué hace y por qué, estás plantando una bomba de tiempo en tu codebase. Y cuando explote a las 2am, estarás debuggeando código que no escribiste sin modelo mental de por qué existe.

Cuestiona el resultado. Pregunta: “¿Puedes simplificar esto?” o “¿Hay código repetitivo aquí que podamos eliminar?” La IA por defecto añade, no mejora. Generará abstracciones, funciones auxiliares y patrones que no pediste. No refactorizará a menos que se lo digas. Cuestiónala.

Esto es especialmente crítico con los tests. Pide a la IA que genere tests y a menudo obtendrás tests que reflejan detalles de implementación en lugar de comportamiento. Se romperán en el momento que refactorices, incluso si la lógica permanece igual. Si quieres tests que verifiquen comportamiento, necesitas decirlo explícitamente. La IA no hará esa elección por ti.

No te dejes seducir por la velocidad. A veces, una respuesta rápida que no entiendes es peor que una respuesta lenta que sí entiendes.

El factor humano #

La IA puede escribir código rápido, pero no puede entender la arquitectura general. No sabe por qué ciertas decisiones se tomaron hace meses. No puede ver el panorama general de hacia dónde va el producto. Solo ve lo que le muestras, tomando decisiones locales sin entender las implicaciones globales. Ese es nuestro trabajo.

Como exploré en diferentes creencias sobre la calidad del software, los equipos a menudo tienen estándares variables sobre qué significa “suficientemente bueno”. Cuando añades IA a la mezcla, mantener ese entendimiento compartido se vuelve aún más crítico. La IA no comparte los valores de tu equipo. Solo genera código.

La disciplina para mantener arquitectura limpia, para decir “no” a hacks rápidos, para refactorizar antes de que las cosas empeoren. Eso es únicamente humano.

Libros como Clean Code y Clean Architecture no son menos relevantes en la era de la IA. Son más relevantes. Te ayudan a detectar cuando la IA va en la dirección equivocada.

Colaboración sobre automatización #

Hay algo más que la IA no puede reemplazar: el equipo.

Una conversación con un colega sobre “¿deberíamos extraer esto en un servicio?” a menudo lleva a insights que ningún prompt de IA sacaría a la luz. Ese ida y vuelta, el cuestionar, el “¿qué si intentamos esto en su lugar?”. Ahí es donde ocurre el entendimiento real.

Extreme Programming Explained enfatiza prácticas como pair programming y propiedad colectiva del código por buenas razones. Estas no son ineficiencias para automatizar. Son cómo los equipos construyen calidad en su proceso.

Cuando saltas la discusión humana y solo dejas que la IA genere soluciones, pierdes la oportunidad de aprender, de desafiar suposiciones y de crecer como equipo.

Tú eres dueño del código #

Cuando la IA escribe código y tú lo commiteas, lo revisas, lo apruebas, lo mergeas y lo deployeas, es tu código. No puedes culpar a la IA cuando algo se rompe en producción. No puedes señalar a Claude o Copilot cuando la arquitectura se vuelve imposible de mantener.

Como escribí sobre el arte del testing, la calidad es una elección que hacemos en cada paso. Cada commit es una decisión. Cada revisión es una oportunidad de detectar problemas. Cada merge es un respaldo de la calidad del código.

Somos la última parte responsable del código que la IA escribe. El commit, la revisión, la aprobación, el merge, el deploy. Todo eso somos nosotros.

Moverse rápido en la dirección equivocada solo te lleva a perderte más rápido. Las líneas de código apareciendo en pantalla no es progreso. El valor que aportamos como desarrolladores no es la velocidad tecleando. Nuestro valor está en entender hacia dónde vamos, mantener disciplina sobre el caos, y asegurar que el código que entregamos hoy no se convierta en la pesadilla de mañana.

Usa la IA. Abraza la velocidad. Pero nunca olvides: tú eres quien conduce. Si sueltas el volante, terminarás en una pila de código imposible de mantener más rápido de lo que esperabas.

Y cuando eso pase, no hay nadie más a quien culpar.