AI can write code quickly. It can also lock the wrong assumptions into a system with a lot of confidence.
In enterprise environments, that confidence is expensive. One fuzzy requirement can turn into a chain of decisions across services, data contracts, security boundaries, and support processes. By the time the issue shows up, you are no longer debugging a defect. You are debugging intent.
At DiUS we have been using spec-driven agent workflows. I chose to compare using tools like SpecKit, OpenSpec and GSD in this blog because they represent different design choices in spec-driven agent workflows: structured guardrails, change-driven specs, and phased execution with verification. The point is not to pick a ‘winner’, but to understand what fits enterprise teams and how to adopt without creating new overhead.
This is still a very new space. The tools and built-in ‘plan’ modes are changing quickly, and our view here reflects what we are seeing in delivery right now. The details may look different in a month. The adoption questions will not.
The failure mode of thin context and instruction drift
Most teams have felt some version of this:
- requirements arrive high level and under-specified
- the agent fills gaps to keep moving
- humans patch assumptions mid-build
- the patchwork hardens into code, then drift shows up late
Spec-driven workflows are trying to break that loop.
There is a useful nuance here. The answer is not “add more context”. Too little context creates guessing. Too much can create noise, and important instructions get lost. You end up in a “lost in the middle” problem where the agent has the information somewhere, but cannot reliably hold onto what matters.
The goal is an “optimal window” of context. High signal, low noise, and stable enough that humans can review it without wading through a novel.
Spec first is a sequencing change, not a documentation revival
It is easiest to think of spec-driven workflows as a simple pipeline: Requirements → spec → plan → tasks → implementation
The spec does not magically create missing information. It forces you to confront what is missing before code exists.
In practice, that sequencing shows up as a small set of files the team can review before code gets written. If those files are clear and easy to maintain, the agent has less room to invent, and the team has something concrete to agree on.
That matters because review is cheaper earlier. If the team can challenge assumptions in a spec and plan, you avoid large code changes built on decisions nobody remembers making.
What the workflow produces
When I say “reviewable artefacts”, I mean a small chain of files that do different jobs. They are designed to keep decisions explicit and keep the agent anchored to them.
Using SpecKit as a concrete example, the workflow typically produces:
- global guardrails, often a constitution file that shapes every output
- a spec that turns requirements into user stories and acceptance criteria
- a clarification trail that captures questions and decisions, instead of burying them in chat
- a research record that captures key technical decisions, rationale, and alternatives
- a plan with technical context, dependencies, and a proposed project structure
- tasks broken into phases with checkpoints you can test
- a consistency check that flags mismatches before implementation
One detail I liked in practice is that some workflows also generate starter operational material early, for example a quickstart guide, even before the code exists. It keeps the conversation grounded in how the thing will actually be run.
Enterprise adoption is a workflow and governance problem
A lot of commentary on these tools focuses on which one generates ‘better code’. In enterprise delivery, the harder question is whether the workflow around those files fits how teams actually ship.
In practice, the deciding factors are usually:
- Can the team review the artefacts quickly?
- Can you trace a change back to a requirement or decision?
- Does it fit your branching, PR, and release practices?
- Can new team members understand what is true today?
- Does the workflow reduce risk, or just create more things to maintain?
If the workflow does not fit how teams ship, engineers will route around it under pressure.
What I found testing SpecKit, OpenSpec and GSD
All three tools are aiming at the same underlying problem. They differ in how they balance rigour, flexibility, and human reviewability.
SpecKit and structured guardrails
SpecKit leans into consistency. You start by defining global principles, typically in a constitution file, to shape the outputs. That’s where you can set non-negotiables like testing expectations, performance constraints, formatting rules, and security requirements.
From there, SpecKit runs a staged flow. For example, it generates a spec, prompts for clarification, produces a technical plan plus a research file that includes alternatives and rationale, then creates phased tasks with checkpoints. It also includes an analyse step that cross-checks the artefacts for gaps and mismatches before implementation.
That structure is useful when you want repeatability and traceability.
It is also where adoption friction shows up. SpecKit is branch-based, and it relies on the branch name to identify the feature. In practice that often means numbered feature branches. If your team uses a different branching model, this can feel like the tool is asking you to change how you ship. That might be worth it, but it is a real cost.
Setup is straightforward. The bigger decision is whether the team is willing to align on its workflow assumptions.
OpenSpec and change-oriented documentation
OpenSpec is lighter and easier to fit into an existing team workflow because it is folder-based rather than branch-based. If a change comes up after implementation, you can create a new spec for the change in the same branch, rather than creating a new feature branch to satisfy the tool.
OpenSpec has a core workflow and an expanded workflow. The expanded mode is useful for teams because it lets you step through artefacts one at a time, which makes review less overwhelming.
Another practical advantage is that OpenSpec workflows are schema-based. Teams can clone the workflow schema and customise it to match how they already work. That matters in enterprise environments where process fit is often the deciding factor.
OpenSpec also makes a clear bet on living documentation. When you archive a feature, the spec is merged into a main spec set. In theory, that gives you an up-to-date view of what the application does today, not just what someone intended six months ago.
There is a condition though. A living spec only helps if the team keeps it true. If people stop using the workflow consistently, the main spec becomes confidently wrong. That can be worse than having no spec at all, because teams start relying on it.
GSD and thorough phased execution
GSD is the most thorough of the three. It splits work into multiple focused phases, and each phase runs through discuss, plan, execute, and verify loops.
It is also the most configurable. Early on, it asks questions about granularity, whether to do research before planning, whether to run plan checks and verification per phase, and which model to use. During discussion, you choose how much to explore, and each choice triggers more questions. If you want a broad sweep of possibilities, it will happily take you there.
A few mechanics matter because they explain why GSD can feel heavy in a team environment:
- a progress command to tell you where you are in the workflow
- a YOLO mode that runs the full sequence automatically and can take a long time
- some GSD plan outputs are structured primarily for the agent. In my testing, the plan file used XML because that format tends to be followed more faithfully by models, but it is slower for humans to skim and review.
GSD can be excellent for exploration, particularly when requirements are unclear and you want to surface options you did not think of. That same strength can also drive scope creep. If you let it, it will widen the decision space.
Setup is not hard, but the tool has a lot of workflows. It can take longer to learn well compared to lighter options.
Our takeaway was straightforward. GSD can be a strong option for exploration and high-risk work, but it is harder to make it the default team operating model without adding overhead.
The review overhead question
This is where enterprise adoption gets real. If you add a full spec and plan review cycle before implementation, you risk doubling review overhead. Teams already review code changes. Adding another set of documents on every feature can turn into a four-round loop: spec review, plan review, AI implementation, code review.
That is not sustainable for most teams.
The pattern that feels workable is more targeted:
- use the workflow for kick-off when requirements are unclear, integration is complex, or risk is high
- use it for tricky work where you want early feedback on design decisions before writing code
- keep the default lightweight so you are not turning every change into a documentation marathon
The goal is targeted rigour where it reduces rework and risk.
Bugs and keeping guidance in sync
A real concern with these workflows is bug fixing. If the agent implements the feature, you find a bug, you prompt it to fix the bug, and the fix is not reflected in the artefacts, you can end up regenerating the same bug later.
The practical takeaway is that bug fixing needs to flow back into the guidance the agent will see next time.
Tooling varies. Some workflows have specific debug approaches, for example a dedicated GSD debug command. Some rely on extensions or expanded modes that keep fixes linked to the generated artefacts. The deeper pattern matters more than the commands.
When you see a recurring mistake, update the right layer of guidance:
- if it is systemic, add it to your global guardrails so every feature benefits
- if it is specific to one feature area, add it to the plan or feature guidance so it does not pollute everything
- capture the decision where the team will actually maintain it
Otherwise you get a new kind of technical debt. The code moves, but the agent’s instructions do not.
Code quality still needs engineering hygiene
Spec-driven workflows do not remove the need for engineering judgement. They change where you apply it.
In practice, generated code can be locally good but globally inconsistent. Agents can be tunnel-visioned on the slice of work they are implementing. Teams will still see issues like:
- type drift, where similar concepts get defined slightly differently in different parts of the system
- duplicated types or duplicated logic because the agent is focused on local context
- missed refactoring opportunities because the agent is not scanning the broader architecture
The mitigation is familiar:
- use linting, formatting rules, and static analysis as guardrails
- treat refactors as deliberate work, sometimes as a separate spec
- review for systemic drift, not just whether the code runs
If you want the agent to follow codebase conventions, the guardrails need to say so. This is another place where a constitution or global config pays for itself.
A small human shift
Working this way makes you “a bit of a BA, a bit of QA”.
That’s also the point where the work stops being an engineer-only activity. The spec and acceptance criteria stage is a natural collaboration moment for the whole team. Product can tighten intent and trade-offs. QA can shape what ‘done’ means and what needs to be proven. UX can catch edge cases and workflow gaps before they harden into code.
You spend more time clarifying requirements, defining acceptance criteria, and thinking about testability before code is written. In regulated and legacy-constrained environments, that is often where delivery risk sits.
A practical recipe for enterprise squads
If you want value from spec-driven workflows without drowning in artefacts, treat this as a team pattern, not a personal tool choice.
1. Start with non-negotiables, not tools
Before you pick a workflow, capture the constraints the agent must respect. Keep it short and concrete. Think of this as “always true” guidance.
Examples:
- data handling rules and security boundaries
- testing expectations, what counts as done
- performance and reliability constraints that matter in production
- architectural guardrails, where code lives and how it integrates
This is where the “constitution” concept is useful even if you do not adopt a specific tool. A stable set of guardrails reduces repeated debate and makes outputs more consistent.
2. Default to a kick-off spec, not full ceremony
Most enterprise features do not need deep research artefacts and multi-stage verification.
Aim for a kick-off pack that fits a normal PR review:
- purpose, one or two paragraphs
- user stories or scenarios
- acceptance criteria that can be tested
- key constraints and assumptions
- a thin technical plan, integration points, data boundaries, operational touchpoints
- known risks and unknowns
Make it reviewable. If it takes an hour to read, it will not be reviewed.
3. Time-box clarification so it stays useful
Clarification is where these workflows earn their keep. It is also where teams can stall.
A simple stop rule works well in practice: clarify until business ambiguities and major integration decisions are resolved. Stop when the questions become low-level implementation detail.
If the agent starts asking about variable names or formatting preferences, you are past the point of diminishing returns.
4. Treat artefacts as code: commit, review, then implement
The team benefit comes from asynchronous collaboration:
- commit spec and plan artefacts
- review them like code
- capture decisions in the artefacts, not in chat threads
- implement against the agreed plan
This supports governance and reduces rework caused by hidden assumptions.
5. Choose the workflow by risk level
A simple operating model keeps this sustainable:
- Default (most features): lightweight spec and plan, then implement
- High uncertainty or high consequence: deeper exploration and verification, potentially using a phased workflow
- Change-heavy brownfield work: a delta-based approach that makes additions, modifications, and removals explicit
This is where OpenSpec’s orientation to change sets can be a good fit for teams working on long-lived systems.
6. If you want a living spec, design for upkeep
If the “main spec” is going to be a source of truth, treat it like one:
- update it as part of “definition of done”
- assign ownership, even if it rotates
- treat spec drift as a defect
- prefer small, frequent updates over occasional rewrites
If the team cannot sustain that habit, it is better to treat specs as feature-time artefacts, not a living reference.
7. Close the loop on bugs so they do not come back
One common failure mode in agent workflows is recurring mistakes. The fix is not just patching code. It is updating the guidance the agent will see next time.
When a bug reveals a missing rule or pattern:
- add a constraint to the global guardrails if it is systemic
- add guidance to the feature plan if it is specific to that area
- capture the decision so future work does not repeat the same misstep
Otherwise, you end up debugging the same class of issues again and again.
My current point of view
Spec-driven agent workflows can reduce drift and rework. In enterprise settings, that only translates into value when the workflow fits how teams actually deliver.
The best tool is the one your whole squad can review, trust, and keep true over time.
A final caution. This space is moving quickly. Tool names and exact workflows may change in weeks, not years. The pattern is what we care about: clarify the hard decisions early, keep artefacts reviewable, and make the “source of truth” a real practice, not a hopeful label.
