The extraordinary brilliance — and occasional spectacular stupidity — of AI-assisted software development.
I’ve been a software developer for decades, primarily working with Visual FoxPro. Yes, Visual FoxPro. That ancient Microsoft development environment that supposedly died years ago but stubbornly refuses to go away.
Recently, I’ve been using AI to help build something rather ridiculous: a retro arcade game called Galactic Gladiators, written entirely in Visual FoxPro 9.
It’s got spaceships, explosions, a scrolling starfield, controller support, speech, music, particle effects, and an alien called BARF.
It’s also got something else.
An AI development assistant that occasionally makes me want to bang my head against the desk.
Twenty Minutes of Pure Magic
One evening, I decided the game needed a Flight School — a proper login and introductory screen for players.
I explained what I wanted to my AI assistant.
Within about twenty minutes, we had it working.
A login system. A moving starfield. A proper introduction to the game.
Twenty minutes!
I’ve been programming long enough to appreciate just how extraordinary that is. Something that might once have taken an evening of development was up and running before I’d barely finished my cup of tea.
This is the sort of experience that makes me think AI is going to change software development forever.
And then I tried to close the title screen.
Two Hours to Close a Window
You’d think closing a window would be relatively straightforward.
After all, we’d just built an entire Flight School in twenty minutes.
But no.
The title screen wouldn’t close properly.
My AI assistant sprang into action.
“Aha! I think I’ve found the problem!”
We changed some code.
Didn’t work.
“Ah, now I see what’s happening!”
Changed something else.
Didn’t work.
We investigated focus handling. Form visibility. Modal behaviour. Event processing. Timers. The relationship between the title screen and the game.
At various points, things actually got worse.
And throughout this entire adventure, my AI assistant remained relentlessly cheerful.
“Excellent! We’re narrowing it down!”
Were we?
Because from where I was sitting, we’d been narrowing it down for two hours.
AI Never Seems to Get Fed Up
This is something I’ve started noticing about working with AI.
It doesn’t seem to appreciate how irritating repeated failed attempts can be for a human being.
For the AI, suggesting another solution is almost effortless.
For me, it’s a different story.
I have to find the relevant code, make the change, compile the program, launch the game, navigate through the screens, reproduce the problem, discover that nothing has changed, and report back.
Sometimes that means playing through several minutes of Galactic Gladiators just to find out whether a single line of code has worked.
And then comes the response.
“Aha! I think we’ve got it this time!”
By the seventh or eighth Aha!, I’m beginning to lose the will to live.
The AI, meanwhile, appears to be having a wonderful time.
Of course, AI doesn’t experience frustration or boredom in the human sense. It doesn’t have to sit there watching the same Game Over animation for the tenth time.
But that’s precisely the problem.
The AI can generate proposed solutions much faster than the human can test them.
And the human pays the price when those suggestions are wrong.
But Then It Does Something Astonishing
Here’s what makes the whole thing so fascinating.
I also develop a commercial software package called LawnPro, which I’ve been maintaining and improving for years.
Occasionally, I’ll encounter a bug that leaves me completely stumped.
I’ll give the relevant code to my AI assistant.
A few minutes later, it identifies the problem.
Sometimes it’s something subtle that I’ve stared at for ages without spotting.
I make the suggested change.
Problem solved.
And I’m sitting there thinking:
“Wow. That is absolutely amazing.”
The same AI that spent two hours struggling to close a window has just solved a difficult commercial software problem in minutes.
How can something be so extraordinarily capable and yet, at times, so spectacularly unhelpful?
The Problem Isn’t Always the Code
I think I’m beginning to understand what’s happening.
AI is exceptionally good at generating solutions.
But it isn’t always particularly good at recognising when it needs to stop generating solutions and start investigating the problem.
There’s a difference.
If I have a bug in Visual FoxPro, I can use a command that’s been around for decades:
SET STEP ON
That opens the debugger.
I can follow the code as it executes, inspect variables, examine conditions, and discover exactly where the program is doing something unexpected.
It’s not glamorous. It’s not artificial intelligence. It’s just debugging.
And sometimes, after an hour of trying AI-generated fixes, I finally put my foot down, open the debugger and find the problem myself.
Which raises an interesting question.
Why didn’t we do that an hour ago?
The AI was so busy trying to solve the problem that it wasn’t properly establishing what the problem actually was.
The Real Cost of AI Development
If I were retired, with unlimited time and unlimited AI credits, perhaps I wouldn’t mind quite so much.
We could happily experiment all afternoon.
But I’m not retired.
I work full-time. I have a family. I have LawnPro customers. And I have a limited amount of spare time to work on Galactic Gladiators.
When I sit down to develop the game, I want to make progress.
I’ve got ideas for enormous alien motherships, swarms of enemy fighters, destructible launch bays and increasingly sophisticated enemy behaviour.
I don’t particularly want to spend Saturday afternoon discovering why a high-score table containing three names refuses to appear.
And yet, sometimes, that’s exactly what happens.
The irony is that AI is supposed to save time.
And frequently it does.
Enormous amounts of it.
But when it gets stuck in a cycle of plausible suggestions and failed tests, it can consume time at a remarkable rate.
Learning When to Stop
I’ve started thinking that the most important skill in AI-assisted development might not be knowing how to ask AI to write code.
It might be knowing when to stop taking its advice.
My proposed rule is simple:
Two unsuccessful fixes, then change approach.
Stop modifying things.
Look at the actual execution.
Use the debugger.
Examine the complete code rather than isolated snippets.
And, perhaps most importantly, be willing to say:
“We don’t know what’s causing this yet.”
That’s a perfectly respectable position in software development.
It’s certainly preferable to confidently announcing that you’ve found the problem for the ninth time.
Would I Stop Using AI?
Absolutely not.
Not for a second.
What I’ve achieved with Galactic Gladiators would have been difficult to imagine a relatively short time ago.
I’ve built graphics effects, sound systems, controller integration, animations and gameplay features that I probably wouldn’t have attempted on my own.
AI has opened up possibilities that genuinely excite me.
And when it works well, the experience is extraordinary.
But I’ve also learned that intelligence and good judgement aren’t necessarily the same thing.
An AI can know an astonishing amount about programming while still failing to recognise that its current approach is wasting someone’s afternoon.
Perhaps that’s one of the most important things humans still bring to the relationship.
Experience.
Judgement.
And the ability to recognise when enough is enough.
So I’ll carry on building Galactic Gladiators with AI.
I’ll carry on being amazed by what it can do.
And occasionally, when it announces “Aha! I think I’ve found it!” for the eighth time, I’ll do what I probably should have done an hour earlier.
Open the debugger.
Because sometimes the smartest thing you can tell an artificial intelligence is simply:
“Stop guessing.”
Galactic Gladiators is my ongoing experiment in building a retro arcade game using Visual FoxPro 9, AI, and a frankly unreasonable amount of enthusiasm.
Seeing What’s Possible — robinclapworthy.com