AI Built My App. Then It Took Me Back to 1991.

I’ve spent a good ‘few’ hours over the past couple of weeks, playing around with ChatGPT Work.

And by “playing around”, I seem to have accidentally become a software engineer again 🤓

It started with building my new website. Then came an app for tracking my social media content, followed by a couple of pet projects, including one for organising and researching all the material I’ve collected on the West Cork Railway over the past 30-odd years… as you do

What has genuinely surprised me is just how much you can now build with AI. I’m not talking about asking ChatGPT to knock up a nice-looking web page. By a fair amount of trial and error, we’ve built repositories in GitHub, connected them to Vercel to build and deploy the applications, used Supabase for the databases, Sanity for content management and integrated the whole lot together.

And by ‘we’ I mean, me, ChatGPT Work, Manus as my AI ‘devils advocate’ and Gemini now and again to double check stuff …

What ‘we’ did

So to cut a long story short, I speak to ChatGPT, to explain what I want to do, have a conversation about how it might work, get ChatGPT to build it, get it into the GitHub repository, Vercel then deploys this onto a staging server etc etc … all automatically … And then I get to test it, tell it what’s wrong and go around the loop again… all with an idiot ‘test’ guide from ChatGPT.

That really is quite incredible.

But, of course, building something is only part of the story.

A few days ago, one of my apps went rogue.

And suddenly it was 1991 again.

What the hell is this thing doing?

I started getting warnings from Supabase because one of the applications was generating a frankly ridiculous amount of network traffic.

The database itself was tiny, about 52 MB. Yet the application was managing to transfer something approaching a gigabyte of data a minute while, from my perspective, it was sitting there doing nothing.

There was nothing on the screen to suggest anything was wrong. The app worked. I could click around it. Nothing crashed. There were no flashing red lights.

Under the covers, however, some flawed logic meant it was repeatedly dragging data out of Supabase. Lots of it. Again and again and again and again. 100’s of times per minute.

That was where this stopped being simply an exercise in getting AI to build an app and became a debugging exercise.

We needed to work out what was happening in the browser, what was happening on the PC, what requests were being made to Supabase, what Vercel could see, whether anything was polling continuously and why a 52 MB database could result in gigabytes of network traffic.

So we all went down the rat hole.

We ended up building a live network and resource monitor into the staging version of the application so I could see the requests, reads, writes, amount of data transferred, rolling totals and, importantly, what operation in the application was responsible for them.

And, to be fair to ChatGPT, it was bloody good at this. Once we had made the problem visible, we could start isolating what was causing it and fixing the underlying logic.

But the more we got into it, the more familiar the whole exercise started to feel.

I’d been here before.

Not with React, Vercel, Supabase, browsers and AI agents, obviously. But with systems doing something completely unexpected underneath while everything looked reasonably innocent on the surface.

I started my career as a software engineer in Dublin in the early 1990s. I worked for a small Irish software company which was effectively a body shop for a UK company, with development also being done in India. We were doing client-server when client-server was still relatively new, migrating applications from IBM mainframes onto OS/2 systems.

That meant things like LU 6.2 communications, IBM CICS, SQL databases, servers, green screen dumb terminals and plenty of opportunities for things to go wrong in interesting ways.

And boy did they what…

I remember spending a couple of all-nighters, sitting on the floor of the data centre of one of Ireland’s major banks at three or four o’clock in the morning, trying to debug an IBM 3270 dumb-terminal data stream coming from a CICS mainframe and going into a Stratus server.

I was literally sitting on the floor with an oxygen hood beside me in case the fire-suppression system went off, trying to figure out what the hell was happening. I was told you had 15 seconds to get the hood on and get out … I never found out if that was true to be honest. But you tend to remember nights like that.

Then there was KEV.TXT. When I joined Ingres in 1993, we had a major new Ingres release on OS/2, and one of our biggest customers had an unexplained race condition. We spent ages tracking it down, eventually found the problem, fixed it, rebuilt the software, put it through QA and released the production version.

Then the customer came back to us. “Why is there a file called KEV.TXT that keeps getting created on C:\Kev.”

Now it might actually have been KOD.TXT. It was more than 30 years ago. Whichever one it was, it was definitely mine.

While we had been debugging the race condition, I’d built a debug routine into the software. If debugging was turned on, it recorded all the information we needed. When debugging was turned off, it didn’t record anything.

The problem was that although I had correctly disabled everything that wrote to the debug file when building the release, I had forgotten to disable the bit that actually created the file.The ‘if debug’ condition had been commented out.

So our nice clean production system was happily creating an entirely harmless, completely empty KEV.TXT.

Today, you’d probably change the offending line, run the tests and deploy a new build over the wire, SaaS and all that.

That wasn’t quite how it worked in my day.

We had to do a complete rebuild and put the software back through the full QA process. Build out the new Master CDs, test all them again and then ship the 17 CDs to the customer, who was in Australia. If memory serves me correctly, it took something like three to four weeksof extra QA to get rid of an empty text file with my name on it.

Experience is what you get when you don’t get what you want.

There were plenty of others. I remember being in another bank, this time in Spain when I was with Compaq, late at night trying to debug an OS/2 driver that was causing a SCSI hard disk system to fail.
So back in the day, I’ve spent way more hours than I care to remember chasing race conditions, communications problems and bugs where what you could see happening bore little or no resemblance to what was actually causing the problem.It was all way under the hood.

So I’ve been there, done that and got a lot of the T-shirts, as the saying goes.

Which is probably why, strangely enough, I’ve quite enjoyed finding myself back down this particular rat hole over the past week or so.

Building it is becoming the easy bit

There is a much bigger point in all of this for me.

What you can now do with ChatGPT Work, Claude Code and similar tools is incredible. I can build things today that I simply wouldn’t have attempted myself a couple of years ago, and I can do it at a speed that would have been unimaginable when I was writing software professionally.

But the experience has also reminded me that being able to generate the software isn’t the same thing as understanding the software.

AI can build exactly what you asked it to build. It can also build what it thinks you asked it to build. And occasionally it can build something completely crap and way off spec. The problem is that a stupid version can look perfect.

I’ve asked it to create a new page in an application and had it come back looking exactly as I wanted, only to discover later that rather than using the design system and master layouts we had already created, it had re-invented its own styling, embedded CSS and bypassed the architecture we had ‘agreed’ on.

And this finally leads me to the biggest issue I had in the app, the one that almost got me blocked. I had an export function in the social media app that appeared to work perfectly. Click the button, get the result. Nothing obviously wrong with it.

Except under the covers it was pulling enormous amounts of unnecessary data from the database.

That is the bit I think gets lost in some of the excitement around AI and software development.

Yes, AI can build the application. The harder problem is getting it to keep building the same application coherently as it evolves.

You need some governance around it. We’ve progressively had to add architectural rules, design rules, Git and branching rules, documentation standards, testing procedures and explicit instructions about things it should check before making changes. Those rules live with the project in GitHub rather than depending on either me or ChatGPT remembering what we agreed three days ago.

And even then, you have to check.

That has probably been one of my biggest lessons from the past couple of weeks. The conversation is moving very quickly from “Can AI write software?” Of course it can. That’s a no brainer.

For me, the more interesting question is how you manage an AI that writes software… and not just today, but over its lifecycle.

• How do you stop architectural drift?
• How do you make it follow decisions made previously?
• How do you make sure a perfectly innocent-looking change hasn’t introduced something ridiculous somewhere else?
• How do you monitor what the resulting application is actually doing?
• And how do you get the AI to obey all those rules consistently?

We’re now at the slightly bizarre point where I’m using AI to help write governance rules for AI, which we then put into the repository so the AI can read the rules before it changes something.

And yes, occasionally it still ignores them 😳

The other lesson is that you still need to have some idea what the hell is going on under the covers.

I certainly couldn’t sit down today and write the kind of software I was writing more than 30 years ago. I don’t need to. AI can write JavaScript, SQL, CSS and all the other stuff far faster than I ever could.

But apparently I still have enough scar tissue to recognise when something doesn’t look right.

An AI telling me a problem is fixed when the monitor is telling me otherwise. A page that looks perfect but has completely ignored the architecture. That, I suspect, is where experience becomes quite interesting in the AI era.

You don’t necessarily need to know how to write every line yourself. But knowing what questions to ask, knowing when the answer doesn’t make sense and knowing when to keep digging rather than accepting “it works” will actually become more important.

Thirty-odd years ago for me, that meant sitting on the floor of a bank data centre at four o’clock in the morning with an oxygen hood beside me, trying to work out what an IBM data stream was doing. It turned out that an update to the CICS systems had added in 5 extra ‘bytes’ to the 3270 data stream, so all our ‘screen scraping’ on the Stratus was off. I kid you not.

So today I can sit here and ask an AI agent to instrument the application, analyse the calls, inspect the database logic and help me figure out why it is merrily transferring a gigabyte of data a minute.

The tools have changed beyond recognition.

But every so often you still find yourself staring at a system and asking the same question I was asking in 1991:

What the hell is this thing actually doing?

And I have to admit, I still quite enjoy finding out.

So I’m curious, who else has been off building a website or some sort of app? and what has your experience been like?

Kev.