Productivity Paradox: The Real Future of OSS AI-DLC

AI promised to make software teams dramatically faster. Yet many organizations are discovering the opposite: more tools, more noise, more review cycles, and unclear ownership. In this session, we will share real lessons from implementing AI across the software delivery lifecycle, including what worked, what failed, and how developers, platform engineers, SREs, security teams, architects, product owners, and leaders are being reshaped by AI-assisted delivery.

Attendees will leave with practical experiments, patterns, metrics, and governance ideas they can apply immediately to evaluate AI beyond demos and hype. We will also introduce an AI-DLC framework designed to help organizations embed AI responsibly across discovery, coding, testing, security, operations, and continuous improvement—turning the productivity paradox into measurable engineering impact.

Transcript

2. KCD_Lima_Perú_2026 Atacando la paradoja de la productividad con OSS AI-DLC. Eduardo Spotti CEO - Crubyt
3. Y vos quien sos? CEO @Crubyt Lider @AWS Sec UG Argentina @CNCF Latam - Argentina @Github GitTogether @CNCF Ambassador @DevOps Ambassador Contribuidor Open Source y escritor sobre IA Miembro activo de iniciativas como twelve-factor app Docente, Padre, Hincha de Boca Junior, MMA, Argentina
4. Levanten la mano... • ¿Cuántos aquí ya tienen al menos una aplicación con IA en producción? • ¿Cuántos ya tienen equipos usando modelos distintos (LLMs)? • ¿Cuántos saben exactamente cuánto están gastando en IA? • ¿Cuántos podrían auditar hoy quién envió información sensible a un modelo?
5. Contexto actual: ¿Qué está pasando con la IA en las empresas?
6. La IA dejó de ser una apuesta. Ya es una prioridad estratégica.
19. BM AD BMAD Method — Arquitectura Multi-Agente Cada agente tiene rol acotado, contexto mínimo y artefactos de entrada/salida definidos Agente Consume Produce E L P RINC IP IO CLAV E Analyst Entrevi stas, docs existentes research_brief.md, hallazgos cuantificados Partición de contexto PM research_brief.md PRD.md — user stories + criterios de aceptación Architect PRD.md + stack existente architecture.md — C4, ADRs, tech stack PO PRD.md + architecture.md Épicas, historias refinadas, backlog priorizado SM Backlog priorizado Sprint plan, task breakdown atómico Dev Task + architecture.md (sol o eso) Código + unit tests — SIN ver PRD completo QA Feature + criterios de aceptación Test report, bug reports formali zados De v no ve el PRD completo. Arquitectura no ve e l código. Cada agente recibe SOLO lo que ne cesita para su tare a → menos ruido, más coherencia. S C A LE - A D A P TI VE Bug fix → flujo liviano (Dev + QA). Feature nueva → flujo completo 7 agentes. Plataforma enterprise → ceremony completa + Orchestrator. BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development
20. BMAD — Ejemplo Técnico: Sistema de Onboarding BM AD Flujo completo con artefactos reales que pasan entre agentes Analyst → research_brief.md → PM → PRD.md → Architect → architecture.md Dev → → código + tests → QA → test report ••• ••• # research_brief.md — artefacto del Analyst # architecture.md — artefacto del Architect # Dev recibe SOLO este doc + su task. NO el PRD. ## Pain Points Cuantificados - 60% empleados: >3 semanas para acceso completo - IT: 40 tickets/mes de provisioning manual - Costo: $1,200/empleado en tiempo perdido ## ADR-001: Workflow Engine Decision: AWS Step Functions Reason: retry nativo, audit log, costo < Lambda ## Oportunidad - Automatizar provisioning via SCIM (Okta + AD) - Workflow aprobatorio en <24h - Meta: acceso completo en ≤5 días hábiles ## ADR-002: Provisioning Decision: Okta SCIM 2.0 Reason: AD sync + MFA + auto-deprovisioning ## Stack Python 3.12 | FastAPI | Postgres | Step Functions ## Nota para el Architect # Stack existente: AWS, Python, Postgres ## Principio: particion de contexto Dev no recibe PRD. Evita over-engineering. −65% tickets manuales de IT BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development 5 días tiempo a acceso completo (antes: 21) ×4 velocidad de onboarding docume ntado
21. RAISE Framework — Scoring de Casos de Uso IA RAIS E 5 dimensiones que convierten una lista de ideas en una decisión de inversión justificada R A I S E Relevance Availability Impact Solution Fit Ethics/Risk ¿El problema realmente necesita IA o alcanza con aut omatización basada en reglas? ¿Existe suficient e data, de calidad, etiquetada, accesi bl e para entrenar o alimentar el model o? ¿Cuánto cuesta el problema hoy? ¿Cuánto valor genera resolverlo? Cuantificado en dinero o tiempo. ¿El enfoque técnico propuest o resuelve el problema correctamente? ¿Hay precedentes similares? ¿Hay riesgos de sesgo, privacidad, regulatorios (GDPR, IA Act) o impacto en empleo? 1 1 1 1 2 3 4 5 2 3 4 5 1 2 3 SCORE PONDERADO = (R×w₁ + A×w₂ + I×w₃ + S×w₄ + E×w₅) / 5 Umbrales: ≥4.0 = Proceder | 2.5–3.9 = Piloto acotado | <2.5 = Descartar o re-plantear BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development 4 5 2 3 4 5 2 3 4 5
22. RAIS E RAISE — Ejemplo: Predicción de Devoluciones (e-commerce) Scoring real que convierte una idea en una decisión de inversión documentada Dimens ión Evidencia / Razonamiento Score Relevance Problema complejo: muchas variables (precio, categoría, historial, proveedor). Las reglas simples sólo capturan el 30%. El ML puede modelar interacciones. 4 /5 Avail abil ity 2 años de hi storial compras/devol uciones disponible. Riesgo: 40% de regi stros tienen campo 'motivo de devolución' vacío → feature engineering requerido. 3 /5 Impact Devoluciones cuestan $2.3M/año (logística inversa + pérdida de margen). Reducir un 20% = $460K anuales. Impacto di recto y medible desde día 1. 5 /5 Solution Fit XGBoost / LightGBM probados en casos similares. El desafío mayor es la integración con el sistema legacy de órdenes (3 meses de ingeniería estimados). 3 /5 Ethics/Risk Riesgo bajo. No usa datos personales sensibles. Riesgo menor: potencial sesgo hacia proveedores con más historial. Requiere monitoreo de fairness. 4 /5 S CORE F INAL 3.8 / 5 Piloto acotado → 2 categorías DE CIS IÓ N DO CUM E NTAD A Proceder con piloto en categorías Electrónica y Moda. Inversión: 3 meses + $80K. Validar reducción de devoluciones antes de escalar al catálogo completo. SIN RAIS E: La empresa hubi era impl ementado el model o sin validar la calidad de datos → 40% de regi stros vacíos → modelo con 58% de accuracy → $0 de ahorro real, $120K perdidos. BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development
23. OpenSpec — Spec-Driven Development (SDD) OPENSP EC Los requerimientos viven en el repo, versionados, antes de que se escriba una línea de código PROPOSAL proposal.md ¿Qué y por qué? SPEC + DESIGN → spec.md + design.md ¿Qué hace? + ¿Cómo? Delta Markers APPLY sistemas brownfield, cada spec marca qué cambió: →Para → tasks.md ADDED / MODIFIED / REMOVED. puede El agente sabeAgente exactamente quécodear tocar sin leer todo el repo. ARCHIVE specs/archive/ Historial permanente ••• specs/ active/ 007-crypto-payments/ proposal.md # qué + por qué spec.md # comportamiento esperado design.md # decisiones técnicas tasks.md # breakdown para el agente archive/ 006-oauth-migration/ # spec completada AGENTS.md AGENTS.md Archivo de instrucciones que cualquier agente IA (Claude Code, Cursor, Copilot) lee automáticamente. Define cómo leer la spec activa, qué format de output y reglas del workflow. # instrucciones para el agente IA State Machine Enforcement El agente NO puede aplicar cambios si no existe una spec en estado 'apply'. Es un gate técnico, no una convención que se puede saltear. BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development
24. OPENSP EC OpenSpec — Ejemplo Técnico: Pagos con Cripto El mismo feature, con y sin OpenSpec. La diferencia es la inconsistencia acumulada. SIN OpenSpec — problema real CON OpenSpec — resultado esperado ••• ••• # Dev A (semana 1): Claude: "agrega soporte para pago con ETH" → esquema: payments.crypto_address (varchar) → endpoint: POST /payments/crypto # specs/active/007-crypto-payments/spec.md ## ADDED: Soporte ETH/BTC - Tabla: payments (campo: crypto_address varchar(42)) - Endpoint: POST /api/payments {currency, address, amount} - Respuesta: {txHash, status, estimatedConf} # Dev B (semana 3, sesión nueva): Claude: "implementa pagos en cripto" → esquema: crypto_payments.wallet (text) → endpoint: POST /api/v2/wallet-payment # Resultado en integración: # TypeError: cannot read wallet of undefined # 2 días de debugging para encontrar # la inconsistencia de esquema ••• ## Delta Markers en spec.md (para sistemas existentes con OpenSpec): ADDED: campo crypto_address varchar(42) → nuevo campo en tabla payments MODIFIED: endpoint /payments → acepta {currency, address, amount} REMOVED: campo legacy_ref eliminado de todas las respuestas BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development # AGENTS.md instruye al agente: # 'Antes de codear, leer spec activa en specs/active/' # Dev A y Dev B leen el mismo spec.md # → mismo esquema, mismo endpoint, mismo contrato # → integración limpia en primera pasada # Al completar → spec se mueve a archive/ # con referencia al commit SHA
25. INTEGRA CIÓ N Los 3 Frameworks en Conjunto Cubren fases distintas del mismo problema: adoptar IA de forma predecible y escalable ANTES del proyecto DURANTE el desarrollo A LO LARGO DEL TIEMPO RAISE BMAD OP ENSPEC Priorización de Casos de Uso Orquestación del Desarrollo Coherencia a Largo Plazo → Input: lista de ideas de negocio → Input: PRD + arquitectura + backlog → Input: cualquier cambio o feature nueva → Proceso: scoring 5 dimensiones (R·A·I·S·E) → Proceso: 7 agentes especializados en secuencia → Proceso: proposal → spec → apply → archive → Output: ranking priorizado con justificación → Output: código coherente + tests + documentación → Output: specs versionadas en el repo → Entregable: decisión documentada y auditable → Entregable: software production-ready trazable → Entregable: historial técnico trazable y auditable RO I esperado > 3× en casos seleccionados Reducción 60% de inconsistencias en código gen erado Cero inconsistencias entre sesiones de agente IA BMAD · R AISE · OpenSpec — Frameworks para IA-Driven Development
26. Estructura del framework 10 secciones · 2 partes · Cada una con desafíos, prácticas, KPI, madurez y tecnologías P A R TE 1 — SD L C C ON IA 1 2 3 4 5 6 7 Discovery & Ideación Kiro + RAISE Arquitectura & Diseño Kiro + BMAD Architect Especificación OpenSpec + BMAD PO /SM Implementación Claude Code + O penCode + Kiro Testing & QA BMAD QA + RAISE R obustness Deployment & CI/CD BMAD Orchestrator + OpenCode Observabilidad LangFuse + RAISE continuo IA-DLC Framework v 1.0 P A R TE 2 — GE ST IÓ N D E A GE NT E S G1 G2 G3 Gobernanza ISO 42001 + BMAD Enterprise Resiliencia LiteLLM + Circuit Breaker Seguridad OW ASP LLM + Guardrails