AI Coding Accuracy and Spec-Driven Development: What Works at Startup, Scaleup and Enterprise

Accuracy Is a Context Problem

When engineers tell me an AI coding tool "got it wrong", I ask to see the prompt. Nine times out of ten, the model did a reasonable job of what it was asked, and what it was asked was ambiguous. "Add discounts to checkout" contains a hundred decisions: stacking rules, rounding, which markets, what happens on renewal, what the admin sees. A human engineer would ask. An AI agent will often pick an answer and move on.

The accuracy of AI-generated code comes from three things, roughly in this order of impact:

1. The clarity of intent: does the agent know what "done" looks like?
2. The feedback loop: can it run tests, type checks and linters to verify its own work?
3. The model: how well it reasons, plans and follows the codebase's patterns.

Most teams spend their energy debating the third while under-investing in the first two.

Where AI Coding Is Accurate Today, and Where It Isn't

From our own usage across a TypeScript and Next.js codebase:

High accuracy:

• Well-scoped changes that follow an existing pattern ("add a new SQS worker like the emails one").
• Tests for existing code, especially when a similar test file exists.
• Refactors with a clear mechanical rule and a good test suite.
• Explaining unfamiliar code, and first-pass debugging from a stack trace.

Medium accuracy:

• New features touching several modules, where the spec is decent but not complete.
• Database migrations (correct SQL, but decisions about locking, backfills and rollbacks need a human).

Low accuracy (without a spec):

• Anything involving business rules that live only in someone's head.
• Cross-cutting changes with implicit constraints: money, tax, time zones, idempotency, permissions.
• Performance work without a reproducible benchmark.

Notice the pattern: accuracy drops as the amount of unwritten knowledge rises.

What "Spec-Based Development" Actually Means

A spec isn't a 30-page requirements document. For AI-assisted work it's a short, structured file that lives in the repo next to the code and answers:

# Spec: Pause subscription from account page
 
## Goal
Customers can pause deliveries for 1–4 weeks without contacting support.
 
## Acceptance criteria
- Pause options: 1, 2, 3, 4 weeks from the next delivery date
- A paused delivery is not charged; the charge date moves with the delivery
- Cannot pause within 48h of a delivery cut-off (show message X)
- Emits SubscriptionPaused event (see events/subscription.ts)
 
## Out of scope
- Pausing for more than 4 weeks, admin-initiated pauses
 
## Constraints and patterns to follow
- Use the existing DeliverySchedule service; do not compute dates in the controller
- All money calculations via lib/money.ts
- Feature flag: subscription-pause-v1
 
## Test plan
- Unit tests for date calculation, including BST/GMT transitions
- API test for the 48h cut-off rule

That's it. About twenty lines, and the agent now knows the rules, the boundaries, the patterns to reuse and how to prove it's done. The same spec is also the best possible pull request description and review checklist.

Tooling That Supports It

The tooling landscape has converged on the idea that agents need persistent, structured context:

• Repository instruction files: CLAUDE.md, AGENTS.md, Cursor rules and similar. Coding conventions, how to run tests, architectural rules and "never do X". Every serious team should have one.
• Spec-first IDEs and workflows: Kiro's requirements → design → tasks flow; plan modes in Claude Code and Cursor that produce a plan for review before any code is written; GitHub's Spec Kit and similar open-source templates.
• Reusable skills and commands: encoded workflows for recurring tasks ("add a new queue worker", "create a migration") so the agent follows your process, not a generic one.
• MCP connections to your sources of truth: tickets, design docs and API schemas, so the spec can reference them rather than copy them.
• Automated verification: fast unit tests, type checking, linting, and AI code review as a first pass before human review.

The tool matters less than the discipline: write the spec, have the agent plan against it, review the plan, then let it implement with tests.

Startup vs Scaleup vs Enterprise

Startup (under ~20 engineers)

Constraint: speed, and very little process tolerance.

What works:

• One good repository instruction file, maintained like code.
• Lightweight specs (the 20-line kind) only for work touching money, data or customer-facing rules. For everything else, a clear ticket and plan mode is enough.
• Invest in a fast test suite early. It's the cheapest accuracy improvement available to you.
• Let engineers choose their tools; standardise the instruction file, not the IDE.

Avoid: heavyweight spec templates and multi-stage approval flows. You'll abandon them in a month.

Scaleup (~20–150 engineers)

Constraint: consistency across teams, and knowledge that's no longer in everyone's head.

What works:

• Specs become the standard for any feature larger than a day or two, stored in the repo and linked from the ticket.
• Shared skills/commands for common workflows, so every team's agent follows the same patterns.
• AI code review as a first pass, human review as the gate.
• Measure: cycle time, change failure rate and review rework, split by AI-assisted vs not. Use the data to decide where to invest.
• Architectural decision records the agents can read, so they stop reintroducing patterns you've deliberately moved away from.

Enterprise

Constraint: governance, security, audit, and many codebases of varying quality.

What works:

• Spec templates tied to the delivery process, with traceability from requirement to spec to pull request to deployment.
• Centrally managed instruction files and approved skills per platform or language.
• Model access through an LLM gateway with logging, data controls and cost attribution (I've written about this separately).
• Clear policies on which data and repositories agents may access, and where human approval is mandatory: security-sensitive code, infrastructure, anything customer-data related.
• Enablement teams who help product teams write good specs. This is a skill, and most engineers haven't been taught it.

The Metrics I Actually Watch

• First-pass acceptance rate: how often an AI-generated pull request is merged with only minor changes.
• Review rework: number of review cycles per PR, AI-assisted vs not.
• Change failure rate: are AI-assisted changes causing more incidents or rollbacks?
• Escaped defects in areas with specs vs without.

If you track only one thing, track first-pass acceptance for work that had a spec versus work that didn't, with the same tools and engineers. That comparison is the clearest test of whether the discipline is paying off.

The Takeaway

If you want more accurate AI-generated code, write down what you want before you ask for it. Keep the spec short, keep it in the repo, and make it define "done" in a way a test can check. Scale the formality with the size of the company, not the hype cycle. The models will keep improving; unwritten requirements will stay unwritten until someone writes them.