Qué cambió: de "sugerir la siguiente línea" a "resolver el ticket"
Durante años, la IA en programación fue autocompletado. Escribías tres palabras y el editor proponía la cuarta. Útil, pero el trabajo seguía siendo tuyo: abrir archivos, entender dependencias, escribir, probar, corregir.
La programación agéntica invierte esa relación. Le describes un objetivo —"migra el módulo de facturación a la API v2"— y un agente hace el recorrido completo: explora el repositorio, arma un plan, edita los archivos que corresponden, ejecuta las pruebas, lee los errores y corrige. Tú revisas el resultado.
La diferencia no es de grado, es de rol. El desarrollador deja de ser quien teclea cada línea y pasa a ser quien define el objetivo, aprueba el plan y revisa el diff. Es un cambio incómodo al principio y muy productivo después, siempre que se adopte con disciplina.
Qué es Claude Code exactamente
Claude Code es el agente de programación de Anthropic que vive en el terminal, no dentro de un editor. Esa decisión de diseño importa más de lo que parece: al estar en la línea de comandos tiene acceso natural a las mismas herramientas que usas tú —git, npm, composer, tu suite de tests, tu CLI de despliegue— sin necesidad de plugins.
También existe como aplicación de escritorio, extensión para VS Code y JetBrains, y en la web. Pero el modelo mental es el mismo: un colaborador con acceso a tu proyecto y a tu shell.
| Capacidad | Para qué sirve | Cuándo la usas |
|---|---|---|
| Plan mode | El agente investiga y propone un plan sin tocar archivos | Siempre que la tarea toque más de 2 o 3 archivos |
| CLAUDE.md | Archivo con las reglas del proyecto que el agente lee siempre | Convenciones, comandos de build, "no toques esta carpeta" |
| Subagentes | Instancias aisladas con su propio contexto y permisos | Búsquedas amplias, auditorías, tareas que ensucian el hilo principal |
| Hooks | Comandos que se disparan en eventos del ciclo de vida | Correr el linter tras cada edición, bloquear cambios en vendor/ |
| Skills | Procedimientos empaquetados que el agente sigue paso a paso | "Así se despliega aquí", "así se revisa un PR en este equipo" |
| MCP | Conexión estructurada a sistemas externos (BD, Jira, ERP) | Cuando el agente necesita datos reales, no suposiciones |
Si te interesa el último punto, lo desarrollamos en detalle en MCP en IA: agentes robustos y confiables.
Hasta dónde llega hoy
El caso que más se cita en el reporte de tendencias de programación agéntica publicado por Anthropic en 2026 es el de Rakuten: un agente completó una tarea de extracción de vectores de activación dentro de vLLM —una librería open source de aproximadamente 12.5 millones de líneas— en unas siete horas de trabajo autónomo en una sola corrida, con 99.9% de precisión numérica frente al método de referencia.
Es un caso extremo y conviene leerlo como tal: repositorio público, tarea bien delimitada, criterio de éxito numérico y verificable. No es "el agente mantiene tu ERP solo". Pero marca el orden de magnitud de lo que hoy es posible delegar.
El otro cambio del año es el paso del pair programming interactivo a la delegación asíncrona: encargas tareas, cierras la laptop, y revisas resultados después. Eso obliga a algo que antes no era crítico: que el agente sepa cuándo detenerse y pedir confirmación.
Cómo se ve en la práctica en un equipo pequeño
Este es el flujo que usamos y recomendamos para equipos de 2 a 10 desarrolladores:
1. TICKET
"El reporte de ventas por vendedor no cuadra
cuando hay notas de crédito del mes anterior."
2. PLAN (sin escribir código todavía)
El agente lee el módulo, encuentra 3 lugares donde se
calcula el total y propone: unificar en un solo servicio,
agregar 4 tests de regresión.
→ El desarrollador aprueba, corrige o descarta el plan.
3. EJECUCIÓN
El agente edita, corre la suite, ve 2 fallas,
las arregla, vuelve a correr. Todo en una rama nueva.
4. REVISIÓN HUMANA (no negociable)
git diff → el desarrollador lee CADA línea.
Lo que no entiende, no entra.
5. PR + CI
El pipeline corre igual que siempre.
Nadie hace merge sin build verde y sin revisión.
Los pasos 2 y 4 son los que separan un equipo que gana velocidad de uno que acumula deuda técnica a gran escala.
Los cinco errores que vemos más seguido
1. Saltarse el plan. Pedir "arregla el bug" y dejar que el agente edite de una. En tareas chicas funciona; en tareas medianas produce cambios amplios que después nadie quiere revisar. El plan cuesta 30 segundos y ahorra horas.
2. Aprobar diffs sin leerlos. Es el error más caro y el más humano. Si el diff es tan grande que no da ganas de leerlo, el problema no es tu paciencia: la tarea estaba mal delimitada. Divídela.
3. No tener tests. Un agente sin suite de pruebas es un desarrollador nuevo sin forma de verificar su trabajo. Si tu proyecto no tiene tests, el primer encargo debería ser justamente escribirlos para el módulo crítico.
4. Trabajar sobre la rama principal. Siempre en rama aparte. Es reversible, revisable y no bloquea al resto del equipo.
5. No escribir el CLAUDE.md. Sin reglas del proyecto, el agente inventa convenciones razonables pero distintas a las tuyas. Veinte líneas bien escritas ("usamos PSR-12", "las migraciones van en db/migrations", "nunca edites assets/dist") eliminan el 80% de las correcciones.
Qué se puede delegar y qué no
| Tipo de tarea | Delegable | Por qué |
|---|---|---|
| Migrar sintaxis, actualizar dependencias, renombrar en todo el repo | Sí, con poca supervisión | Mecánico, verificable por compilación y tests |
| Escribir tests para código existente | Sí | El agente lee el comportamiento actual y lo fija |
| Corregir bugs con caso reproducible | Sí, revisando el diff | Hay criterio de éxito claro: el caso deja de fallar |
| Implementar una funcionalidad nueva bien especificada | Sí, con plan aprobado | Necesita que tú definas el alcance primero |
| Decidir la arquitectura del sistema | No, pero sirve para explorar opciones | Es una decisión de negocio y de largo plazo |
| Cambios en cálculo tributario, planilla o dinero | Solo con revisión especializada | El costo de un error es legal y económico, no técnico |
| Ejecutar despliegues o borrar datos en producción | No sin confirmación explícita | Irreversible; para eso existen los permisos y los hooks |
El impacto real en costos
Antes de hablar de ahorro, una advertencia: la programación agéntica no reduce el equipo, cambia lo que hace el equipo. En los proyectos donde lo hemos medido, el tiempo que antes se iba en tareas mecánicas se reasigna a lo que estaba postergado: pruebas, documentación, refactors, atención al cliente.
Un ejemplo concreto de un mantenimiento típico que hacemos:
- Migración de un módulo de reportes (28 archivos, PHP 7.4 a 8.2): antes ~5 días de un desarrollador; con agente + revisión, 1.5 días.
- Cobertura de tests de un módulo de inventario: antes se posponía indefinidamente; ahora se resuelve en una tarde.
- Costo de la herramienta: entre S/ 80 y S/ 400 al mes por desarrollador según el plan y la intensidad de uso.
La cuenta que importa no es "cuánto cuesta la licencia" sino "cuántas horas de desarrollador senior cuesta no tenerla". Con una tarifa de mercado en Lima, la herramienta se paga con dos o tres horas ahorradas al mes.
Riesgos que hay que nombrar
Código que nadie entiende. Si el equipo acepta cambios que no puede explicar, la deuda técnica crece más rápido que antes, no más lento. La regla es simple: lo que no puedes explicar en la revisión, no entra al repositorio.
Dependencias inventadas. Un agente puede sugerir un paquete que no existe o que existe con otro nombre. Es un vector de ataque conocido. Verifica cada dependencia nueva contra el registro oficial antes de instalarla.
Secretos en el contexto. Si el agente lee tu .env, ese contenido pasa por el modelo. Usa variables de entorno, archivos de ejemplo sin valores reales y reglas de exclusión.
Falsa sensación de terminado. "Los tests pasan" no significa "está bien". Significa que pasan los tests que existen. Si la suite es débil, el verde es decorativo.
Cómo empezar esta semana
- Elige un proyecto secundario, no el sistema que factura. Uno donde un error cueste tiempo, no dinero.
- Escribe un CLAUDE.md de 20 líneas: stack, comandos de build y test, convenciones, carpetas prohibidas.
- Primer encargo: tests. Que el agente cubra el módulo más frágil. Ganas red de seguridad antes de dejarlo editar.
- Segundo encargo: una migración mecánica. Actualizar una librería, unificar el formato, eliminar código muerto.
- Mide dos cosas durante un mes: horas invertidas por ticket y cantidad de correcciones post-merge. Si las correcciones suben, tu proceso de revisión es débil.
- Recién después, lleva la práctica al sistema principal, siempre con rama, plan y revisión.
Conclusión
La programación agéntica no elimina desarrolladores: elimina el tiempo que los desarrolladores pasaban haciendo lo que ya sabían hacer y no les enseñaba nada. Lo que gana valor es exactamente lo que el agente no puede hacer por ti: entender el negocio, decidir la arquitectura, revisar con criterio y responder por el resultado.
El equipo que adopta agentes sin proceso de revisión va a ir más rápido hacia un lugar peor. El que los adopta con plan, ramas, tests y revisión honesta va a hacer en un trimestre lo que antes le tomaba un año.