TL;DR — For reversible, stage-sensitive engineering decisions, AI assistants default to production-grade advice unless you specify business context. This isn't a model intelligence problem you can wait out. It's an objective-function problem you can fix in the next prompt. Below: the mechanism (with appropriate hedging), a before/after example, and a concrete taxonomy of what "context" actually means.

1. A Scene You've Probably Seen

Fifty users. MVP stage. Hypothesis validation is the only thing that matters.

You ask Claude Code to do a security review. You get back:

• "Move the database into a separate VPC and use VPC Peering or PrivateLink."
• "Wrap every external call in mTLS with automated cert rotation."
• "Stream audit logs to a separate AWS account for SOC2 readiness."

None of it is wrong. But if you do all of it at this stage, you'll burn your runway on infra migration before validating whether anyone wants the product.

The same pattern shows up outside security:

• Redis cluster with read replicas recommended for a 30 RPS service
• Hexagonal architecture proposed for a 100-line script
• GitOps + ArgoCD + Terraform module separation recommended for a 3-person team

The usual conclusion follows:
"AI can't do trade-offs. Humans need to decide."

The direction is right. The diagnosis is too vague to act on — so let's narrow it.

2. Scoping the Claim

This article is about a specific class of decisions: reversible and stage-sensitive.

• Reversible: you can undo it without losing data, breaking contracts with users, or rewriting half the codebase. (Adding Redis is reversible. Changing your primary key strategy is not.)
• Stage-sensitive: the right answer depends on where you are (MVP / growth / scale), not on universal best practice. (Caching layers, auth hardening depth, observability depth, infra topology.)

For irreversible or stage-insensitive decisions — DB engine, public API contracts, auth model, multi-tenancy boundaries, anything touching PII or payments — AI's conservative reflex is closer to right. That's covered in Section 6.

Within scope, the claim is:

AI assistants default to production-grade advice. You can change that, but only by stating your stage, scale, and trade-off weights explicitly.

3. Why the Common Diagnosis Falls Short

"AI only has the codebase as context, so it can't reason about trade-offs."

Three problems with this framing.

(a) Trade-offs are value judgments, not capability tests.
Risk preference, time preference, capital allocation — these are objective-function definitions, not things a model can derive from code alone. Two senior engineers reading the same code reach opposite conclusions. The CTO says "ship," the security lead says "no" — neither is smarter. They optimize different functions. Asking AI to "make the trade-off" without naming the objective is asking it to optimize without a loss function.

(b) You're not unable to give it context. You're choosing not to.
Every major coding assistant has a context-injection slot: CLAUDE.md, .cursorrules, AGENTS.md. Most "AI gave a bad recommendation" stories are at least partially "the user didn't specify context" stories — not all of them (models also hallucinate, miss repo state, or carry generic safety bias), but more than people admit.

(c) Humans over-engineer too.
Senior engineers carry trauma from past outages and pre-armor their code. AI's over-engineering and human over-engineering have different failure modes — AI tends toward boilerplate hardening, humans toward sticky abstractions — but neither is automatically easier to undo. The real axis isn't AI vs. human. It's context-aware vs. context-blind decisions.

4. A Hypothesis: The Production-Mature Prior

Here I have to hedge, because nobody outside the labs knows training mixes for sure. But the publicly visible candidates for what feeds these models are skewed:

• High-star GitHub repos (already scaled, already hardened)
• Vendor docs (AWS, GCP, k8s) — best-practice prose, not MVP code
• High-vote Stack Overflow answers (often "the robust way")
• Tech blog post-mortems ("here's what we should have done")

What these share: they document code that survived long enough to need scale, reliability, and compliance vocabulary. MVP-shaped code — single-file Flask apps, a docker-compose.yml with ten environment variables, a single RDS instance, hand-rolled session cookies — exists in training data too, but the advice prose attached to it is rare. The model has read a lot more "you should harden this" than "this is fine for now."

This is a hypothesis about a contributing factor, not a proven mechanism. Outputs also reflect instruction tuning, RLHF, system prompts, and safety policies — any of which can independently push toward caution. But it lines up with the observed behavior, and it's testable: try the before/after in Section 5 yourself.

Security review amplifies the effect. Threat catalogs (OWASP, CVE) are by construction lists of things that went wrong. A model trained heavily on those, when asked "is this secure?" without a threat model, hedges toward more findings — false positives increase when the model can't price the cost of being wrong in either direction.

5. Before / After — Same Model, Different Context

Here is the actual move. Same model (Claude Sonnet 4.6), same prompt, same code. The only difference is whether business context was supplied.

Code under review: a 60-line Express endpoint that accepts a JSON payload, looks up a user by email in Postgres, and returns a JWT.

Before — no context

Prompt: "Review the security of this endpoint."

Response (paraphrased, typical shape):

1. Add rate limiting with Redis token bucket
2. Move JWT secret to AWS Secrets Manager
3. Enforce mTLS between service and database
4. Audit-log every auth attempt to a separate AWS account
5. Add a WAF in front of the load balancer
6. Implement refresh token rotation with revocation list
7. Add CAPTCHA on repeated failures

Seven recommendations. None wrong in absolute terms. All sized for a company past Series A.

After — with context

Add this paragraph to the prompt (or to CLAUDE.md):

Stage: MVP, 50 users, solo dev, $200/month infra budget, 8-month runway.
Threat model in scope: of the OWASP Top 10, prioritize Injection (A03),
Broken Authentication (A07), and Sensitive Data Exposure (A02). Out of scope:
nation-state attackers, insider threats, denial-of-service.
Anti-goals: do NOT recommend mTLS, WAF, separate AWS accounts, or anything
requiring a dedicated infra hire.

Response (paraphrased, typical shape):

1. Confirm parameterized queries (looks fine)
2. Hash passwords with bcrypt cost ≥12 — current code uses cost 8, raise it
3. Validate JWT signing alg explicitly; reject alg: none
4. Put the JWT signing secret in an env var; document a rotation procedure (manual is fine at this stage)
5. Log auth failures to existing application logs; add a counter for "review at 5k MAU"

Five items, all things a solo dev can do this afternoon. Same model, same code.

That's the entire claim of this article, demonstrated. Try it on your own code; the shape of the answer changes.

6. The Reframe

The loose version:

"AI can't do trade-offs. Humans must decide."

The sharper version:

For reversible, stage-sensitive decisions, AI defaults to production-grade advice. The intervention point is supplying business context — stage, scale, trade-off weights, anti-goals.

This framing is more useful than the original because:

1. It points to an action. The responsibility moves from "AI is limited" to "I haven't told it where I am." Whether or not that's the whole story, it's the part you can fix in the next prompt.
2. It's durable, but not "permanently true." Future tooling will surely improve at inferring stage from repo shape, asking clarifying questions, and pulling org context from product telemetry. But humans will remain accountable for the objective function, even when they delegate parts of stating it.
3. It admits scope. It's a claim about reversible × stage-sensitive decisions, not all decisions.

7. What "Context" Actually Means — a Taxonomy

"Give the AI more context" is vague advice. Useful context has four layers:

A working CLAUDE.md snippet for an MVP:

## Project Context

- **Stage**: MVP — validating hypothesis. 50 users, target 200 MAU.
- **Team**: Solo developer. No ops headcount.
- **Constraints**: 8-month runway. Infra budget under $200/month.
- **Trade-off weights** (highest to lowest): ship speed, code clarity,
  scalability. Latency p95 under 1s is fine.
- **Security scope**: OWASP Top 10, prioritized — Injection, Broken Auth,
  Sensitive Data Exposure. Out of scope: nation-state, insider threats, DoS.
- **Anti-goals — do NOT recommend**:
  - Microservices, k8s, service mesh, mTLS
  - VPC Peering / PrivateLink / separate AWS accounts
  - Architecture patterns for files under 200 LOC
  - Caching, queues, or workers for features without measured load
- **Re-evaluation trigger**: revisit these weights at 5,000 MAU or when
  payments ship.

The anti-goals list is the unusual part. Most people skip it. It's the highest-leverage line in the file: it removes a class of recommendations the model would otherwise default to.

8. When AI's Default Is Actually Right

The thesis is scoped to reversible × stage-sensitive decisions. Outside that scope, AI's conservative bias is an asset:

• Non-recoverable downside — anything touching PII, payment data, health data, customer secrets, auth tokens. Also: tenant isolation, key management, backup/restore, audit logs, retention/deletion compliance, breach notification readiness, secrets handling, vendor and supply-chain risk.
• Regulated industries — finance, healthcare, government, ed-tech with minors. The default prior may even underestimate what's required.
• Expensive-to-reverse decisions — primary DB engine, auth model, multi-tenancy boundaries, public API contracts, event schemas, ID strategy, billing model, permission model, observability foundations.

For these, lean into the conservative recommendation. Override only with a written reason.

The honest summary: this article is a heuristic for one specific quadrant of decisions, not a universal law.

9. What Would Change This?

It's tempting to add "at least for now" at the end and move on. Worth a beat instead.

Things that would partially close the gap:

• Stage inference from repo shape — a meta-layer that looks at commit cadence, test coverage, observability stack, and recommends differently for "solo founder Express app" vs. "Series B microservice fleet."
• Org-aware agents — read access to product metrics, infra spend, roadmap, risk policy. So the model can reason about cost the way a senior engineer does.
• Policy profiles — "MVP mode" / "scale mode" / "compliance mode" as first-class settings.

What won't change: humans remain accountable for the objective function. Even if the tool infers your stage, you still own the decision of whether to accept the inference. So the practical claim — supply context, or don't be surprised by the defaults — survives most plausible improvements.

10. Summary

One actionable rule: before your next "review this" prompt, write four lines — stage, constraints, trade-off weights, anti-goals — into the prompt or into CLAUDE.md. Re-run. If the recommendations don't shift, your context is probably still too thin or you've hit a different failure mode (the model ignoring the file, generic safety bias, or a genuine capability limit). At that point, you have a real problem to debug instead of a vague "AI gave bad advice."

Open to feedback. Especially curious: (a) does the before/after replicate cleanly on your codebase? (b) where does the "Production-Mature Prior" hypothesis break — concrete counter-examples wanted. (c) is the same pattern visible in adjacent tooling — data engineering, MLOps, security scanners?