The Way to Great Software Is Slow and Steady
And you need very little AI for that
Several years ago, I met a guy who worked as an ambulance driver in the area where I grew up.
Not being great at small talk myself, I decided to skip past through it and began asking him a bunch of questions about his work. He was delighted; he clearly loved what he did for a living, and had no patience for small talk either.
Within a few minutes, he revealed to me that he was considered one of the top ambulance drivers in the area. Unsure whether I was supposed to take this seriously or not (after all, I thought to myself, how would you even "rank" an ambulance driver?), I waited a few seconds before laughing, rather responding with a curious look which he interpreted as me wanting to find out more about it.
What he proceeded to explain has stuck with me for many years.
As an ambulance driver, there are a few metrics that matter:
How fast you can get to the scene (and back to the hospital). Obviously this matters as a few seconds can make all the difference.
How many accidents you get involved in. Ambulances apparently get involved in a lot of them; that makes sense given that they're rushing through traffic trying to get their patients to the hospital as quickly as possible.
How stable is the ambulance environment while you're driving it. This is helpful as paramedics may try to help the patient while the ambulance is moving. Too much disruption (like hitting hard on the brakes) makes this much harder.
After he told me all this, I was hooked. I had to know: how did he manage to perform better than the other drivers on all of those metrics?
He explained to me: "It's very simple. At the start, I pick a speed that feels comfortable, slightly on the slow side, and I stick to it. I never increase the speed, and I rarely ever stop". "Everyone else", he continued, "pushes on the accelerator as hard as they can, and then keep hitting the brakes HARD at every intersection or whenever another driver cuts them off. Me, I just keep going: slow and steady".
His ability to calmly focus on the task at hand and not be taken over by the frenzy of the moment literally saved lives.
This little anecdote came back to mind as I was reflecting on what it means to "vibe code" your way into working software.
(If you, like me, don't spend much time on X/Twitter these days, you might have missed out on the conversation around "vibe coding". If that's the case, let me thank you on behalf of your neurons. You're a saner person for it. But just for the purpose of this post, I'll give you the tldr: "Vibe coding" is giving up on your hard-earned skills so that some Silicon Valley CEO or VC can get rich. That's it, you're now a vibe coding expert.)
I realised that this is very much what it feels like to write code with AI. You give it a prompt, and straight away you have code that it would have taken you, perhaps, several minutes to write by hand. It feels like going full speed, pushing hard on the accelerator.
What a huge time saver, right?
Not so fast.
Aren't you at least going to read the code and try to get a sense of what it's doing? That's what you would do if this was somebody else's code and you were being asked to approve its deployment.
So you proceed to read that code. This may take a few minutes, and it feels like slowing down drastically, coming from the high of a few moments ago when you were prompting your way to success.
At this point, you have a few scenarios.
The best possible one is that the code looks fine, reads fine, and is doing what you expect it to. This is the equivalent of driving the ambulance through a road with zero traffic.
The evidence is there to tell us that this scenario is pretty rare. Between hallucinations and the tendency to generate over-engineered, convoluted code, the chances of AI churning out highly readable, production-ready code are as slim as finding no traffic in New York City. It can happen, mind you, but you'd count yourself lucky if it did.
Another scenario is that the code is manifestly wrong. That's like hitting a traffic jam on a tight, one-way street. You'll need to turn around, and try another way altogether, assuming there is one. This is a huge waste of time.
There's a third scenario, and it's the most insidious. It's the one where everything looks good, there's nothing obviously wrong, but in the end the code is broken in some hard-to-find way. Perhaps the LLM made up a non-existent library, or it assumed that you could leverage a feature that your language doesn't actually support.
This is like Google Maps taking the inexperienced ambulance driver to the wrong hospital: everything looks good, you're going to a hospital after all, and you've no reason to doubt the GPS. Except that it's taking you to the wrong place, and by the time you realise (and correct) the issue you'll have wasted A LOT of time.
The veteran driver just knows where to go, and doesn't blindly rely on her GPS.
The same can be said for the software engineer. Nothing wrong with enhancing your experience with an LLM, but ultimately you need to know what you're doing.
Speed alone is not a strategy. AI-generated code offers the illusion of instant progress, but without disciplined scrutiny, it leads to fragile results. The best engineers, like the veteran ambulance driver, move deliberately—balancing efficiency with reliability.
Mastery isn’t speed—it’s knowing that slow and steady wins when precision matters most.