AI is a Race Car, Not Autopilot | ryansouthgate.com
AI-assisted coding feels a bit like being handed the keys to a race car.<br>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.<br>Speed is not the whole story<br>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.<br>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!<br>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.<br>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.<br>The driver still matters<br>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.<br>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).<br>The racing line<br>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.<br>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.<br>The car doesn’t know the destination<br>A race car is useless on its own. It needs a driver, a track, a strategy and a team (pit crew, engineers etc).<br>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.<br>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.<br>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<br>“HEY, it’s trained on a stolen vast corpus of Human Knowledge”.
AI is fast, and...