My Experience with AI-First Spec-Driven Development

Previously, I theorized about the Spec-Driven Development approach, which became fairly popular. I have a lot to say about it, but I waited until my team and I got hands-on experience with it in a production system. After several months, I am ready to share some insights and my thoughts on applying SDD.

If you are completely new, I suggest you jump to my article about moving requirements to the source to manage them end-to-end. SDD basically addresses that with an AI agent to produce the source code and keep it in sync with the spec.

Why OpenSpec

My team delegated to OpenSpec the requirements for a portal where both the UI and backend live in one git repo. The portal is a standalone application not tied to other systems. That makes it an ideal candidate for SDD.

Why OpenSpec and not other candidates like SpecKit, Kiro, BMAD, etc? The answer is trivial: we just used what was already in the organization. So I can't comment on other tools or do a comparative analysis.

Would we select another tool if we could? Probably, but years of experience have taught me that a zoo of tools across teams usually causes trouble later.

Within the team, we agreed to move the portal's development onto AI rails and produce requirements artifacts with AI as well.

The Workflow

From the start, the process looks like this:

• As a PO (PM, BA, or whoever), I write a brief description focused mainly on business intent and expected outcome in a Jira ticket.
• When ready, I create a new branch in the repository for the feature and initiate an OpenSpec change: /opsx-new <ticket-number+feature-name>.
• Then I run /opsx-continue, adding the contents of the Jira ticket, to generate the first artifact: proposal.md.
• I review the document in a few iterations, commit it, and push the branch to the remote.
• The dev part begins with reviewing proposal.md, asking questions, generating design.md and task.md, along with discussing and clarifying the details.
• Then a developer proceeds with /opsx-apply and reviews the generated solution.
• After that, the branch is deployed to a dev environment for testing (manual or with AI evals if a chatbot is involved).
• If everything is fine, the branch is merged into the master branch. If not, a dev repeats the solution-generation cycle.
• Then I run a custom skill that generates release notes and user documentation based on the OpenSpec change artifacts. Since we store both release notes and user docs in the same repository, it's very convenient.
• After that, I run /opsx-archive, which synchronizes the change, adds it to the spec, and archives the change.

Diagram generated with AI.

Overall, the happy path isn't difficult, except you need some git skills. There are possible variations of the flow, such as generating proposal, design, and task artifacts in one shot (/opsx-propose), but the team agreement is to generate everything gradually.

What Happens to Jira and Confluence

That simplified flow makes previous requirements sources such as Jira and Confluence, and their analogs, redundant. We still need requirements and the entire process around them, but the artifacts and their storage now change. We might still need PRDs, as I don't expect some stakeholders to get access to our git repo and read a Markdown file from there. But duplicating information across SDD artifacts and other management systems seems illogical.

For that purpose, we moved almost all documentation into the source code to say goodbye to Confluence (not completely, unfortunately). Jira is a bit more complicated. We need it as a ticket tracker with Sprints, Epics, and other Scrum-derived ways of operating, so we can't get rid of it without making my management unhappy.

One of the main product manager's responsibilities is keeping management happy. At first, after implementation but before archiving, I generated up-to-date Jira descriptions with feature scope and acceptance criteria.

My mind naturally resists senseless duplication of data across systems. I also remind myself of an absolute truth: no one is ever reading those tickets.

We ended up with tickets that have no descriptions, acting as placeholders to track work status and comply with the organization's rules. OpenSpec's change folder contains a ticket reference, so it's traceable.

I might end up in trouble for that, but then I can generate ticket descriptions from the specs post-factum. I consider doing so upfront a useless waste of tokens, though.

So now I go straight to the agent app (Codex, Claude Desktop, OpenCode) and run /opsx-explore with all the information I have. After that, I create proposal.md and follow the next steps.

Why It's Working

We have been using OpenSpec, SDD, and AI-first development for several months already. That experiment is successful, to my mind, for the following reasons:

1. We are a small team with multiple priorities. We can continue developing the portal with AI tools at a good pace while focusing on other priorities.
2. We don't have a dedicated Business Analyst who can thoughtfully work on the requirements and write specs. As a product manager, who also juggling multiple other priorities, I delegated that to OpenSpec.
3. This product is a standalone, not-yet-brownfield portal maintained by a small team with everything in one repository.

As you can see, we don't fully rely on AI and keep a human in the loop at every stage. But there are a bunch of things where we don't use the SDD flow:

• For the AI chatbot, I make minor prompt adjustments for regressions without OpenSpec.
• Some bugs, UI ones specifically, are fixed without OpenSpec.
• Security is handled outside of OpenSpec.
• Evals are also handled outside.

The main reason SDD with OpenSpec is a heavyweight process is that it consumes a lot of time and tokens compared to a situation where you already know exactly what to fix and where.

That raises the risk of drift, but so far we haven't struggled with it. Maybe, considering the modest scope of the product, we won't suffer from that at all.

Where It Might Not Work

The reasons why OpenSpec and/or SDD might not work are the opposite of what makes it successful in my case:

• I don't know how to scale it for distributed systems with multiple microservices.
• I don't know how to deal with it in a monorepo with responsibilities shared across multiple domains/teams.
• I don't know how to effectively structure the spec once it grows so big that it starts polluting the context.
• I don't know how it could handle a change that is too big to handle in one go.

Please let me know if you have any questions. Meanwhile, I will keep digging into the topic, as I think I've just touched the first layers of what is transforming the industry right now.