Two years ago, I was doing what most of us were doing pressing Tab in VS Code and letting Copilot autocomplete a function. There were no rules. No structure. No one had thought through where AI fit in the development process. You just used it. When it felt right. For whatever felt useful.
That was the wild west phase.
Looking back now, I can see the maturity curve clearly. And it's moving faster than most practitioners realize.
Phase 1: The Autocomplete Era
It started with a method. A class. A boilerplate block you didn't want to type. The AI was a smarter IntelliSense it saved keystrokes, it knew patterns, it was fast. But the developer was still the architect of everything. The AI was just a better clipboard.
The problem? No one agreed on where the AI's responsibility ended and the developer's began. Should you generate an entire class or just a method? How much context should you give it? Where do you document the intent so the AI doesn't go off-track?
There were no clear answers. We all just winged it.
Phase 2: The Context Problem Becomes Obvious
As models got better, the bottleneck shifted. The AI could write good code. What it couldn't do was understand your system without you explaining it every single time.
Developers started discovering that the quality of the output was almost entirely a function of the quality of the context provided. Copy-paste your architecture doc, describe your constraints, explain the pattern suddenly the output went from "okay" to "actually useful."
This surfaced a discipline that hadn't existed before: context engineering. How do you capture the intent, the architecture, the constraints, the decisions made and make it available to an AI agent in a way it can actually use?
This wasn't a coding skill. It was something new. Part documentation, part prompting, part architectural thinking.
Phase 3: The Agent Shift - "From Assistant to Collaborator"
Then agents arrived. And the whole mental model flipped.
We went from "AI helps me write code" to "AI writes code while I review and steer." The developer role started shifting toward something closer to a tech lead or architect setting direction, defining quality bars, reviewing outputs, managing the flow of work across multiple AI agents working in parallel.
This is where the process discipline became non-negotiable.
Because when an AI agent is writing code autonomously, vague requirements are catastrophic. An under-specified task that a human developer would seek clarification on an agent will just solve, confidently, in the wrong direction.
The stakes of bad process suddenly got much higher.
Phase 4: Frameworks Emerge - SDLC Gets a Structure for the AI Era
This is where we are now.
Frameworks like BMad are emerging to give structure to what was a completely improvised workflow. The idea is straightforward but significant: if AI agents are doing real work across the SDLC from requirements to architecture to code to testing then you need a defined process for how that work flows, how context is captured, how roles are assigned, and how humans stay in control of outcomes.
What's interesting is that these frameworks aren't reinventing SDLC from scratch. They're formalizing the practices that good teams had already figured out the hard way documenting architecture decisions, writing clear stories, separating concerns between "what to build" and "how to build it."
The difference is that now these practices aren't optional good hygiene. They're the interface between humans and AI agents. Without them, the agents hallucinate direction. With them, the agents deliver.
What's Actually Changing in How We Work
A few shifts I see becoming permanent:
Requirements quality matters more than ever. A vague PRD was always a problem. Now it's a multiplier the AI will execute confidently on the wrong thing at 10x speed. Writing precise, testable requirements is a core engineering skill now.
Architecture-first is back. The "let's figure it out as we go" approach breaks down with agents. You need the shape of the system decided before agents start building pieces of it. The architect role is getting a second act.
Documentation is now a first-class deliverable, not an afterthought. Because it's the primary way you communicate intent to AI agents. The developer who says "I'll document it later" is the developer whose agents go off-track.
Review and judgment are the new core skills. When AI writes the code, the human's value is in knowing what good looks like catching subtle design problems, questioning architectural choices, identifying what was missed. Senior developer skills become more valuable, not less.
The T-shaped developer gets broader. You need enough understanding of product, architecture, and testing to give agents context and review their outputs across the full stack. Pure specialists who only know one layer become bottlenecks.
Where This Goes Next
The velocity of change here is genuinely hard to overstate. Two years ago: Tab completion. Today: agents writing entire features from a story. Tomorrow: agents managing their own context, querying documentation systems, and flagging ambiguities before writing a line.
The SDLC isn't disappearing. It's being restructured around a new kind of collaborator one that's fast, capable, context-dependent, and requires clear direction to be useful.
The developers and teams who figure out the process discipline for working with agents will move at a pace that looks almost unfair compared to those still treating AI as a fancy autocomplete.
Process maturity was always what separated good engineering teams from great ones. That's still true. The process just looks different now.
Thought process
Thought process
2-3 line summary:
Two years ago we were pressing Tab and hoping for the best. Today, AI agents are writing entire features — and the teams winning aren't the ones with the best models, they're the ones with the best process. The SDLC has quietly matured, and the gap between structured and unstructured AI development is widening fast.
First published on LinkedIn.