I’ve recently started working with what’s known as AI-SDLC: applying a classic software development lifecycle, but with an AI accompanying you through every phase.
Within that approach, I’ve been using a variant called Spec-Driven Development. I wanted to write down my first impressions while they’re still fresh — with the honesty of someone who has just begun.
The Core Idea
The temptation with a coding AI is to say «build me this» and accept whatever comes out. Spec-driven development does exactly the opposite: it forces you to think before you code.
Instead of jumping straight to implementation, the work moves through a series of phases where you first understand the problem, agree on what you’re going to do, and only then touch the code.
The 7 Phases of the Process
As I’ve experienced it, the cycle follows these stages:
-
Explore: The AI explores the code and context before proposing anything — which files are involved, which dependencies exist, and what risks lie ahead. Basically, doing its homework.
-
Propose: Possible approaches are laid out with their pros and cons, and one is chosen. Here you decide, not the machine.
-
Spec: A specification is written: what the change must satisfy, with concrete, verifiable acceptance criteria.
-
Design: The how is defined — the technical plan, the affected files, and the architectural decisions.
-
Apply: Now, finally, you implement — ideally with tests guiding the development.
-
Verify: You check that everything holds up: tests, build, and a manual review of whatever can’t be automated.
-
Archive: The change is closed and left documented.
What surprised me most is how much work happens before writing the first line of code. At first, it’s frustrating; later, you’re grateful you didn’t charge in blind.
Key Takeaways from the Experience
1. Breaking things down pays off
The biggest practical lesson: a large task gets split into small, independent changes. It’s slower to organize upfront, but each piece is reviewed and reverted separately, isolating problems right away. A monolithic change is a minefield; five small changes are five tidy boxes.
2. The AI proposes, you decide
Important decisions pause and get escalated to human judgment. The AI is lightning-fast at generating options and spotting details I’d miss, but critical judgment — especially where there’s risk or ambiguity — stays human. It works infinitely better as a copilot than as autopilot.
3. Verify in the real environment, not just in development
My favorite (and most instructive) anecdote involved a CSS rules issue between a host application and a federated module (microfrontend). The AI accurately identified and fixed the original bug inside the federated module, but when rendered within the host app, the broken styling persisted.
After some hard troubleshooting, the AI proposed a solution that brought visual parity between both environments. However, since CSS at scale isn’t my primary area of expertise, I couldn’t immediately grasp what was causing the conflict or why the proposed fix worked.
I took the time to dig deeper, research the underlying CSS behavior, and get a full picture of what was happening under the hood. In the end, I realized the AI’s proposed workaround—while visually effective—wasn’t the cleanest architectural approach. I decided instead to align the solution with the existing CSS pattern used throughout the federated module.
Lesson burned in: «Green» in development or a visually working UI guarantees nothing on its own. You have to verify against what actually ships, dig into the why behind AI solutions, and ensure the fix aligns with sound architecture rather than just patching symptoms.
4. The AI gets things wrong, and that’s fine
There was a diagnosis we took for granted that turned out to be wrong. The correct one surfaced by verifying it empirically, not by reasoning about it. Far from being a failure of the method, that is the method: propose, doubt, and check. The discipline of verifying is what saves you — not trusting that the answer is right the first time.
A Beginner’s Balance Sheet
I’m not going to oversell it: this doesn’t do the work for you. It demands more rigor upfront, more patience with the process, and above all, not switching off your brain just because an AI sounds convincing.
In return, it leaves you a trail of documented decisions, small and easily auditable changes, and a verification net that catches errors that would otherwise reach production.
As a first contact, I’m left with one clear feeling: the AI speeds you up, but you’re still the one steering. And I think that’s exactly the healthy way to use it.
I’ll keep sharing how this evolves in future posts.