DEV Community

Cover image for AI-DLC de AWS: Hacia un ciclo de vida del desarrollo de software nativo de IA.

AI-DLC de AWS: Hacia un ciclo de vida del desarrollo de software nativo de IA.

Actualmente, muchos equipos utilizan la inteligencia artificial para analizar requisitos, formular preguntas, explorar alternativas, generar código, crear pruebas, explicar errores o redactar documentación. Aunque estas herramientas aceleran actividades concretas, normalmente son las personas quienes organizan el proceso, deciden cuándo recurrir a la IA y determinan cuál será el siguiente paso.

Amazon Web Services (AWS) propone una visión diferente: AI-DLC (Artificial Intelligence–Driven Development Life Cycle; Ciclo de Vida de Desarrollo Impulsado por Inteligencia Artificial).

En AI-DLC, la inteligencia artificial no se limita a responder solicitudes. También analiza el objetivo, formula preguntas, prepara planes, propone alternativas y ejecuta las actividades después de recibir la aprobación humana. Este patrón se repite durante todo el desarrollo.

La metodología fue creada por Raja SP y su equipo en AWS. Raja es Principal Solutions Architect (arquitecto principal de soluciones) y lidera programas de transformación para desarrolladores dentro de AWS.

La IA propone el camino y ejecuta el trabajo aprobado; las personas aportan contexto, revisan los resultados y toman las decisiones importantes.

Para entender cómo funciona, aplicaremos AI-DLC a un proyecto hipotético: una aplicación web para reservar citas médicas.

El equipo del proyecto

En nuestro ejemplo participarán:

  • María, Product Owner o PO (responsable del producto): explica la necesidad, responde las preguntas y valida lo que se construirá.
  • Diego, Developer (desarrollador): revisa los diseños, el código y las pruebas.
  • Jose, arquitecto de soluciones: interviene cuando deben evaluarse integraciones, requisitos no funcionales o decisiones técnicas.
  • Un agente de IA: formula preguntas, crea planes, propone artefactos y ejecuta el trabajo aprobado.

El arquitecto de soluciones no se presenta como un participante obligatorio en todas las actividades. Lo incorporamos como especialista porque AWS menciona la participación de arquitectos y señala que, durante la construcción, el equipo debe aclarar en tiempo real las decisiones técnicas y arquitectónicas.


Fase 1: Inception

Inception (concepción) es la fase en la que el equipo comprende lo que necesita construir y organiza el trabajo.

Su principal ritual es Mob Elaboration (elaboración colaborativa). Durante esta sesión, el equipo revisa conjuntamente las preguntas y propuestas generadas por la IA. No se trata de que cada participante prepare documentos por separado para transferirlos posteriormente, sino de aclarar y decidir en tiempo real.

Aplicamos el Intent

El proyecto comienza con un Intent (intención), una declaración de alto nivel sobre lo que se desea conseguir.

María, como PO, comunica:

Crear una aplicación web que permita consultar los horarios disponibles y reservar una cita médica.

La IA no comienza generando código. Primero pregunta:

  • ¿El paciente debe registrarse?
  • ¿Puede cancelar o reprogramar una cita?
  • ¿Cómo se evitarán reservas duplicadas?
  • ¿Cómo recibirá la confirmación?

María aclara el comportamiento esperado. Diego identifica posibles restricciones de implementación y Jose señala que la aplicación deberá integrarse posteriormente con el sistema de médicos y horarios de la clínica.

Con estas respuestas, la IA genera artefactos como:

  • User Stories (historias de usuario).
  • Acceptance Criteria (criterios de aceptación).
  • NFR, Non-Functional Requirements (requisitos no funcionales).
  • Riesgos y criterios de medición.

Estos artefactos no se aceptan automáticamente. El equipo los revisa y solicita cambios hasta estar de acuerdo.

Aplicamos las Units

Después, la IA divide el proyecto en Units (unidades de trabajo). Cada Unit agrupa una parte cohesionada de la solución que puede construirse con cierta independencia.

Para nuestro proyecto propone:

  1. Gestión de médicos y horarios.
  2. Reserva y reprogramación de citas.
  3. Confirmaciones y recordatorios.

María valida que las Units cubran la necesidad inicial. Diego revisa si pueden desarrollarse de manera independiente y Jose analiza sus integraciones.

La IA también propone un Workflow Plan (plan del flujo de trabajo). Como AI-DLC es adaptable, no todas las iniciativas deben pasar por las mismas actividades. Un proyecto nuevo puede necesitar requisitos, diseño y pruebas completas, mientras que una corrección sencilla podría avanzar directamente hacia la generación de código.

Nuestro ejemplo es un proyecto greenfield (desarrollado desde cero), por lo que requiere mayor elaboración antes de comenzar a programar.

Aplicamos un Bolt

Las Units se construyen mediante Bolts (iteraciones aceleradas). Un Bolt es un ciclo breve, normalmente medido en horas o días, en lugar de las varias semanas que podría durar un sprint tradicional.

Para la Unit de reservas, la IA propone el siguiente Bolt:

Implementar la consulta y selección de horarios disponibles, generar las pruebas y presentar el resultado al equipo.

El PO y los desarrolladores revisan el alcance. Si consideran que es demasiado grande, pueden dividirlo antes de aprobar su ejecución.

Fase 2: Construction

Construction (construcción) transforma las Units aprobadas en software probado.

Su ritual es Mob Construction (construcción colaborativa). Durante este proceso, la IA propone los diseños, planes de implementación, código y pruebas; mientras el equipo aclara las decisiones técnicas y arquitectónicas en tiempo real.

En nuestro proyecto, la construcción de la Unit de reservas sigue este recorrido.

Domain Design

La IA propone un Domain Design (diseño del dominio) con los conceptos y reglas principales:

  • Paciente.
  • Médico.
  • Horario.
  • Cita.
  • Estado de la cita.

También identifica reglas como impedir que dos pacientes reserven el mismo horario o liberar el horario cuando una cita sea cancelada.

María confirma que las reglas representan el comportamiento esperado y Diego revisa que no existan contradicciones.

Logical Design

Después, la IA genera un Logical Design (diseño lógico), donde convierte las reglas anteriores en una propuesta técnica.

Aquí Jose, como arquitecto de soluciones, adquiere mayor participación. Revisa:

  • Cómo se consultarán los horarios.
  • Cómo se evitarán reservas simultáneas.
  • Cómo se integrará la aplicación con otros sistemas.
  • Cómo se protegerá la información.
  • Qué ocurrirá si el servicio de notificaciones falla.

La IA puede presentar varias alternativas, pero la decisión final pertenece al equipo.

Código y pruebas

Con el diseño aprobado, la IA prepara un plan numerado para generar:

  • La lógica de reserva.
  • Las interfaces necesarias.
  • Las validaciones.
  • Las pruebas.
  • La documentación.
  • Los archivos de despliegue.

El plan debe ser revisado antes de comenzar. AI-DLC prioriza la planificación y los puntos de aprobación para evitar que una suposición incorrecta avance hasta el código.

Después de la aprobación, la IA genera el código y las pruebas. Diego revisa la implementación y valida que pueda comprenderla, mantenerla y corregirla. Jose vuelve a intervenir solamente si el resultado modifica alguna decisión de solución.

El resultado es una Deployment Unit (unidad desplegable): código, configuraciones y pruebas preparados para ser desplegados.

Fase 3: Operations

Operations (operaciones) comprende el despliegue, la observación y el mantenimiento de la solución.

La IA utiliza el contexto acumulado durante las fases anteriores para analizar infraestructura, despliegues, métricas y errores bajo la supervisión del equipo.

En nuestra aplicación podría detectar:

  • Aumento en los tiempos de respuesta.
  • Errores al consultar horarios.
  • Intentos frecuentes de reservar citas ocupadas.
  • Fallos en el envío de confirmaciones.

La IA puede analizar el problema y recomendar una acción, pero el equipo conserva el control sobre las decisiones relevantes.

Los rituales mantienen la supervisión humana

Mob Elaboration y Mob Construction no son reuniones adicionales agregadas al proceso. Son la forma en que AI-DLC organiza la colaboración entre la IA y las personas.

Ambos rituales siguen un ciclo sencillo:

  1. Las personas proporcionan una tarea o intención.
  2. La IA crea un plan y formula preguntas.
  3. El equipo proporciona aclaraciones.
  4. La IA ajusta su propuesta.
  5. Las personas aprueban el plan.
  6. La IA ejecuta.
  7. El equipo verifica el resultado.

Así, la velocidad de la IA no elimina la responsabilidad humana. Cada propuesta puede ser revisada antes de ejecutarse y cada resultado debe validarse antes de continuar.

¿Qué cambia frente al desarrollo asistido?

En el desarrollo asistido, la persona podría solicitar:

Analiza estos requisitos e identifica preguntas pendientes.

Después, otra persona puede iniciar una conversación diferente para diseñar la solución y, posteriormente, solicitar pruebas o código.

En AI-DLC

El equipo comunica una intención y la IA participa en un flujo continuo:

  1. Analiza el contexto disponible.
  2. Propone preguntas y aclaraciones.
  3. Prepara un plan.
  4. Espera la revisión humana.
  5. Genera los artefactos aprobados.
  6. Recomienda el siguiente nivel de trabajo.
  7. Conserva las decisiones como contexto.
  8. Ejecuta únicamente después de recibir aprobación.

Las personas también formulan preguntas, modifican los planes y proponen alternativas.

AI-DLC no reduce su participación. Organiza la colaboración para que la IA pueda tomar mayor iniciativa sin adquirir autonomía completa.

En el desarrollo asistido, las personas conducen el proceso y recurren a la IA para determinadas actividades. En AI-DLC, la IA también ayuda a conducir el proceso, mientras el equipo controla las decisiones y valida los resultados.

Los 10 principios de AI-DLC, en breve

  1. Reimaginar, no adaptar: no limitarse a insertar IA en un proceso antiguo.
  2. Invertir la conversación: la IA también formula preguntas y propone cómo avanzar.
  3. Integrar técnicas de diseño: diseñar antes de generar la implementación.
  4. Reconocer la capacidad real de la IA: aprovecharla sin otorgarle autonomía completa.
  5. Atender sistemas complejos: utilizarla donde existen reglas, dependencias y decisiones relevantes.
  6. Conservar artefactos útiles: mantener aquello que aporta contexto, control y trazabilidad.
  7. Facilitar la transición: utilizar conceptos relacionados con prácticas conocidas.
  8. Simplificar responsabilidades: reducir divisiones y transferencias innecesarias.
  9. Minimizar etapas: conservar únicamente las actividades que aportan valor o control.
  10. Evitar flujos rígidos: adaptar el recorrido a la complejidad de cada trabajo.

Conclusión

AI-DLC no plantea que la inteligencia artificial reemplace al equipo ni que construya software sin control.

La propuesta es establecer una colaboración diferente: la IA pregunta, planifica, descompone, genera y analiza; mientras que el PO, los desarrolladores y los especialistas aportan experiencia, corrigen supuestos y aprueban el trabajo.

En nuestro proyecto aplicamos los principales elementos del documento:

  • Intent: expresa lo que se desea conseguir.
  • Unit: divide el proyecto en partes cohesionadas.
  • Bolt: permite construirlas mediante ciclos breves.
  • Domain Design: define conceptos y reglas.
  • Logical Design: convierte esas reglas en una solución técnica.
  • Code and Tests (código y pruebas): materializan el diseño.
  • Deployment Unit: reúne el resultado listo para desplegarse.
  • Mob Elaboration y Mob Construction: organizan la colaboración entre la IA y el equipo.

Ese es el cambio que AWS propone: dejar de utilizar la inteligencia artificial solamente como una herramienta que recibe órdenes y comenzar a integrarla como una colaboradora que ayuda a conducir el desarrollo, siempre bajo supervisión humana.


Fuentes

Top comments (0)