[ PLAYBOOK · 01 ] · 7 DE MAYO, 2026 · 7 min

Programación agéntica con Claude Code.

Una mirada práctica a dónde están las ganancias, dónde quedan asperezas y cómo un equipo de ingeniería puede adoptar la herramienta sin debilitar su proceso de revisión.

Lo que cambia con la programación agéntica

La mayoría de los equipos llama a su autocompletado un "agente de IA". Eso es marketing.

Un agente de verdad lee la base de código, escribe código, ejecuta las pruebas e itera sobre las fallas sin instrucciones en cada paso. Ambos son útiles. Solo uno cambia lo que un desarrollador hace en una tarde.

Claude Code es la herramienta más opinada de la categoría agéntica. Es un CLI construido por Anthropic que opera dentro de un repositorio existente. Edita archivos, ejecuta comandos de shell, interpreta la salida de las pruebas, planifica antes de actuar y expone cada acción para que un humano la revise. El cambio relevante no es que escriba código. Es que la herramienta sostiene la atención a través de tareas multi-paso donde antes la persona desarrolladora tenía que mantener la memoria de trabajo.

Las ganancias de este cambio son reales, y están concentradas. Tres flujos de trabajo se llevan la mayoría de las victorias de productividad que hemos medido. El resto es hype o trabajo que todavía requiere juicio humano. El plan de despliegue tiene que dar cuenta de ambos.

Un recorrido corto por Claude Code en 2026

Las piezas a continuación son las que sostienen la adopción del equipo. Hay más (slash commands personalizados, status line, extensiones de IDE), pero las cuatro de abajo son las que cambian cómo se hace el trabajo.

Modo plan

El modo plan separa "decidir qué hacer" de "hacerlo". La persona usuaria emite una solicitud. El agente lee los archivos relevantes, formula un plan paso a paso y espera aprobación explícita antes de tocar la base de código. Aprobar es una sola tecla. Rechazar regresa a refinar el plan.

Es la característica de mayor apalancamiento para construir confianza durante el despliegue. Un equipo puede adoptar la programación agéntica bajo la regla "siempre planificar primero" y construir la confianza a partir de ahí.

Skills

Una skill es un flujo de trabajo empaquetado. Es un directorio con un archivo SKILL.md que incluye un nombre, una descripción y un cuerpo de instrucciones que el agente sigue cuando se invoca. La persona usuaria escribe /nombre-de-la-skill y el agente carga el conjunto completo de instrucciones de la skill como contexto.

Los equipos usan skills para cualquier flujo que se repite: cortar una release, abrir un pull request estructurado, generar un runbook a partir de un retrospectivo de incidente, normalizar una característica a través de la base de código. La skill captura el conocimiento institucional una sola vez, y cada developer del equipo lo ejecuta de la misma manera.

Servidores MCP

Los servidores Model Context Protocol son el puente entre Claude Code y las herramientas que el equipo ya usa. Hay servidores MCP para Linear, GitHub, Postgres, Chrome DevTools, Playwright y una lista creciente de plataformas pagas. El agente puede leer un ticket de Linear, abrir la rama correspondiente, ejecutar la prueba que falla a través de Playwright y devolver un borrador de descripción de PR, todo sin salir de la sesión del terminal.

El costo de integración es bajo. El costo de disciplina es real. Cada servidor MCP agrega herramientas que el agente puede llamar, lo cual amplía su radio de acción. Conviene tratar la selección de servidores MCP como una decisión de permisos, no como una decisión de funcionalidad.

Hooks y subagentes

Los hooks ejecutan comandos de shell en puntos predefinidos del ciclo del agente: antes de una llamada a una herramienta, después de ella, antes de enviar el input del usuario, al inicio de la sesión y al final de la sesión. Son el lugar correcto para imponer barandillas que el agente no debería poder sortear con argumentos. Tres patrones se pagan solos en la mayoría de los equipos.

PreToolUse en Bash: bloquear comandos destructivos (rm -rf, git push --force, drop table) antes de que el agente pueda ejecutarlos.
PostToolUse en Edit: ejecutar el formateador en cada archivo que el agente toca, para que el estilo se mantenga consistente sin negociar.
UserPromptSubmit: inyectar contexto del proyecto (rama actual, hash del último despliegue) para que cada prompt comience anclado.

Los subagentes son la historia de paralelización. Para tareas que se descomponen limpiamente, Claude Code puede lanzar subagentes que operan en paralelo. El patrón que más rinde es la investigación independiente: un subagente busca patrones de uso en la base de código, otro consulta documentación de API, un tercero revisa regresiones de seguridad. El orquestador recoge sus resúmenes y avanza. El patrón que no rinde es descomponer trabajo fuertemente acoplado. Si las subtareas necesitan los resultados unas de otras, secuenciarlas en serie en el orquestador es más rápido y más barato.

Los tres flujos donde las ganancias son reales

En despliegues con equipos de ingeniería durante los últimos doce meses, tres flujos muestran de manera consistente ganancias medibles de productividad. Comparten una propiedad: son abiertos, requieren atención sostenida a través de muchos archivos, y el rol del developer es más curador que mecanógrafo.

Investigación de bugs de cola larga

Bugs que abarcan tres o más archivos, que aparecen solo bajo datos específicos, y que no tienen un dueño obvio. El agente lee la prueba que falla, traza el grafo de llamadas, plantea una hipótesis de causa, ejecuta la prueba, itera. Un developer senior se queda en el ciclo para cuestionar las hipótesis y confirmar las soluciones. En nuestros despliegues, el tiempo en el reloj de estas tareas suele bajar 50 por ciento o más.

Refactors multi-archivo con forma determinista

Algunos ejemplos: "renombrar este concepto a través de la base de código", "extraer esta lógica duplicada en una utilidad compartida", "convertir esta API interna de callbacks a async". Son tareas donde el objetivo es preciso y la verificación es mecánica (la suite de pruebas). El agente sobresale porque el trabajo es en gran medida procedimental. El developer revisa el diff y corre la suite.

Preguntas exploratorias sobre la base de código

Preguntas como "dónde establecemos este header", "qué servicios consumen esta cola", "cuál fue la razón histórica de esta rama en el flujo de auth". Son preguntas cuyas respuestas viven en la base de código pero le toman a una persona una hora reunir. El agente puede buscar, leer y resumir a través de muchos archivos en minutos. La salida es una nota de investigación, no un cambio de código.

Lo que aún requiere juicio humano

Los mismos despliegues han mostrado tres categorías de trabajo donde la salida del agente es consistentemente más débil que la de un developer senior, y donde apoyarse en él produce deuda de segundo orden.

Decisiones arquitectónicas

Elegir entre dos patrones viables. Decidir si un nuevo servicio se justifica. Decidir qué extraer y qué dejar inline. El agente puede articular tradeoffs pero no carga la historia del equipo. No sabe qué decisión previa es estructural y cuál es vestigial. Las decisiones arquitectónicas siguen siendo responsabilidad humana, con el agente como apoyo de investigación.

Revisión de seguridad y control de acceso

El agente lee bien el código. No tiene un modelo de amenazas para la aplicación específica del equipo. Aceptará patrones que parecen idiomáticos pero filtran datos a través de casos límite que el equipo debió haber marcado. La revisión de seguridad sobre el código escrito por el agente se queda con humanos, idealmente con una checklist de modos de fallo específicos del proyecto codificada como hook.

Estilo de código y nomenclatura transversales

El estilo es un contrato del equipo. El agente elige el estilo más común en sus datos de entrenamiento, que rara vez es el del equipo. El remedio es un hook de estilo (formateador en PostToolUse), una sección explícita en CLAUDE.md sobre convenciones de nomenclatura, y revisiones de código que llamen la deriva temprano. Sin estas piezas, el código escrito por el agente comienza a parecerse a cualquier otro repositorio del internet abierto, que es la pérdida de identidad que vuelve una base de código difícil de razonar a lo largo del tiempo.

Un plan de despliegue de 30 días para un equipo de ingeniería

El patrón de despliegue de abajo ha funcionado con equipos de 5 a 25 ingenieros. Carga las barandillas al frente, construye confianza a través del modo plan, y solo afloja los predeterminados después de que el equipo ha vivido con la herramienta durante dos semanas.

Semana 1: cimientos

Instalar Claude Code en cada máquina del equipo. Escribir el primer CLAUDE.md del proyecto con tres secciones: un párrafo de resumen sobre qué es el proyecto, la disposición de directorios, y el comando de pruebas. Configurar dos hooks: una lista de bloqueo PreToolUse para Bash y una llamada al formateador en PostToolUse. Autorizar servidores MCP para las herramientas fuente de verdad del equipo (GitHub, Linear, la base de datos). Poner a todo el equipo en modo plan por defecto.

Semana 2: skills y patrones

Elegir tres flujos recurrentes que el equipo ejecuta cada semana. Escribirlos como skills bajo .claude/skills/. Ejemplos que aparecen con más frecuencia: abrir un PR estructurado, escribir una entrada de runbook, agregar una nueva migración de base de datos. Realizar una sesión de 60 minutos donde dos ingenieros le muestren al equipo cómo usaron Claude Code para un ticket real, incluyendo un momento donde rechazaron un plan y reformularon el prompt.

Semana 3: medición y revisión

Registrar el tiempo a merge en los tickets donde el developer usó Claude Code, y los tickets donde no. La meta no es un binario "usó al agente o no". Es un registro por ticket para que el equipo vea dónde se concentran las victorias y las pérdidas. Agregar una rúbrica de revisión de código para los diffs escritos por el agente: adherencia al alcance, consistencia de nomenclatura con el resto de la base de código, cobertura de pruebas en el nuevo camino de código.

Semana 4: abrir los predeterminados

Si las primeras tres semanas fueron bien, levantar el modo plan como predeterminado para tareas bajo un umbral de riesgo definido. Para trabajo de mayor riesgo (migraciones de producción, cambios de auth, cualquier cosa que toque facturación), el modo plan se queda obligatorio. Codificar esa regla en settings.json para que no se negocie caso por caso.

Medición: cómo saber si está funcionando

Un despliegue de 30 días no es un referendo sobre la herramienta. Es una búsqueda de los flujos en los que el equipo es más rápido, los flujos en los que no, y los flujos en los que el agente introduce riesgo más rápido de lo que lo retira. Tres números son útiles, en orden de cuánto importan.

Tiempo a merge en tickets asistidos por agente, por tipo de ticket. Si los bugs de cola larga y los refactors multi-archivo no se aceleran, el despliegue tiene un problema antes de que la herramienta lo tenga.
Tasa de defectos en las cuatro semanas posteriores a un release que llevó código escrito por el agente, comparada con las cuatro semanas previas. Una tendencia plana o de mejora es la meta. Los picos significan que la rúbrica de revisión necesita ajuste.
Foco autorreportado del developer. Una encuesta semanal de dos preguntas: "la herramienta te ahorró tiempo esta semana" y "te causó fricción esta semana". Ambas pueden ser ciertas. Las respuestas calibran la siguiente iteración de skills y hooks.

Si esos tres números se mueven en la dirección correcta al final de la semana cuatro, el despliegue es real. Si no lo hacen, la falla está en el patrón de despliegue, no en la herramienta misma.