AI agents can now write software faster than most organizations can safely coordinate or govern it. The absurd part is it’s not faster in a way that helps, rather faster in a way that outruns every human checkpoint built to catch a bad decision before it ships.
AI’s output speed looks like pure upside until you closely notice what is driving it. AI agents behave like stateless developers with no architectural judgment. Every prompt-driven change they make piles ambiguity on top of ambiguity faster than any human team can walk it back. Opsera calls this the Agentic Paradox: AI speed is building a future that is structurally unmaintainable, one ungoverned prompt at a time.
Spec-driven development exists to break that cycle. This piece looks at four things:
- why prompt-driven coding compounds drift the moment AI agents touch a real codebase,
- why most early attempts at “adding specs” still underdeliver,
- what a genuinely intent-aware approach to spec-driven development looks like in practice,
- how that compares to other AI-native platforms competing in this space.
What Prompt-Driven Coding Actually Costs You
AI agents don’t carry institutional memory forward from one task to the next, and they have no architectural judgment about a system they’ve never seen documented. A prompt captures what someone wanted in the moment, in whatever detail they happened to type, and then it disappears into a chat log. Nothing about it is structured. Nothing about it is versioned. Nothing about it gets checked against what the system was actually built to do.
Three things tend to happen once agents start working off prompts alone across a shared codebase.
- Work gets duplicated first. An agent solves a problem in one session, but none of its reasoning survives past that session. The next engineer or agent to touch the same area ends up solving it again, sometimes differently and sometimes in a way that doesn’t fit what came before.
- Agents start contradicting each other next. Two agents assigned to adjacent parts of a system have no shared reference for what the system is supposed to do, so each one optimizes locally against whatever it was told. The seams between their work become the place bugs live.
- Review turns into archaeology last. A reviewer looking at an AI-generated pull request has no specification to check it against, only a diff and their own memory of how the system used to behave. That memory grows less reliable the larger and faster the codebase moves.
As Rajeev Madhavan, Founder and Managing Director of Radiant, puts it, AI has given every developer superpowers, but code generation without enterprise-grade governance limits how safely that power can be used. Every unaudited change stacked on top of the last one only raises the stakes.
That governance gap matters because of what it displaces. Every hour spent tracing a bug back to an agent’s undocumented assumption is an hour not spent shipping the next feature. Over time this creates a kind of undertow: the more ungoverned agentic work accumulates, the more of the team’s capacity gets absorbed just containing the damage, which leaves even less capacity to fix the underlying process. Left alone, the problem doesn’t level off. It compounds.
The Research Behind Why This Keeps Getting Worse
It would be reasonable to assume more AI simply means more velocity. Applied without the right guardrails, AI acceleration makes the underlying governance problem worse, not better.
AI coding agents generate changes to a codebase in seconds, but they are fundamentally stateless. They don’t carry forward what the last agent learned, and they have no way to judge whether a change fits the system’s actual architecture unless that architecture has been written down somewhere they can read. Applied to a codebase whose context has already eroded, an agent doesn’t fix the drift. It accelerates it, generating plausible changes that diverge further from the system’s real intent with every iteration.
Gartner’s research reflects this shift directly:
- The Maintenance Cliff – by 2027, organizations that do not adopt spec-driven development for AI work will see 25% slower delivery, driven by rising costs in defect remediation and rework.
- The Accuracy Benchmark – prioritizing semantics and persistent context in AI-ready data is projected to increase agentic AI accuracy by up to 80%, alongside up to 60% lower operational costs, which underscores just how much of the AI accuracy problem is actually a context problem wearing a different name.
- The Validation Barrier – 35% of successful AI adopters identify validating the accuracy of AI-generated output as one of their top three operational challenges, a direct symptom of agents operating without a reliable, shared source of truth.
- The Resilience Deficit – 62% of enterprise risk leaders admit their current business continuity plans do not adequately prepare them for the disruptions introduced by rapid AI scaling.
Srikrishnan Ganesan, CEO of RocketLane, frames the practical version of this gap directly. AI can generate code in minutes, but turning it into real enterprise outcomes still takes weeks, and closing that gap means anchoring every artifact to intent while keeping governance inline rather than adding it after the fact.
Why Most Attempts at Spec-Driven Development Fail
Given how expensive ungoverned agentic work turns out to be, it would make sense for spec-driven development to be a clear win the moment a team adopts it. In practice, a lot of early attempts underdeliver, and the reason usually traces back to how the problem gets framed from the start.
Traditional spec-first approaches tend to treat the problem as a paperwork exercise: write the design doc, get sign-off, start coding. That approach produces what might be called a spec on paper: a document that looks authoritative but stops being true the moment implementation drifts away from it. The code changes but unfortunately, the document doesn’t. Six months later an agent reads that document as gospel and builds something the system was never designed to support.
Elsewhere in the market, the same failure shows up dressed differently. Platforms built around rapid prompting and visual prototyping tend to optimize for how fast the first draft appears, not how well the underlying intent survives. The result gets called vibe coding debt: fast app generation that lacks the enterprise-grade guardrails needed to stop architectural drift and security exposure from creeping in behind the scenes.
The harder, more valuable work is treating the specification as something checked against continuously, not filed away once. That means the spec has to be:
Machine-readable, so an agent can validate a proposed change against it without a human translating the document first. Versioned alongside the code it describes, so the two never drift apart without anyone noticing until it’s too late. Enforced structurally, so every change, human or agentic, has to satisfy the spec before it ships, not get reviewed against it afterward.
Gap 1: Specs Written as Prose Can’t Be Checked by an Agent
A large share of existing specifications live purely as prose in a wiki page or a design document, written for a human to read once. That format is exactly the wrong shape for an agent trying to determine whether a proposed change is consistent with the system’s intent.
An agent can’t reliably check a code diff against three paragraphs buried in a page nobody has opened in eighteen months. It has no structured way to parse what still matters, what changed since, or which parts of the document already stopped being true.
Without a structured, machine-readable specification, teams end up circling back to the same failure points:
Agents infer intent from surrounding code instead of an authoritative source, which reproduces whatever inconsistencies already exist in the codebase. Humans manually verify AI-generated changes against their own memory of what the system should do, because there is no structured artifact to check against. Specification drift compounds without anyone noticing, because nothing is flagging the growing gap between what the document says and what the code actually does.
Gap 2: Specs Without Enforcement Get Skipped Under Deadline Pressure
The second recurring failure mode is treating the specification as a reference document instead of a gate. If writing to spec is optional and shipping fast is not, specs lose almost every time a deadline tightens.
A specification that exists but isn’t checked against every change is a specification that will eventually get skipped by someone confident enough in their own read of the system to bypass the step. That confidence is often misplaced, especially once multiple people and multiple agents are contributing to the same codebase at once.
Teams that don’t build enforcement into the workflow end up with specs that are accurate on day one and stale by the second sprint. Every agent and engineer working from that spec afterward inherits a document that’s already wrong, with nothing telling them so.
Who Benefits When Spec-Driven Development Is Done Right
Spec-driven development done well touches more of the organization than the engineering team writing the code. It maps closely to what Opsera describes as its three value pillars: intent architecture, context integrity, and governed velocity.
- Engineering leaders get a shared, machine-readable specification that replaces informal tickets and tribal knowledge, keeping humans and AI agents aligned throughout execution and preventing the rework that unstructured development tends to produce.
- Security and compliance teams get AI-generated code checked against explicit architectural and behavioral constraints before it merges, rather than reviewed for compliance after the fact.
- Product and business stakeholders get a specification that reflects current intent, so requirements changes propagate forward through the system instead of getting reinterpreted differently by whoever happens to be prompting the agent that week.
- Engineers and AI agents working on the system inherit a persistent context layer covering architecture, security, policy, and operational rules, instead of reconstructing intent from code comments and old chat history.
Roman Vorel, VP and GM of Digital Supply Chain and ERP at Intel, describes the broader shift this way: Forge lays the foundation for enterprise autonomy by creating and preserving context through governed workflows and systems of record, enabling solutions like ITSM to resolve issues intelligently and deploy changes through the DevSecOps processes companies already trust.
What Good Spec-Driven Development Looks Like in Reality
Good spec-driven development isn’t measured by whether a spec document exists somewhere in the repository. It’s measured by whether:
The specification is structured enough for an agent to check a proposed change against it automatically, with no human translating the document first. Every code change, human or agentic, is required to satisfy explicit architectural and behavioral constraints before it merges.
The spec updates alongside the code instead of drifting away from it, so it’s still accurate long after kickoff. Governance over AI-generated changes is enforced inline, as a structural property of the workflow, rather than bolted on as a manual review step later.
That’s a different bar than “we wrote a design doc before we started coding.” It’s closer to a specification that functions as a living, human and machine-readable system of record, one that both people and agents can read, check against, and trust for as long as the system exists.
Forge’s Approach to Spec-Driven Development: 3 Core Capabilities
Forge treats specifications as the operating memory of the software development lifecycle, not a document written once and forgotten in a folder. Rather than starting with what a prompt asked for, Forge starts with what the approved specification says, and whether a proposed change matches it.
As Kumar Chivukula, Co-Founder and CEO of Opsera, describes it, the vision behind Forge is to redefine enterprise software delivery through true AI-SDLC, where intent, context, and spec-based development drive every step, with enterprise guardrails built in. AI gave enterprises speed. Forge pairs that speed with governance.
That reframing shows up in three connected capabilities, built to take a team from idea to production in hours instead of months.
Spec-Driven Development
Forge shifts quality control upstream by requiring AI-generated code to satisfy explicit architectural and behavioral constraints before it ever merges. Instead of catching drift in a slow manual review after the code already exists, the specification acts as a gate the code has to clear first.
Forge generates the underlying specs in about three minutes, covering intent analysis, requirements documentation, architecture design, security and compliance mapping, and the work orders needed for controlled execution. That collapses a process that traditionally takes twelve to sixteen weeks down to hours, without skipping the governance steps that make the output worth trusting.
Contextual Shared Memory
Instead of prose documents that go stale the moment implementation starts, Forge engineers a persistent context layer that folds architecture, security, policy, and operational rules into one shared source of truth. That gives every AI agent working on the system situational awareness in place of a chat history that resets with every new session.
This is the mechanism behind the accuracy gains cited earlier. Removing information rot and stateless hallucination is what allows agentic accuracy to climb toward that 80 percent improvement ceiling, since agents are finally reasoning from the same persistent picture of the system instead of rebuilding it from scratch every time.
HITL Verification Work Orders
Rather than trusting that every developer will remember to check agent output against the spec, Forge couples human oversight with autonomous agents through Work Orders. A Work Order is a human-auditable license that authorizes a specific agentic action and ties it back to a specific human intention.
That makes governance a property of the workflow itself, not a step someone has to remember to perform on top of everything else. It also authorizes parallel execution across multiple agents, since every action stays individually traceable even when several agents are running at once.
Matthew Flug, Research Manager for Intelligent Application Modernization and Deployment Platforms at IDC, frames the underlying requirement this way.
Modern, intelligent application delivery requires a platform that provides architectural consistency across environments for both modernizing legacy systems and launching new builds. By using reverse engineering to anchor system logic and intent throughout the build cycle, a platform like Forge helps enterprises address legacy technical debt while improving the speed and quality of cloud-native application delivery.
Katie Norton, Research Manager for DevSecOps and Software Supply Chain Security at IDC, adds the security dimension.
As AI increases the speed and scale of code generation, organizations need stronger ways to validate what is being built, what risks it introduces, and whether it meets policy requirements before code progresses. That’s the coordinated workflow Forge is built to deliver: architecture analysis, security scanning, compliance checks, and remediation, supporting more autonomous execution while preserving auditability across the software lifecycle.
Put together, these three capabilities are designed to make the specification the thing agents actually build from, rather than a document that sits somewhere in the repository drifting further from reality with every sprint.
Forge Capabilities at a Glance
| Capability | What It Does | Technical Mechanism |
| Spec-Driven Development | Shifts quality control upstream, before code merges | Requires AI-generated code to satisfy explicit architectural and behavioral constraints prior to merge |
| Contextual Shared Memory | Gives AI agents persistent institutional memory | Folds architecture, security, policy, and operational rules into one shared context layer |
| HITL Verification Work Orders | Authorizes every agentic action | Couples human oversight with autonomous agents through a machine-auditable license tied to a specific human intention |
Forge Key Benefits
- Minutes, not weeks, for a technical baseline – ForgeScore replaces manual architecture reviews that typically take weeks and pull senior engineers off other priorities.
- Machine-auditable governance – Work Orders create a traceable license for every agentic action, so nothing ships without a specific human intention behind it.
- Business logic preserved before code is touched – Legacy-to-intent reverse engineering captures institutional knowledge before it’s lost to attrition or quietly rewritten away.
- Works with tools teams already use – Integrates with Cursor, Claude, GitHub Copilot, VS Code, existing CI/CD pipelines, and both cloud and on-premises environments.
- No model training on your code – Proprietary code, intent, and architectural data stay private and are never used to train foundational AI models.
- One assessment, eight dimensions – Security, architecture, performance, maintainability, test coverage, infrastructure fit, cost efficiency, and AI adaptability are covered in a single ForgeScore run.
Trade-offs to Consider
- Requires upfront investment in specs – Getting the speed gains out of Forge depends on formalizing specs and intent first, which is real work before the payoff shows up.
- A workflow change, not just a tool swap – Moving from informal tickets and tribal knowledge to living specification documents changes how teams operate day to day, not just what software they use.
- Best suited to systems worth the assessment – For a small, low-complexity legacy app, an 8-dimension ForgeScore assessment may be more rigor than the system actually needs.
- Governance depends on adoption – Work Orders only enforce policy if teams actually route agentic work through them, so partial adoption limits how complete the audit trail is.
Is Forge Right for Your Organization?
Forge tends to fit best for organizations with the following characteristics.
- Engineering teams running multiple AI agents across a shared codebase, where consistency between agents matters more than the speed of any single prompt.
- Organizations with compliance-heavy systems, where auditability of AI-generated code is a requirement rather than a nice to have.
- Engineering leadership that needs every AI agent action traceable to a specific human decision and a specific approved specification.
- Distributed teams that need a single, shared source of truth about intent, rather than relying on chat history or a small group of engineers who remember the original design conversation.
Forge may be less of a fit for organizations in the following situations.
- A small team running a single agent on a simple, low-stakes project, where the overhead of formal specification management may outweigh the benefit.
- Organizations not yet using AI coding agents at all, since a meaningful part of Forge’s value comes from governing AI-driven work specifically.
- Teams fully committed to a manual, prompt-only workflow with no near-term interest in structured specification management.
How Forge Compares to Other Spec-Driven and Governance Platforms
Most competing platforms address part of the spec-driven development problem, usually the speed of generation or the visual prototyping layer, without treating the specification itself as a persistent, enforced source of truth.
| Competitor | Their Weakness | Forge Knockout |
| 8090 | Prioritizes rapid app generation speed but lacks the enterprise-grade guardrails needed to prevent unmanaged architectural drift and security exposure | Work Orders provide a specific, machine-auditable license for AI agents to act, moving execution from unmanaged speed to governed production |
| Dazl | Focuses on visual prototyping and high-speed prompting that often results in context rot, where agents lose track of long-term architectural intent | Persists architectural intent across the entire factory, targeting the up to 80 percent accuracy improvement that comes from eliminating context loss |
| vFunction | Treats modernization as a purely technical refactoring task, producing modernized legacy that fails to deliver business ROI | Anchors modernization directly to business value through an 8-dimension technical fidelity assessment rather than technical guesswork |
| Retool (AI) | Optimized for internal admin tools and prototypes, which creates shadow IT risk and lacks end-to-end governance for core applications | Manages the entire idea-to-production lifecycle as a unified software factory, rather than a siloed prototyping tool |
| Gallop Intelligence | Competes only in the modernization use case and treats modernization as purely technical, producing modernized legacy that fails to deliver business ROI | Anchors modernization to business value through the same 8-dimension technical fidelity roadmap used across Forge’s other use cases |
For a spec-driven development conversation specifically, the two most relevant comparisons are 8090 and Dazl, since both compete directly in the new software build use case.
8090 optimizes for how fast an app can be generated. That speed is real, but it arrives without the guardrails needed to prevent architectural drift or security exposure once the app grows past a prototype. Forge’s Work Orders close that gap by tying every agentic action to a specific, auditable human intention, so speed and governance stop being a trade-off.
Dazl optimizes for visual prototyping and rapid prompting, which tends to produce context rot over longer sessions as agents lose track of the system’s original architectural intent. Forge’s Contextual Shared Memory is built specifically to prevent that failure mode, persisting intent across the full build cycle instead of letting it erode session by session.
The Bottom Line: From Prompts to Persistent Intent
The organizations getting the most reliable output from AI coding agents aren’t the ones writing the most detailed prompts. They’re the ones who’ve stopped treating intent as something typed into a chat window and forgotten the moment the session ends.
Venkat Gopalan, Chief Digital, Technology, and Data Officer at Belcorp, put it plainly. What his organization needed was more than faster code. It needed an AI-driven SDLC that accelerates time to market, delivers measurable business outcomes, and lets talent focus on strategic, high-value work, carrying business intent from concept to cloud without losing governance along the way. What once took weeks can now be achieved in minutes with an enterprise-grade blueprint, a new standard for building and scaling in the AI era.
That’s the shift spec-driven development makes possible: prompts as disposable requests give way to specifications as a persistent, enforced source of truth, and AI-assisted development holds together at scale instead of drifting further from its original intent with every new session.
Frequently Asked Questions
What makes Forge different from 8090?
8090 prioritizes rapid app generation speed but lacks the enterprise-grade guardrails needed to prevent unmanaged architectural drift and security exposure. Forge moves from unmanaged speed to governed production through Work Orders, which provide a specific, machine-auditable license for every AI agent action.
What makes Forge different from Dazl?
Dazl focuses on visual prototyping and high-speed prompting, which often results in context rot as agents lose track of long-term architectural intent. Forge persists architectural intent across the entire factory through Contextual Shared Memory, targeting the accuracy gains that come from eliminating that kind of context loss.
Can I move from a prompt-driven workflow to spec-driven development with Forge without starting over?
Yes. Forge is designed to work with an existing codebase and an existing history of prompt-driven changes, generating specs directly from what already exists rather than requiring teams to freeze development and start from a blank spec.
Does Forge replace tools like Cursor, Claude, GitHub Copilot, or VS Code?
No. Forge integrates with the tools your team already uses, including Cursor, Claude, GitHub Copilot, and VS Code, along with your existing CI or CD pipelines and cloud or on-premises environments. Forge governs the AI-SDLC around those tools rather than replacing them.
How is spec-driven development different from just writing more detailed prompts?
A detailed prompt is still a one-time, unstructured request that disappears into chat history once the session ends. A living specification is a structured, versioned artifact that Forge generates in about three minutes, checks every change against automatically, and keeps readable by both humans and AI agents going forward.
We haven’t adopted a spec-driven workflow yet. Why start with Forge instead of just tightening our prompting practices?
Better prompting practices still produce disposable, unstructured requests that reset with every new session. Forge builds living specifications that persist, get versioned, and get checked against automatically, a level of consistency that prompting discipline alone can’t replicate once more than one agent or engineer is working on the same system.
