Does Software Architecture Need a Rethink Because of AI?

I recently watched an episode of John Collison’s Cheeky Pint podcast with Sam Altman. One topic that caught my attention was what the “global software upgrade” might look like. This discussion starts 12 seconds into the podcast and relates to the recent PHP security vulnerabilities and whether we should reassess how we architect and build software to make it more resilient to AI-based attacks.

If AI makes it easier to generate code and find vulnerabilities, should that change how we build applications? I think it raises another question: how much code should we be generating in the first place?

As an APEX developer, I have often marveled at the complexity of some software architectures and wondered how teams keep them maintained and secure. It turns out it is very difficult.

Opportunities for APEX

I think this presents several opportunities for APEX. APEX runs in the Oracle Database, with ORDS routing browser requests to the APEX engine. This reduces the amount of application-specific code and infrastructure a team must secure and maintain.

This benefit also applies to upgrades and patching. APEX applications use a shared engine that renders pages and processes requests from metadata stored in the database. When Oracle fixes a vulnerability in that engine, applications using the affected functionality can benefit from the same platform fix.

That does not remove our responsibility for application security. We still need to review authorization, custom code, integrations, and configuration, and test our applications after upgrades.

Note: There is a tradeoff here. A vulnerability in a shared runtime can affect many applications, just as a fix can benefit many applications. Centralizing those responsibilities makes disciplined platform maintenance essential.

Reducing the amount of application-specific code results in less software to secure and maintain.

At AI World this year, Scott Spendolini demonstrated what a React app looks like compared to an app developed using APEXlang. What stood out to me was how much of the implementation APEX handles for the developer, and what that could mean for maintaining the app after it is built.

APEXlang makes the AI connection more concrete. It represents an APEX application definition as readable text that developers and AI agents can generate, inspect, version, secure, and validate. The APEX engine uses application metadata stored in the database at runtime. Applications may still include custom SQL, PL/SQL, and JavaScript.

As AI allows us to build more applications faster, maintenance and security matter even more. For me, that makes APEX’s approach (less application-specific code, backed by a shared engine) more compelling than ever.