Artificial Intelligence Software Development Life Cycle

Desarrollo guiado
por IA.

Este sitio es una guía operativa para que equipos de desarrollo adopten IA de forma disciplinada, sin perder calidad ni control técnico. No se trata de usar herramientas por separado: es una metodología completa que ordena cómo el equipo toma decisiones, genera artefactos y construye software con IA en cada etapa del ciclo.

🎯
Propósito. Enseñar y orientar al equipo — y a otros equipos que quieran adoptar este modelo — sobre cómo trabajar con IA de forma estructurada. Incluye metodología, plantillas, convenciones, casos de uso, antipatrones y laboratorios prácticos para llevar a la práctica cada concepto.
⚠️
Principio cero — La IA es un amplificador, no un reparador Los equipos fuertes usan IA para volverse aún mejores. Los equipos con problemas encuentran que la IA solo amplifica e intensifica lo que ya está roto. Esta metodología no funcionará si los cimientos básicos — CI/CD funcional, tests automatizados, observabilidad mínima, version control maduro — no están en su lugar. Antes de adoptar AI-SDLC, evalúa los pre-requisitos en la sección Adopción.
Fuente: DORA 2025 — State of AI-assisted Software Development
📚 RUTA DE APRENDIZAJE RECOMENDADA

Sigue este orden para comprender AI-SDLC desde los conceptos básicos hasta la implementación avanzada. Para equipos nuevos: completa los laboratorios 01-06 antes de intentar aplicar en producción.

Bases metodológicas que sustentan este modelo
Stack de referencia

Implementación Pixarron/Mentora

Esta es una implementación concreta de AI-SDLC. La metodología es portable y puede adaptarse a otros stacks, pero aquí mostramos cómo se aplica con nuestras herramientas actuales.

📋 Gestión y Documentación
🎯
Jira
Backlog, estados, trazabilidad
📄
Confluence
SPEC, ADR, Runbooks
💬
MS Teams
Comunicación, alertas, aprobaciones
🤖 IA y Desarrollo
🧠
ChatGPT / Claude
Análisis, diseño, generación, revisión
🎨
v0
Prototipado UI rápido
💻
Windsurf
IDE AI-first, Cascade agent
☁️ Infraestructura
🐙
GitHub
Repositorio, ramas, PRs
⚙️
GitHub Actions
CI/CD automatizado
🔷
Azure
App Service, MySQL, Azure AI Search
📊 Observabilidad
🔔
n8n
Automatización de workflows
📈
New Relic
APM, métricas, alertas
🛡️
Cloudflare
DNS, WAF, CDN, protección
Nota: Este stack es una implementación concreta de AI-SDLC. La metodología es portable y puede adaptarse a otras herramientas (GitLab en lugar de GitHub, Linear en lugar de Jira, Datadog en lugar de New Relic, etc.).
SDLC guiado por especificaciones

El proceso completo

Cada etapa produce artefactos que alimentan la siguiente. La IA actúa en cada fase, pero los humanos controlan las decisiones críticas.


Flujo Jira recomendado

👤Backlog
👤Ready for Spec
🤝Spec Draft
👤Spec Approved
🤝In Development
👤PR Created
🤝Code Review
⚙️Ready for Deploy
👤Done ✓
👤Humano
🤖IA
🤝IA + Humano
⚙️Automático / Pipeline

Métricas DORA 2025

El marco de referencia para medir el desempeño de ingeniería. La edición 2025 agregó Reliability como quinta métrica y renombró MTTR a Failed Deployment Recovery Time.

DF
Deployment Frequency
Frecuencia de despliegues a producción. Top 15%: múltiples deploys diarios.
GitHub Actions · Azure
LT
Change Lead Time
Desde el primer commit hasta producción. Top 15%: menos de 1 hora.
Jira · GitHub
CFR
Change Failure Rate
% de cambios que provocan degradación en producción. Top 15%: menos de 4%.
New Relic · GitHub Actions
FDRT
Failed Deployment Recovery Time
Tiempo para restaurar tras un deploy fallido (antes MTTR). Top 15%: menos de 1 hora.
New Relic · Rollback slots
REL
Reliability
Consistencia en cumplir objetivos de performance y disponibilidad (SLOs). Nueva métrica 2025.
SLOs · New Relic · Error budgets
Nota sobre DORA 2025: El reporte DORA 2025 (renombrado State of AI-assisted Software Development) abandonó las clases fijas (Elite / High / Medium / Low) y ahora muestra distribuciones por percentil. Estos números son referencia de benchmark, no metas absolutas.
Fuente: dora.dev · Reporte 2025

DORA 2025 · Capacidades amplificadoras

Las 7 capacidades que amplifican el impacto de la IA

DORA 2025 identifica 7 capacidades organizacionales que amplifican el valor de adoptar IA, y que cuando faltan, hacen que la IA empeore el desempeño. Estas no son métricas — son condiciones del entorno. Click en cada capacidad para profundizar.

Insight clave: los equipos que adoptan IA sin estas capacidades reportan caídas de productividad y peor calidad. Los que las tienen reportan ganancias compuestas. La metodología AI-SDLC apunta justamente a desarrollar estas capacidades antes y durante la adopción.
Fuente: DORA 2025 — State of AI-assisted Software Development
Vista integral del stack

Arquitectura y stack para scaleup de IA moderna

Click en cualquier componente para ver descripción, propósito, cuándo se usa y si la intervención es humana o de IA.

Arquitectura lógica de la plataforma
Aplicación · Microservicios
🔄
n8n — Automatización & Workflows
Flujos de negocio, integraciones, agentes, tareas programadas
Observabilidad
Seguridad
Flujo de desarrollo AI-Native
Capas transversales — Gobierno, calidad y escalabilidad
Intervención humana
Intervención IA
Mixto / Asistido
Continuo / 24-7

Tu stack actual

Herramientas por capa

Cada herramienta tiene un rol preciso en el proceso. La clave no es tener más herramientas, sino saber cuándo y cómo usarlas dentro del flujo metodológico.

Casos de uso reales

El stack en acción

Así se mueven las herramientas a través del proceso en cada escenario del equipo.

Artefactos

Plantillas listas para usar

Copia, adapta y versiona en Confluence y GitHub. La consistencia entre artefactos es lo que permite que la IA entienda el contexto del proyecto.

Fundamentos

Principios del desarrollo guiado por IA

Estas reglas son las que separan a los equipos que usan IA como una calculadora de los que la integran como parte del proceso de ingeniería.


Cobertura del stack actual


📚 Bases metodológicas que sustentan este modelo Click para expandir · 9 prácticas

Los 9 principios anteriores no nacieron en este sitio: son síntesis de prácticas establecidas por la industria. Esta es la genealogía intelectual de AI-SDLC. Click en cualquier base para ver origen, definición y aplicación concreta en este modelo.

Evolución

Modelo de madurez AI-SDLC

Cinco niveles progresivos (0 → 4). El objetivo no es saltar al final: cada nivel asienta las bases del siguiente. Avanza de forma deliberada.


Evalúa tu madurez AI-SDLC

Responde el checklist para diagnosticar tu nivel actual y obtener recomendaciones personalizadas.


Nivel 3 — Arquitectura multi-agente

La evolución natural del nivel 2: en lugar de un agente generalista, múltiples agentes especializados colaboran orquestados por la SPEC. Cada agente tiene un rol definido, herramientas específicas y puntos de control donde el humano valida.

📄 SPEC estructurada
Confluence + Claude
🧠 Product Owner Agent
Valida requerimientos, criterios de aceptación
🏗️ Architect Agent
ADRs, diagramas C4, contratos de API
💻 Developer Agent
Windsurf Cascade + Claude Code
🧪 Tester Agent
Genera unit, E2E, edge cases
🔍 Reviewer Agent
Seguridad, convenciones, PR review
📊 Ops Agent
New Relic + n8n + runbooks automáticos

Herramientas de orquestación

Orquestación
LangGraph
Flujos multi-agente con estado persistente. Ciclos, memoria y supervisión humana en loops.
Colaboración
AutoGen
Agentes conversacionales de Microsoft. Fácil integración con herramientas y human-in-the-loop.
Equipos de agentes
CrewAI
Roles, objetivos y memoria compartida. Natural para simular roles del equipo de desarrollo.

Roadmap de mejoras — tu stack

Adopción responsable

¿Está tu equipo listo para AI-SDLC?

La metodología no es universal. Sin cimientos, amplifica el caos existente. Esta sección te ayuda a evaluar si es el momento, cuándo evitarla, y cómo medir si realmente funciona.

Pre-requisitos antes de adoptar

Si tu equipo no cumple al menos 7 de 10, no estás listo para AI-SDLC todavía. Resuelve los fundamentos primero.


Cuándo NO usar la metodología completa

SDD y PromptOps son overhead en ciertos contextos. Sé honesto: si estás en alguno de estos escenarios, aplica solo las partes que sumen.


Cómo medir si la metodología está funcionando

Los KPIs de adopción son distintos de las métricas DORA. Miden si el propio método está siendo usado y generando valor.

Nota: Si estos KPIs no mejoran o empeoran tras 3 meses de adopción, es señal de que el proceso es overhead y no valor real. Ajusta, no abandones: probablemente estás aplicando demasiado método para el contexto del equipo.
Estándares del equipo

Convenciones y acuerdos de trabajo

Las convenciones no son burocracia: son el lenguaje común que permite que la IA entienda el repositorio y que el equipo trabaje sin fricción.

Gestión de prompts

PromptOps: prompts como código

Los prompts son artefactos de ingeniería, no solo strings. Deben versionarse, revisarse y pasar por las mismas etapas de calidad que el código.

📁
Estructura del Prompt Registry
/prompts
├── chatbot/
│ ├── system.v1.md
│ ├── system.v2.md
│ └── persona-support.v1.md
├── evaluator/
│ └── academic-feedback.v1.md
/evals
└── chatbot-basic.yaml
/datasets
└── student-answers.json
PROMPT_CHANGELOG.md
🔄
Flujo PromptOps
1. SPEC define comportamiento esperado
2. Prompt inicial en /prompts/{nombre}.v1.md
3. Implementación y testing
4. Evaluación con dataset
5. PR con comparación de versiones
6. Deploy y observabilidad
7. Mejora continua → v2, v3...
📝
Frontmatter YAML
---
id: chatbot-system
version: 2
author: jorge.paz
date: 2026-04-28
model: gpt-4o
eval_score: 0.89
---

Eres un asistente...
Principios de PromptOps
Versionar como código
Cada cambio de comportamiento es una nueva versión, no un edit
Pull Request obligatorio
Revisión humana antes de deployar a producción
Evaluación automática
Dataset de test + métricas de calidad objetivas
Changelog documentado
Registro de cambios y razones de cada versión
Ejemplo: Iteración de un prompt
v1: "Responde preguntas de estudiantes" → Respuestas demasiado largas y genéricas.
v2: "Responde en máximo 3 frases cortas, tono pedagógico" → Mejor, pero falta estructura.
v3: "Usa formato: 1) Concepto clave, 2) Ejemplo práctico, 3) Próximo paso" → Optimal.

Cada versión es un archivo separado con metadata, eval_score, y PR de aprobación.

Cómo se calcula el eval_score

El eval_score: 0.89 no aparece por magia. Es la media ponderada de aciertos sobre un eval set fijo de entradas y criterios esperados. Hay dos paradigmas complementarios:

Eval determinista
Assertions sobre el output: contiene/no contiene, regex, schema JSON válido, longitud, tono mediante palabras clave. Rápido, barato, reproducible.
assert output.includes("paso 1")
assert output.length < 500
assert json.parse(output)
Eval con LLM-as-judge
Otro LLM evalúa calidad subjetiva: coherencia, utilidad, tono. Útil para tareas creativas, pero introduce sesgo del juez (prefiere su propio estilo). Mitigación: usar modelo distinto al evaluado y rúbrica explícita.
judge: "¿La respuesta cumple
estos 3 criterios? Devuelve
score 0-1 por cada uno."
Herramientas concretas
Promptfoo DeepEval OpenAI Evals Langfuse Scores
Fórmula práctica: eval_score = (Σ assertions_passed · weight) / total_weight. Guárdalo en el frontmatter y regéneralo en CI cada vez que cambie el prompt o el eval set.

A/B Testing de prompts en producción

El eval offline tiene un límite: no captura los patrones reales del tráfico. Antes de promover v2 a default, pásalo por split testing:

90%
Tráfico → v1 (control)
10%
Tráfico → v2 (challenger)
1–2 sem
Ventana de comparación
Métricas a comparar (no offline, sino reales en producción): latencia p95, tokens consumidos por respuesta, thumbs-up/down del usuario, tasa de re-pregunta (señal de confusión), tasa de abandono de sesión. Si v2 gana de forma estadísticamente significativa, se promueve a default. Si empata, gana el más barato o el más rápido.

Política de rollback de prompts

Si v3 deteriora producción a las 3am — por ejemplo, empieza a responder fuera de alcance o con latencias altas — debes poder revertir sin redeploy.

Mecanismo recomendado
Feature flag tipo PROMPT_VERSION=v2 (en variable de entorno, LaunchDarkly, Unleash o similar). El registry expone todas las versiones publicadas, no solo la "production":
// Backend lee el flag en cada request
const version = env.PROMPT_VERSION || 'v3';
const prompt = registry.load('chatbot-system', version);
1. Detección
Alerta en Langfuse/New Relic por caída de score, spike de tokens o errores.
2. Rollback
Cambiar el flag a la versión anterior. Efecto inmediato, sin CI/CD.
3. Post-mortem
ADR con la causa raíz. Agregar casos al eval set para que no vuelva a pasar.
Regla: si una versión no puede revertirse en menos de 5 minutos, la metodología PromptOps no está realmente implementada. El registry debe tratarse como un feature flag de comportamiento.
Governance

IA y Control Humano

La IA acelera, pero el humano decide. Tabla de responsabilidades claras en cada etapa del ciclo.

Etapa 🤖 IA puede 👤 Humano debe
SPEC Redactar borrador, detectar ambigüedades, sugerir requisitos Aprobar alcance y criterios de aceptación
ADR Comparar opciones técnicas, identificar trade-offs Tomar decisión arquitectónica final
Código Generar implementación, tests, documentación inline Revisar PR, validar lógica de negocio y seguridad
Tests Generar casos de prueba, edge cases, coverage Aprobar cobertura mínima y casos críticos
CI/CD Proponer pipeline, detectar regresiones Aprobar cambios críticos de pipeline
DB/Migración Generar scripts, detectar riesgos de datos Validar migración en staging, aprobar producción
Deploy Preparar release, rollback scripts, verificaciones Aprobar deploy a producción
Incidente Sugerir diagnóstico, proponer fix, generar runbook Decidir resolución crítica, comunicar stakeholders
Prompt Proponer versiones, evaluar con dataset Aprobar publicación del prompt
Regla de oro: La IA nunca tiene la última palabra en decisiones que afectan usuarios, seguridad, o arquitectura de sistema. El humano es responsable de todo código que entra a producción, aunque lo haya generado una IA.
DevSecOps

Seguridad en el ciclo de desarrollo

La seguridad no es una etapa al final. Es una práctica que se aplica desde el IDE hasta producción — shift-left security.

Errores frecuentes

Antipatrones del desarrollo con IA

Los errores que cometen casi todos los equipos cuando adoptan IA sin metodología. Identificarlos es el primer paso para evitarlos.

Ejercicios prácticos

Laboratorios de aprendizaje

Ejercicios concretos para que el equipo practique la metodología. Cada lab tiene objetivo, duración estimada y entregable esperado.

Vocabulario técnico

Glosario del AI-SDLC

Los términos que el equipo debe conocer para trabajar con esta metodología. Sin lenguaje común, las conversaciones son más lentas y los malentendidos más frecuentes.

Preguntas frecuentes

FAQ — Dudas comunes del equipo

Las preguntas que surgen siempre cuando un equipo adopta desarrollo guiado por IA. Respuestas directas, sin rodeos.

Bibliografía y fuentes

Referencias

Libros, reportes, papers y recursos que sustentan la metodología AI-SDLC. La idea no es citar todo, sino dar al equipo un punto de entrada confiable para profundizar en cada área.

🤖

Asistente AI-SDLC

Experto en metodología

¡Hola! Soy tu asistente experto en AI-SDLC. Puedo responder preguntas sobre la metodología, herramientas, arquitectura, flujos de trabajo, o cualquier tema del sitio. ¿En qué puedo ayudarte?
Powered by Azure OpenAI (gpt-5.4-mini) • Limpiar chat