I haven’t written a line of code since January. Not because I couldn’t. I stopped because spec-driven development showed me I was spending time on the wrong part of the job.

Today, it is easy to type “build me XYZ” and get code in seconds. I did that too. Sometimes the result looked great. Then I ran the same prompt again and got something different. Logic shifted. Edge cases disappeared. The output stopped being predictable.

The turning point came when I discovered SDD. I started with intent, boundaries, and clear outcomes. Then I let AI handle implementation inside that frame. The results became stable, repeatable, and useful.

So I picked a real test: Expenses Manager 2.0. I am rebuilding it with more AI and with less manual work. I want to see how far this approach can go in a real production path, not in a polished demo.

That realisation didn’t come cheap.

You can’t build on what you can’t repeat

The first version worked. I was genuinely impressed. So I pushed further and asked AI to extend the same component.

The structure shifted. Something was slightly off. I adjusted the prompt. The result changed again, differently wrong this time. By the fourth attempt I had four versions, each solving a different subset of the original problem, none of them complete.

That is not a workflow. That is roulette.

The tempting answer is to keep going. Refine the prompt. Add more context. Be more specific. I did all of that. Even so, the problem didn’t shrink. It moved. AI without a fixed frame drifts. Push it far enough and it starts contradicting itself between files. The logic in one component breaks what the next one assumed.

The real cost wasn’t the time spent on bad attempts. In fact, it was that nothing accumulated. You cannot build on output you cannot trust. Version three might be better than version two. You have no way of knowing if version four will quietly undo what version three fixed.

At some point I stopped. Not because I gave up. Because I finally asked the right question.

The missing frame

The right question wasn’t about the prompt. It was about the frame.

I stumbled on a Microsoft post. A short video, easy to scroll past. It led me to 🌱 Spec Kit on GitHub. A lightweight tool for writing specs before building. The idea sounded obvious. After all, I had been writing specs for years in documents nobody read.

This was different.

🌱 Spec Kit specs are not documentation. They are instructions. You define intent and expected outcomes before a single line of code exists. And you write them with AI, not for AI. The AI helps you think through the edges before implementation begins. By the time you hand the spec to a coding agent, the decisions are already made. The frame exists. The only job left is to build inside it.

That is what spec-driven development means in practice. Not a methodology. A discipline: decide what you are building before you build it.

The first time I ran a real SDD cycle, the output was consistent. Same prompt on a different day, same structure. Not because the AI got smarter. Because I gave it less room to drift.

As a result, I have not written a single line of application code since January. I have shipped more with AI and a clear spec than I ever did with teams of ten behind me. If you want to know how I worked around the model limits along the way, that story is here.

The specs are the work. The rest is execution.

What comes next

The running example for this series is Expenses Manager 2.0. A real app I have been running for years, now rebuilt from scratch using SDD. No shortcuts. No polished demo. A real production path, documented as I go.

My series starts with the SDD methodology: how specs become plans, plans become tasks, and tasks become working software. Then the build itself, a mix of my two favourites: Power Platform and Azure AI, used wherever each fits best.

Along the way you will meet 🌱 Spec Kit, GitHub Copilot, Claude, Claude Code, Dataverse, Microsoft Foundry, AI Agents, and MCP Servers. Each one shows up when the problem needs it.

Post 2 is where the methodology starts. What spec-driven development actually is, where it came from, and why it changes the way you think about building software.

I am not presenting a finished playbook. This is an experiment: real decisions, documented as I make them. The series is already specced. If you want to follow along, the next post is already written.

One thing nobody tells you: this is expensive. I have waited out billing cycles to afford the next phase. SDD keeps the waste low. Every token goes toward something already defined.

Still worth it. The spec made sure of that.