The happiness of the unhappy paths
Photo credit: Job Savelsberg via Unsplash
As vibe coding continues its rapid journey from concept to trend to practice to product, experienced engineers watch with curiosity, unease - and a sense of familiarity.
If you haven’t already encountered this idea, then you may not have been paying attention to your social media feed for the last few months. The idea is that coding tools powered by Large Language Models enable users to describe in plain natural language what they want out of a program, and the tool generates the code. It can even install libraries, run commands and respond to error messages. Like many processes that involve LLMs, the user prompts and nudges and cajoles the tool until it has produced something that they want. Initially, this approach was suggested as a great way to build prototypes, demos and hobby projects but, inevitably, code built this way is finding its way into production.
This is what creates the feeling of unease and familiarity amongst experienced developers. And the unease does not come from a fear for their jobs - rather, it comes from knowing that they will have an awful lot of work to do, and they know just what that work is likely to entail. The familiarity comes from flashbacks to previous generations of user generated code. If they are old enough, they may remember Access databases and Excel macros that they were handed with the instruction to, ‘Just roll this out to the whole company.’ Or they may have experienced being given a set of HTML pages - or even a Powerpoint presentation - that was used for a demo and being asked to, ‘Just finish it off and put it live.’
People who haven’t built software before may imagine that developers spend all their time creating new features - and may be puzzled by why the process appears to take so long, especially when they’re starting with a demo, or a prototype, or some code which has already been built. Why don’t they just build what they’ve been shown?
People who have built software know that, the majority of the time, the demo, or the prototype, or the user generated code, copes with the happy path: the situation when the user enters only correct data, when the records exist as expected in the database, and every component of the architecture is available and working properly. They also know that most of the work lies on the many, many unhappy paths: when the user enters incorrect data by accident, when , when the data is of poor quality, and something has fallen over. And they know that these unhappy paths are traversed with high frequency: they live by the law that, if it is possible for something to go wrong, then it will go wrong (and probably at the worst possible time).
The need to anticipate these unhappy paths, to design and build for them - and crucially, to test for them - seems to be one of the things tripping up early adopters of vibe coding. Prompting your AI tool into giving you a working prototype is straightforward: coaxing it to a deal with all possible failure modes is not as easy - and neither is getting hands on with the code which has been generated, figuring out what it means and how you should change it
This doesn’t mean that vibe coding is a dead-end (although it would be great if we could find something else to call it). I am confident that practices, patterns and products will spring up around it, just like they have done for all other forms of development. Some of these will enable people with limited technical skills to use computers to build things that they never would have thought of building, and some of these will help technical people manage behaviour and components at all layers of the stack - including the new AI layer.
But all of them will need us to imagine what lies down all those unhappy paths, and to do the work that helps us to walk them with confidence.
