Claude Code en equipo: qué cambia cuando el agente vive en la terminal

Los agentes de código en terminal han cambiado la forma de una jornada más de lo que lo hizo el autocompletado del editor, y no por el motivo que se esperaba. Que se escriba código nuevo más rápido está bien. El cambio que importa es que ahora se hace una clase de trabajo que antes no hacía nadie: la migración que toca doscientos ficheros, la batería de pruebas del módulo que todos evitaban, la investigación de por qué un servicio va lento que antes exigía una tarde libre.

Esto es lo que hemos aprendido usándolos en un equipo de consultoría y en varias bases de código de clientes.

Dónde las ganancias son de verdad grandes

Cambio mecánico a escala. Renombrar un concepto en todo un repositorio, migrar una API obsoleta, añadir un parámetro a lo largo de una cadena de llamadas. Siempre se pudo y nunca compensaba una semana de una persona. Un agente lo hace en una hora y, sobre todo, hace el aburrido fichero ochenta con el mismo cuidado que el primero.

Entender código ajeno. Aterrizar en la base de código de un cliente y preguntar qué pasa cuando una petición llega a este endpoint ahorra los dos primeros días de cada proyecto. Es el uso de más valor en consultoría y no implica escribir nada de código.

Pruebas del comportamiento existente. Pruebas de caracterización alrededor de un módulo heredado, generadas desde el código y ejecutadas después para demostrar que pasan. Es trabajo de mucho volumen, poca creatividad y con una comprobación automática de corrección, que es exactamente la forma en la que los agentes son buenos.

La tarea que te habrías saltado. Arreglar la prueba inestable, escribir el runbook, limpiar los logs. El coste marginal del mantenimiento pequeño bajó lo suficiente como para que ese trabajo ocurra.

Dónde está sobrevendido

En todo lo que exija una decisión que no has tomado. Un agente implementará encantado la arquitectura que insinuaste vagamente, a fondo y en la dirección equivocada. El fallo no es código malo: es un volumen grande de código coherente comprometido con una premisa que nadie examinó. Dedicar diez minutos a escribir el enfoque antes de empezar es el hábito con más retorno de todos.

También todo aquello donde falta el bucle de realimentación. Los agentes son más fuertes donde pueden ejecutar algo y verlo fallar: pruebas, comprobación de tipos, un linter, una build. En una base de código sin pruebas ejecutables la calidad de la salida cae en picado, y la lectura honesta es que el agente vale lo que vale tu integración continua.

Lo que tuvimos que cambiar

La revisión pasó a ser la restricción, así que la revisión tuvo que cambiar. El tamaño de los diffs subió; la atención del revisor no. Partimos la revisión en dos preguntas hechas por separado —¿es este el cambio correcto? y ¿es correcto este cambio?— y movimos la primera antes, a un plan escrito previo al código. Las puertas de revisión para código escrito por agentes es la versión larga.

Los ficheros de contexto se ganaron el sueldo. Un CLAUDE.md en la raíz que describa los comandos de build, la estructura y las tres convenciones locales elimina casi toda la corrección repetida. Hoy es el fichero con más apalancamiento del repositorio; escribimos sobre qué va dentro.

Los permisos necesitaron una política. Un agente que puede ejecutar shell arbitraria en un repositorio con credenciales cloud en el entorno es un incidente de producción esperando a un mal día. Los nuestros corren contra roles cloud de solo lectura por defecto, y las escrituras pasan por la tubería de siempre.

Dejamos de contar líneas. Cualquier métrica basada en volumen se quedó sin sentido en una semana. Lo que medimos ahora es el tiempo de ciclo desde el problema hasta el cambio integrado, y la tasa de defectos después de integrarlo.

Lo que cuesta, con franqueza

Por ingeniero es una suscripción de decenas de euros al mes, o facturación por uso que en días intensos sube. Frente al coste cargado de un ingeniero es ruido, y la pregunta no es el precio sino si existe capacidad de revisión para absorber la salida. En equipos donde un sénior revisa todo, el agente convierte a esa persona en el cuello de botella y al equipo en algo más lento. Es un modo de fallo real y es organizativo, no técnico.

Qué hacer esta semana

Coge la tarea de mantenimiento que todos llevan dos meses aplazando —la actualización de dependencias, las pruebas que faltan, el código muerto— y dásela a un agente con una descripción escrita y clara de qué significa terminado. Es una tarea de poco riesgo, tiene una comprobación natural de corrección y te dirá más sobre si la herramienta encaja en tu código que cualquier benchmark.