Modelo operativo y transformación
Qué significa realmente AI-native Software Delivery
Una definición operativa que conecta intención, contexto, ejecución, aceptación y aprendizaje en la entrega de software con IA.
Joan ArandaLa expresión AI-native Software Delivery necesita una definición que permita decidir. Si solo describe un equipo que utiliza IA, apenas nos dice cómo trabaja, qué puede delegar o por qué deberíamos confiar en lo que entrega.
Propongo entenderla como un sistema de entrega diseñado para incorporar trabajo generado por IA, con intención explícita, contexto suficiente, condiciones de aceptación y capacidad de aprender de cada ejecución. Es una definición de trabajo, no un estándar de la industria.
La palabra “native” no exige automatizar todo. Señala que la organización ha tenido en cuenta estas capacidades al diseñar su forma de producir y validar software. El juicio humano puede seguir siendo central.
Cinco preguntas para examinar el sistema
Antes de elegir una herramienta o añadir agentes, examinaría cinco preguntas. No obligan a crear cinco documentos: en una tarea pequeña pueden resolverse de forma breve.
| Parte del sistema | Pregunta | Evidencia útil |
|---|---|---|
| Intención | ¿Qué comportamiento necesitamos y qué queda fuera? | Ejemplos y criterios de aceptación |
| Contexto | ¿Qué restricciones y decisiones debe respetar el trabajo? | Contratos, reglas e invariantes relevantes |
| Ejecución | ¿Qué puede delegarse y dentro de qué límites? | Alcance de la tarea y permisos de actuación |
| Aceptación | ¿Cómo comprobaremos el resultado y quién lo acepta? | Pruebas, revisión y responsabilidad explícita |
| Aprendizaje | ¿Qué debe conservarse para la próxima tarea? | Decisiones, fallos y evidencia reutilizable |
La calidad de la respuesta depende también de las relaciones entre estas partes. Una especificación puede ser clara y omitir una restricción importante. Una implementación puede superar las pruebas disponibles y seguir sin resolver la intención original. Un cambio aceptado puede dejar una decisión valiosa sin registrar.
Un ejemplo deliberadamente pequeño
Consideremos una aplicación ficticia de reservas. Queremos permitir la cancelación cuando faltan al menos 24 horas para el inicio. No es un cliente real ni una experiencia de producción.
La intención parece sencilla, pero necesitamos aclarar qué reloj es autoritativo, qué ocurre exactamente en el límite y qué estados permiten cancelar. También debemos decidir si la operación se puede repetir sin volver a liberar capacidad o enviar otra notificación.
El contexto incluye el comportamiento existente y los consumidores de la operación. La ejecución puede delegarse al agente dentro del módulo elegido. La aceptación requiere casos de límite y estado, además de revisión de integración. El aprendizaje conserva la decisión sobre el reloj y el motivo de evitar efectos duplicados.
Generar la función es solo una parte del recorrido. La utilidad de la IA dependerá de cuánto ayude al conjunto y de qué coste introduzca en comprensión, revisión y corrección.
Qué cambia para un responsable de ingeniería
Esta definición cambia la pregunta de inversión. En lugar de limitarse a “¿qué herramienta añadimos?”, permite preguntar “¿qué parte del sistema limita la entrega y qué capacidad necesitamos mejorar?”.
Si la intención es ambigua, ampliar ejecución puede aumentar las propuestas que hay que rehacer. Si falta contexto, conviene hacer accesibles las restricciones relevantes. Si la aceptación depende de una persona sobrecargada, más generación no elimina ese cuello de botella. Si los errores se repiten, quizá falte aprendizaje entre tareas.
No se deduce que todas las organizaciones deban centralizar esas capacidades de la misma forma. Un equipo pequeño puede coordinarse con mecanismos ligeros. Varios equipos con sistemas compartidos pueden necesitar acuerdos más explícitos.
La definición no es una garantía
Un flujo con documentos y puntos de validación puede generar burocracia. También puede crear una ilusión de control si la evidencia no comprueba el comportamiento importante. Por eso cada mecanismo debería justificar qué decisión mejora o qué incertidumbre reduce.
Tampoco existe una etiqueta que demuestre productividad. La investigación de DORA describe la IA como amplificador del sistema organizativo existente; esa observación invita a examinar el sistema, pero no predice el resultado de un equipo concreto.
Mi criterio para usar la expresión es este: podemos explicar qué trabajo se delega, qué condiciones permiten aceptarlo y cómo la experiencia modifica la siguiente ejecución. Si solo podemos enumerar herramientas, la definición todavía no ayuda a entender nuestra forma de entregar.
Referencias
- DORA, State of AI-assisted Software Development 2025: contexto sobre capacidades organizativas; no prueba de este ejemplo.
- Birgitta Böckeler, Understanding Spec-Driven-Development: lectura complementaria sobre diferencias entre enfoques y mantenimiento de especificaciones.
Las cinco preguntas y el ejemplo son una propuesta editorial propia preparada para esta publicación. No describen activos internos de hiberus.