Circa 2005 there is a classic post on the Joel on Software message board written by Benji Smith about “Why I hate frameworks“.
Update 2026:
Let’s pretend that I want to learn how to code in the era of AI. I decided to get a tutor.
On the first day, I get to class I ask, “I want to learn how to code with AI.”
The teacher says well the way to do that is that is we start in this Visual IDE, and you start typing code, and the IDE uses AI to guess what you need and starts filling out the line. And line by line as you type more, it continues to write code for you.
I reply “Isn’t that inefficient? I thought there was a better way than that?”
The teacher continues, you are right, this is why we started that way, but we do not do it as much anymore. In fact, that was just the beginning. Once people figured that was too slow, along came some AI Chat tools. Using the chat tools you now can put what they want into the chat, and the chat tool would write code snippets. After the chat tool generates the code, you copy and paste the code into the IDE. Do this repeatedly until you build the application.
I look at him with the look that he has two heads. “That does seem a little better, but that does not really scale that well.”
The teacher responds, well that is why we do not code that way either. In fact, not long after the arrival of the chat tools, companies started integrating them into the IDE or creating their own IDE’s that have this chat functionality built in. This way you chat into the IDE, and the the IDE can put the code exactly where you need it. It is like magic. Some of the IDEs and AI combinations will even create new files for you! It is a boom to productivity.
“Great, how can I get started” I rejoiced.
Well of course the teacher replies, it really was state of the art, but we do not code that anymore. The IDE’s gotten better, and allows you to actually write your intent, and it would build more than one section of code. It will build whole small applications. People were feeling it and hence was named Vibe Coding. You feel the vibes and write them as let the AI generate the code.
“Wow, this is what I want, I can build anything this way!”
And as expected, the teacher responds; this is why we do not do it that way anymore. See this was not as efficient as expected, and when building larger systems completely failed. The AI’s would hallucinate and often build very insecure and poorly coded projects.
Disappointed I said “Now what?”
The AI and IDE’s solved that problem. You need to create a series of files that help with the structure of the language, the architecture of the application, and best practices. You need to create a series of markdown files, and then you can give it some prompts to start building the application. This was called Context Engineering.
“Ok, now this sounds really like I can build applications” I grinned.
The teacher then looked at me, shook his head and said, it solved the technology part of it, but not the business part of it. Context Engineering did not last long, as right after that we started working on not only using AI to write code, but to also helping write the requirements. As I always say, if you have good requirements, you will get a better application. Now you work with your partners to describe what you are looking to build; the AI now will ask questions and produce what is called a Product Requirements Documents (PRDs). Such was born Specification-Based Development.
But before you want to jump right and start building that way, it quickly advanced. As AI is very wordy and wrote long PRDs, it was impossible for the AI to have enough context to read all the requirements and the context and build an application. The SPD people extended to include a planning phase; it broke the PRD into smaller user stories, so that the AI could build the application one part at a time. SPD tools are all the rage.
I lit up like a Christmas tree; I could not wait to dig in and start SPD’ing.
Just then the teacher went on, I can see you want to dig in, but we do not use SPD anymore. We found that the amount of code generated by AI was impossible to review by humans. People were so excited to use SPD, that they forgot how much code they could produce, how could any human review it let alone test it.
To solve this, we created Software Factories. The AI would handle everything, give it a requirement, it figures out what you want to build, it creates tests, generates code, runs the tests to make sure it fits, compares to the requirements, does a complete code review and commits the code. It is amazing that all of the AI companies write code this way! The human in the loop is rarely needed. AI has solved building applications; it is the way of the future.
I was amazed. I wondered where I could get my hands on a Software Factory.
The teacher seeing me eager to get started said, stop right there, Software Factories are complex and need to be built custom for each project. And if a project is already in progress, there are a lot of things that need to be done first. You need tests, all kinds of tests, documentation of code that is already written, decisions made, etc. In fact, it is so complex we started thinking of how to build Software Factory Factories.
At that moment I threw my hands up and decided to go into plumbing.















