Is AI Coding the new MS Access Database

Back in my AIB days in Dublin, before I ever set foot in Singapore, there was always that bank employee who'd built a little Access database to track something the mainframe couldn't. A loan pipeline. A customer follow-up list. A workaround for a report nobody in IT had time to build. It worked. Everyone loved it. Right up until that person left, or the file got corrupted, or someone needed it to talk to another system and it simply couldn't.

In fact – one of my first projects when I moved to Australia was an Access Database migration for one of the countries largest banks.

Someone in the bank had build an MS Access Database to track ‘customer service cases’. There was nowhere to keep track of them – so MS Access seemed the perfect fix. Others saw it, added to it and it grew … and grew … and grew. Now it was driving the work of 600 staff in an operational center for the bank. A diligent employee came in at 5am every morning to kick off a report, print out its hundred’s of pages and distribute them to the 600 staff members. Then he came in at 4:30, because he needed longer to run the report before staff started to arrive.

If that wasn’t bad enough, the problem was about to get worse. Back then MS Access created a single database file. The infamous .MDB file. A single Windows operating system file with the extension .MDB. So what? Well, back then, the Windows operating system (using FAT16) couldn’t handle files that were larger than 2GB. And this access database was getting dangerously close to 2GB – with no sensible way to purge records. So we embarked on a several month project to migrate the database to SQL Server – keeping the reports that drove the work of 600 people. Thankfully the new database could run the report much faster – so no more 4:30am starts.

I've been thinking about that a lot lately, because I think AI coding tools are about to do the same thing to software — just faster, and at a much bigger scale.

The empowerment is real

Let's not undersell what's happening. A product manager, an ops lead, a business analyst who's never written a line of code can now describe what they need in plain English and have a working app an hour later. No ticket in the IT backlog. No six-month wait behind "strategic priorities." No developer explaining why their simple request is actually a three-sprint effort.

This isn't a fringe trend. There are already north of 16 million citizen developers worldwide, and Gartner expects that number to keep climbing fast enough that citizen developers could outnumber professional developers 4-to-1 inside large enterprises within a couple of years. Low-code and no-code adoption drove that shift over the last decade. AI coding assistants are about to pour gasoline on it, because now the "low-code platform" is just... a conversation.

I get why this is exciting. I have spent my entire career in FinTech – long before it was called FinTech. I started out writing RPG/400 programs on the AS/400. Evolved with Windows 3.1, Client Server, Digital Banking, Mobile Banking and now AI. One of the biggest barriers to good customer and employee experience is "what IT has bandwidth to build." AI coding removes that barrier almost overnight. For a lot of real, everyday problems, that's a genuine win.

But I've seen this movie before

Here's my concern, and I want to be careful not to be the guy yelling at clouds — because that guy is usually wrong about where technology is headed. AI coding tools don't just lower the barrier to building something. They lower the barrier to building something without anyone thinking about architecture, security, data governance, or what happens in three years.

Access databases were never really the problem. The problem was what they became: undocumented, unmonitored, business-critical systems running outside of any IT oversight, holding sensitive data, with a single point of failure being whoever built it. Multiply that by every department, every branch, every well-meaning employee with a spreadsheet-sized problem, and you get exactly what shadow IT always produces — a pile of "temporary" tools nobody can inventory, secure, or retire.

AI coding tools have the same failure mode, just with a much lower floor of expertise required to trigger it. You don't need to know Access or VBA anymore. You just need to know what you want. That's the empowering part and the scary part, and they're the same part.

The banking angle

For banks and credit unions specifically, this should get your attention. A citizen-built app that pulls customer data, automates part of an onboarding flow, or touches anything adjacent to PII isn't just an efficiency win — it's a potential exam finding waiting to happen. Regulators don't care that the app was built with good intentions in an afternoon. They care whether it's documented, access-controlled, and auditable. Most of these AI-generated tools will be none of those things, at least not without deliberate governance wrapped around them.

The institutions that get ahead of this won't do it by banning AI coding tools — that ship has sailed, and frankly, trying to ban it just pushes it further into the shadows. The ones who get it right will do what the smarter organizations eventually did with citizen development: build a sanctioned lane. Approved tools, a lightweight review gate for anything touching customer data, a place to register what's been built so it doesn't disappear into institutional memory when the person who built it moves on.

Not a doom take — a governance take

I don't think AI coding is a mistake. I think it's inevitable, and mostly good. But "mostly good and inevitable" describes plenty of technologies that also left a mess behind for someone else to clean up. Every mini app built today by someone who's never had to think about data lineage, disaster recovery, or what happens when three of these tools need to talk to each other is a small IOU against future IT capacity.

The MS Access era taught us that the tools get more powerful faster than the guardrails do. AI coding is that lesson again, just compressed into months instead of decades. The organizations that win this round will be the ones who build the guardrails now, while the pattern is still new — not the ones who wait until the app sprawl is already somebody's Tuesday-morning problem.

— Derek