Saltar al contenido
Todos los casos

Una plataforma AI-native que convierte especificaciones en software funcional

Lidero la arquitectura de una plataforma que captura el conocimiento de una aplicación como especificaciones estructuradas y lo convierte en software generado y revisable, con verificación automatizada, pipelines de entrega reales y ambientes de vista previa desechables.

  • Ingeniería de software AI-native
  • Ingeniería de nube y plataforma
  • Arquitectura de software

Reto

La IA puede generar código rápido. Un equipo de ingeniería empresarial todavía necesita saber por qué existe ese código, si respeta la arquitectura prevista, si el modelo de datos es correcto, qué cambió entre una ejecución y otra, y si alguien podrá mantenerlo dentro de seis meses. El prompting libre aumenta la producción; por sí solo no construye un sistema confiable de entrega de software.

Contexto

La plataforma tenía que preservar el conocimiento de producto y arquitectura fuera del modelo: estructura del proyecto, especificaciones, entidades y relaciones, comportamiento de los programas, valores por defecto, plantillas reutilizables y las decisiones que dan forma a la aplicación generada.

La meta nunca fue una mejor demo de generación de código. Era un flujo de ingeniería AI-native repetible que las personas pudieran entender, los agentes de código pudieran consumir y los equipos de entrega pudieran revisar, probar, previsualizar y operar.

Arquitectura

Un repositorio de conocimiento versionado es la fuente de verdad de la intención de la aplicación. Describe el sistema en forma estructurada: arquitectura, especificaciones, modelos de datos, programas, relaciones y definiciones de proyecto reutilizables. Los agentes de código y los generadores determinísticos trabajan desde el mismo conocimiento en lugar de reconstruir el contexto desde prompts.

La generación se divide en fases explícitas de planificación y aplicación. El sistema puede determinar qué pretende crear o cambiar antes de que esos cambios se escriban, lo que crea una frontera natural de revisión para las personas y para la verificación automatizada.

El trabajo estructural repetible corresponde a la generación determinística; el razonamiento acotado corresponde a los agentes. El resultado pasa después por las mismas disciplinas que el software escrito a mano: pruebas, revisiones de seguridad, verificación de build, control de versiones y un ambiente de vista previa en ejecución.

Las aplicaciones generadas pueden recibir ambientes de vista previa aislados y desechables mediante infraestructura como código y entrega automatizada. La revisión ocurre entonces contra software funcionando, no solo contra texto generado.

Mi rol

Lidero la arquitectura tanto de la plataforma como del modelo de ingeniería detrás de ella: qué pertenece al repositorio de conocimiento, cómo los agentes consumen especificaciones, dónde la generación debe seguir siendo determinística, dónde el criterio humano sigue siendo obligatorio, cómo funcionan las fronteras de plan y aplicación, y cómo se validan, previsualizan y entregan las aplicaciones generadas.

Decisiones clave

  1. Mantener el conocimiento de la aplicación fuera del modelo

    Por qué
    Los prompts son sesiones; las especificaciones son activos de ingeniería duraderos. La arquitectura, los modelos de datos, el comportamiento y las decisiones deben sobrevivir a los cambios de modelos, agentes y personas del equipo.
    Concesión
    El modelo de conocimiento hay que mantenerlo con la misma disciplina que el software que describe.
  2. Usar generación determinística para la estructura repetible

    Por qué
    Cuando la misma especificación debe producir la misma estructura, la creatividad es un defecto. La generación determinística vuelve predecibles esas partes mientras los agentes se concentran en el trabajo que realmente exige razonamiento.
    Concesión
    Todo lo que el modelo formal no logra expresar queda fuera de la generación determinística hasta que el modelo evoluciona.
  3. Separar la planificación de la aplicación

    Por qué
    Quien revisa debería poder entender qué pretende cambiar un agente o un generador antes de que toque el working tree. El plan se vuelve un punto de control explícito.
    Concesión
    Introduce un paso adicional y exige que la representación del plan siga siendo comprensible conforme la generación se vuelve más sofisticada.
  4. Revisar los sistemas generados mientras están corriendo

    Por qué
    El código generado puede verse razonable y aun así estar equivocado como sistema. Los ambientes de vista previa desechables incorporan comportamiento, integración y experiencia de uso al proceso de revisión.
    Concesión
    La infraestructura de vista previa tiene un ciclo de vida y un costo reales, así que el aprovisionamiento, la expiración y la limpieza hay que diseñarlos y no improvisarlos.

Resultado

La generación asistida por IA se convierte en una capacidad de entrega controlada y no en un prompt aislado. Un cambio puede rastrearse desde la intención y la especificación hasta la salida planificada, la verificación y una vista previa en ejecución. La misma arquitectura ofrece además un modelo reutilizable para adoptar agentes de código en los equipos de ingeniería sin abandonar las disciplinas que mantienen el software mantenible.

Restricciones

Las plantillas de aplicación, el modelo interno de conocimiento, las formas de los productos generados, las cuentas de despliegue y los detalles de entrega propios de la organización se omiten intencionalmente.

Tecnologías

  • AWS
  • AWS CDK
  • ECS / Fargate
  • Aurora / RDS
  • Step Functions
  • GitHub Actions
  • Next.js
  • Node.js
  • PostgreSQL

Este caso está sanitizado. Se omiten nombres de clientes, sistemas internos y detalle confidencial; cuando no es posible compartir especificidades, la arquitectura se describe como patrón.