Un framework de readiness para Agentic AI en el SDLC

Antes de escalar agentes de código a todo el ciclo de desarrollo, vale la pena una evaluación honesta: en cuáles de las diez dimensiones del SDLC ya está listo el equipo, y en cuáles todavía no. Tres fuentes documentan, cada una, una pieza distinta de esa preparación - requisitos, arquitectura/código y gobernanza.

Requisitos: specs, no prompts sueltos

La primera prueba de preparación es simple: ¿los requisitos llegan al agente como una especificación estructurada - jornada del usuario, criterio de éxito, plan técnico - o como un prompt improvisado? GitHub documenta esta distinción como la diferencia entre spec-driven development y vibe coding: sin spec, la "claridad sobre cómo debe interactuar con los sistemas existentes" solo aparece después de que el código ya está escrito, cuando corregirlo ya es costoso.

Arquitectura y código: legible para un agente, no solo para un humano

El experimento de harness engineering de OpenAI define la segunda prueba: ¿el repositorio es lo bastante "legible" como para que un agente entienda el dominio de negocio a partir del propio código, sin depender de contexto tácito en conversaciones que nunca ve? Los equipos preparados documentan las decisiones de arquitectura dentro del repositorio; los no preparados todavía mantienen el conocimiento crítico disperso en Slack, reuniones, o en la cabeza de una sola persona.

Pruebas: parte de la ejecución del agente, no un paso manual posterior

Un equipo preparado trata las pruebas como parte del propio ciclo de ejecución del agente - corriendo antes de que cualquier PR se considere listo para revisión, no como una verificación manual que hace un humano después. Eso es preparación de proceso, no de herramientas: exige que la suite de pruebas ya exista y sea lo bastante confiable como para que el agente la ejecute sin supervisión constante.

Seguridad, DevOps y observabilidad: la misma capa que describe Microsoft

La tesis central de Microsoft - "AI alone won't change your business. The system running it will" - define el estándar para estas tres dimensiones: seguridad nativa (no añadida después), DevOps que trata el despliegue de agentes como parte del pipeline normal, y observabilidad que cubre el ciclo completo - "source, test, deploy, observe, and improve". Un equipo preparado ya tiene estas tres piezas funcionando para código escrito por humanos; escalar a agentes es una extensión, no una construcción desde cero.

Datos: gobernanza que ya existe, no creada para el agente

Los datos a los que un agente va a acceder necesitan clasificación, alcance y política de retención que ya deberían existir independientemente de cualquier agente - si esa gobernanza no existe para el acceso humano, no va a aparecer mágicamente cuando un agente entre en el proceso.

Gobernanza y métricas: dueños definidos, no responsabilidad difusa

La prueba final de preparación: ¿existe un dueño claro para cada agente en producción, con métricas de éxito definidas antes del despliegue, no descubiertas después de que algo ya salió mal? La ausencia de ownership claro es la señal más confiable de que un equipo todavía no está preparado, sin importar cuán sofisticada sea la tecnología que esté usando.

Las diez dimensiones de la evaluación

1. Requisitos - spec estructurada, no un prompt suelto
2. Arquitectura - decisiones documentadas en el repositorio, no en Slack
3. Código - legible para un agente, convenciones explícitas
4. Pruebas - parte de la ejecución, no una verificación manual posterior
5. Seguridad - nativa, no añadida después
6. DevOps - despliegue de agentes en el mismo pipeline, no un proceso aparte
7. Observabilidad - ciclo completo: source, test, deploy, observe, improve
8. Datos - gobernanza que ya existe, no creada específicamente para el agente
9. Gobernanza - dueño claro por agente
10. Métricas - éxito definido antes del despliegue, no después

Cómo usar la evaluación

Cada dimensión recibe una nota independiente - es común que un equipo esté preparado en pruebas y código, pero no en datos y gobernanza. El objetivo no es una nota única de "listo" o "no listo"; es un mapa de dónde invertir antes de escalar, porque la dimensión más débil es la que va a determinar el tamaño real del incidente cuando (no si) algo salga mal.

Fuentes

• GitHub - Spec-driven development with AI: Get started with a new open-source toolkit - https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
• OpenAI - Harness engineering: leveraging Codex in an agent-first world - https://openai.com/index/harness-engineering/
• Microsoft - AI alone won't change your business. The system running it will. - https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/