01 / Tesis central
El cuello de botella cambió.
La inteligencia artificial cambió el cuello de botella del delivery digital. Antes, el reto principal era construir software. Ahora, el reto principal es decidir qué construir.
La IA redujo radicalmente el costo y el tiempo de construcción, pero no eliminó el riesgo de construir lo incorrecto. Por eso, AI-BDF no está diseñado para producir más software, sino para producir mejores decisiones, más rápido y con evidencia.
No ganan los que construyen más. Ganan los que descartan mejor.
02 / Qué es AI-BDF
Un modelo de trabajo para operar en la era de IA.
El AI-Native Bet Delivery Framework es un modelo de trabajo para organizaciones que quieren operar en la era de IA usando equipos pequeños, experimentación rápida, Spec Driven Development y gobierno ligero basado en evidencia.
Conecta niveles
Portfolio -> Ecosystem -> Pod.
Cambia la unidad de trabajo
De historias de usuario a hipótesis de valor.
Cambia el output
De incremento a decisión validada, versión funcional y aprendizaje.
03 / Por qué es un framework
No es una receta. Es un sistema adaptable.
AI-BDF es un framework porque no prescribe una única forma rígida de trabajo. Define principios, roles, artefactos, flujos, reglas y métricas que pueden aplicarse en diferentes productos, servicios, ecosistemas y contextos organizacionales.
No es una metodología cerrada ni una receta paso a paso. Es un sistema adaptable que permite tomar mejores decisiones sobre qué construir, cómo validarlo, cuándo escalarlo y cuándo descartarlo.
04 / Tesis operativa
Del problema a la medición de impacto.
AI-BDF funciona sobre una lógica simple:
Problema
Hipótesis
Experimento
Prototipo
Validación
Decision
Industrialización
Medición de impactoExploración
Uso de IA para aprender rápido.
Idea
Prototipo
Evaluar
Descartar / IterarIndustrialización
Uso de specs para construir con robustez.
Spec
Build
Evaluate
Ensure
Release05 / Principios
Los 12 principios del AI-BDF
Los principios son la capa de criterio del framework. Guían decisiones, diseño organizacional, flujo de trabajo, artefactos y métricas.
1. Impact First
Enunciado
El objetivo del framework no es entregar software, sino generar impacto medible en el negocio.
Justificación
La entrega por sí sola no garantiza valor. Una organización puede entregar muchas funcionalidades y aun así no mover ningún resultado relevante.
Implicaciones prácticas
- Cada apuesta debe estar conectada a una métrica de negocio.
- Las revisiones deben discutir resultados, no solo avances.
- El éxito se mide por impacto, no por volumen de entrega.
Anti-patrones que evita
- Celebrar entregas sin impacto.
- Medir velocidad como proxy de valor.
- Confundir actividad con progreso.
Artefactos donde aplica
Bet, Problem Frame, Hypothesis, Validation Result, Decision Record, Metrics Dashboard.
2. Decision First
Enunciado
El recurso más escaso no es la capacidad de construcción, sino la calidad de las decisiones sobre qué construir.
Justificación
La IA acelera la producción, pero también puede acelerar el desperdicio.
Implicaciones prácticas
- Toda apuesta debe pasar por un punto explícito de decisión.
- El Product Builder decide con evidencia.
- Las decisiones importantes deben quedar trazadas.
Anti-patrones que evita
- Ejecutar sin decidir.
- Escalar por presión política.
- Usar IA para acelerar trabajo mal enfocado.
Artefactos donde aplica
Decision Record, Evidence, Bet, Hypothesis, Portfolio Review.
3. Hypothesis Before Solution
Enunciado
Toda solución debe nacer de una hipótesis explícita, no de una opinión disfrazada de requerimiento.
Justificación
Una hipótesis permite declarar qué creemos, cómo lo validaremos y qué evidencia cambiaría nuestra decisión.
Implicaciones prácticas
- Antes de prototipar debe existir una hipótesis.
- Toda hipótesis debe tener métrica, baseline y criterio de éxito.
- Las ideas sin hipótesis no entran al flujo.
Anti-patrones que evita
- Soluciones sin problema claro.
- Requerimientos que no pueden validarse.
- Backlogs infinitos sin criterio.
Artefactos donde aplica
Problem Frame, Hypothesis, Experiment, Validation Plan, Bet.
4. Experiment Before Scale
Enunciado
Nada debe escalarse antes de ser validado mediante experimentos y evidencia suficiente.
Justificación
Escalar prematuramente aumenta costo, deuda y complejidad.
Implicaciones prácticas
- Primero se prueba en pequeño.
- Se priorizan prototipos funcionales sobre documentos extensos.
- Solo lo validado pasa a Spec Driven Development.
Anti-patrones que evita
- Industrializar ocurrencias.
- Confundir prototipo con producto.
- Escalar por entusiasmo, no por evidencia.
Artefactos donde aplica
Experiment, Prototype, Validation Result, Decision Record, Spec.
5. Specification as Source of Truth
Enunciado
Los specs son la fuente oficial de verdad; el código es una implementación de los specs.
Justificación
En entornos AI-native, el código puede generarse rápido, pero sin especificación se pierde trazabilidad e intención.
Implicaciones prácticas
- No se industrializa sin spec.
- Las reglas de negocio deben ser explícitas.
- Las pruebas deben derivarse de los specs.
Anti-patrones que evita
- Código como única documentación.
- Prompts improvisados sin trazabilidad.
- Construcción acelerada sin control.
Artefactos donde aplica
Spec, Requirement, Acceptance Criteria, Business Rules, Test Plan, Release Decision.
6. Quality by Design
Enunciado
La calidad no es una fase posterior ni una persona; es una responsabilidad embebida en el sistema.
Justificación
En AI-native se puede producir más rápido de lo que se puede validar manualmente.
Implicaciones prácticas
- Todos en el pod son corresponsables de la calidad.
- Quality Builder es responsabilidad, no silo.
- No se libera sin evidencia de calidad.
Anti-patrones que evita
- QA al final.
- Testing tardío.
- Seguridad como compuerta final.
Artefactos donde aplica
Acceptance Criteria, Test Plan, Quality Evidence, Security Validation, Release Decision.
7. AI as Amplifier
Enunciado
La IA amplifica la capacidad humana, pero no reemplaza el criterio, la responsabilidad ni la validación.
Justificación
La IA permite prototipar, construir y analizar más rápido, pero puede producir errores si se usa sin criterio.
Implicaciones prácticas
- La IA debe usarse con intención explícita.
- Los outputs generados por IA deben validarse.
- El AI Builder orquesta IA, no simplemente genera código.
Anti-patrones que evita
- Vibe coding sin control.
- Copiar outputs de IA sin revisión.
- Confundir velocidad con madurez.
Artefactos donde aplica
Prompt Log, Prototype, Spec, Test Plan, AI Usage Evidence.
8. Flow Over Coordination
Enunciado
El sistema debe optimizar el flujo de generación de valor, no multiplicar mecanismos de coordinación.
Justificación
En pods pequeños, muchas capas de coordinación dejan de agregar valor.
Implicaciones prácticas
- Menos ceremonias, más flujo.
- WIP explícito por pod, ecosistema y portafolio.
- El AI & Flow Coach optimiza el sistema, no administra tareas.
Anti-patrones que evita
- Reuniones como sustituto de claridad.
- Coordinación excesiva.
- Medir ocupación en lugar de flujo.
Artefactos donde aplica
Flow Metrics, WIP Limits, Kanban Board, Blocker Log, Ecosystem Review.
9. Evidence Over Opinion
Enunciado
Las decisiones relevantes deben basarse en evidencia, no en jerarquía, intuición o presión.
Justificación
La evidencia permite distinguir entre lo que creemos y lo que sabemos.
Implicaciones prácticas
- Toda validación debe producir evidencia.
- Las opiniones deben convertirse en hipótesis.
- Las decisiones deben explicar qué evidencia las soporta.
Anti-patrones que evita
- Decidir por cargo.
- Defender ideas favoritas sin datos.
- Continuar iniciativas por inercia.
Artefactos donde aplica
Evidence, Validation Result, Decision Record, Metrics, Review.
10. Learning is the Product
Enunciado
El principal producto del sistema es aprendizaje validado que mejora decisiones futuras.
Justificación
En contextos de incertidumbre, aprender rápido es una ventaja competitiva.
Implicaciones prácticas
- Los experimentos fallidos también generan valor si producen aprendizaje.
- El conocimiento debe documentarse y reutilizarse.
- Descartar bien es una forma de progreso.
Anti-patrones que evita
- Ocultar experimentos fallidos.
- Medir solo entregas exitosas.
- No documentar decisiones.
Artefactos donde aplica
Learning Log, Experiment, Validation Result, Decision Record, Retrospective.
11. Shared Ownership
Enunciado
El pod es corresponsable del resultado, aunque existan responsabilidades diferenciadas.
Justificación
Product Builder, AI Builder y Quality Builder son responsabilidades, no cargos rígidos.
Implicaciones prácticas
- El Product Builder decide el producto.
- El AI Builder acelera construcción y exploración.
- Todo el pod responde por calidad, aprendizaje e impacto.
Anti-patrones que evita
- "Eso no es mi rol".
- Silos dentro de pods pequeños.
- Calidad delegada.
Artefactos donde aplica
Pod Charter, Responsibility Map, Decision Record, Quality Evidence, Review.
12. Continuous Evolution
Enunciado
El framework es un sistema vivo que evoluciona con métricas, aprendizaje y retroalimentación.
Justificación
La tecnología, el negocio y las capacidades de IA cambian rápidamente.
Implicaciones prácticas
- El sistema debe revisarse periódicamente.
- AI Warriors evolucionan estándares y prácticas.
- Los aprendizajes de los pods deben escalar al ecosistema.
Anti-patrones que evita
- Congelar la metodología.
- Convertir AI-BDF en burocracia.
- Escalar equipos sin escalar capacidades.
Artefactos donde aplica
Maturity Assessment, Metrics Dashboard, Learning Log, AI Warriors Backlog, Framework Change Log.
06 / Niveles
Niveles del framework
Nivel 1: Pod
Donde ocurre el aprendizaje y la creación de valor.
Responsabilidades: Product Builder, AI Builder y Quality Builder.
WIP: máximo 2-3 hipótesis activas.
Nivel 2: Ecosystem
Donde se enfoca capacidad y se alinean apuestas.
Incluye pods, AI & Flow Coach, AI Engineering Leader y Head of Product Builders.
Regla: si entra una apuesta nueva, otra debe salir, pausarse o matarse.
Nivel 3: Portfolio
Donde se decide inversión estratégica.
Regla: la capacidad es finita. No todo entra al portafolio.
07 / Apuestas
Invertir capacidad para validar impacto.
Una apuesta es una decisión estratégica o táctica de invertir capacidad para validar una posibilidad de impacto.
Portfolio Initiative
Bet
Hypotheses
Experiments
PodsEstados posibles
08 / Decision
Flujo de decisión
Definir el problema, usuario, contexto e impacto esperado.
Convertir el problema en una hipótesis verificable.
Construir una versión funcional mínima usando IA.
Validar con usuarios, datos, pruebas o evidencia operativa.
Descartar, iterar, pausar o escalar.
Convertir lo validado en solución confiable mediante SDD.
09 / Gobierno
Reglas de Gobierno
Las Reglas de Gobierno definen las restricciones estructurales del AI-BDF. Mientras los principios orientan la forma de pensar, las reglas de gobierno establecen cómo debe operar el sistema para preservar el flujo, la calidad y la capacidad de decisión.
Estas reglas buscan garantizar que todas las implementaciones del framework mantengan un comportamiento consistente, independientemente del tamaño de la organización o del dominio de negocio.
1. Organización
El Pod es la unidad mínima de entrega
Todo el trabajo de construcción ocurre dentro de un Pod. Ningún trabajo de desarrollo debe ejecutarse fuera de un Pod.
Objetivo: Mantener equipos pequeños, autónomos y responsables del resultado.
Un Pod tiene entre dos y tres personas
Cada Pod está conformado por un máximo de tres personas para minimizar la coordinación y maximizar la velocidad de aprendizaje.
Objetivo: Reducir el costo de comúnicacion y favorecer la toma rápida de decisiones.
Las responsabilidades no son cargos
Las responsabilidades fundamentales del Pod son:
- Product Builder
- AI Builder
- Quality Builder
Estas responsabilidades pueden rotar entre los integrantes del Pod según el contexto.
Objetivo: Favorecer equipos adaptativos y evitar especialización excesiva.
La calidad es responsabilidad del Pod
Todos los integrantes del Pod son corresponsables de la calidad del producto.
El Quality Builder lidera esta responsabilidad, pero no es el único responsable.
La calidad se garantiza mediante los Specs, las evidencias y las validaciones del framework.
Objetivo: Integrar la calidad dentro del flujo de trabajo y no como una actividad posterior.
2. Decision
El Product Builder decide
Dentro del Pod, la decisión final sobre el producto pertenece al Product Builder.
Incluye decisiones sobre:
- qué hipótesis ejecutar;
- qué experimentos descartar;
- cuándo iterar;
- cuándo escalar una apuesta.
Objetivo: Evitar ambigüedad en la toma de decisiones.
El Head of Product Builders prioriza el Ecosystem
Las decisiones sobre asignación de capacidad, priorización de apuestas y dirección estratégica del Ecosystem corresponden al Head of Product Builders.
Objetivo: Alinear la ejecución de los Pods con la estrategia organizacional.
3. Flujo
Ningúna hipótesis escala sin evidencia
Toda hipótesis debe ser validada mediante experimentos y evidencias antes de convertirse en una apuesta de industrialización.
Objetivo: Reducir el riesgo de construir soluciones sin validar.
Ningún producto se industrializa sin Spec
Toda iniciativa aprobada para escalar debe contar con una especificación formal que describa el comportamiento esperado del sistema.
Objetivo: Convertir el conocimiento validado en una fuente única de verdad.
Ningúna liberación ocurre sin Ensure
Antes de liberar un producto, el sistema debe demostrar evidencia suficiente de calidad, seguridad y confiabilidad.
Objetivo: Garantizar entregas confiables sin sacrificar velocidad.
4. Capacidad
La capacidad es finita
La organización asigna capacidad a apuestas, no a proyectos. Toda nueva apuesta requiere capacidad disponible.
Cuando no exista capacidad suficiente, la apuesta permanecerá en estado:
Approved - Waiting for Capacity
Objetivo: Evitar sobrecarga del sistema y proteger el flujo.
Un Ecosystem agrupa un número limitado de Pods
Cada Ecosystem coordina aproximadamente entre cinco y seis Pods, liderados por un Head of Product Builders y habilitados por un AI & Flow Coach y un AI Engineering Leader.
Objetivo: Mantener un alcance organizacional manejable y facilitar la coordinación.
10 / Comparación
Modelo tradicional vs AI-BDF
| Elemento | Modelo tradicional | AI-BDF |
|---|---|---|
| Unidad de trabajo | Historia de usuario | Hipótesis |
| Centro | Backlog | Problema |
| Output | Incremento | Decisión validada |
| Ritmo | Sprint | Loop continuo |
| Validación | Tardía | Continua |
| Coordinación | Alta | Mínima |
| Exito | Entrega | Impacto |
| Calidad | Fase / rol | Sistema |
| IA | Herramienta auxiliar | Amplificador del sistema |
| Gobierno | Control de avance | Decision sobre inversión |
11 / Métricas
Relación con métricas
AI-BDF mide madurez y desempeño mediante cinco dimensiones:
Decision Quality
¿Estamos decidiendo mejor?
Learning & Experimentation
¿Estamos aprendiendo más rápido?
AI Leverage
¿Estamos usando IA de forma efectiva?
Quality & Trust
¿Estamos construyendo con confiabilidad?
Flow
Esta fluyendo el valor sin bloqueos innecesarios?
12 / Frases guía
Frases guía del framework
El sistema ya no está diseñado para construir software. Está diseñado para tomar mejores decisiones más rápido.
La IA acelera la construcción. El framework protege el criterio.
Vibe coding para aprender. Specs para escalar.
No todo prototipo merece convertirse en producto.
El portafolio no decide que hacer. Decide donde no invertir.
Cierre conceptual
Menos desperdicio. Más impacto confiable.
Menos coordinación.
Más criterio.
Menos backlog.
Más hipótesis.
Menos ejecución ciega.
Más evidencia.
Menos software innecesario.
Más impacto confiable.