AI-assisted coding feels a bit like being handed the keys to a race car.
In the right hands, it’s quick, precise and capable of covering a lot of ground in a very short amount of time. In the wrong hands, it’s still quick - and more likely to end badly.
Speed is not the whole story
The obvious comparison is speed. A race car is built to go fast. AI-assisted coding tools are also built to make software development faster. They can write boilerplate, tests, explain unfamiliar code, refactor repetitive patterns and sometimes get you from “rough idea” to “working prototype” in minutes.
This is genuinely useful; a force multiplier, even if we don’t entirely understand what the true cost of it is……. We’ll find out soon enough, when Private Equity stops subsidising our tokens!
I’ve used AI for small scripts, awkward bits of syntax, first-pass test cases and helping me reason about unfamiliar/badly written libraries. Used well and with care, it removes some of the friction & labour-intensive tasks from my workflow. It can be like having a very fast (sometimes inexperienced and over-eager) pair of hands next to you.
But speed by itself is not the goal. A race car going fast in a straight line is impressive, but the driver still needs to brake, turn, read the track, understand the weather, feel grip levels, protect the tyres and know when not to overtake. Software development is similar. Shipping code quickly is great, but only if the code is correct, maintainable and appropriate for the system it’s going in.
The driver still matters
Nobody with half a brain would put someone who has just passed their driving test straight into an F1 car and tell them to set purple sectors. They’ll know the basic controls and be able to point the car in the correct-ish direction. But knowing what the controls do is not the same as knowing how to use them at speed, under pressure, with consequences.
AI has a similar trap, a junior/inexperienced developer or non-technical person can ask an AI tool to build a feature and get back something that looks convincing. It may compile. It may even work for the happy path. But does it handle edge cases? Is it leaking data? Does it fit the architecture? Is it efficient? Is it introducing a dependency we don’t need? Has it silently changed behaviour somewhere else? This is where experience matters, an experienced developer is not valuable because they can type faster than AI. They’re valuable because they know what good looks like, they know what to build. They can spot when the generated code is almost right, but subtly wrong. They know which parts of the answer need testing, which bits “feel” odd and when the fastest-looking route is going to create pain/suffering later (tech debt).
The racing line
Following the racing line on a track is the fastest way to get round. Racing lines are not only about the corner right in front of you, but putting the car on the right place on track, with the correct inputs, to ensure that the next 2, 3, 4 corners are all going to be navigated quick and flow nicely.
A race car is fastest when it stays within the rules of the track. AI needs similar boundaries: coding standards, architecture rules, security requirements and clear prompts. Without this, AI will cut-corners, driving off track, making a mess and possibly damaging parts.
The car doesn’t know the destination
A race car is useless on its own. It needs a driver, a track, a strategy and a team (pit crew, engineers etc).
AI is the same, it doesn’t know what the business really wants, sometimes, even employees don’t and it can be really difficult to articulate that to others, let alone computers. It doesn’t know the history of the codebase, why certain trade-offs were made, and what business decisions led to those trade-offs. It doesn’t know why that 15-year old, ugly code (with // DO NOT TOUCH
comments around it) exists. It doesn’t know that a certain client depends on a weird bit of behaviour from 2015. It will happily remove all of this - just to get to the end of its current task quicker.
Developers/Engineers have always been that link between the business and the technology, the interpreters of business needs into code, the driver between humans and machine. Race teams collect tons of telemetry data from each practice, qualifying and race. But more often than not, the more valuable information comes from the driver, who’s out there piloting the machine, communicating back to the team.
AI isn’t aware of the destination, but damn… it sure is confident a lot of the time! Being confidently wrong can have more junior engineers or non-technical people second guessing their instincts and siding with AI because
“HEY, it’s trained on a
stolenvast corpus of Human Knowledge”.
AI is fast, and can generate a ton of good code, but also a ton of crap. At least when humans are coding, you’re constantly thinking about the problem when you’re constructing the solution. Your subconscious is working and plugging away at any gaps you might have missed. AI will generate a large amount of code before you’ve really understood the problem and thought it through.
Knowing what’s under the bonnet
This comparison also works for me because I like working on my own car. I could pay a mechanic to do everything (but I’m really tight), most of the time it would be much quicker too. But I prefer understanding the problem myself. If something is knocking/leaking, rubbing or not quite right, I want to know why. I want to know what part failed, what the replacement does and whether the fix has actually sorted the problem.
If it’s my car, I want to understand what’s been done to it, why something broke and why the fix works. AI-assisted coding feels similar. It can diagnose a bug, suggest a fix and write the patch. But if I merge the change without understanding it, I’ve outsourced the thinking. I’ve let someone else work on my car, taken the keys back and driven away without checking what they changed. If my name is next to the commit, I’m going to understand it and make sure I stand by what’s been done. Maybe it’s fine. Some people want that abstraction and don’t want to verify things, but others (like me) like to see what’s really gone on. The useful thing about fixing things yourself is that the knowledge compounds. The first time you do a job, it takes ages. You watch videos on YouTube, read forum posts, buy the wrong tool, lose the skin off your knuckles, swear a bit, and eventually get there. The next time is much faster because you understand the system better. Code works the same way. Reading the generated code, tracing the logic, running the tests and understanding why the fix works is the bit that makes you better. AI can speed up the repair, but it shouldn’t remove the learning.
Faster laps need better brakes
The faster the car, the better the brakes need to be. The same is true with AI-assisted development. If you’re going to generate code faster, you need better ways of checking it. That means more tests, code reviews, running it locally and not just trusting the git diff. It means reading the code AI produced as if someone else on the team wrote it and asked you to approve it.
AI does not remove the need for engineering discipline. It increases the need for it. Unit tests, E2E tests and code coverage all become more important metrics for CI/CD. Any code that’s been written by AI, that isn’t tested is a huge liability.
Failing to check what’s been done, like an engineer failing to check the wheel nuts are on securely, well, that is how a race car ends up being parked in a wall at 200mph.
Knowing when not to accelerate
One thing I like about experienced racing drivers is that speed is not constant. They don’t just keep their foot down because the car is capable of it. They lift off (don’t get me started on Super Clipping). They brake early. They wait. They defend. They preserve the car for later in the race. They read the race and adjust their approach.
There are times when AI is brilliant:
- Generating boring boilerplate
- Writing first-pass tests
- Explaining unfamiliar code
- Converting one data shape into another
There are also times when I want to be more careful:
- Security-sensitive code
- Database migrations
- Authentication and authorisation
- Anything involving money
- Large refactors across a codebase I don’t fully understand
In those areas, AI can still help, but I don’t want it driving. I want it in the passenger seat like a co-driver in WRC. I can see the road ahead, but having someone there by my side, quickly providing clarity of things on the way, is the way I want it.
The pit crew matters too
Race cars are not just driver and engine. There is a whole team and data around them. Engineers, telemetry, mechanics, strategy, tyre experts, fuel load, data from previous laps.
Software has the same thing. The better the surrounding engineering setup, the more useful AI becomes. A clear codebase, good tests, small pull requests, useful logs, consistent patterns and fast feedback loops all make AI safer to use.
If the project is already messy, AI can multiply that mess very quickly. It will copy the patterns it sees, including the bad ones. If there are five different ways of doing the same thing, it’ll probably invent a sixth. AI won’t create engineering culture & standards, it amplifies the one you already have.
So is AI good or bad?
I don’t think that’s the correct question. Is a socket wrench good or bad?
A race car is not good or bad. It’s a tool built for a purpose. On track, with the right driver and supporting team, it’s amazing. A machine, put together by incredible humans, made up of thousands of individual parts working together in perfect harmony. However, put that car in the wrong place, with bad parts or give it to someone who doesn’t respect what it can do, and it’s dangerous.
This is where I’m at with AI-assisted coding. I’m not scared of it, and I’m not interested in pretending it isn’t useful. It is incredibly useful. It can make good developers faster. It can help remove some of the duller parts of the job. It makes learning easier and prototyping quicker.
But it doesn’t replace judgement. If anything, it makes judgement more important. The skill moves from “can I write this code?” (which is now “Yes” for anyone with access to AI) to “is this the right code, in the right place, for the right reason?”
The best drivers get more out of the car, and win more races. Poor drivers don’t win in fast cars. AI has the same multiplier effect.
That is still software development.
Just with a faster engine.