Las 4 piezas que necesitás para dejar de mirar cómo trabaja un agente de código.
Si para que Claude haga algo tenés que quedarte sentado mirando la terminal, no tenés un agente autónomo.
Tenés un copiloto más rápido.
La diferencia parece pequeña, pero cambia completamente la forma de trabajar.
En un caso, le das una tarea, mirás qué hace, corregís, volvés a pedir y repetís.
En el otro, definís un resultado, Claude trabaja, verifica lo que hizo y vuelve a vos solamente cuando necesita una decisión que no puede tomar solo.
Eso es autonomía.
Y no aparece simplemente porque el modelo sea más inteligente.
Aparece cuando diseñás el sistema alrededor del agente.
En este artículo vas a ver las cuatro piezas que hacen posible ese cambio:
Dejar que un agente modifique tu código sin mirar cada movimiento suena peligroso.
Lo es si no podés volver atrás.
Y Claude se va a equivocar.
Vos también.
La pregunta importante no es si va a cometer errores.
Es:
¿Cuánto te cuesta cuando se equivoca?
Si un error puede destruir una tarde de trabajo, es lógico que quieras mirar todo lo que hace.
Pero si podés volver fácilmente a un estado anterior, revisar exactamente qué cambió y aprobar antes de incorporarlo al código principal, la aritmética cambia.
Ahí es donde entra Git.
Git es lo que hace que equivocarse sea barato.
Cada commit guarda un estado del proyecto. Podés comparar cambios, volver atrás y entender qué se modificó.
GitHub agrega una capa de colaboración y revisión sobre ese historial.
Para trabajar con agentes, hay tres cosas especialmente importantes:
Si Claude rompe algo, volvés a un commit anterior.
El error deja de costarte una tarde.
Puede costarte unos minutos.
El diff muestra las líneas que se agregaron y eliminaron.
No necesitás revisar todo el proyecto.
Revisás el cambio.
El pull request permite que el agente proponga un cambio sin imponerlo.
El agente trabaja.
Vos revisás.
Vos aprobás.
Ese pequeño cambio de arquitectura es enorme.
El agente puede trabajar solo sin que vos tengas que confiar ciegamente en él.
Uno de los errores más caros con agentes no es que escriban código malo.
Es que escriban código perfecto para resolver el problema equivocado.
Por eso conviene separar dos etapas:
primero entender y planificar; después ejecutar.
Claude Code tiene un modo específico para esto: Plan Mode.
En ese modo puede leer el proyecto y analizarlo sin modificar los archivos.
Podés pedirle algo como:
Scalability SystemsLeé /src/auth y entendé cómo manejamos sesiones y login.
Quiero agregar login con Google.
Analizá qué archivos deberían cambiar, qué riesgos ves
y armá un plan de implementación.
No modifiques ningún archivo todavía.El objetivo no es hacer más burocrático el proceso.
Es hacer que el momento más barato para cambiar de opinión ocurra antes de escribir código.
El circuito queda así:
Para cambios pequeños, podés saltarte la planificación.
Si podés explicar el cambio en una oración y sabés exactamente dónde tocar, probablemente no necesitás un plan.
Pero cuando el cambio toca varios archivos, tiene casos borde o no conocés bien el código, planificar primero suele ser mucho más barato que corregir después.
Esta es probablemente la pieza más importante de todas.
Claude puede llegar a un punto donde el trabajo parece terminado.
Pero "parece terminado" no es una condición verificable.
Y si no existe una forma objetiva de comprobarlo, alguien tiene que hacerlo.
Ese alguien terminás siendo vos.
La solución es darle al agente una señal que pueda devolver:
pasa o falla.
Por ejemplo:
La diferencia está en cómo escribís la tarea.
En vez de:
"Implementá una función que valide emails."
Podés decir:
Implementá validateEmail.
Debe aceptar:
- user@example.com
Debe rechazar:
- invalid
- user@.com
Escribí los tests y corrélos después de implementar.
Si algún test falla, investigá la causa, corregila
y volvé a correrlos.Ahora Claude no tiene que preguntarse qué significa "terminado".
Tiene una condición.
Hay otra idea importante:
el que escribió el código es un mal juez de su propio código.
Claude no es la excepción.
Viene sesgado por el razonamiento que produjo el cambio.
Por eso una segunda revisión con contexto limpio puede encontrar problemas que el primer proceso pasó por alto.
Claude Code incluye herramientas para hacer este tipo de revisión.
Por ejemplo:
/code-reviewTambién podés hacer una revisión contra una especificación concreta:
Usá un subagente para revisar el diff contra SPEC.md.
Verificá que cada requisito esté implementado,
que los casos borde tengan test y que no se haya
tocado nada fuera del alcance.
Reportá huecos de implementación, no preferencias de estilo.La clave está en pedirle que busque errores relevantes, no que encuentre problemas porque sí.
Un revisor al que le pedís "encontrá problemas" va a encontrar problemas aunque el trabajo esté bien.
Por eso hay que definir qué cuenta como problema.
"Listo, funciona."
Eso no es evidencia.
La evidencia es:
Esto importa especialmente cuando dejás una sesión trabajando sin supervisión.
Porque revisar evidencia es mucho más rápido que volver a comprobar todo vos.
Y hay un detalle que suele pasarse por alto:
las pruebas más importantes muchas veces son las que comprueban lo que NO debería pasar.
Que un usuario no pueda acceder a los datos de otro.
Que el sistema no invente información que no tiene.
Que una acción no ocurra cuando falta una condición.
Esos errores son peligrosos justamente porque muchas veces no rompen nada visible.
El sistema sigue funcionando.
Solo que funciona mal.
Hasta acá tenemos:
Falta una última pieza:
que la verificación ocurra automáticamente.
Hay distintos niveles para hacer esto.
Podés incluirlo directamente en el pedido:
Implementá esto.
Corré los tests.
Si fallan, investigá la causa, corregila
y volvé a correrlos hasta que pasen.
No des por terminada la tarea hasta que
todos los tests relevantes estén verdes.No necesitás montar una infraestructura compleja para empezar.
De hecho, para muchísimas tareas esto ya resuelve gran parte del problema.
Claude Code también permite definir condiciones de finalización para una sesión.
La idea es sencilla:
no termina porque Claude cree que terminó.
Termina cuando se cumple la condición que definiste.
Los hooks permiten ejecutar acciones automáticamente en determinados momentos.
Por ejemplo:
Después de cada edición, corré el linter.
O:
No permitas terminar el proceso si los tests no pasan.
Esta diferencia es importante.
Un archivo como CLAUDE.md contiene instrucciones que Claude debe seguir.
Un hook puede convertirse en una condición automática del sistema.
Lo que escribís como instrucción es una regla.
Lo que automatizás como hook es una barrera.
Todo lo que tenga que ocurrir siempre, sin excepciones, merece evaluar si debería estar automatizado.
Hay una idea equivocada alrededor de los agentes:
"Quiero que haga todo solo."
Ese no debería ser el objetivo.
El objetivo es otro:
que sepa cuándo puede seguir solo y cuándo tiene que llamarte.
Un buen sistema no intenta eliminar a la persona.
Elimina el trabajo que no necesita a la persona.
Por ejemplo:
Objetivo
↓
Claude investiga
↓
Claude planifica
↓
Claude implementa
↓
Claude verifica
↓
¿Cumple?
├── No → corrige → vuelve a verificar
│
└── Sí → propone el cambio
↓
Vos revisás
↓
MergeEse es el cambio importante.
No pasás de "hacer código manualmente" a "dejar que una IA haga código".
Pasás de:
persona → cada paso → persona → cada paso
a:
objetivo → sistema → resultado → decisión humana cuando hace falta
Pensá en esto.
Le das a Claude una tarea antes de levantarte de la computadora.
No le decís exactamente qué archivo tiene que tocar.
No le dictás veinte pasos.
Le explicás el resultado que necesitás.
Claude investiga.
Planifica.
Implementa.
Corre los tests.
Detecta un error.
Lo corrige.
Vuelve a probar.
Prepara el cambio.
Y recién entonces te necesita.
No porque se haya quedado esperando.
Porque llegó al único punto donde realmente hace falta una decisión humana.
Ese es el objetivo.
No tener una IA que trabaje mientras vos la mirás.
Tener un sistema que pueda trabajar aunque vos no estés mirando.
El principio es mucho más grande que Claude Code.
Pensá en cualquier proceso de tu negocio:
Si una persona tiene que empujar manualmente cada uno de esos pasos, esa persona es el sistema.
Y cuando esa persona no está, el sistema se detiene.
La autonomía aparece cuando el criterio que hoy está en la cabeza de alguien pasa a estar escrito, automatizado y verificable.
Eso es lo que hace posible que un proceso trabaje solo y te llame únicamente cuando hay una decisión que tomar.
No necesitás un agente que haga todo. Necesitás un sistema que sepa cuándo puede seguir solo y cuándo tiene que llamarte.
Git hace que equivocarse sea barato.
La planificación define qué hay que hacer.
La verificación define qué significa hacerlo bien.
Y el loop permite que el sistema continúe sin que vos tengas que empujarlo en cada paso.
Claude es una pieza.
El sistema es el producto.
Probablemente ya tengas procesos que todavía dependen demasiado de vos.
No hace falta automatizar todo. Primero hay que encontrar qué parte del proceso hoy requiere intervención humana, por qué la requiere y qué tendría que pasar para que pudiera ejecutarse sola.
Eso es lo que hacemos en Scalability Systems: diseñamos y construimos sistemas comerciales que reducen la dependencia de la operación manual y hacen que el negocio pueda avanzar sin que tengas que estar encima de cada paso.
Esta es solamente la primera parte.
Los loops autónomos dan para mucho más: hooks y eventos, corridas sin supervisión, claude -p, trabajo en paralelo sobre cientos de archivos y distintas formas de dejar agentes trabajando en horarios definidos.
Pero antes de automatizar más cosas, hay una pregunta que importa mucho más:
¿Qué proceso debería poder funcionar aunque vos no estés ahí?
Todo lo técnico de esta guía está basado en la documentación oficial de Claude Code:
Las funciones de Claude Code cambian rápido. Si algo de esta guía no coincide con la versión que estás usando, la documentación oficial manda.