# APEXlang and AI-Assisted Oracle APEX Development > **Based on a 2026 Oracle APEX Budapest Meetup talk** > > This article is based on material I presented at the **Oracle APEX Budapest Meetup on June 10, 2026**, during a session about **Oracle APEX 26.1 and AI-assisted development**. > > The focus here is APEXlang: why I believe it represents more than a new export format, and why it may become an important bridge between Oracle APEX, source control, AI-assisted development and enterprise governance. For years, Oracle APEX has given developers a higher level of abstraction. We do not normally build every page by writing low-level code. Instead, we describe what we want: - a report - a form - a validation - a process - a navigation entry - an authorization rule APEX turns those declarations into a working application. That declarative model is one of the reasons APEX can be so productive. But AI-assisted development introduces a new question: **How can an AI understand an APEX application well enough to help us build and modify it safely?** This is where I find **APEXlang** particularly interesting. ## APEXlang is not just another export format At first glance, APEXlang can look like a different way to export an APEX application. I think that interpretation is too narrow. The more important idea is that the application becomes available as a **readable, structured application specification**. In other words: ```text Business intent ↓ APEXlang specification ↓ Review and governance ↓ Running APEX application ``` That changes how we can think about an APEX application as a development artifact. Traditionally, an export was often something we mainly associated with: - deployment - migration - backup - source control APEXlang adds another possibility: **the application definition itself becomes something humans, development tools and AI assistants can reason about.** ## An Open Application Specification Language The way I described APEXlang in my presentation was: **an Open Application Specification Language for Oracle APEX.** The important word here is not only *language*. It is *specification*. APEXlang describes the application at a higher level. It focuses on the application's structure and intent rather than trying to represent everything as low-level implementation code. That makes it naturally compatible with the declarative philosophy APEX has always had. APEXlang is designed to be: - declarative - human-readable - AI-friendly - file-based - versionable - mergeable - suitable for review - compatible with modern development workflows This is an important distinction. The goal is not: > Generate as much code as possible. The goal is: > Express the application clearly enough that people and tools can understand what it is supposed to do. ## From black box to readable source Low-code platforms have always had an interesting challenge. They give us abstraction and productivity. But that abstraction can also make the application definition harder to inspect outside the development environment. A traditional export may be technically useful while still being difficult to: - read - compare - review - validate - explain to an AI model APEXlang addresses this visibility gap. Conceptually: ```text Traditional application export harder to read harder to diff harder to review harder for AI to interpret ↓ APEXlang readable versionable diffable reviewable validatable AI-friendly ``` That matters even without AI. But AI makes the value much easier to see. ## A simple APEXlang example An application specification can describe things such as: ```text page "Sales" { id: 5 identification { name: Sales title: Sales } security { authentication: pageRequiresAuthentication } regions { region "Sales Dashboard" { identification { name: Sales Dashboard type: classicReport } source { location: localDatabase type: sqlQuery } } } } ``` Even without knowing every detail of the syntax, a developer can understand what is being described. There is: - a page - a title - an authentication requirement - a report region - a database source This is very different from asking an AI assistant to infer the structure of the application from screenshots or an opaque deployment artifact. ## The AI needs application context When AI assistants work well with source code, one reason is simple: **they can see the source.** They can analyze: - files - functions - dependencies - structures - changes Historically, that has been more difficult with low-code applications. The application may be perfectly understandable inside the low-code IDE, while an external AI tool has very little useful context. APEXlang helps close this gap. Instead of giving the AI screenshots and saying: > Guess how this application works. we can give it a structured application definition. That creates much better conditions for AI-assisted development. ## This is not "vibe coding for APEX" One of the messages I emphasized in the meetup was that APEXlang should not be interpreted as uncontrolled AI code generation. The workflow I find more interesting looks like this: ```text Prompt ↓ APEXlang structured application definition ↓ Review Git diff + rules + validation ↓ Import ↓ APEX application ``` The roles are different: ```text AI ↓ accelerates APEXlang ↓ makes the intent visible Developer ↓ controls ``` That is a much better enterprise development model than: ```text Prompt ↓ Generate something ↓ Hope it works ``` The intermediate specification matters. ## Why the intermediate representation matters A prompt is temporary. A specification can become a durable development artifact. Suppose I tell an AI: > Create a customer search page. That prompt alone is not enough for a serious business application. We still need to know: - which data source it uses - which fields are searchable - which users are allowed to access it - how navigation works - which components belong to the page - what validations apply - how the result fits the rest of the application In an enterprise environment, we need something persistent between the idea and the running application. Conceptually: ```text "Create a customer search page" ↓ APEXlang ↓ structured specification ↓ review ↓ controlled application ``` This is where I see APEXlang becoming much more than an export mechanism. ## AI speed with enterprise control Generative AI is very good at increasing speed. Enterprise software development needs something else as well: **control.** We need to be able to answer questions such as: - What changed? - Who reviewed the change? - Is the application still secure? - Can we reproduce the application? - Can we compare two versions? - Can we validate the result? - Can we audit the development process? AI generation does not remove these requirements. If anything, faster generation makes them more important. The faster we can create software, the more important it becomes to understand what has actually been created. ## Source control becomes more meaningful A file-based, readable representation naturally fits source control better. A possible workflow becomes: ```text APEX application ↓ APEXlang export ↓ Git ↓ change ↓ diff ↓ review ↓ merge ↓ import ``` Now consider AI inside the same process. ```text Requirement ↓ AI-assisted generation ↓ APEXlang change ↓ Git diff ↓ Developer review ↓ Validation ↓ APEX ``` This is a very different development model from letting an AI modify production application behavior without a visible intermediate step. ## The developer stays in control One of the most important points for me is that APEXlang does not make the APEX developer irrelevant. I believe the opposite is more likely. AI can generate. APEXlang can make that generation visible. But someone still needs to understand: - the business requirement - the APEX model - Oracle Database - security - architecture - performance - maintainability That remains the developer's responsibility. I summarized the roles like this: ```text AI accelerates APEXlang makes the application intent visible Developer understands, evaluates and controls ``` The developer's job does not become: > Write every component manually. But it also does not become: > Type a prompt and accept whatever appears. The role moves toward: - understanding intent - evaluating generated specifications - correcting them - approving them - validating architecture - protecting security and maintainability ## From implementation to application intent This is a broader change in how I think about AI-assisted development. The most important artifact may increasingly become the **application intent**. Traditionally we often move from requirement to implementation like this: ```text Requirement ↓ Developer interpretation ↓ Implementation ``` With generative tools, another model becomes possible: ```text Requirement ↓ Structured application intent ↓ AI + developer ↓ Implementation ``` APEXlang gives that structured intent a possible technical form. That is why I find the philosophy behind it more interesting than the syntax itself. ## A generative APEX development lifecycle The development lifecycle I presented can be summarized like this: ```text Requirements business intent ↓ AI Generation prompts + agents ↓ APEXlang ↓ Source control merge + diff ↓ Application Builder ↓ Application ↓ Runtime ``` But the flow is not necessarily strictly linear. Developers may work directly in Application Builder. AI tools may generate or modify application specifications. Source control may contain the shared definition. The important point is that these paths can converge around a common application artifact. That creates a new balance between: **business intent → AI → developer tools → review → running application** ## APEX was already prepared for this idea What makes this particularly interesting is that APEX has always been declarative. The platform already works at a higher level of abstraction. We do not normally say: > Generate the HTML, JavaScript, server logic and database interaction for this complete report manually. We say: > This is a report. The platform knows how to implement it. That is one reason I think APEX and generative AI fit together naturally. AI is much more useful when it can operate on concepts that have clear meaning. For example: ```text page region report form item validation process authorization navigation ``` These are already part of the APEX vocabulary. APEXlang makes that vocabulary available in a form external tools can work with. ## The "what", not only the "how" One of the design goals I find particularly important is abstraction. APEXlang aims to describe **what** the application should contain rather than forcing developers to express everything in terms of **how** the platform internally implements it. This mirrors the strength of low-code itself. A low-code platform gives developers leverage because they work with higher-level concepts. AI can potentially benefit from the same abstraction. Instead of generating large amounts of low-level code, the AI can work with application concepts. That is a much more attractive direction for maintainable enterprise software. ## Human-readable matters It is tempting to think that if AI generates the application, humans do not need to understand the generated representation. I strongly disagree. Human readability becomes even more important when generation becomes faster. If a generated specification is readable, the developer can ask: - Is this really what we wanted? - Is this page correct? - Is authentication required? - Did a new region appear unexpectedly? - Did the SQL source change? - Has a security rule disappeared? Human readability makes AI output reviewable. Without reviewability, enterprise adoption becomes much harder. ## Diffable matters Imagine asking an AI: > Add a new filter to the customer search page. I do not only want the result. I want to see the change. ```diff customer search page + item "Country" + source: CUSTOMER.COUNTRY_ID + lov: COUNTRY_LOV ``` The exact syntax is less important than the principle. A developer should be able to review what changed before accepting it. This is one of the reasons source-control-friendly application definitions are important. ## Mergeable matters Team development also requires merging changes. One developer may work on one part of the application. Another developer may work on another. An AI assistant may propose a third change. If the application definition can participate in normal source-control workflows, these changes become much easier to manage systematically. This brings low-code development closer to development practices that are already familiar in code-centric environments. ## Validation matters AI can produce incorrect output. This is not unique to AI. Developers produce incorrect output too. The difference is speed. AI may produce a large amount of incorrect output very quickly. That makes validation essential. A structured specification creates opportunities for automated checks before a change becomes a running application. The principle is: ```text Generate ↓ Validate ↓ Review ↓ Deploy ``` not: ```text Generate ↓ Deploy immediately ``` ## Governance matters For enterprise applications, governance is not optional. We need standards. For example: - naming conventions - security requirements - approved components - architectural patterns - logging requirements - accessibility rules - database standards If application intent is represented in a structured way, it becomes easier to imagine automated governance around it. An organization could potentially verify that generated application changes comply with its internal rules before they are accepted. That is much more interesting than AI generation alone. ## AI-assisted development is broader than generation At the June 2026 meetup, the broader theme was **AI-assisted development** in Oracle APEX. Generation is only one part of that. AI may help developers with: - understanding existing applications - explaining PL/SQL - generating initial structures - suggesting changes - documenting applications - analyzing reports - creating test ideas - working with project knowledge The important question is not: > Can AI generate an APEX application? The more useful question is: > Where can AI remove repetitive work while keeping the application understandable and controlled? ## APEXlang as context for AI assistants One particularly useful role for APEXlang is context. An AI assistant needs to understand the application before giving useful advice. A readable application definition can give it that context. A workflow could look like this: ```text APEX application ↓ APEXlang ↓ AI assistant ↓ "Explain this page" "Where is this authorization used?" "Which pages depend on this shared component?" "Suggest how to add this requirement" "What changed between these two versions?" ``` This may be just as valuable as generation. In mature enterprise systems, understanding existing applications is often more important than creating new applications from scratch. ## This connects to something I was already thinking about In 2023, I was already asking what generative AI could mean for Oracle APEX application development. At that time, one of the interesting possibilities was moving from natural-language requirements toward generated application structures. I wrote about that evolution here: **[Generative AI in Oracle APEX: From a 2023 Vision to APEX 26.1 →](https://davidpataki.com/generative-ai-in-oracle-apex-from-a-2023-vision-to-apex-26-1)** APEXlang makes that discussion much more concrete. The missing layer between: ```text natural language ``` and: ```text running application ``` can now become a structured application specification. That is an important architectural difference. ## Prompt engineering is not enough Another reason I like this direction is that it moves the discussion beyond prompt engineering. A good prompt is useful. But enterprise application development needs more than a good prompt. It needs: ```text Requirement + Application model + Data model + Security + Standards + Existing application context + Review ``` The prompt is only one input. APEXlang can provide a more durable representation of the application itself. ## The future APEX developer I do not expect the APEX developer to disappear. I expect the role to change. Less time may be spent on some repetitive implementation tasks. More time may be spent on: - business analysis - data modelling - architecture - security - defining application intent - reviewing AI output - integration - validation - governance That is not a weaker developer role. It is a role operating at a higher level of abstraction. ## The database still matters It is also important not to separate this discussion from Oracle Database. An APEX application is not only a collection of pages. In serious business systems, much of the value is in: - the data model - SQL - PL/SQL - constraints - security - integrations - transactional consistency AI-assisted APEX development still depends on these foundations. APEXlang can describe more of the application layer. It does not remove the need to understand the database underneath it. This is why my own professional journey still feels continuous: ```text Oracle Database ↓ Oracle APEX ↓ Oracle Cloud ↓ AI-assisted development ``` AI is not replacing the previous layers. It is building on them. ## What should APEX teams do now? My recommendation at the meetup was not to try to transform everything at once. Start with a small use case. For example: - explain an existing report - analyze an APEX application definition - generate documentation - explain PL/SQL - create a small application specification - build an internal project assistant Then measure the value. Look for: - time saved - fewer errors - faster onboarding - less repetitive work - better documentation And build reusable patterns. For example: ```text prompt templates PL/SQL packages REST wrappers logging authorization patterns review processes ``` AI usage itself is becoming a development skill. Developers need to learn: - how to ask - how to provide context - how to verify - how to recognize risk - how to control the result ## The real question is not how much AI can generate AI can generate more and more. That is becoming less surprising every year. For enterprise development, I think the more important questions are: > Can we clearly express what the application should do? > Can we inspect what the AI created? > Can we compare it with the previous version? > Can we validate it? > Can we review it? > Can we govern it? > Can we maintain it five years later? That is why I believe APEXlang is important. ## Looking back from 2026 When I look at APEXlang, I do not mainly see a new file format. I see the continuation of the original APEX philosophy. APEX has always allowed us to describe applications at a higher level than traditional hand-coded development. APEXlang takes that declarative model and makes it more visible to: - developers - source control - development tools - automation - AI assistants That visibility may become extremely important in AI-assisted software development. ## The idea in one sentence If I had to summarize the philosophy in one sentence: **APEXlang connects the speed of AI with the declarative model of Oracle APEX and the control required by enterprise software development.** The future question may not be: > How much code can AI generate? It may be: > How clearly can we express, validate and govern application intent? That is the direction I find much more interesting.