Prompts are not specs: why prompt engineering isn't enough to ship production code

The AI coding industry spent 2024 and 2025 obsessed with prompt engineering. It was the wrong obsession.

Prompt engineering optimizes for the immediate output. Get the code generated. Move on. That works for prototypes, demos, and toy projects. It breaks the moment the code has to survive in production where edge cases exist, integration contracts matter, and the cost of being wrong is real.

The teams that have figured out how to ship AI-generated code to production have all converged on the same insight: prompts are not specs. The unit of work isn't the prompt. The unit of work is the specification that captures the constraints, not just the request.

This post explains the difference, why the prompt-engineering ceiling exists, and what replaces it.

What prompts optimize for

A prompt is a single-turn interaction. You write a request, the AI produces output, you evaluate.

Prompts optimize for happy-path success. "Build a signup flow with email verification" gets you a signup flow with email verification. The flow probably handles the typical case. The AI did what you asked.

The implicit assumption is that you'll catch and fix anything wrong in review. That works for small, contained changes. It falls apart for systems where the wrong behavior in edge cases compounds.

What specs optimize for

A spec optimizes for the constraint space.

"Build a signup flow with email verification" is a prompt.

"Build a signup flow that handles duplicate email addresses by returning a specific error, blocks invalid domains using a configurable allowlist, rate-limits to 5 attempts per IP per hour, expires unverified accounts after 7 days, logs all attempts for audit, sends verification emails via the existing email service, and integrates with the existing user model without breaking the password reset flow" is a spec.

The spec is longer because it has to be. Production code is judged not by what it does on the happy path but by what it cannot do under load, attack, and edge cases.

The production failure mode

The default failure mode of prompt-driven AI coding looks like this:

Day 1. You prompt the AI to build a feature. The AI produces working code. You review the happy path, it works, you merge.

Day 14. A user reports something broken. You investigate. Edge case the AI didn't handle.

Day 30. Another bug. Another edge case.

Day 60. Three production incidents traceable to AI-generated code that didn't handle scenarios you never thought to ask about.

The pattern: prompts produce code that solves the case you asked about. Specs produce code that handles the constraint space.

The asymmetry is brutal. The AI is happy to generate happy-path code all day. It will not push back and say "what about this edge case?" It will not surface integration contracts you forgot to mention. It will not write defensive code against scenarios you didn't anticipate.

The human has to bring all of that. The spec is where it goes.

Why prompt engineering hit its ceiling

The 2024 and 2025 wave of AI coding tools (Lovable, Bolt, v0, GitHub Copilot Chat) all bet on the prompt as the primary unit of work. The user types a prompt, the system produces output, the loop continues.

This worked beautifully for prototypes. "Build me a landing page for X" produces a usable landing page. "Build a simple TODO app" produces a working TODO app.

It hit a ceiling around real applications. The complexity of production systems, with their integration contracts, edge cases, error states, and operational concerns, exceeded what could fit in a single prompt.

Users responded by writing longer prompts. Five paragraphs. Ten paragraphs. With sections labeled "requirements" and "constraints" and "edge cases."

At that point, the prompt has become a spec. The semantic distinction matters because tools designed for prompts treat them as one-turn requests. The user has to fight the tooling to make spec-driven development work inside a prompt-driven UX.

What changes when you treat specs as the unit

When the spec is the unit of work, the tooling and process changes:

The specification has structure. Specific sections for context, requirements, acceptance criteria, edge cases, integration contracts, test plan. The structure is the discipline.

The work is multi-turn. The AI executes, encounters questions, asks for clarification, iterates. The spec is the persistent context.

Review focuses on whether implementation matches spec. Not whether the code is elegant. The AI handles elegance. The reviewer handles correctness against spec.

Test coverage is a first-class concern. The spec includes a test plan. The AI generates tests as part of the implementation. The reviewer verifies the tests cover the spec.

Iteration is normal. A spec is revised when reality reveals it was wrong. The implementation re-executes against the updated spec. The history is preserved.

This is what the CR pattern operationalizes. The CR is the spec. The pattern makes the spec the unit of work.

The hiring implication

The senior engineer of 2026 is not primarily a coder. They are a specifier.

The skills that matter:

Decomposing a feature into shippable units. The CR-sized chunk that can be specified, executed, and merged independently.

Understanding the constraint space. What can go wrong, what's the integration contract, what edge cases matter.

Writing precisely. Vague specs produce vague code. The senior engineer's writing has the same precision as their code used to.

Code review at a higher abstraction level. Reading PRs not for "is this elegant" but for "does this match the spec, did the AI miss anything."

The skills that matter less:

Writing every line of code yourself. The AI does this.

Knowing every API by heart. The AI looks it up.

Optimizing micro-syntax. The AI handles it.

This isn't a downgrade. The senior engineer skill is harder, not easier, because writing a complete spec requires deeper understanding of the system than writing the code does.

The product manager implication

The PM role converges with the senior engineer role.

PMs already do spec-writing. They write PRDs, requirements documents, user stories. In the prompt era, PMs wrote loose specs and engineers filled in the gaps. In the spec era, PMs write tighter specs and the AI fills in the implementation.

The implication: PMs need more technical depth. Not "can you code" but "can you reason about edge cases, integration contracts, and operational concerns."

The PMs who can do this become enormously leveraged. They're now driving production output directly, not just specifying what engineers should build.

The PMs who can't either upskill or become less central.

The team structure implication

A traditional team of 5 engineers + 1 PM + 1 designer becomes:

1 operator (combining the spec-writing of PM and senior engineer roles). The operator writes CRs, reviews PRs, makes architectural decisions, owns the product.

The AI. Executes CRs, handles implementation, runs tests, produces PRs.

A designer (for things AI doesn't do well yet, like brand and high-end UX).

Customer-facing team (sales, support, customer success).

The engineering org shrinks. The output stays the same or grows. The leverage is in the spec-writing capacity, not the headcount.

This is uncomfortable for engineering managers. The instinct to scale by hiring engineers is wrong in the spec era. Scaling by upskilling specifiers and improving the spec-writing process is right.

Concrete examples of prompt vs spec

Bad prompt: "Build a payment integration."

Better prompt: "Build a Stripe integration with subscription billing."

Spec: "Integrate Stripe Subscription Billing using the Customer Portal pattern. Customers sign up via Stripe Checkout. On successful subscription, create a User record with subscription_status=active. Webhook handlers must process: customer.subscription.created (mark active), customer.subscription.deleted (mark cancelled, retain access until period end), customer.subscription.updated (update plan), invoice.payment_failed (mark past_due, retain access for 7 days, then suspend). All webhook handlers must be idempotent (handle duplicate events). Use the existing User and Subscription models. Add audit logs for every subscription state change. Test cases: new subscription, plan upgrade, plan downgrade, cancellation, failed payment retry, dunning flow."

The spec is much longer. It captures the constraint space. The implementation that comes out is production-grade because the spec described production requirements.

The prompt version would produce code that handles the typical case and breaks in the long tail.

Why this matters for AI coding tools

Tools optimized for prompts have a structural limit. They can get better at understanding short requests, generating more elegant code from less context, but they can't substitute for the spec.

Tools optimized for specs (the CR pattern) have a different ceiling. They benefit from better AI models because the model can execute longer, more complex specifications more reliably. They scale with both AI capability and human spec quality.

The bet on the CR pattern as the durable abstraction is the right bet. Prompts are a UI affordance. Specs are the unit of work.

Lovable, Bolt, v0, and the prompt-driven tools will continue to be useful for prototypes and demos. They've found their level. The next level (production code) requires a different abstraction.

What this means for buyers

If you're picking AI coding tools for your team in 2026, the question isn't "which has the best AI" or "which generates the most code." Both are well-correlated with the underlying model, which is converging across tools.

The question is "which tool treats specs as first-class." The ones that do will produce production code. The ones that don't will produce prototypes you can't deploy.

The litmus test: ask the tool to handle a specific edge case in your existing code. If the tool needs you to write a long prompt with sections labeled "requirements" and "edge cases," the tool is prompt-driven and you're fighting it. If the tool has a spec interface with sections, structured acceptance criteria, and test plans as first-class concepts, the tool is spec-driven.

The closing thought

The AI coding industry needed to learn that prompts are not specs. Some of the industry has learned. Some still hasn't.

The teams that learn it earliest get the largest gains. They produce more software, faster, with smaller teams, because they've moved past the prompt-engineering ceiling.

The teams that don't will keep producing prototypes that they can't ship, blaming the AI, when the actual problem is that they're trying to use prompts where they need specs.

If you're shipping production code with AI in 2026, you're already implicitly doing spec-driven development, even if your tools don't have the concept. Avery makes it explicit. The CR pattern is the spec format. The tooling supports it from day one.