En un flujo de desarrollo asistido por inteligencia artificial, generar una aplicación rápidamente es solo una parte del proceso. En entornos empresariales también importa cómo se revisan los cambios, cómo se versionan y cómo se mantiene esa aplicación a medida que evoluciona.
Oracle APEX 26.1 aborda este escenario mediante Oracle APEX AI Application Generator y APEXlang, un lenguaje abierto de especificación de aplicaciones diseñado para que desarrolladores, herramientas externas y agentes de IA puedan trabajar sobre una representación estructurada de una aplicación APEX.
La novedad lleva la IA generativa más allá de la asistencia sobre fragmentos de código y la incorpora al ciclo de construcción y evolución de aplicaciones empresariales.
¿Qué es APEXlang?
APEXlang permite representar una aplicación APEX mediante archivos de texto estructurados, legibles y editables, que describen sus componentes. En esa definición pueden representarse elementos como:
- Páginas.
- Formularios y reportes.
- Navegación.
- Componentes compartidos.
- Procesos y lógica de aplicación.
- Autenticación y autorización.
- Automatizaciones.
- Recursos SQL.
- AI Agents y sus herramientas.
Esto crea una representación sobre la cual pueden trabajar tanto desarrolladores como herramientas externas y agentes de IA.
APEXlang no busca reemplazar SQL, PL/SQL o JavaScript ni funcionar como un lenguaje de programación de propósito general. Su función es representar declarativamente el modelo de una aplicación APEX, mientras el código específico continúa utilizándose allí donde la solución lo requiere.
Sobre esa definición, los agentes pueden generar o modificar componentes, mientras APEX continúa utilizando su modelo de aplicación y su runtime para resolver servicios como sesiones, autenticación, autorización, transacciones, acceso a datos, renderizado, workflows y aprobaciones. El resultado generado queda expresado como metadata con una estructura documentada que el equipo puede leer, revisar y modificar.
El agente de IA no genera código de implementación suelto: opera sobre la definición declarativa de la aplicación, mientras APEX sigue resolviendo autenticación, sesiones, transacciones y acceso a datos con su propio runtime.
Del requerimiento a la aplicación: cómo funciona
El flujo puede entenderse en cinco etapas.
- Se define el requerimiento. El desarrollador puede partir de una especificación funcional o describir en lenguaje natural la funcionalidad necesaria. Por ejemplo: crear una página para consultar pedidos pendientes, incorporar filtros por cliente, estado y fecha, mostrar un gráfico por estado y restringir el acceso a determinados usuarios.
- El agente trabaja sobre la definición de la aplicación. Con APEXlang, la estructura de la aplicación queda disponible en un formato que los agentes de IA pueden interpretar y modificar. Esto permite trabajar tanto sobre aplicaciones nuevas como sobre componentes existentes.
- Se genera o modifica APEXlang. Los cambios quedan representados en archivos
.apxy otros artefactos vinculados a la aplicación. La interacción con la IA produce así un resultado que puede incorporarse al proyecto, revisarse y evolucionar junto con el resto de la aplicación. - El equipo revisa y valida los cambios. La definición puede inspeccionarse desde herramientas externas, compararse mediante diff y validarse antes de incorporarla. SQLcl permite, por ejemplo, validar APEXlang sin necesidad de conectarse a una base de datos, y esa validación también puede proporcionar feedback al agente para identificar y corregir errores antes de la importación.
- La definición vuelve a Oracle APEX. Una vez validada, la aplicación puede importarse nuevamente en App Builder y continuar su ciclo habitual de desarrollo, pruebas y despliegue.
App Builder, VS Code, Git e IA dentro del mismo ciclo
APEXlang también modifica la relación entre Oracle APEX y las herramientas externas de desarrollo. Las aplicaciones APEX ya podían exportarse y administrarse mediante control de versiones; la diferencia es que APEXlang incorpora una representación pensada para ser legible, editable, validable y posteriormente importada de nuevo a la plataforma.
Un equipo puede continuar desarrollando visualmente desde App Builder, exportar la aplicación como APEXlang, trabajar desde Oracle SQL Developer for VS Code, utilizar agentes de IA, almacenar los cambios en Git y posteriormente importar la definición actualizada. Más abajo, al cierre de la nota, se detalla un esquema completo de este ciclo.
Un flujo posible sería:
- Desarrollar una funcionalidad desde App Builder.
- Exportar la aplicación como APEXlang.
- Trabajar los cambios desde una rama en Git.
- Utilizar un agente para agregar o modificar componentes.
- Revisar las diferencias generadas.
- Validar la definición.
- Importar los cambios nuevamente en APEX.
Oracle también contempla el uso de APEXlang junto con Working Copies, lo que permite aislar modificaciones, trabajar externamente sobre ellas y posteriormente integrarlas a la aplicación principal.
Para equipos que combinan low-code con prácticas DevOps, esto acerca el desarrollo visual de APEX a flujos habituales de ingeniería de software, sin abandonar el modelo declarativo de la plataforma.
Dónde está realmente el cambio técnico
Una forma útil de analizar APEX AI Application Generator es observar qué parte de la aplicación queda bajo intervención de la IA.
En un asistente de programación convencional, el modelo suele trabajar directamente sobre archivos de implementación: genera funciones, componentes, consultas, APIs o lógica que posteriormente pasa a formar parte del software.
Con APEXlang, el agente puede operar sobre otro nivel: la definición declarativa de la aplicación. Puede indicar qué páginas existen, qué componentes contienen, cómo se relacionan o qué comportamiento deben tener, mientras APEX interpreta esa definición dentro de su modelo de ejecución. Desde el punto de vista de arquitectura, esto desplaza parte de la revisión técnica: el equipo no necesita evaluar únicamente líneas de implementación generadas por un modelo, también puede revisar qué cambió dentro del modelo de la aplicación.
Eso tiene varias implicancias prácticas:
La unidad de revisión cambia
Un diff puede mostrar modificaciones sobre componentes y propiedades de la aplicación. Esto facilita analizar la intención del cambio antes de incorporarlo.
Distintos agentes pueden trabajar sobre un mismo formato
APEXlang funciona como una representación común de la aplicación. El flujo no queda necesariamente ligado a una única interfaz conversacional: Oracle documenta su utilización con diferentes agentes de coding y herramientas externas.
El desarrollo generado sigue dentro del modelo APEX
Las definiciones producidas no constituyen una aplicación independiente del entorno. Se apoyan en los servicios que ya proporciona APEX para ejecutar autenticación, autorización, sesiones, transacciones, acceso a datos, workflows y otros componentes de la plataforma.
La deuda técnica no desaparece: cambia dónde puede aparecer
APEXlang reduce la necesidad de generar determinados detalles de implementación, pero eso no significa que una aplicación generada mediante IA quede automáticamente bien diseñada. Una mala estructura de datos, una autorización incorrecta, SQL ineficiente, una integración mal planteada o una decisión funcional equivocada continúan siendo problemas de arquitectura y desarrollo.
La diferencia es que una parte mayor de la construcción puede permanecer dentro de un modelo declarativo conocido por la plataforma, mientras el código específico se concentra donde realmente resulta necesario. Ese matiz es importante: incorporar IA al desarrollo no elimina la necesidad de ingeniería, modifica qué tareas pueden automatizarse y sobre qué artefactos debe concentrarse la revisión humana.
¿Y las aplicaciones APEX existentes?
APEXlang no está limitado a generar proyectos desde cero. Una aplicación existente puede exportarse en este formato y ser utilizada por herramientas externas o agentes de IA para proponer cambios sobre su definición actual.
Oracle documenta casos como generar nuevas páginas y componentes, realizar modificaciones incrementales, revisar una aplicación o identificar y corregir problemas utilizando la validación de SQLcl.
Esto resulta especialmente interesante en entornos empresariales donde las aplicaciones evolucionan durante años y el trabajo cotidiano está más relacionado con extender, mantener y modernizar que con comenzar nuevamente desde cero.
La IA acelera la construcción, pero la arquitectura sigue importando
La posibilidad de generar páginas, reportes, componentes o modificaciones mediante lenguaje natural puede reducir considerablemente el trabajo necesario para determinadas tareas. Sin embargo, una aplicación empresarial continúa dependiendo de decisiones técnicas y funcionales como:
- Diseño del modelo de datos.
- Reglas de negocio.
- Autenticación y autorización.
- Permisos sobre la información.
- Integraciones.
- Calidad del SQL y PL/SQL.
- Rendimiento.
- Arquitectura de ambientes.
- Estrategia de despliegue.
- Pruebas funcionales y de seguridad.
Un agente puede colaborar en la construcción dentro de esa arquitectura. La calidad de la aplicación sigue dependiendo del contexto proporcionado, de las decisiones de diseño y de los controles aplicados durante el ciclo de desarrollo.
Esto adquiere mayor importancia cuando las aplicaciones procesan información financiera, sanitaria, comercial o transaccional, donde una funcionalidad técnicamente válida también debe respetar reglas operativas, perfiles de acceso y criterios de seguridad específicos.
APEXlang dentro de los proyectos Oracle de Inthegra
En Inthegra trabajamos con Oracle APEX en proyectos de desarrollo, extensión y modernización de aplicaciones dentro del ecosistema Oracle. La incorporación de APEXlang amplía las posibilidades de ese modelo de trabajo al conectar el desarrollo declarativo de APEX con herramientas externas, prácticas de ingeniería de software y agentes de inteligencia artificial.
Para nuevos desarrollos, puede acelerar determinadas etapas de construcción. En aplicaciones existentes, abre posibilidades para asistir tareas de evolución y mantenimiento sin separar el trabajo generado por IA del ciclo habitual de desarrollo de la aplicación.
Desarrollo asistido por IA sobre Oracle APEX
Acompañamos a empresas en la adopción de Oracle APEX AI Application Generator y APEXlang: integración con Git y SQLcl, definición de criterios de revisión y arquitectura de datos, seguridad y despliegue. Como Oracle Partner, llevamos estas capacidades a producción de forma segura y escalable.
Conocer el servicio →Oracle APEX AI Application Generator incorpora así una nueva pieza al desarrollo sobre APEX: una aplicación puede ser expresada mediante una definición estructurada, modificada por desarrolladores o agentes, revisada y versionada con herramientas externas, validada y posteriormente ejecutada sobre la plataforma.
Para los equipos técnicos, el cambio relevante está en cómo IA generativa, desarrollo declarativo y prácticas de ingeniería de software empiezan a operar sobre un mismo ciclo de aplicación. Generar más rápido amplía las posibilidades de desarrollo; entender qué se generó, dónde impacta y cómo se integra a la arquitectura sigue siendo parte fundamental del trabajo.
