From Vibe Coding to a Software Factory
Climbing the ladder of maturity isn't difficult, you only need to know what level you are
In February 2025, Andrej Karpathy needed one tweet to name what thousands of people were already doing, including (to some extend) myself. He called it vibe coding: you "fully give in to the vibes" and forget the code even exists. It was half a joke, framed around throwaway weekend projects. The joke escaped the lab and within weeks, vibe coding was a hiring filter, a startup pitch, and by November, Collins Dictionary's Word of the Year [1]. And somewhere along the way the term split into two meanings that people now use with equal conviction: the fastest way to build software in history, and an insult for unmaintainable slop. In my opinion, both camps are right. The distance between those two meanings isn't a matter of opinion, but we should see it as a ladder. And at the top of it sits something that didn't have a name a year ago either: the AI software factory, where specs go in, software comes out, and no human reads a line in between. The Software Factory is what we want to achieve, Vibe Coding is what we want to avoid.
I didn't learn that ladder from a framework. Earlier this year, on Bill Inmon's Substack, I told the whole story: how a small frog game I built for my daughter became my AI laboratory, how pasting Codex snippets made me maybe 25% faster, and how Cursor then made me feel so fast that I stopped reading the code entirely. Features landed, screens appeared, and what piled up underneath was legacy at record speed, like a 2,000-line class file that even the AI refused to touch. ("This is a very large file." Yes. You wrote it.) Here's what matters for this article: the way out was not going back to reading every line. I never did, and if you've vibe-coded for six months, you won't either. I climbed out a different way, by applying what I have learned for years: standards, specifications, and an agent team that now ships my software. That climb, and the ladder it runs on, is what this article is about.
Getting to maturity: the 5 Levels
Before we start with the 5 Levels (which is inspired by our Vane Loop AI Maturity Ladder), let me sketch out 2.5 personas I used to see in this space:
Persona 1: The Non Software Engineers. This kind of persona can either have technical skills or no technical skills at all (and that’s why I wrote “1.5” personas). Basically, they like software but never learned the technical skills behind it. They know how software works from using it, not writing it.
Persona 2: The Software Engineers. They worked in software engineering for years if not decades. Writing code is key to how they work every day and they enjoy coding. However, they have one big disadvantage over persona 1: they understand code and thus can’t let go.
I consider myself to be more like Persona 2, though I am not the “heavy” software developer. I worked and live software architecture and thus I know how to built software but have no strict emotional connection with code (though I can perfectly write and read it)
But I won’t keep you from showing my ladder for much longer, here it is:
Level 1: Chat-assisted Coding
This is the level where I see a lot of people are still in large corporations I work with. They use ChatGPT, create code there (simple functions) and copy them over. They especially use it for complex logic. Every line is checked by those people if it makes sense. The output I often see as “frankenstein” code: a lot of stuff is copy/pasted together. We already had this in the past, when people copied stuff over from stackoverflow (btw, what’s up with them now?). In architecture, we coined this as “Copy-Paste Pattern”. Not a good one, tbh.
However, I would rather encourage people to do it and offer them ways to move up the ladder. It gives people a first “touchpoint” with AI assisted coding and you need to pick them up where they are.
Level 2: Vibe Coding
Vibe Coding is what is the term I started this article with. As stated by Karpathy, this is when you “completely give in to the vibes”. Is it bad? No. But also here, it is necessary to offer ways to move up the ladder. I see a lot of non-Devs in this stage. People never had a touchpoint with software development but suddenly they had ways to create their own custom software without needing to study it or go through this extremly challenging learning curve of developing software.
Developers sometimes use it also, but more for prototyping. I hear them say “this never works in production”. And damn, they are right. Vibe Coded apps don’t work in production. However, it is important to experiment with this step as well. I met people the last months that were active in this step of the ladder and over months, they learned more about software engineering (or gave it to people that knew it). In my opinion, this level brings business and technology much closer together. I actually encourage business users now to “Vibe Code” as it improves the requirements phase a lot.
Business users create prototypes and IT don’t have to guess what they want to have. While for Prototyping, this is really good, it should be avoided for production software. Vibe Coders typically have no idea about what it means to build great software. Great harnesses such as Claude Code help but don’t take away the complexity of software. You need to think about the blast radius here (such as auth, PII, anything customer-facing) and understand that this creates a lot of zombie software in the long run.
Why is it above Level 1, given that the technical maturity here seems low? This is a valid question and here is my honest feedback: people on level 1 (but also on level 3) have issues in “let go”. People on level 2 actually don’t care about code at all (they can’t read it!). They will progress faster (or with level 5) don’t even have to.
The logical next step for people on this level is to skip level 3 and move directly to step 4.
Level 3: Pair programming
Level 3 is the level software developers land after a while. They find it increasingly challenging to constantly copy over the code from chatgpt’s web interface. Also, this is when more and more devs get more tokens and subscriptions. Still, developers read the code and check the code if it is correct.
In this level, trust issues still exist and people have issues in let-go. Vibe Coders never get there as they typically don’t have the skills to read and understand code.
Also, this level is often characterized by low token availability in organisations. I met developers having tokens for 1 week of the month before they had to go back to “normal” development. Though, a performance improvement is first visible here and developers gain more trust in the AI tools. Here and there, they claim that they change code but understand that these tools are already really mature.
One key downside here: people on this layer never work on the big picture and performance increase is rather limited. Also, people on this layer rarely use agents tailored to speed them up.
A characteristic of this is that people working in this level often use one tab (e.g. with Copilot, Claude Code, …) they work in for potentially days! People can move up when they start to create own agents and skills and context files (such as the Claude.md, Agents.md or what I recommend: a book of standards). This takes away repetitive tasks.
Level 4: Spec-Driven Development
This is now the layer where vibe coders from level 2 and people on level 3 meet for the first time. Developers arrive here when they learned to let-go of reading and writing code and focus on the bigger picture. However, this is not a level they typically reach on their own, only if enabled by the company they work in.
This level needs guardrails, frameworks and adjustments to the software development process. Also, people here get use frameworks and agents for different steps, a lot runs automatically. People here focus on reading and shaping the user stories in what they want to achieve. The focus shifts from reading code to describing what the output should be. Code here is not assessed anymore and testing is also automated.
The people working on software move away from the code and focus on the specs. When I was in this level, I created a requirenments agent that worked with me (looped!) and shaped what I want to have. The agent challenged my ideas, asked for more details in case not enough was present. Eventually, the agent created an implementation-plan.md of the feature, broke it down into user stories and tasks. Before kicking off the implementation, I checked the output if it made sense or not, re-shaped it again and finally kicked-off the development. A key revelation I observed here: the better the plan, the better the output and less re-do is necessary.
Over time, I actually looped in more agents, such as a principal designer that worked on the design and an architectural reviewer that improved the plan with architectural notes the implementer agents should follow-through on. This architectural reviewer agent knew my coding guidelines and how the architecture is composed, thus following the standards. This also reduced architectural drift a lot.
A key thing in this: coding gets much cheaper (you can use cheaper models such as sonet) while planning became token intense (Opus). But overall, I could create much more features in the same subscription as the output got much better and needed less re-do or throw-away.
Key here is also automating testing a lot. I recommend a three-way testing approach here:
The first step is Unit Testing. Agents write the tests and they write a bug report when tests fail. Then it goes back to my implementation agents that fix bugs. This loop goes as long until all lights are green.
Once step 1 is done, Integration Test Agents write these tests and we have the same loop, until all is green. The loops here are more complex as they test real behaviour that spans different classes
The last step is end-to-end tests. For web applications I use play Playwright that automates the full flow. The agents write tests that simulate real user behaviour and also loop until things work as expected.
This step is already really close to the Software Factory, but some steps are still missing here. Ready for it?
Level 5: Software Factories
Software Factories are now the level you want to reach. This is when a major shift happens in how software is developed. It is fully automated and developers move fully from writing and reading code. Rather, they focus on some key items:
Automating the process: business units get integrated into the process. They work with tickets (e.g. in Jira, Github Issues and alike) and agents answer these tickets. Agents have different modes, such as research mode (where business users explore the functionality and the agents give them feedback), plan mode (agents guardrail the business users into describing the features they need and challenge them; also, they ask back and tell the user if they need more information. Agents lock the business users into loops until they have enough information). Also, developers focus on the CI/CD and DevOps part (i’d keep this deterministic). A key guardrail I recommend here is to combine deterministic software and work on graphs rather than having agents decide in which step they are in.
Building new factories: My premise here: you can’t build a car in dishwasher factories. So we will see different factories once maturity raises. Some factories will focus on rapid prototyping while others focus on mobile apps and others on web applications. Factories get more and more specialised and the maturity will constantly increase.
Constantly improving the harness: and I’d argue this is most likely the single most important task where most developers should work on in the future. Instead of writing code, developers will optimize the agents to write better and better code. They ensure that agents keep their corporate standards, rules and are compliant. They will develop new agents for specific use-cases. This does require a lot of architectural understanding, great engineering skills and proper technical understanding. Developers that arrive at this step are fit for the future. I didn’t see a framework for software factories that can be used out of the box (and GSD, for instance, is extremely generic, just like Fabro).
Another key aspect here is that software development happens on servers rather than on indivdual notebooks. It will run 24/7 and takes the full process. My own factory is going even a step further: once a feature “landed”, more steps are added:
Security Loop: I use other model families to do security challenges on the feature developed. E.g. if my feature was developed with Claude Models, I use Codex to challenge. The security loop is essential here: I constantly scan my repo for attack vectors and I use the extremely heavy models (GPT 5.6 Sol, Fable). The security loop is moving until all issues are solved.
Documentation: this is often an annoying step but a very important one. I also automated that. Whenever a new feature lands, automation creates the documentation, does screenshots and alike.
A software factory is an end-to-end process. You are guided through these steps by a (deterministic) workflow and you have tailored agents that know what tasks to work on. Also, a software factory knows the context of the app (when coming to an existing application, my agents create an app_context.md that keeps this information current)
Reaching this level is now quite complicated. It requires skilled people to work with and you need to constantly upgrade the factory. an abandoned factory soon produces expensive vibe-coded like applications. You can create software extremly fast but you also need a lot of validation. Challenging the output with other models ensures a high level of output quality but you would still need a lot of human review.
Where am I on this path? I would say 4.5 on a fast path towards level 5. I am still running it on my machine, though having a lot of automation steps already achieved. Also, I am working on the workflow orchestration and making great progress here.
One important note here: I never build a “full” software with a single prompt. This is superstition and not possible at all. I always work on features and shape them with the factory. If features get bigger, I slice them and start different instances of a factory. Your context in your head also has token limits and you need to think things through :)!
Where are you and what path should you follow?
A key thing you need to think about first is in which of these steps you are right now. This gives you the best judgement on where to go next. Here are some practical recommendations I normally give when consulting my clients or exchanging with people:
Level 2 (Vibe Coding): you can fast-track to level 4, but you need a strong learning curve here. You need to learn to understand software architectures. I would not recommend you to learn how to code though it is a surplus if you do (knowing how to code is a strong foundation for software architectures). It is important for you to learn how modern software is built, what aspects it brings, how modern software development works and alike
Level 1 or Level 3: the learning you need to take is to “let go”. You have all the technical basics to advance to level 4 but you are fighting with trust issues. I’d recommend you to get a Codex or Claude Code subscription for your private use and build a hobby project for your own. This will give you the trust you need to move up the stack there.
Getting up from Level 4 to Level 5 is then the place where both paths merge. However, this is more tricky since you need to build more than just that, you need to build the factory (or get one of the ones I mentioned) and you need to integrate that into software development processes of your organisation.
[1] Collins Dictionary, Word of the Year 2025: https://www.collinsdictionary.com/woty
[2] Dan Shapiro, The 5 Levels: https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/