Anchoring Engineering: The Last Mile of AI Adoption

 I’ve seen this scene play out at tech conferences time and time again recently:

Under the spotlight, a presenter confidently demos their latest AI Agent system. Inside a carefully constructed sandbox environment, it performs flawlessly: querying databases with natural language, automatically screening resumes, or even logging in to order takeout.

“Incredible!” The CEOs in the audience watch with glittering eyes. “This is the productivity revolution we’ve been waiting for!”

With a wave of a hand, the directive comes down: “Integrate this into our order system next week.”

One week later, the engineering team quietly rolls back all the code.

When that agent actually faced the tangled legacy systems of the enterprise, poorly documented APIs, and databases full of dirty data, “AGI” instantly degraded into “Artificial Stupidity”: modifying refund amounts to appease customers, deceiving users due to hallucinations, or even suggesting DROP DATABASE to optimize performance.

Why are the demos so stunning, yet the real-world implementation such a mess? This isn’t just a matter of engineering maturity; it touches on the most fundamental contradiction of agents: The game between Determinism and Non-determinism.

Uncertainty: The Inevitable Cost of Intelligence

Before diving into technical details, we must accept a counter-intuitive fact: The cost of intelligence is uncertainty.

If a system is 100% deterministic, it’s not “intelligent” — it’s just a complex automation script. The very reason we need AI is to handle those fuzzy scenarios that hard-coded logic cannot cover.

This uncertainty comes from two ends:

1. Input Ambiguity: Human language is highly context-dependent. “Organize the files” means “archive them” to a secretary, but “throw them away” to a cleaner.
2. Output Probability: Non-determinism is like the chaos of the quantum world. Large models aren’t retrieving truth; they are collapsing the next word from a superposition of infinite possibilities. They are weavers of dreams, not recorders of reality. This mechanism is the source of their creativity, but also the root of their hallucinations.

Therefore, we cannot completely eliminate uncertainty, or we would kill the intelligence itself.

The Rising Bar: “Basic Intelligence” is Being Swallowed

If uncertainty is such a hassle, why do we insist on using it?

Because the potential payoff is too high.

AI is rapidly swallowing up “basic intelligence” labor. CRUD code that junior engineers used to write, document summaries done by interns, standard questions answered by customer support — all can now be replaced by AI.

But there is a brutal trend here: The threshold for “Basic Intelligence” is constantly rising.

Yesterday, “basic intelligence” might have meant simple text classification; today, it includes writing unit tests and SQL queries; tomorrow, entire CRUD business logic might fall under the “basic intelligence” category.

To gain the massive efficiency this automation brings, we must endure and manage the accompanying uncertainty. This is the price we must pay for “Intelligent Productivity.”

Your AI is Lying

The biggest challenge in landing AI agents is often not “what can it do,” but how to constrain it from “doing strictly wrong things.”

Current LLMs are more like drunken artists, particularly good at non-deterministic tasks: writing poetry, painting, brainstorming. This “free-rein” randomness is the source of creativity.

But in software engineering, non-determinism is a nightmare.

When you ask AI to modify code, it might:

1. Hallucinate: Import libraries that don’t exist.
2. Deceive: When facing a failing test, instead of fixing the code, it comments out the test case and reports “Fixed.”
3. Bullshit with Authority: Write meaningless test logic, or even hardcode return true to cheat the assertions.

I personally experienced a case where, in order to pass CI/CD, the AI quietly commented out all failing test files and thoughtfully wrote in the commit message: “Optimized project structure, ensured tests pass.”

AI doesn’t understand “correctness.” It is only trying to maximize its Reward Function — which means pleasing you.

Building Order in Randomness

There is a massive chasm here:

• Traditional Software Engineering: Built on absolute determinism (compilers never lie).
• AI Agents: Fundamentally non-deterministic probabilistic models.

When we try to build software products that must be deterministic using non-deterministic AI, conflict is inevitable. This is why Context Engineering is so hard: in the greenhouse of a Demo, context is controlled; in the wasteland of the real world, context is bizarre and unpredictable.

To combat this uncertainty, the industry has proposed many solutions, such as RAG (Retrieval-Augmented Generation), MCP (Model Context Protocol), Workflows, Specifications, etc. These methods are essentially “Pre-constraints” — attempts to increase certainty at the input and behavior boundaries. But as long as the core engine (LLM) remains probabilistic, the risk cannot be completely eliminated.

The key to untying this knot lies in introducing a new role: The Deterministic “Anchor”.

AI is like a kite, naturally prone to random movement in the sky. We need a string (the Anchor) to tether it, allowing it to dance within a controllable range.

Without this string, the kite either flies away (hallucination runs wild) or crashes (task failure). Only by holding this string can it fly high and steady.

For agent systems, the formula for future reliability should be:

$$ \text{Reliable AI System} = \text{Non-deterministic LLM (Creator)} + \text{Deterministic Anchor (Gatekeeper)} + \text{Human Guidance (Navigator)} $$

This is not just a technical reconstruction, but a reconstruction of the value chain:

1. Static Anchors: Syntax analysis, type checking. Low-level errors must be strictly intercepted by traditional compilers.
2. Dynamic Anchors: Rigorous automated testing. Code generated by AI must undergo stricter testing than human code. Test cases are the immovable “Constitution.”
3. Runtime Anchors: Sandbox isolation. All side effects (file usage, API calls) must be isolated to ensure observability and rollback capability.
4. Human Anchors: Values and Direction. AI has no values; values must be defined by humans. The human role is no longer just a coder, but providing critical directional guidance and correction mechanisms. When AI “goes astray” in the sandbox, humans must be like driving instructors, ready to slam the passenger brake at any moment.

The Final Level: Anchoring Engineering

Software development in the age of agents is no longer just bricklaying (Coding), but gardening.

Large models provide insane vitality, capable of growing a garden full of colorful plants overnight. The key to a harvest lies not in sowing, but in pruning. The shears in the developer’s hand are the Anchoring Tools.

In this era, productivity is no longer scarce; what is scarce is how to use those shears well, to cut away the toxic branches and keep the fruitful ones.

I call this “Anchoring Engineering.”

This is the craft that helps humans sift gold from the massive output of AI.

This will be the final level for AI adoption.

Stop worshipping the alchemy of Prompt Engineering, and embrace Anchoring Engineering.