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:

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:

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:

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:

Prompt
   ↓
APEXlang
structured application definition
   ↓
Review
Git diff + rules + validation
   ↓
Import
   ↓
APEX application

The roles are different:

AI
↓
accelerates

APEXlang
↓
makes the intent visible

Developer
↓
controls

That is a much better enterprise development model than:

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:

"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:

APEX application
      ↓
APEXlang export
      ↓
Git
      ↓
change
      ↓
diff
      ↓
review
      ↓
merge
      ↓
import

Now consider AI inside the same process.

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:

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:

Requirement
    ↓
Developer interpretation
    ↓
Implementation

With generative tools, another model becomes possible:

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:

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:

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.

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:

Generate
   ↓
Validate
   ↓
Review
   ↓
Deploy

not:

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:

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 →

APEXlang makes that discussion much more concrete.

The missing layer between:

natural language

and:

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:

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:

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:

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.