After a year of running Claude Code in production, we've reached a clear conclusion: the bottleneck in getting AI to do real work isn't the model—shifting attention from "making the model smarter" to "making constraints harder" delivers results that exceed swapping models three times combined. The core idea is treating AI as a probabilistic execution system and using three layers of constraints to compress probability into determinism.
What this is
We break the engineering practice into three layers:
Rules layer (weak): Write project conventions into CLAUDE.md, .claude/rules/, Skills, and Commands. Key point: rules must be script-checkable—phrases like "high quality" carry almost no constraint force for the model.
Division of labor layer (medium): Use SubAgents to isolate roles. The classic three-role setup: planner (outputs plans only, never writes code), coder (implements per plan), and reviewer (an independent, smaller model in read-only audit mode). Core principle: keep the "writer" and "auditor" out of the same context to prevent self-review.
Feedback layer (strong): Use Hooks (auto-triggered script hooks), MCP (the protocol for connecting external tools), Checkpoints (auto-validation points), and acceptance scripts for runtime enforcement—no passing without compliance. This is the layer with real force.
The most counterintuitive finding: having AI review its own code is like letting a student grade their own exam; switching to a tier-smaller, different-series model for review actually breaks over-identification and costs less.
How the industry sees it
This echoes the AI engineering community's consensus shift over the past six months: from "tuning prompts and models" to "engineering constraints." Both LangChain and Anthropic emphasize similar views—70-90% of Agent project failures get stuck at the engineering stage, not from insufficient model strength.
The counter-argument is equally clear: managing AI like a "junior programmer that needs strict supervision" isn't cheap—the human cost of maintaining a 200-line CLAUDE.md and configuring Hooks may exceed hiring a junior engineer. This playbook only suits teams with sustained quality demands; for one-off scripts or personal projects, it's over-engineering.
Another view: the "compress probability into determinism" framing is overly optimistic. Same prompt, different outputs is fundamentally how LLMs work—engineering constraints can only reduce variance, not eliminate it.
Impact on regular people
For enterprise IT: When deploying AI coding tools, the focus isn't which model to pick, but whether your engineering team can maintain this constraint system—otherwise you'll likely get stuck at "dazzling demo, production flop."
For individual careers: There's an engineering-constraints gap between "using AI" and "delivering reliable output with AI." This threshold is becoming a new dividing line for programmers—not whether you can code, but whether you can set rules for AI.
For consumer markets: Regular users won't see this playbook in the short term, but SaaS providers will gradually wrap these constraints into their offerings. Future differences in "one-click AI coding" experiences may hide in these invisible engineering details.