I Thought I Needed Better AI. I Actually Needed a Better Engineering System.🚀
My journey from AI-0 to AI-2 with OpenSpec, Spec Kit, and BMAD — and why AI-3 is next.
For a while, I thought the problem was simple: I needed AI to generate better code.
Better prompts, better models, better context, better agents. If the output wasn’t good enough, I refined the prompt. If the architecture started drifting, I explained it again. If the AI forgot an important decision, I gave it more context. And if things became messy enough? Well… there was always a new chat. 😅
And honestly, it worked. Sometimes it worked incredibly well.
Until I realized something uncomfortable.
The code wasn’t actually the problem.
The real problem was everything around the code: requirements, context, architecture, decisions, planning, validation, and perhaps most importantly, keeping all of those things synchronized while the project kept changing.
That realization changed the way I think about AI-assisted development. It also started what I now think of as my personal journey from AI-0 → AI-1 → AI-2 → AI-3.
Along the way, I started exploring three approaches that challenged how I was building software: OpenSpec, Spec Kit, and BMAD.
But this isn’t another “OpenSpec vs. Spec Kit vs. BMAD — which one is better?” article.
I think that’s the wrong question.
What happens when you stop treating AI as a code generator and start designing an engineering system around it?
🧭 What do I mean by AI-0, AI-1, AI-2, and AI-3?
There are many AI maturity models. Most of them describe how organizations evolve from ad-hoc AI usage to mature, integrated AI systems.
I’m borrowing the idea of maturity levels, but I’m applying it to something much more personal: my own AI-assisted engineering workflow.
These are not industry-standard levels. They are simply a way for me to reason about how my development process is evolving.
Looking backward, the progression became surprisingly clear:
MY AI ENGINEERING JOURNEYMY AI ENGINEERING JOURNEY
AI-0 AI-1 AI-2 AI-3
AD HOC EXPERIMENTAL OPERATIONAL SYSTEMIC
│ │ │ │
▼ ▼ ▼ ▼
Prompt Specify Integrate Orchestrate
│ │ │ │
▼ ▼ ▼ ▼
AI writes AI works from AI becomes part The system helps
code structured intent of the engineering maintain coherence
workflow
│ │ │ │
▼ ▼ ▼ ▼
HUMAN HUMAN HUMAN HUMAN
= Memory = Designer = Glue = JudgmentOnce I saw it this way, a lot of things clicked.
AI-0 — “Hey AI, build this.” 🤖
AI-0 is where I started, and I suspect a lot of developers start there too.
You have an idea. You open your AI coding assistant. You describe what you want and say:
Build this feature.
AI generates code. You run it. Something breaks. You paste the error. AI fixes it. Another thing breaks, so you prompt again. Eventually, it works. 🎉
And that feels incredible, because it is incredible. You’ve just compressed what could have been hours of coding into minutes.
But there’s a hidden problem.
At AI-0, the AI knows what I told it. I know everything else.
I remember why a particular architecture was chosen. I remember the weird business constraint someone mentioned three days ago. I remember why I explicitly decided not to use a certain library. I remember which shortcut is temporary and what “done” is supposed to mean.
The AI doesn’t.
So without realizing it, I become the project’s external memory.
As the project grows, this gets expensive. I start spending more and more time explaining my own project back to the AI.
AI-0 ┌──────────────┐
│ IDEA │
└──────┬───────┘
▼
┌──────────────┐
│ PROMPT │
└──────┬───────┘
▼
┌──────────────┐
│ AI GENERATES │
│ CODE │
└──────┬───────┘
▼
💥 ERROR?
│
▼
┌──────────────┐
│ PROMPT AGAIN │
└──────┬───────┘
└────────────── ↻That was my AI-0: AI was generating code quickly, but I was manually maintaining coherence.
🪤 The trap: better prompts feel like the solution
My first reaction was obvious: improve the prompts.
So I added more context, more detailed instructions, architecture explanations, coding conventions, examples, longer prompts, and carefully crafted agent instructions.
And yes, the results improved.
But something still felt wrong, because I was optimizing the conversation instead of optimizing the engineering system.
That distinction ended up being huge for me.
A brilliant prompt can produce a brilliant implementation. But what happens six weeks later, when the requirement changes, the architecture evolves, and three different agents have touched the same area?
Then the uncomfortable question appears:
Where does the truth live?
Is it in the prompt? The code? The README? The ticket? AGENTS.md? CLAUDE.md? A conversation from last Tuesday? Or is it still mostly in my head?
That question is what pushed me toward AI-1.
AI-1 — Stop prompting. Start specifying. 🧠
At AI-1, my question changed.
Instead of asking:
How can I make AI write better code?
I started asking:
How can I give AI a better engineering environment to work inside?
That might sound like a small change, but it isn’t. Once you ask that question, code generation becomes only one step inside a much bigger process.
Intent
↓
Requirements
↓
Specification
↓
Architecture
↓
Plan
↓
Tasks
↓
Implementation
↓
ValidationSuddenly, the specification stops being “documentation.” It starts becoming part of the execution environment.
That was a major shift for me.
🧩 Then OpenSpec, Spec Kit, and BMAD entered the picture
At first, I approached them the wrong way.
I was asking: Which one has more features? Which one gives better output? Which one has better agents? Which one should I use? Which one wins?
But the more I explored them, the less interested I became in picking a winner.
Each one made me think about a different part of the same underlying problem:
How do we preserve engineering intent while AI is changing the system?
That, to me, is much harder than generating code — and much more important.
📘 What OpenSpec made me think about
OpenSpec pushed me to think more seriously about specifications as living engineering artifacts.
When something changes, the question shouldn’t only be “What code needs to change?” It should also be: What assumption changed? What behavior changed? What does the system believe before and after this change? Which existing decision does this affect?
This starts moving development away from isolated prompts. The AI isn’t simply receiving instructions anymore; it’s operating against a more explicit representation of what the system is supposed to become.
And that distinction matters.
Code tells us what exists. A good specification tells us what should exist — and why.
📐 What Spec Kit made me think about
Spec Kit reinforced another idea for me: there should be structure between an idea and implementation.
We often jump directly from “I want feature X” to “Generate feature X.” AI makes that jump dangerously easy.
But software engineering exists in the space between those two sentences.
Before implementation, we should be asking: What exactly are we building? What are the constraints? What assumptions are we making? What does success look like? What is the technical approach? How should the work be decomposed?
Only then should we ask:
What code should we write?
The more capable AI becomes, the more tempting it is to skip those steps. Ironically, I think those steps become even more important.
🧠 What BMAD made me think about
BMAD pushed the idea further toward process, roles, and specialized reasoning.
Instead of imagining one magical AI that understands everything, you start thinking about different responsibilities: product thinking, architecture, planning, implementation, review, and testing.
Different stages require different context. Different stages require different reasoning.
That led me to another realization:
Maybe the future isn’t one giant prompt containing everything. Maybe it’s a system of specialized contexts working from shared artifacts.
That is a very different model from “Here’s my repository. Please build the feature.”
🧭 Three tools, three different questions
This is roughly how I now think about them:
THE THREE QUESTIONS
OpenSpec Spec Kit BMAD
│ │ │
▼ ▼ ▼
CHANGE INTENT PROCESS
│ │ │
▼ ▼ ▼
"What changed?" "What exactly are "Who or what should
we building?" reason about this?"
│ │ │
└──────────────────────┼───────────────────────┘
▼
ENGINEERING CONTEXT
↓
CODEThe deeper value for me wasn’t choosing a winner. It was changing the way I thought about the system around the code.
AI-2 — AI becomes operational ⚙️
Eventually, the experiments stopped feeling like experiments. Parts of these ideas started becoming part of how I actually work.
That’s what I call AI-2 — Operational.
Get Abderrafii GOUTAIB’s stories in your inbox
Join Medium for free to get updates from this writer.
AI isn’t sitting beside the engineering workflow anymore. AI is inside the workflow.
AI-2 ┌─────────┐
│ INTENT │
└────┬────┘
▼
┌──────────────┐
│ REQUIREMENTS │
└──────┬───────┘
▼
┌──────────────┐
│ SPEC │
└──────┬───────┘
▼
┌───────────────────────┐
│ ARCHITECTURE / PLAN │
└───────────┬───────────┘
▼
┌─────────┐
│ TASKS │
└────┬────┘
▼
┌──────────────┐
│IMPLEMENTATION│
└──────┬───────┘
▼
┌──────────────┐
│ VALIDATION │
└──────┬───────┘
└──────→ Feedback → SPECThis changes something fundamental.
The code is no longer the only artifact carrying knowledge. Intent exists outside the implementation. Decisions become explicit. Requirements survive across sessions. Agents can work from shared context instead of relying entirely on conversation history. Changes can be reasoned about before code is generated.
That is a huge improvement over AI-0.
But there is a catch.
🧷 At AI-2, I’m still the glue
This may be the most important lesson I’ve learned so far.
Even with specifications, structured planning, agents, and tests, I’m still the glue holding the system together.
I notice when the implementation doesn’t really match the requirement. I catch when an architectural decision contradicts something decided earlier. I decide whether a specification needs to change. I resolve ambiguity, decide which context an agent needs, review the output, and connect the pieces.
Requirements ──────┐
Specifications ────┤
Architecture ──────┤
Decisions ─────────┼──────► 👤 ME ──────► Implementation
Agent Context ─────┤ "GLUE"
Tests ─────────────┤
Validation ────────┘So AI-2 doesn’t mean “AI builds software autonomously.”
For me, it means:
AI has become an operational part of my engineering process, but human judgment still coordinates the system.
And that exposes the next bottleneck: me.
AI-3 — What happens when I’m no longer the glue? 🔥
This is the question I’m exploring now.
And I don’t think AI-3 simply means:
MORE AGENTS! 🤖🤖🤖
Giving five agents access to a badly structured project does not magically create an engineering organization. It might just create chaos five times faster.
For me, AI-3 is about making the system itself capable of maintaining more coherence.
Imagine a requirement changes. The system can identify which specifications are affected, which architectural decisions should be reconsidered, which tasks need to be generated, which implementation areas are impacted, which tests prove the new behavior, which assumptions are now invalid, and — most importantly — where uncertainty is high enough that a human decision is required.
That is a much more interesting form of autonomy.
Not:
“AI writes everything without humans.”
But:
AI can move through a well-defined engineering system while humans intervene where judgment actually matters.
That’s the AI-3 I’m interested in.
And I’m not there yet.
🏗️ The AI-3 system I have in mind
Something closer to this:
AI-3 ┌─────────────────┐
│ HUMAN │
│ │
│ Judgment │
│ Direction │
│ Governance │
└────────┬────────┘
│
▼
┌──────────────────────────┐
│ ENGINEERING SYSTEM │
│ │
│ Specs ↔ Architecture │
│ ↕ ↕ │
│ Tasks ↔ Implementation │
│ ↕ ↕ │
│ Tests ↔ Validation │
│ ↕ ↕ │
│ Context ↔ Decisions │
└──────────────────────────┘The human doesn’t disappear.
The human moves upward.
From carrying context manually to making higher-value decisions.
🎯 The biggest lesson from AI-0 → AI-2
Looking back, my biggest mistake was assuming that better AI would automatically produce better engineering.
It doesn’t.
Better models help. Better agents help. Larger context windows help. Better prompts help.
But none of them eliminate the need for structure.
In fact, the more capable AI becomes, the more important that structure may become.
Because generating 10,000 lines of code is becoming cheap.
Understanding whether those 10,000 lines represent the right system is not.
📉 The bottleneck is moving
For decades, writing code was expensive.
AI is rapidly reducing that cost.
So the bottleneck moves.
BeforeIdea
↓
Design
↓
██████████████████████████████ Implementation
↓
Test
WITH AIIdea
↓
██████████ Requirements
↓
██████████████ Context
↓
██████████████████ Architecture + Decisions
↓
███ Implementation
↓
████████████ Validation
Not a scientific measurement, obviously — just a way of illustrating how the pressure feels like it is shifting.
The important questions are becoming less about:
Can we implement this?
and more about:
Can we precisely describe what should be implemented?
Then:
Can we preserve that intent while the system evolves?
And eventually:
Can humans and agents collaborate without losing architectural coherence?
That’s why I’m increasingly interested in specifications, context engineering, agent workflows, and tools like OpenSpec, Spec Kit, and BMAD.
Not because I want AI to type faster.
It already types much faster than I do.
I’m interested because I’m trying to solve a different problem:
How do you build an engineering system where AI can make increasingly consequential changes without decreasing your confidence in the software?
🗺️ My personal maturity model
At this point, my model looks like this:
Level Stage What changes Human role AI-0 Ad HocAI generates and modifies code 🧠 MemoryAI-1 Experimental Specifications, structured context, and planning appear 🧭 Designer AI-2 OperationalAI becomes embedded across the development workflow 🧷 Glue AI-3 SystemicThe system maintains more coordination, validation, and context 🎯 Judgment
Or, even more simply:
AI-0 AI-1 AI-2 AI-3Prompt Specify Integrate Orchestrate
│ │ │ │
▼ ▼ ▼ ▼
"Do this" "Understand this" "Work within this" "Run this system" HUMAN HUMAN HUMAN HUMAN
Memory Designer Glue Judgment
That last transition is the one I’m working on now.
🤔 So which one wins: OpenSpec, Spec Kit, or BMAD?
I don’t think there needs to be one winner.
At least, that’s no longer the question I’m trying to answer.
I’m much more interested in what each approach reveals about the direction software engineering is moving.
OpenSpec made me think harder about change and specifications.
Spec Kit made me think harder about the path from intent to implementation.
BMAD made me think harder about process, roles, and agent-driven workflows.
Experimenting with all three made me realize something bigger:
The next generation of AI development tooling isn’t just about generating code. It’s about managing intent.
Because once code becomes cheap, clarity becomes expensive.
🚀 AI-3 comes next
I’m intentionally not claiming AI-3 yet.
I want to build it, break it, watch agents misunderstand each other, see where specifications drift from implementation, discover where humans still need to intervene, and figure out which parts can actually become systematic.
Then I’ll write about what worked — and what failed.
Because if there’s one thing this journey has taught me, it’s this:
The goal isn’t to remove humans from software engineering.
The goal is to stop making humans do the work that the engineering system should have been doing all along.
AI-3 comes next.
