Lo que se hace en media hora, ¿por qué el proyecto sigue atascado?
Son las once de la noche y tienes la mirada clavada en la terminal. El Agent acaba de terminar de escribir el código de una función, y también corrió las pruebas; cuando aparece el mensaje, miras la marca de tiempo: media hora. La semana pasada, tu equipo había programado tres días completos para lo mismo.
Justo cuando estás por apagar el ordenador e irte, el móvil muestra una notificación: en la lista de requisitos pendientes todavía hay ocho tickets que nadie ha tocado, y el Pull Request de ayer tampoco lo ha revisado nadie. De pronto te das cuenta de algo: lo único que se aceleró fue el tramo de "escribir código"; todos los demás tramos siguen exactamente igual.
Este es justamente el problema que Boris Cherny, creador de Claude Code, y el equipo de Anthropic quisieron señalar directamente al hacer público recientemente un "playbook del ciclo de vida de desarrollo de software (SDLC) nativo de IA". El youtuber Rob Shocks desglosó este documento en su canal, y la frase central es: el código ya no es el cuello de botella; tu proceso sí lo es.
El "doble de velocidad" es real, pero solo ocurre en un lugar
El ciclo de vida de desarrollo de software tradicional luce así: planificación, diseño, construcción (build), pruebas (test), despliegue (deploy) y mantenimiento (maintenance); al terminar una vuelta, se regresa al punto de partida para recibir la siguiente función, el siguiente bug, el siguiente lanzamiento.
Antes de que aparecieran los Agents, el tramo de "build" (construcción) era casi siempre el más largo y el más costoso. Después de la aparición de los Agents, este tramo se comprimió enormemente; según Rob Shocks, equivale al doble de velocidad. El problema es que ni la planificación, ni el diseño, ni las pruebas, ni la revisión, ni el mantenimiento se aceleraron junto con él. Y justo esa es la pregunta que este documento de Anthropic quiere responder: si el Agent nos ayudó a comprimir el "build", ¿cómo rediseñamos con Agents cada uno de los demás tramos?
De "reunirse para recoger requisitos" a "discutir con el Agent hasta llegar a un acuerdo"
Empecemos por la fase de planificación. La forma tradicional es sentarse a reunirse, recoger requisitos, escribir un PRD, organizar talleres y alinearse ronda tras ronda con las partes interesadas.
En el nuevo flujo que describe Anthropic, el primer paso se invierte: primero dejas que el Agent te entreviste una y otra vez, para que pregunte con claridad qué función quieres construir, qué bug quieres arreglar, o cómo debería verse el producto completo, y así construya un contexto íntegro. Rob Shocks menciona que él mismo usa un skill de exploración llamado "Switch Dimension Discovery", y también señala que existen otras opciones en el mercado, como "Realm" de Matt Pocock, o el "Requirements Discovery" integrado en Cursor —las herramientas pueden variar, pero el objetivo es el mismo: dejar que el Agent siga preguntando hasta que realmente entienda lo que quieres. Lo que a ti te toca hacer es volcar en esa conversación, en la medida de lo posible, tu propia experiencia, tu comprensión del dominio y todo el contexto relevante.
A continuación, el Agent organiza y sintetiza los puntos de dolor extraídos de esa conversación, y los escribe en un archivo: intent.md. Lo especial de este archivo es que las personas pueden leerlo y entenderlo, y a la vez las máquinas pueden actuar directamente sobre él (human-readable and machine-actionable).
En el SDLC tradicional, una idea primero se convierte en una historia de usuario dentro de la lista de tareas pendientes, se le asignan puntos de historia, y pasa por varias transferencias antes de que alguien finalmente ponga manos a la obra. En el mundo que describe Anthropic, en cambio, cualquier persona que plantee un tema —ya sea un cliente que reporta un bug, un product manager con una idea de nueva función, o un ingeniero que quiere dejar constancia de una mejora de proceso— puede hacer una lluvia de ideas directamente con Claude y convertir el resultado en un intent.md. La implementación real es sencilla: se crea en el proyecto una carpeta llamada `intent`, y ahí se guarda cada intent.md.
Una vez escrito el archivo, el trabajo no termina ahí. La persona que planteó esa intención (a quien Anthropic llama originator) debe revisar lo que el Agent redactó, para confirmar que ambas partes entendieron lo mismo —el originator no tiene por qué ser un experto del equipo; cualquiera puede desempeñar ese papel. Después, estos intent.md dispersos se reúnen en algo parecido a una lista de tareas pendientes, ya sea como archivos markdown individuales o organizados en Notion o Linear, y el responsable de producto los prioriza; incluso se le puede encargar al Agent una clasificación inicial, etiquetándolos como frontend/backend, tamaño de la tarea, tipo de función o nivel de prioridad.
intent.md es solo el primer paso: una línea de producción llamada "artifact chain"
Una vez aprobado el intent.md, el flujo avanza a la siguiente estación: spec (especificación). Anthropic recomienda que, en cuanto se confirme el intent, se use un hook o un proceso fijo para disparar automáticamente la generación del spec, y ofrece un prompt de ejemplo: leer el intent.md adjunto, producir una especificación de requisitos y diseño, aplicar los skills disponibles para planificar cumpliendo con las guías de marca, y escribirlo íntegramente en spec.md. Aquí no hay una respuesta estándar única: puedes usar directamente el plan mode integrado de Cursor, Claude Code o Codex, o bien construir tú mismo un skill de generación de spec con el estilo propio de tu equipo.
El siguiente paso es plan: el ingeniero alimenta el intent y el spec juntos al Agent, entra en plan mode, y produce un plan.md. Anthropic sugiere que en este paso se cuestione el plan a la inversa: preguntarle "qué cambios podrían salir mal". El objetivo es que el plan.md quede tan completo que, aunque se entregue de forma aislada a otro ingeniero, esa persona pueda ejecutarlo directamente sin necesidad de volver a mirar el intent ni el spec. Esto es especialmente importante porque Rob Shocks advierte algo concreto: todo este flujo nunca lo lleva a cabo un solo Agent de principio a fin —distintas fases son atendidas por distintos Agents, incluso por distintos hilos de conversación (context window)—, así que debes tratar el intent, el spec y el plan, estos "artefactos" (artifacts), como documentos formales de traspaso, para que el siguiente Agent pueda retomar el trabajo directamente a partir del documento mismo, sin cargar con la memoria de la conversación anterior.
El propio plan.md también tiene una estructura fija: enumera los archivos que hay que modificar, el orden de trabajo o la lista de tareas, los riesgos y las limitaciones, y una "prueba" —algún criterio de éxito verificable, que puede ser una revisión de lint o si las pruebas pasan o no. Anthropic también recomienda guardar cada versión del intent, del spec y del plan, junto con quién hizo cada cambio; esta es la pieza que a muchas empresas les resulta más difícil de implementar, pero que resulta más crítica para hacer seguimiento de los resultados (por ejemplo, los indicadores DORA).
Al entrar en build (construcción), Anthropic recomienda acelerar con "auto mode" —pero Rob Shocks advierte que esto depende en gran medida de tu organización: primero hay que correrlo un tiempo en un entorno con permisos restringidos, e ir ampliándolos poco a poco, hasta que tengas claro qué herramientas, qué paquetes externos y qué fuentes de red caen dentro de un "ámbito de uso razonable" que puedas permitir; solo entonces conviene fijar ese conjunto de permisos en la configuración de Cursor o Claude, para que el Agent pueda avanzar más rápido sin que tengas que vigilarlo a cada momento, manteniendo a la vez bajo control el "radio de explosión" (blast radius). El equipo también recomienda combinar esto con worktree, para que varios Agents trabajen en distintas tareas al mismo tiempo; y lo que conecta todo esto y mantiene el proceso en su carril es el hook —por ejemplo, actualizar automáticamente el plan al terminar el build, impedir que el Agent toque ciertas carpetas, o bloquear la instalación de un paquete npm que aún no ha sido aprobado. Un entorno de ejecución de Agents más avanzado incluso puede dividir el plan en varias tareas independientes y repartirlas entre múltiples sub-agents que trabajan en paralelo.
En la fase de test (pruebas), el principio de Anthropic es: dejar que el Agent complete la mayor cantidad posible de pruebas antes de que intervengan los ingenieros humanos o el equipo de QA —escribir pruebas, correr el lint, ejecutar el build para confirmar que no hay errores; si el equipo usa herramientas como Playwright, incluso se puede hacer que el Agent levante el servicio de verdad, tome capturas de pantalla, grabe el proceso de operación y luego lo entregue. Anthropic también recomienda correr una ronda de evals cada vez que se modifica un skill o se cambia de modelo: primero se recopilan unos veinte casos reales ya procesados junto con sus resultados esperados, y cada vez que aparece un nuevo modelo, cambia la escala, o hay un cambio fundamental en la forma de trabajar, se vuelve a probar con ese conjunto de casos para confirmar que todo el SDLC no haya retrocedido.
Al entrar en deploy (despliegue), el Agent abre un Pull Request basándose en la revisión que ya completó un humano; Anthropic recomienda que otra instancia de Claude revise este PR de forma asíncrona, conforme a las políticas y normas de seguridad del equipo —y si no está de acuerdo, hay otra instancia de Claude dedicada exclusivamente a gestionar el ida y vuelta de esos comentarios de revisión. A nivel de gobernanza, puedes diseñar un hook que exija que el despliegue pase por la aprobación de una persona específica, o que cumpla cierta puerta de lanzamiento (release gate) antes de dejarlo pasar; una vez aprobado el PR, otro Agent corre una ronda de verificaciones de seguridad y CI, que puede ser una comprobación decisiva de lint y umbrales, o una revisión de seguridad como Cursor Bugbot o la de Claude, que te ayuda a detectar errores una vez más.
Por último está maintenance (mantenimiento) —Rob Shocks afirma sin rodeos que este es el tramo "más ambicioso" de todo el documento. El mantenimiento tradicional es reactivo: estás almorzando, estás de guardia, o quizás recibes a las tres de la madrugada una alerta de que el servidor se cayó, mientras un ticket queda completamente ignorado bajo una montaña de tareas pendientes. En el SDLC nativo de IA, en cambio, un incidente de seguridad, un ticket nuevo, un mensaje en Slack, o incluso una tarea programada, pueden despertar a Claude sin que ninguna persona intervenga, para que diagnostique y actúe de forma asíncrona —y, basándose en los registros que encuentre o los mensajes que reciba, genera él mismo un intent.md. En la práctica, puedes configurar de antemano ciertos indicadores a vigilar; en cuanto una página se caiga o el tráfico de la API se dispare, se dispara el Agent para diagnosticar, redactar el intent y proponer una solución —todo esto ocurre antes de que siquiera toques el ordenador.
El giro: lo que realmente se pone a prueba no es la inteligencia del Agent, sino si has hecho bien la gobernanza
Llegados a este punto, es fácil leer este playbook como si dijera "basta con meter un Agent en cada fase para que todo el proceso se acelere automáticamente". Pero, sumando todo, lo que realmente sostiene esta artifact chain es un montón de cosas nada glamurosas: guardar cada versión del intent, del spec y del plan, dejando claro quién la modificó; probar primero con permisos restringidos y ampliarlos poco a poco; usar hooks para bloquear carpetas y paquetes que no se deben tocar; correr una ronda de evaluación de regresión cada vez que se cambia de modelo; exigir revisión independiente y puertas de seguridad para cada PR. Si falta cualquiera de estas piezas, "dejar que el Agent se haga cargo de todo el SDLC" se convierte fácilmente en "dejar que el Agent replique el caos a mayor velocidad en más fases".
El propio Rob Shocks admite que el flujo de trabajo que enseña en su canal no coincide del todo con el documento de Anthropic, y que en el mercado también existen otras corrientes, como Superpowers o BMAD —no hay una respuesta estándar que sirva para todos; lo importante es que el equipo elija una y procure no estar cambiándola cada dos por tres.
A partir de hoy, lo primero que debes escribir no es código, sino un intent.md
Si solo pudieras llevarte un cambio de hábito de todo este flujo, probablemente sería este: la próxima vez que vayas a construir una función o corregir un bug, deja primero que el Agent te pregunte una y otra vez, vuelca el contexto que tienes en la cabeza, escríbelo como un intent.md, y recién entonces avanza.
Esto también explica por qué este flujo resulta particularmente interesante para otro asunto que nos importa: en cuanto una función tiene que pasar por las siete puertas de intent, spec, plan, build, test, deploy y maintain, cada una de ellas puede estar corriendo en un Agent distinto, con un modelo distinto, y el número de llamadas termina siendo muchísimo mayor que si "un solo Agent lo escribiera todo de principio a fin". Una vez estandarizado el proceso, el consumo se vuelve más predecible, pero también más disperso —y esto es justamente lo que AI Token King quiere resolverle a los equipos: sin importar cuántos Agents estén encadenados detrás ni cuántos modelos se vayan alternando, puedes consultar de una sola vez qué modelo se usó en cada llamada, cuántos Tokens consumió y cuánto se cobró realmente.
Preguntas frecuentes (FAQ)
P1: ¿Qué es exactamente intent.md? Según lo que Rob Shocks transmite sobre la práctica del equipo de Anthropic, intent.md es un documento de intención que surge de una lluvia de ideas entre el "originator" (la persona que plantea el tema) y Claude, cuya característica distintiva es que "las personas pueden leerlo y las máquinas pueden actuar directamente sobre él". Sustituye a las historias de usuario dispersas de la lista de tareas tradicional y se convierte en el punto de partida de artefactos posteriores como el spec y el plan.
P2: ¿Quién puede escribir un intent.md? Cualquiera. Puede ser un cliente que reporta un bug, un product manager que quiere agregar una función, o un ingeniero que quiere dejar constancia de una idea de mejora de proceso —no hace falta ser un experto del equipo. Después de escribirlo, Anthropic recomienda que la misma persona que planteó el tema revise lo que el Agent organizó, para confirmar que ambas partes entendieron lo mismo.
P3: ¿Qué relación tiene intent.md con spec.md y plan.md? Los tres forman lo que Rob Shocks llama la "artifact chain" (cadena de artefactos): intent.md establece primero el problema y el contexto a resolver; en cuanto el intent queda aprobado, un hook o un proceso fijo dispara la generación de spec.md (la especificación de requisitos y diseño); luego el ingeniero alimenta el intent y el spec juntos al Agent, entra en plan mode, y produce plan.md (los archivos concretos a modificar, el orden, los riesgos y los criterios de verificación).
P4: ¿Significa esto que todo el flujo puede funcionar sin supervisión humana? No. La transcripción enfatiza varias veces que las personas deben permanecer en los puntos de revisión clave: el originator debe verificar el intent, el ingeniero debe confirmar el plan antes de ejecutarlo, y antes del despliegue se necesita la aprobación de una persona o el cumplimiento de una puerta de lanzamiento. Lo que plantea Anthropic es reducir el tiempo humano invertido en cada fase, no eliminar por completo el juicio humano.
P5: ¿Es obligatorio copiar exactamente la versión de Anthropic de este flujo? No. El propio Rob Shocks dice en el video que el flujo de trabajo que enseña en la práctica no coincide del todo con este documento de Anthropic, y que en el mercado también existen otras corrientes como Superpowers o BMAD. Lo importante es que el equipo elija una y la estandarice en la medida de lo posible, en lugar de cambiar de método en cada proyecto.
Declaración de fuentes
El contenido de este artículo se elaboró a partir del video "Claude Codes New INTENT.MD, What is It?" (https://www.youtube.com/watch?v=LoMOPj-lO8U), publicado en septiembre de 2026 en el canal de YouTube Rob Shocks. Se trata del desglose y la transmisión oral que hace ese canal sobre el "playbook del ciclo de vida de desarrollo de software nativo de IA" publicado por Anthropic (el equipo al que pertenece Boris Cherny, creador de Claude Code); no es una cita textual del documento oficial original de Anthropic consultado directamente por el autor de este artículo. Los pasos del proceso y los nombres de herramientas mencionados en el texto (como Switch Dimension Discovery, Realm, Cursor Requirements Discovery) reflejan fielmente el contenido del video, sin ser una traducción palabra por palabra, sino una reorganización y elaboración propia del contenido. Si tu equipo desea implementar formalmente un flujo similar, se recomienda consultar directamente el documento oficial publicado por Anthropic para verificar los detalles.
Para seguir leyendo
• ¿Qué es AGENTS.md? Un README pensado para que lo lea la IA, y por qué Codex, Claude Code y Copilot ya lo están usando
• ¿Qué son los Agent Skills? Claude enseña a la IA usando carpetas, y ahora es un estándar abierto que OpenAI y Google también están adoptando
• ¿Cómo hacer que un AI Agent Skill sea confiable? 5 puntos clave y errores comunes
• ¿Claude Code consume demasiados Tokens? 3 trucos para ahorrar más del 50% en costos
Pasa a la acción
Cuando una función tiene que pasar por las siete puertas de intent, spec, plan, build, test, deploy y maintain, detrás pueden estar turnándose varios Agents y varios modelos, y la factura de Tokens también queda dispersa entre llamada y llamada. Prueba gratis AI Token King y pon sobre la mesa, de una sola vez, los Tokens consumidos, el modelo usado y el costo realmente cobrado en cada llamada; sin importar cuántos Agents y modelos encadene tu SDLC nativo de IA, sabrás exactamente a dónde se fue el dinero.
