AI-SDLC de Anthropic: nuestras convicciones sobre el ciclo de desarrollo de productos en la era de la IA

Del código al método: Anthropic presenta su visión de la ingeniería de software basada en IA a través de una guía en seis etapas y comparte abiertamente sus propias configuraciones. Lo interesante es que se aleja de la documentación funcional clásica de un producto para centrarse en el proceso. Analizamos paso a paso un cambio de paradigma que está poniendo patas arriba el ciclo de vida de desarrollo de software (SDLC) tradicional.

En el momento de escribir este artículo, el diagnóstico es ya prácticamente unánime: el código ha dejado de ser el cuello de botella.

Los PRD, los rituales de estimación o las revisiones de seguridad del producto existen porque la fase de build dura semanas, por lo que hay que crear un conjunto de rituales que garanticen que ese tiempo de desarrollo se utiliza de la mejor manera posible. Pero, si el build pasa a durar apenas unas horas, todo ese proceso pierde su sentido. Sin embargo, no desaparece por completo, sino que se traslada a las etapas que aún funcionan a ritmo humano. Sin embargo, no desaparece por completo: se desplaza hacia las etapas que todavía avanzan a velocidad humana. Pensemos, por ejemplo, en la seguridad: un equipo de seguridad está dimensionado para un volumen de trabajo humano y cuando los agentes multiplican el volumen de código, o bien la cola de revisión se alarga o bien el código llega a producción sin haber sido revisado suficientemente.

Este playbook de Anthropic formaliza esta evolución del proceso, pasando de un modo secuencial con "puertas de control" humanas a un auténtico bucle en el que el paso entre las etapas se realiza de forma mucho más fluida, rápida y automatizada. Para quienes llevamos años trabajando en Producto, es casi un sueño hecho realidad. Todos hemos imaginado alguna vez ese bucle de feedback prácticamente permanente sin haber conseguido nunca implementarlo de verdad.

Su respuesta se resume en seis etapas, desde la planificación hasta el mantenimiento. Hay un hilo conductor: cada paso termina escribiendo un archivo en el control de versiones, la siguiente comienza leyéndolo y la sucesión de commits sirve como pista de auditoría.

Este es nuestro análisis de cada una de estas etapas.

• Plan: el archivo de intención y lo que debería precederlo
• Diseño: el fin de la barrera entre las necesidades y el diseño
• Desarrollo: las skills por un lado, las sesiones paralelas por otro
• Test: la calidad del código no es la del producto
• Despliegue: la gobernanza se convierte en código
• Mantenimiento: un bucle que supervisa el funcionamiento del sistema
• Lo que el playbook no hará por ti

Plan: el archivo de intención y lo que debería precederlo

En Anthropic, todo empieza con un documento de intenciones. A alguien se le ocurre una idea, llega un ticket o se activa una alerta, y esa persona habla con el agente en lugar de buscar un hueco con el equipo de producto. De esa conversación sale un texto breve escrito con sus propias palabras, que el Product Owner —el término que utiliza Anthropic en su artículo, aunque también podríamos hablar de Product Manager o Product Builder— revisa y corrige antes de hacer commit: el problema, el resultado esperado, los usuarios y sistemas afectados, las restricciones y las preguntas abiertas. Lo que antes requería varias semanas de recopilación y refinamiento puede resolverse ahora en unas horas.

En el ciclo tradicional, quien detecta un pain point tiene que encontrar a alguien que le ayude a documentarlo, y el texto que finalmente llega a Engineering está ya a varios intermediarios de distancia de lo que esa persona quería expresar originalmente. Aquí, quien plantea la necesidad sigue siendo su autor. El equipo de producto tiene la última palabra, pero actúa como árbitro en lugar de convertirse en mero escribano.

En cambio,  hay algo que el playbook no contempla en ningún momento: comprobar que el problema realmente existe. Su único indicador de calidad para esta etapa es la tasa de supervivencia de las ideas, es decir, la proporción de aquellas que el equipo de producto acepta en lugar de descartar. El criterio se centra en el consentimiento de una persona, no en la existencia de la necesidad. Sin embargo, nada impide confiar a los agentes una parte del trabajo de discovery, análisis de verbatims o síntesis de entrevistas: el playbook, simplemente, no entra en ello.

En la práctica, esta omisión sale cara. Pierre Sur, Product Builder en Thiga, pasó seis meses en una empresa de MedTech y extrajo de esa experiencia un aprendizaje principal: unas especificaciones imprecisas dan lugar a código que funciona pero que no sirve para nada, mientras que unas prioridades mal definidas dan lugar a funcionalidades inútiles, entregadas en unas horas en lugar de en unas semanas. Por el contrario, un PRD alimentado con perfiles de usuario, casos límite e historias de usuario extraídas de entrevistas reales le proporcionó un prototipo viable desde la primera iteración.

Diseño: el fin de la barrera entre las necesidades y el diseño

Su segunda etapa derriba la barrera entre las necesidades y el diseño. El agente lee la intención validada y elabora unas especificaciones: recorrido del usuario, contratos de API, modelo de datos, criterios de aceptación. Trabaja bajo las restricciones de las skills que rigen las reglas de marca, seguridad, cumplimiento normativo y experiencia de usuario. Producto revisa sin escribir, se centra primero en los puntos que el agente ha señalado como problemáticos, toma las decisiones necesarias junto con los responsables de las políticas implicadas y decide si se pasa a la fase de build. Cabe señalar que el playbook mantiene toda la nomenclatura clásica —Product Owner, tech lead, platform engineer—: redistribuye las tareas entre los roles existentes sin plantear en ningún momento que estos puedan fusionarse, mientras que el debate sobre las fronteras entre Forward Deployed Engineer, Product Engineer y Product Builder parte precisamente de la hipótesis contraria.

Esta separación, la que existe entre la persona que escribe lo que hay que hacer y la que diseña cómo hacerlo, tenía sus razones en términos de responsabilidad. También resultaba lenta y costosa: el analista formalizaba la necesidad, el diseñador la traducía de nuevo en una experiencia de usuario, y se necesitaba un ida y vuelta adicional cada vez que la traducción se alejaba de la intención inicial. Producir ambas cosas en la misma sesión elimina ese traspaso y, con él, la pérdida de información.

La elección que hace Anthropic del artefacto sobre el que se toma la decisión resulta más discutible. La secuencia intención, spec, plan, diff y pull request es limpia y auditable, y el markdown tiene una ventaja clara: un diff de una spec puede revisarse igual que un diff de código, de modo que las necesidades pasan por el mismo circuito de revisión que la implementación. El playbook también contempla el prototipo y le reserva un lugar: el de un front-end prototipado a partir de la intención antes de exportarlo al agente de código.

El enfoque puede situarse en otro lugar. La especificación establece el marco y proporciona al agente lo necesario para producir, pero la decisión puede basarse igualmente en algo que funcione, conectado a los módulos del sistema de información y construido con los componentes de interfaz propios de la empresa: un Product Owner (o más bien un Product Builder en este caso) no defiende lo mismo ante su comité cuando llega con un documento validado que cuando presenta un objeto que se puede probar y que funciona como prueba de concepto.

Desarrollo: las skills por un lado, las sesiones paralelas por otro

Es la etapa más desarrollada del documento y contiene varias ideas interesantes.

La mejor de ellas son las skills. El principio es el siguiente: tomar una regla que hoy se aplica de manera desigual (por ejemplo, un estándar de seguridad o una convención de API), escribirla en un archivo cuyo encabezado indique cuándo debe activarse, guardarla en el repositorio o distribuirla a toda la organización y hacer que cada evolución sea validada por el responsable de esa política, igual que validaría código. El conocimiento deja así de estar únicamente en la cabeza de tres personas y el agente lo aplica sin necesidad de recordárselo en cada sesión. 

Anthropic es sincero sobre esta limitación, algo que no es tan habitual. Una skill sigue siendo un mecanismo de control orientativo: hace más probable que se aplique la regla durante la escritura del código, pero nada obliga a una sesión a cumplirla. Para una política que debe cumplirse sin excepciones, se necesita un mecanismo determinista detrás, un hook que bloquee  la acción o una fase de revisión que vuelva a comprobar su cumplimiento. ¡Pocos proveedores de frameworks reconocen por escrito que su componente principal no garantiza nada!

El ecosistema de código abierto, por su parte, se queda corto. Pierre Sur dedicó una semana a BMAD al inicio de su proyecto, de las cuales seis horas las empleó en la configuración para dar a luz un PRD genérico de calidad media. Su conclusión sobre los frameworks disponibles en el mercado, ya sea BMAD, OpenSpec o Speckit: todo se limita al código generado; nadie habla de tests, de validación de calidad ni de monitorización. Al final, acabó creando sus propios componentes, adaptados a las limitaciones del proyecto.

La parte cuestionable es el trabajo en paralelo. Cada sesión se ejecuta en su propio espacio de trabajo de Git, aislada de las demás, y lo único que comparten es el ingeniero que las dirige. Anthropic recomienda empezar con dos o tres, estableciendo como límite el número de flujos que una persona sea capaz de revisar correctamente. El trabajo pasa a convertirse en una tarea de orquestación.

Aunque Anthropic mantiene un límite —la capacidad de revisión de cada persona—, la productividad individual se dispara en este modelo. Sin embargo, esto no debe interpretarse como una invitación a reducir un equipo a una sola persona. Si bien el tamaño de los equipos puede reducirse, ciertas competencias deben seguir estando representadas en ellos, especialmente en el caso de productos críticos.

Por ejemplo, en una herramienta interna para generar datos de demo destinados al equipo comercial, sin legacy ni grandes riesgos asociados, un Product Builder por sí solo puede sacar adelante un producto en cuestión de días. Pero en el backoffice MedTech en el que trabajó Pierre Sur, con diez años de código existente y unas exigencias de fiabilidad superiores a las de velocidad, la configuración adecuada era un PM acompañado de dos desarrolladores con experiencia en IA. Para un producto de este tipo, el equipo de una sola persona sigue siendo una utopía.

Test: la calidad del código no es la del producto

Anthropic reubica los controles de calidad. En el ciclo tradicional, estos se realizaban al final de cada etapa: el código está terminado, se prueba, se valida y se pasa a la siguiente fase. En su propuesta, la evaluación se integra en la implementación. El desarrollador escribe la prueba junto con el código, y el indicador de referencia pasa a ser el porcentaje de cambios que se aprueban a la primera. Una especie de «Desarrollo Impulsado por la Evaluación», por así decirlo (lo que resultará familiar a los amantes del TDD).

El principio tiene todo el sentido. Las verificaciones al final del proceso eran una herencia de una época en la que realizar esos controles resultaba costoso: se agrupaban las comprobaciones para amortizar el esfuerzo que suponía movilizar a un equipo de QA. Ese cálculo deja de tener sentido cuando el agente escribe el test al mismo tiempo que la funcionalidad.

Donde el playbook deja una zona gris es en lo que entiende por calidad. Todo lo que mide se refiere al código: la prueba se supera, la cadena de integración está en verde, el cambio supera la revisión a la primera. El problema es que un producto puede cumplir las tres condiciones y, aun así, fallar por completo en su objetivo. En los productos basados en LLM, esta limitación resulta todavía más evidente, ya que la fiabilidad en producción depende en gran medida de la capa que rodea al modelo, que es precisamente a lo que hace referencia el harness engineering.

En TheFork, la funcionalidad de búsqueda con IA superó todas las pruebas técnicas a la primera. Fue en las entrevistas con los usuarios cuando los equipos descubrieron el verdadero problema: la gente no entendía por qué se les proponía un restaurante concreto. La solución: mostrar una foto o un fragmento de una reseña que justificara el resultado (no formaba parte de ninguna prueba automatizada). Ninguno de los indicadores del playbook habría permitido detectarlo.

Despliegue: la gobernanza se convierte en código

Es la etapa en la que el playbook entra con mayor profundidad en la implementación.

El mecanismo se basa en uno de los artefactos clave de Claude: los hooks. Estos interceptan la acción del agente antes de que se produzca y emiten un veredicto: autorizado, sujeto a aprobación o bloqueado, indicando el motivo y el procedimiento a seguir para obtener luz verde. Los hooks de equipo residen en el repositorio y se leen como si fueran código. Los que no son negociables residen en ajustes administrados que el ingeniero no puede desactivar. Su configuración típica para una empresa regulada impide la lectura de archivos de secretos, bloquea el acceso a la red desde la línea de comandos, evita que el agente se inicie si el sandbox no puede inicializarse y solo admite extensiones distribuidas a través del marketplace interno. El principio que articula todo el sistema es sencillo: el agente llega hasta la puerta de producción, pero no la cruza.

El hook obliga a detenerse porque es el único mecanismo del playbook que abandona el terreno probabilístico. Una skill hace probable que una regla se aplique; una eval mide a posteriori con cierto margen de tolerancia. Un hook, en cambio, es código que se ejecuta antes de la acción y emite un veredicto binario. De hecho, Anthropic señala que, cuando una política debe cumplirse sin excepción, una skill no es suficiente: necesita un hook detrás. La investigación académica también ha empezado a abordar esta cuestión, con trabajos que buscan expresar estas fronteras entre humanos y agentes mediante protocolos ejecutables.

La revisión sigue la misma lógica de superposición de capas. Varios agentes revisan el mismo diff con objetivos diferentes —seguridad, rendimiento o estilo— y la persona solo interviene sobre aquello que queda pendiente. El playbook especifica además que el agente no revisa su propio trabajo, evitando así ese punto ciego.

Este nivel de detalle cambia algo muy concreto para las organizaciones sujetas a fuertes restricciones. El backoffice MedTech en el que trabajó Pierre Sur exigía una trazabilidad completa mediante un registro de auditoría, pseudonimización por defecto y una gestión granular de los permisos. Al no encontrar estas capacidades en los frameworks disponibles en el mercado, fue necesario desarrollar los guardrails manualmente, proyecto a proyecto, sin ninguna garantía de que se mantuvieran de una sesión a otra. Ese es precisamente el vacío que vienen a cubrir los hooks y las configuraciones administradas.

Mantenimiento: un bucle que supervisa el funcionamiento del sistema

La última etapa es la más ambiciosa del documento. Un script determinista supervisa una métrica de la que conoce la media móvil y activa al agente en cuanto se supera el margen de control. Con una desviación estándar, simplemente lo registra. Con dos, el agente realiza un diagnóstico en modo de solo lectura. Con tres, propone una corrección mediante una pull request. El bucle se cierra sobre sí mismo: cualquier desviación detectada en producción vuelve a la etapa Plan en forma de intención y el ciclo comienza de nuevo.

El mecanismo es ingenioso y los umbrales progresivos evitan la trampa de que el sistema entre en pánico ante el primer contratiempo. La cuestión es qué le pedimos que monitorice. Los tres ejemplos que cita el playbook —tasa de fallos en los tests, tasa de errores del servidor después del despliegue y tiempo de ciclo de las pull requests— miden en realidad lo mismo: la salud técnica de la cadena de producción. Un producto puede mantener los tres indicadores en verde durante meses mientras pierde usuarios sin que nada dentro del bucle llegue a detectarlo.

Hay otra desviación que también escapa a esta monitorización y, en este caso, el playbook no puede escudarse en una cuestión de alcance, porque forma parte del propio ciclo de desarrollo: el coste de funcionamiento. Un producto que incorpora llamadas a modelos puede ver cómo su factura cambia por sí sola. Basta con que un prompt de sistema acumule más contexto con cada iteración o que el uso se dispare para que el gasto mensual vaya aumentando sin que falle ningún test ni aparezca ningún error de servidor.

Y, sin embargo, es exactamente el tipo de señal que su sistema de bandas de control podría gestionar muy bien: una media móvil, un umbral y un agente que investiga de dónde procede la desviación. El playbook no lo propone en ningún momento y, en las cinco etapas anteriores, ninguno de sus indicadores habla en euros.

Lo que el playbook no hará por ti

Mientras que los frameworks open source se detienen en el código generado, este llega hasta los archivos de configuración, los hooks que bloquean una acción antes de que se produzca y las configuraciones que un ingeniero no puede eludir. Las organizaciones sujetas a fuertes restricciones encontrarán aquí mecanismos para permitir que los agentes trabajen sin renunciar a la trazabilidad, algo que hace apenas un año no estaba ni mucho menos garantizado.

Su propio título deja claro cuál es su límite: software development lifecycle. Un ciclo de desarrollo de software comienza cuando sabemos qué construir y termina cuando está en producción. Nadie espera que un manual de desarrollo haga discovery, y reprochárselo al playbook sería injusto. El riesgo está en otra parte: en quien lo interprete como un modelo operativo completo, porque tiene la estructura y la aparente exhaustividad necesarias para parecerlo.

En Club Med, donde Thiga desplegó agentes en los equipos de Producto y Tech, no se implementó nada antes de entrevistar a los equipos y observar sus rituales para identificar dónde estaban realmente los puntos de fricción. Después, se mapearon los procesos y se evaluaron según su complejidad y recurrencia. Solo entonces llegaron los workshops de priorización. Las tareas de contenido y documentación pasaron de requerir entre tres y cinco días a resolverse en media jornada. Ninguna de las seis etapas del playbook describe este trabajo y, sin embargo, fue precisamente lo que determinó hacia dónde debían dirigirse los agentes.

Las seis etapas funcionan. La pregunta que nunca plantean es si aquello que vamos a construir merece realmente la pena. Y esa pregunta sigue intacta una vez adoptado el playbook.