Specification Driven Development
Or more commonly known as “Back to the future!”, again.
We are in a strange moment in development. We are actually reverting to a way of working that was the state of the art when i first started programming professionally all the way back in 1988 with my first job; programming ADA from a design document that laid out EVERYTHING for the Missile Management System that was going into EAP, the prototype for Eurofighter.
As a programmer I had very little input to this. I had a much more interesting job programming the HUD for the cockpit simulator, this was written in assembler and this was pretty much the wild west of programming, happy days.
Anyway, the programmer (me) in this world was a glorified typist, these systems were much too important to be left to junior programmers and so designers and consultants created the pseudocode and the programmers were just supposed to type in the pseudocode converting to ADA on the way, boring and slow (and i would argue not even more reliable)
We have seen quite a few tools turn up recently, VibeKanban, https://www.vibekanban.com/, SpecFlow. https://www.specflow.com/ and Amazon have copied everyone else, as usual, with their own version.
With the relatively old/new approach of using spec driven design to drive agentic programming we are reverting to the world of programmer becoming typists again BUT the programmer is now an LLM, this is enormous for developers, we have to move up the ladder and be product owners, designers and push the typing to the LLM.
Geoff Huntley takes this to the logical next level with his Ralph approach, I encourage everyone to take a look at his own explanation, The Ralph Wiggum Loop from 1st principles (by the creator of Ralph)
The Ralph Insight
Geoff Huntley figured out something he calls Ralph. The key insight is simple: fresh context keeps the AI smart. When you let conversations get too long, the AI starts making mistakes. It loses track of what it's doing.
So you structure the work differently. Instead of one long session, you run a loop:
Recommended by LinkedIn
The AI forgets everything between iterations. But that's fine, because everything it needs to know is in files: specs that define what to build, a plan that tracks what's done, notes about how to run tests. The AI reads these fresh each time.
This sounds inefficient. It's not. It's like how good programmers write small functions. Each iteration is self-contained. The AI stays in its "smart zone" because it's never juggling too much context.
Lets see it in practice
All this is theoretical and it's difficult to see how to apply it. So I have created a git repo that you can clone and then kick off a Ralph session and watch it create the old unix game, Rogue.
Clone this repo, https://gitlab.com/swissgrammie/rogue-ralph, , follow the instructions in the readme and at the end you will have a working rogue. It takes about 1 to 2 hours to iterate through the specifications already within the project and as it's a well known game it took Claude around 10 minutes to generate the specification documents.
What does it look like? See below, not too shabby at all..
Happy ‘coding’.
PS. This is all very well for new software or standalone features but what about my existing 20M+ lines of code written in COBOL or PL/1, well no surprise we have a solution for you with Heirloom/X.
Good advices, thanks you. :) This phenomena is called context overload. Even though the model might accept much larger context, keeping it small helps focusing better on what really matters for the next response. If there is a need to remember more than the committed code between the loops, you can use a separate *.md file where the AI would summarise important aspects of it's change so that it could "onboard" itself with less effort (input and processing tokens) in the next loop. In Claude code, it have also built in command "/compact" that would shrink the context of the current session history.
Just read this article, I agree with the direction laid out here https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04
Very interesting and well-written
Not that I understand it but it's great to have smart friends.
Exactly what I was doing Graham just around the corner in Lytham St Annes working for GRE. The hardwork those days was getting the specification right and getting through all the Spec reviews. Writing the PL1 was straightforward. I am gravitating back to those days and finding that with clearly written specifications the genAI generate good quality code that works like a dream.