Anthropic ha publicado un documento que se sale de su registro habitual: en vez de anunciar un modelo o una función, plantea cómo debería ser un ciclo de vida del desarrollo de software diseñado alrededor de agentes de IA en lugar de simplemente adaptado a ellos. Es material de proceso, no de producto, y llega en un momento en el que buena parte del sector ya ha metido asistentes en su día a día sin haberse parado a revisar si las fases de trabajo siguen teniendo sentido tal y como estaban.
La diferencia entre usar agentes y diseñar para agentes
La distinción que sostiene el planteamiento es más importante de lo que parece. Lo que casi todos hacemos hoy es coger un ciclo de desarrollo pensado para humanos —analizar, escribir, revisar, probar, desplegar— y meter un asistente dentro de la casilla de «escribir». El resultado es que se acelera un tramo del proceso y se atascan todos los demás: se genera código mucho más rápido del que nadie puede revisar, las pruebas se quedan cortas porque se escribieron pensando en otro volumen, y la documentación envejece a una velocidad que antes no existía.
Diseñar para agentes significa aceptar que si una fase se vuelve casi gratuita, el cuello de botella se muda a otra parte y hay que rediseñar allí. No es una idea nueva en gestión de procesos, pero aplicada al desarrollo tiene consecuencias muy concretas: la revisión deja de ser un trámite final y se convierte en la actividad central; las pruebas dejan de ser una tarea que se posterga y pasan a ser el mecanismo que hace seguro delegar; y la especificación de lo que hay que hacer gana peso, porque es lo único que un agente no puede inventarse por ti.
Cuando escribir código deja de ser lo caro, el cuello de botella se muda a revisarlo. Ese es el trabajo que hay que rediseñar.
Las fases que más se mueven en la práctica
Sin necesidad de suscribir ningún marco concreto, cualquiera que lleve unos meses trabajando con Claude Code reconoce dónde se han desplazado los pesos de su propio trabajo:
- La especificación se vuelve el trabajo caro. Explicar bien qué hay que construir, con qué restricciones y qué está fuera de alcance, es hoy el paso que más determina el resultado final.
- La revisión se convierte en la habilidad crítica. Leer código ajeno rápido y con criterio, detectando lo que parece correcto pero no lo es, importa más que la velocidad escribiendo.
- Las pruebas pasan a ser infraestructura de confianza. Sin una suite decente, delegar es apostar; con ella, delegar es rutina.
- La documentación cambia de destinatario. Ya no la lee solo el equipo: la lee el agente en cada sesión, y eso convierte un archivo de contexto desactualizado en una fuente activa de errores.
Ese último punto es el que más subestima la gente. Un fichero de instrucciones de proyecto que describe una arquitectura que ya cambió no es documentación obsoleta e inofensiva: es una instrucción equivocada que el agente aplicará con toda la diligencia del mundo cada vez que abras una sesión.
Un documento para equipos grandes, un lector que suele ir solo
Conviene decir con claridad para quién está escrito este tipo de material. Un playbook de ciclo de vida asume una organización con roles repartidos, revisiones cruzadas y responsables distintos en cada fase; es decir, una empresa de producto. El freelance o el estudio de dos personas que lee esto no tiene esa estructura, y trasladar el documento tal cual sería un ejercicio de burocracia inútil.
La traducción útil consiste en quedarse con el mecanismo y descartar el organigrama. Si eres tú quien escribe, revisa y despliega, el riesgo no es la falta de proceso: es que las tres funciones las hace la misma cabeza y en el mismo rato. Ahí es donde separar los roles artificialmente —revisar en otro momento, con otra sesión limpia, o delegar la revisión a un subagente que no tenga el contexto de haber escrito el código— aporta más que cualquier plantilla.
Por dónde empezar sin rehacer tu forma de trabajar
La tentación con un documento así es leerlo, asentir y no cambiar nada, que es lo que pasa con la mayoría de los marcos de trabajo. Para que sirva de algo conviene bajarlo a dos o tres decisiones pequeñas y verificables. Documentar el proyecto pensando en que lo va a leer un agente, no un compañero: rutas, convenciones, qué no se toca. Poner una barrera de verificación antes de que nada llegue al cliente, aunque sea un único paso automático. Y ser honesto sobre el tamaño de las tareas que se delegan, porque el fallo más común no es que el agente escriba mal, es que se le pidió demasiado de una vez sin ningún punto de control por el camino.
La implicación práctica para quien factura por proyecto es directa y afecta al presupuesto, no solo al código. Si la parte cara del trabajo se ha desplazado de escribir a especificar y revisar, seguir presupuestando por horas de programación es medir la parte del proceso que se ha abaratado e ignorar la que se ha encarecido. Ese es el ajuste incómodo que ningún playbook corporativo va a hacer por ti, y probablemente el más rentable de los que salen de leerlo.
