PRD Revenge

Vibe vs Agile in the ultimate showdown

There was a time, ages ago, some point after the Pleistocene, when I started hearing this word “agile.” It fluttered here and there on the wind, agile, drifting into my ears more and more like a riff I couldn’t quite decide if I liked, but couldn’t get rid of either. What was this Agile (now capitalised) that all the software types I worked with were talking about?

Then out of nowhere there I was, working with people who were doing this full on. They had this new method of building software, one where you didn’t create big software Product Requirements Documents (PRD) to follow to the letter because, with humans, the result would invariably be totally different from the thing plopped on your server months later. Instead, you were to go bit by minimally viable bit, fleshing out an application as you went along. It made a ton of sense at the time.

Now software is being built not by humans, but by other software in the form AI, specifically with this mysterious dark art (regrettably) dubbed “vibe coding.” There are worse analogies I’m sure, but not many. Bear in mind this practice is all of a couple of months old, but it’s sweeping across the plains of software like some sort of anime world engulfing storm.

This storm is mainly driven by Product Requirements Documents (PRD) as exemplified to stupefying degrees by Ryan Carson, who is exemplifying more nice dude down the block you borrowed a saw from than 5x founder, so is quite watchable. What this “new” practice entails is lots of lists and playbooks telling the robots what to do to the letter, and as Ryan points towards, checkpoints and checklists to make sure the human in the equation has some oversight of what their doing.

The issue now with designing software is now having to think it all out a lot better instead of diving right in as you would with Agile. It’s essentially PRD Revenge. Ljubljana’s (don’t worry about pronunciation, we get it) Codeplain take it one step further by creating a human-compliant spec language the robots can understand and follow better. It would be great to see things like this where you just have a spec and nothing else. You modify it, the robots are supposed to match the spec. You maintain the doc and that should be that. The tablets are given on the mount and your command forthwith obeyed for millennia. Or until the robots or the APIs get updated and then it’s all out the window maybe.

What this means is that you, the software product designer, are now the product manager and owner. You have and draw the map to the territory and get the robots to traverse it. But it’s not figuring it out as you go though. There is no sketching per se. But there is an interesting creative tension in the creation of the PRD, going back and forth with other robots if it’s feasible, etc. It’s up to designers though to learn how to make better maps and more importantly get more humans involved in drawing the mountains and the lakes in.