I’m back
I have to be very honest. I have been lazy and undisciplined. My routine has not changed that much compared to when I was actively writing, yet I decided to put writing aside for later. That later took months (I don’t even want to make the count).
I realized that my ideas are important (to me) and I do want to write them down. So hopefully I will start writing a bit more instead of waiting months.
Current State of Spec-Driven development
I came across this video (https://youtu.be/b6cbxSaa4U4?si=g1wDFOLra4U9daFR) which gives a very high-level overview of how these frameworks have grown and evolved.
There is a part of the video in which the creator shows criticism of Spec-driven development. That’s something that I have seen on other videos and articles as well.
I’m going to be rough on my next statement, but it is my impression that these guys that criticize this techniques are just a bunch of smart asses. Real world is like school. Your classroom will have a small percentage of geniuses, a small percentage of bad apples. Then a vast majority of average joes. This is the real world.
Of course that if you are a smart ass, you don’t need Spec-driven development. You can just plan your next task with Claude with surgical precision and execute accordingly. You will beat up Claude every time it messes up, because you are smarter, and you will get shit done quickly.
The rest of the world does need guidance (some more than others, obviously), and need structured process to achieve consistent results. The aim of Spec-driven development is to provide that structured process so the code generated by the AI is more precise. The trick is to know when it makes sense to leverage this, and when it is better and faster to interact with Claude or Cursor or whatever.
Software Engineering at Scale
I’ve been lucky enough to have experience on very large enterprise projects, both as programmer, as Lead/Architect, but also as Manager. My analogy about real life being like a class room is not something I just farted, that is something I have observed for the past 20 years.
This is why on any serious company with a serious IT department, you will find “SOPs” about how to do something:
- We create feature branches this way
- Commit message should be written this way
- Code should or should not have comments
- Functional over procedural programming
All the above made-up examples exist in real world for one reason: consistency and predictability. This is for the average Joes to have a structure way to doing things. Spec-driven development is very similar in a way; when used correctly, it does help increase consistency and predictability, while it sacrifices speed along the way.
When you are in large enterprise projects, some of them are multi-year programs, with hundreds of developers trying to push features on the same system, consistency and predictability become key, because those are key elements of the delivery process.
Also, for those that are curious enough, Spec-driven development frameworks become the ignite spark to figure out how do they do it. And they become better at context engineering. Then they can be smart asses saying that Spec-driven development is not needed, because you can gather your context more precisely by hand. I’m just kidding on my last paragraph.
I’m glad I decided to write something back, even if I did it with some cursing down the way. Anyway, this blog is mine and targeted at my future me, so I don’t care.