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.
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
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
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.
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.
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.
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.