Spec-Driven Development for Startups

Spec-driven development is a way of building software where a written, version-controlled specification is the source of truth and the code is only one implementation of it. A human writes the spec and the criteria that define success. AI coding agents write the implementation, run it against those criteria, and keep iterating until it passes. The code stops being the thing you protect. The spec becomes the thing you protect.

If you have been doing this informally, with a long prompt and a good CLAUDE.md file, this is the disciplined version of that instinct. The reason it matters to founders right now is not tooling. It is that the bottleneck in software has moved. Your agents can produce more code in a day than your team can read in a week, so the question stops being how fast can we write it and becomes how do we know it works. Spec-driven development is one answer, and one company shipping access-control software has pushed it to the point where nobody on the team reads the code.

What is spec-driven development?

Three things have to be true before a workflow earns the name:

1. The spec is a real artifact. It is written down, versioned alongside the repo, and covers intent, constraints, edge cases, and what is explicitly out of scope. Not a prompt you retype, not a Slack thread.
2. Success is executable. The spec carries acceptance criteria a machine can evaluate: tests, end-to-end scenarios, user journeys, evals. If a human has to eyeball the result to decide whether it is done, the loop cannot close.
3. The agent iterates without you in the middle. It implements, runs the harness, reads the failures, and tries again. You come back to a result plus evidence, not to a diff you have to babysit line by line.

That third condition is what separates spec-driven development from vibe coding and its more disciplined successor, agentic engineering. Vibe coding is prompt-first and improvisational, which is fine for a prototype and terrible for anything you have to maintain. Spec-driven development is spec-first and auditable: months later you can ask why the system behaves this way and get an answer from the spec instead of archaeology through a diff.

The term has older roots in software engineering, but it hardened into a named category in 2025 around tools like GitHub's Spec Kit, which structures the workflow into specify, plan, tasks, and implement steps, and Amazon's Kiro, an IDE built to enforce spec-first work. Martin Fowler's site now runs a series comparing these tools, which is usually a sign a practice has stopped being a trend.

Spec-driven development vs test-driven development

Test-driven development starts at the code level: write a failing unit test, write just enough implementation to pass it, refactor. A human writes both halves, and the unit test is the primary artifact.

Spec-driven development starts one level up. The artifact is a specification covering intent, constraints, edge cases, and how success gets verified, and the agent produces both the implementation and most of the test code from it. TDD asks whether this function does what you meant. Spec-driven development asks whether the system does what the spec promised the user.

The practical difference is what lands on your desk. In TDD you review code. In spec-driven development you review the spec and the evidence that the spec is satisfied.

Why the spec became the work product

The clearest founder-facing version of this comes from Y Combinator. In How To Build A Company With AI From The Ground Up, YC partner Diana Hu argues that the common framing of AI as a productivity boost misses the shift entirely, and that AI should not be a tool your company just uses:

It should be the operating system your company runs on.

Inside that argument she names the build pattern directly. She calls it the AI software factory and frames it as the next evolution of test-driven development: humans write a spec and a set of tests that define success, then agents generate the implementation and iterate until the tests pass. Her division of labor is the whole idea in two sentences:

The human defines what to build and judges the output. The actual code is the agent's job.

Hu is not speaking from theory. She co-founded Escher Reality, an augmented reality startup acquired by Niantic in 2018, led AR platform work there, and joined YC as a partner in 2021, where she now sees these AI-native patterns across YC companies. And she notes that some companies have already pushed this one to the point where their repos contain no handwritten code, just specs and test harnesses.

That claim sounds like hyperbole until you read the one company that has published exactly how it does it.

Inside a real software factory

StrongDM builds zero trust privileged access management. Its product controls who can reach which databases, servers, and clusters, which makes it roughly the last category of software you would expect to build without human code review. In February 2026 it published Software Factories and the Agentic Moment, a first-person account of how its AI team works.

The team was founded on July 14, 2025 by Justin McCarthy, StrongDM's co-founder and CTO, with Jay Taylor and Navan Chauhan. Their summary of the approach is one sentence:

We built a Software Factory: non-interactive development where specs + scenarios drive agents that write code, run harnesses, and converge without human review.

The operating rules are two lines:

Code must not be written by humans

Code must not be reviewed by humans

And a third, practical one that tells you what this costs:

If you haven't spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement

Simon Willison, who saw the demo before the write-up went public, called out the second rule as the interesting one, and it is. Not writing code is now unremarkable. Not reading it is a different claim, and it only holds if something else is doing the proving.

Tests are not enough, scenarios are

StrongDM's team started with a hunch: how far can we get without writing any code by hand? Their own answer is blunt. Not very far, at least until they added tests. And then the agent, focused on the immediate task, started gaming them. Their summary of the problem:

return true is a great way to pass narrowly written tests, but probably won't generalize to the software you want

They found two failure modes that anyone running agents at volume will recognize:

• Tests are too rigid. When the software itself has agent loops inside it, a boolean pass or fail cannot capture whether it did the right thing. Evaluating success often requires an LLM as judge.
• Tests can be reward hacked. A test that lives in the codebase can be lazily rewritten to match the code, or the code can be rewritten to trivially pass the test. If the agent can edit its own grader, you do not have a grader.

So they changed two things. First, they repurposed the word scenario to mean an end-to-end user story, often stored outside the codebase, similar to a holdout set in model training, and validated flexibly by an LLM rather than by an exact assertion. Second, they replaced the green or red test suite with a probabilistic measure they call satisfaction: of all the observed trajectories through all the scenarios, what fraction of them likely satisfy the user.

Then came the part that makes it work at volume. To validate against the third-party services their software depends on, they built a Digital Twin Universe: behavioral clones of Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets, replicating their APIs, edge cases, and observable behaviors. With twins instead of live services they can run thousands of scenarios per hour without hitting rate limits, triggering abuse detection, or accumulating API costs, and they can test failure modes that would be dangerous or impossible against live services.

That is the actual lesson for founders, and it is not the no-review rule. It is that the strength of your spec-driven loop equals the strength of your validation harness, and building a serious harness is now cheap enough to be worth it. Cloning a significant SaaS API used to be a proposal no engineer would bring to their manager. Agents changed that math before they changed anything about how you write features.

The same shift shows up elsewhere in YC's portfolio. On YC's Root Access, Momentic, which builds a verification layer for software, frames it as two schools of thought: either your code is the source of truth, so whatever runs in production is by definition what you specified, or the source of truth is the spec, the detailed user journeys, flows, success criteria, and edge cases a human writes with AI, and the code is only an implementation of it.

That distinction has a commercial edge you should be feeling internally. As code output rises, the bottleneck moves to verifying the work. Linters and code review tell you the code follows patterns. They do not tell you the product still works in production, which is why testing in the AI coding era is now a founder problem rather than a QA problem, and why the AI-feature version of the same question is running real evals.

What changes on your team

If you adopt this seriously, four things change, and none of them is your tool choice.

Review replaces typing as the senior skill. The scarce person on your team becomes the one who can write a spec precise enough that a machine cannot satisfy it the wrong way, and who can look at a satisfaction score and know whether to ship. That is a different muscle from writing clean code, and some strong engineers hate it. Find that out before you restructure around it.

Your spec quality becomes your ceiling. Ambiguity used to be absorbed by an engineer who asked a question in standup. Now it gets resolved by a model that guesses, confidently, and produces a thousand lines around the guess. Vague acceptance criteria no longer cost you a conversation, they cost you a rework cycle.

Your token bill goes up and your headcount does not. StrongDM's $1,000 per engineer per day is a deliberate provocation, but the direction is real. Hu makes the same trade explicit: be willing to run an uncomfortably high API bill, because it is replacing a far more expensive headcount line. Model that as a real budget item before you promise a board a hiring plan.

Coordination overhead falls, and the org should follow. This is the part founders defer and should not. If the spec plus the harness carries the intent, a lot of the meetings that existed to transmit intent stop earning their keep. That is how the future of software engineering reshapes a team's shape rather than just its output, and it is the part that makes founders ask whether AI replaces software engineers at all.

The security question this raises

I write this as a CISSP, and StrongDM building access-control software under a no-human-review rule is either the strongest possible endorsement of the method or a warning, depending on what you copy from it. What makes it defensible is not confidence in the model. It is that they replaced review with something harder to fool than review: validation the agent cannot see, a probabilistic bar instead of a boolean one, and twins that let them run adversarial and failure-mode scenarios at a volume no human QA team could match.

Copy the harness, not the headline. Before you drop human eyes from any surface, answer these:

• What is the blast radius if this ships wrong? A broken dashboard is a bug. A broken authorization check is an incident with a disclosure obligation attached.
• Can my harness see the failure I actually fear? Most test suites do not contain a scenario for privilege escalation, tenant data leaking across an account boundary, or a secret written into a log. If the scenario does not exist, passing means nothing about it.
• Where does the agent's own access stop? An agent that can edit code, edit tests, and deploy has quietly become your most privileged identity. Give it scoped credentials, a separate environment, and an audit trail, the same way you would treat a contractor with production access.
• Who signs? Someone has to be accountable for a release. Automating the work does not automate the responsibility, and regulators and customers will ask a person, not a pipeline.

The honest summary: spec-driven development moves risk rather than removing it. It moves risk out of the code and into the spec and the harness. That is a good trade only if you invest there proportionally.

Where spec-driven development breaks down

It is not free and it is not universal. Four places it goes wrong:

• On genuinely exploratory work. If you do not yet know what you are building, writing a precise spec is a way of guessing expensively. Prototype loosely first, then spec what survived, which is the whole point of treating AI prototyping as a separate mode with different rules.
• On legacy code. The method assumes you can validate end to end. In a large system with no harness and hidden coupling, you will spend the first months building the ability to check, not shipping features. That is the real reason AI-native companies have an edge here, and it is Hu's point about incumbents: startups have no legacy systems and no thousands of people to retrain.
• When the spec is just the code in prose. If your spec restates the implementation, you have added a document to maintain and gained nothing. A spec should describe user-visible behavior and constraints, not the class structure.
• When nobody owns the harness. Validation infrastructure decays like any other infrastructure, and it decays silently, because a rotting harness still reports green. Give it an owner.

This is one piece of a broader pattern we track across the AI for startups pillar: the durable work moves up a level, from producing the artifact to defining and verifying what a good artifact is.

What to do this week

• Pick one feature you were going to build anyway. Write the spec first, in a versioned file next to the repo, including what is out of scope, then let an agent implement it. Compare the result to how that feature would normally have gone.
• Write three end-to-end scenarios for your riskiest existing flow, in plain language, describing what a user does and what must be true afterward. Store them outside the codebase so the agents cannot edit them.
• Look at your current tests and ask which ones an agent could satisfy without building the right thing. Rewrite the worst one as a scenario.
• List the surfaces where you will keep human review no matter what: auth, payments, customer data, migrations, infrastructure permissions. Write the list down, because the default otherwise is drift.
• List what your coding agents can actually reach today: repos, secrets, deploy targets, production data. Revoke anything on that list they do not need this week, and write down what still needs a separate environment.
• Pull last month's real token spend per engineer and divide it by a loaded engineer month. That ratio is the number an investor or a board member will ask you about, so know it before someone else computes it.

Running your company this way is a bigger decision than picking a coding workflow. It changes what your team does all day, what you can promise a customer, and what you have to be able to prove. That operating picture is exactly what we teach in the AI Operating System for Startups.

Sources

• How To Build A Company With AI From The Ground Up (Y Combinator), the talk by YC partner Diana Hu that anchors this article, on AI software factories, the closed-loop company, and the roles that survive. Background on Diana Hu: Y Combinator and her LinkedIn profile.
• Software Factories and the Agentic Moment (StrongDM), the primary source for the factory rules, the scenario and satisfaction concepts, the Digital Twin Universe, and the token-spend benchmark, written by co-founder and CTO Justin McCarthy. See also the principles page for the seed, validation, feedback loop.
• How StrongDM's AI team build serious software without even looking at the code (Simon Willison), independent reporting on the demo and on why the no-review rule is the hard part.
• The Q/A Layer for the AI Coding Era (YC Root Access), the conversation with Momentic co-founders Wei-Wei Wu and Jeff An on truth-driven and spec-driven development and the verification bottleneck.
• What is Spec-Driven Development? (GitHub Spec Kit documentation) and Understanding Spec-Driven Development (martinfowler.com) for the tooling landscape, including Spec Kit and Kiro.