The Future of AI is APEX

Everyone probably has a good idea of how APEX has been or can be enhanced by AI, but in this blog, I’m arguing that the real objective should be how AI can be enhanced by APEX.

As much as we like to think of AI models being intelligent and fully autonomous, they are still built, trained and used by ‘people’, limited by how we approach each of those steps.

Used with that understanding, AI is a fantastic augmenter and accelerator of productivity, if someone competent is involved somewhere in the chain and paying attention, amazing things will be achieved in the coming years.

Human Flaws, Now Automated

However, therein lies the crux of our longer-term problems with AI. These models will make a good developer faster and more thorough, but they won’t turn a bad developer into a good one. In the case of a bad developer, all you're left with is more of the same, much more.

This issue is exacerbated by the self-regulating barrier to entry on development roles essentially being removed. We all started out with varying levels of talent, but one thing we all had in equal measure was a certain passion, enough to have not given up while starting out. AI-driven development removes the pain of learning even a basic, but broad level, of IT knowledge and development practices to start being an active developer.

This is already creating a new reality; many open-source projects are being bombarded with woeful PRs generated entirely by AI and submitted by people with little to no experience. Because of this, AI ‘bans’ are coming in to help protect the accumulated trust many of these projects have spent decades building up with the wider community. [1]

Now, I’ve never bought into the idea of complete doom for development careers that some have predicted, but left unchecked. This wave of activity will put pressure on and change our priorities. ‘Low-skilled’ manual developers (i.e. new devs) will be overtaken by ‘no-skilled‘ AI developers. And those in the middle of their careers will increasingly either be competed out of their wage bracket or morph into more architectural and supervisory roles. Only the best will exist with responsibilities relatively unchanged, entrusted with the ‘old knowledge’ that powers the fundamental infrastructure of the world (e.g. the rise, fall and rise again of COBOL competency).

Fatigue is Worsening

But, even those who transition to supervisory roles must consider ‘review fatigue’. There are plenty of great articles that go into how review fatigue is becoming a problem [2][3], so I won’t go into it here. But to talk about the impact a little bit, we have a wave of (mixed-value) productivity and the only thing protecting production environments is a thin layer of peer reviewers that are expected to spend the entire day checking as much output as possible (unit tests only catch predictable issues, or known issues against regression).

With traditional development, there’s shared responsibility for code output between the developer and the reviewer, and a certain standard of output expected. Now, we’re hearing more about AI agents that carry no responsibility for standards (does it look like it works at worst, does it pass unit tests at best). In this new world, all the responsibility now falls on the reviewer, often the same person orchestrating the one or many AI agents in the first place.

And because this is the one step where an actual person can still be held accountable, every single line must be carefully assessed. Imagine forcing yourself to read a very boring book 8 – 10 hours a day, under pressure to do so as quickly as possible, with all the creative process stripped out and the very real possibility of missing or misreading a line having very public consequences. I’m not surprised this is becoming unsustainable.

Close Enough Isn’t Good Enough

Even with things as they are and where they’re going, there are still industries that will continue to drive demand for human-produced code to avoid the productivity vs. quality clash entirely, i.e. any industry where ‘close-enough’ still unambiguously leads to complete failure.

All these industries are examples where complete accountability is still required. The ability to assign responsibility, pinpoint the exact moment of failure, understand the cause and reform processes to ensure it doesn’t happen again. Or answer for those failures legally and be able to prove that every precaution was taken and no shortcuts were used.

• Medical

• Energy

• Aerospace

• Military

• Banking

• Vehicle Automation

• Robotics

And while more of our lives will inevitably be handed over to automation every year, at certain points, tremendous amounts of trust are required to avoid public backlash, trust that hasn’t been earned yet.

Between output accelerating, checks and balances struggling under the pressure, and the demand for perfect (and accountable) solutions to not only remain but increase, we are in dire need of standards and guardrails for application development to break free of this predicament and truly take advantage of AI.

What is APEXLang?

I present APEXLang, the AI-friendly language of standards and guardrails.

APEXLang (readable and stateless application component definitions) takes the greatest strength of APEX as a whole: it’s secure by default, enterprise-supported, standardised implementation of common application features, and captures those features in the form of a new definition language.

This means APEX can finally take full advantage of CI/CD practices, diff checks, code editor productivity (third-party extensions, autocomplete, highlighting and linting, etc.), version control and most importantly, AI.

Because it’s structured, simple (compared to compiled code at least), and readable, APEXlang is perfect for AI to understand and manipulate. Especially since Oracle have already released AI skills and SQL Developer updates to complement it. [4][5]

Side note: as APEXLang is to APEX applications what DDL is to database objects, should we refer to it as an ADL (Application Definition Language)? Whatever it’s categorised as long term, right now it’s a massive leap forward for APEX and has unlocked a lot of doors for Oracle and APEX developers.

AI Development, Perfected

So if APEX is already a great solution for enterprise problems, i.e. secure applications on a supported and continuously updated platform, and those applications can be developed using AI, we get the benefit of increased output delivered by AI while simultaneously raising standards across the board for AI-based development.

AI-developed APEX applications are by default:

• Secure

• Built on a supported platform (fixes and updates provided by Oracle)

• Cloud native (using OCI)

• Quicker and easier to produce when compared to code-only approaches.

All while still being almost completely customisable.

The review fatigue phenomenon is also reversed, and creativity is restored to the role of a developer. When you’re only coding the structure and component attributes of an application (because APEX takes responsibility for the low-level implementation), there is a significant reduction in the scope of what needs to be reviewed. And because of the secure-by-default nature of APEX, and the guardrails APEXlang naturally inherits from this, trust around the output delivered by AI using APEXlang is exceptionally high in a way that no other method can dream of approaching.

How Far Can We Go

The introduction of APEXlang is a big change, and the coming years could be very consequential if we capitalise on it. Now APEX owns the majority of the no-code/low-code and agent-code space (vibe-code is the established term, but I think it undermines what is now achievable using APEXlang, so agent-code it is). The way to drive this forward is to move into a bigger space entirely.

'Traditional’ web libraries like Svelte, Vue and Angular no longer exclusively benefit from agent-coding. In fact, compared to the benefits APEX now derives, it puts them on the defensive. What I want to see Oracle doing to take advantage of this moment is to continue bold innovations and encroach on its turf.

Here are some outside-the-box ideas:

1. Evolve APEXlang into an official ISO standard, like SQL, e.g. ADL (Application Definition Language). APEXlang can still be the Oracle flavour, but throw open the doors and invite others to join in promoting this new approach to AI development. Terraform exists for infrastructure; why not ADL for applications?
   
   

2. Pursue PWA enhancements aggressively. We need fully offline-able solutions and data synchronisation methods to compete properly in this new space.
   
   

3. Official APEX extension for VS Code. I’d like the app builder attributes panel next to .apx files so I can see the options available and make small changes via GUI if preferred. And have a button to trigger running an application from the page in focus.

Maybe those ideas have an obvious flaw, but I encourage everyone to put their ideas into the community so we can start getting creative with which direction we ask Oracle to go next.

Summary

There’ve been a lot of false starts around AI over the past 2 years. AI being driven forward by APEX-derived standards and improvements feels like the last few pieces of the jigsaw falling into place and a tangible shift towards a new chapter in AI-based development practices.

I hope this blog has provided some genuinely interesting perspectives on the topic and sparks new ideas in others from across the community.

If you'd like to explore what APEXLang and AI-driven development could mean for your organisation, get in touch with our team or continue the conversation with us.

[1] https://medium.com/@livewyer/ai-disruption-to-open-source-software-oss-377f10be2d8a

[2] https://atomicrobot.com/blog/ai-review-fatigue

[3] https://siddhantkhare.com/writing/ai-fatigue-is-real

[4] https://github.com/oracle/skills

[5] https://marketplace.visualstudio.com/items/Oracle.sql-developer/changelog#user-content-26.1.2-may-2026