Chapter 5 · Control Mechanisms: Preventing Scope Creep and Premature Victory

Chapter goals: Master control mechanisms that prevent agents from going off-track or declaring completion too early, and understand the three-layer termination check and verify-check dual-gate.

5.1 The Trap of Premature Victory

You ask the agent to implement a "password reset" feature. It modifies the database schema, writes the API endpoint, adds email templates, runs unit tests (all green), and confidently tells you "done." But when you actually run it: the mail service config is missing so links can't be sent; the database migration failed mid-way leaving an inconsistent schema; the end-to-end flow was never run once.

This is not an isolated incident. A classic 2017 ICML paper proved that modern neural networks are systematically overconfident — the confidence a model reports is significantly higher than its actual accuracy. AI coding agents are no exception. They "feel" done, but are actually far from it. Your harness must replace the agent's "feeling" with externalized, execution-based verification.

5.2 The Slippery Slope

Premature completion claims almost always follow the same script: the code looks fine — syntax is correct, logic seems reasonable, static analysis shows no obvious errors. But the harness doesn't mandate comprehensive execution verification, so the agent skips actual running or only runs partial tests. Run unit tests but skip integration tests; run tests but don't check coverage. Ultimately, "the code looks fine" is taken as evidence that "the feature is done."

Information degrades at every stage. From task spec to code implementation to runtime behavior, each transformation can introduce bias, and each skipped verification amplifies information asymmetry.

5.3 Three-Layer Termination Check

Agent says: done
    ↓
Layer 1: Run lint / typecheck first
    ↓
Layer 2: Then run tests and startup checks
    ↓
Layer 3: Finally run the full user flow
    ↓
Pass all three layers to count as done

Code written + unit tests green
    ↓
But app doesn't actually start + full flow never run
    ↓
Config, DB, external service issues all hidden
    ↓
So the agent declares victory prematurely

5.4 Green Unit Tests ≠ Task Complete

This is the most common trap and the most dangerous. The agent writes code, runs unit tests, sees all green, and says "done." But the design philosophy of unit tests — isolating the unit under test, mocking dependencies —恰恰 makes them unable to detect cross-component issues:

Interface mismatch: the renderer passes a relative path to the preload script, but the preload script expects an absolute path.各自的 unit tests both pass because they use mocks. The problem only surfaces during end-to-end testing.

State propagation errors: a database migration changes the table schema, but the ORM cache layer still holds cache entries for the old schema. Unit tests run in a fresh mock environment every time, so this cross-layer state inconsistency is never exposed.

Environment dependencies: code behaves correctly in the test environment (everything mocked), but fails in the real environment due to config differences, network latency, or service unavailability.

"While I'm At It, Let's Refactor" Is Poison to Completion Judgment

Claude Code has a common behavior pattern: it starts refactoring code, optimizing performance, and improving style before the core feature passes verification. Knuth's famous quote "premature optimization is the root of all evil" takes on new meaning in the agent context — refactoring moves the boundary between verified and unverified code, potentially breaking code paths that were implicitly correct.

The Systematic Bias of Self-Assessment

Anthropic's 2026 research discovered a deeper failure mode: when asked to evaluate its own work, the agent systematically gives overly positive assessments — even when human observers would judge the quality as clearly substandard.

This problem is especially severe on subjective tasks (such as design aesthetics). "Is the layout polished?" is a judgment question, and the agent reliably skews positive. Even on tasks with verifiable outcomes, the agent's poor judgment ability degrades its performance.

The solution is not to make the agent "more objective." The same model generating and evaluating is inherently biased toward being lenient with itself. The solution is to separate "the one who works" from "the one who checks."

An independently-assessed agent, specifically tuned to be "picky," is far more effective than having the generating agent self-assess. Anthropic's experimental data:

Architecture	Runtime	Cost	Core Feature Usable?
Single agent (bare run)	20 min	$9	No (game entities unresponsive)
Three-agent (planner + generator + evaluator)	6 hr	$200	Yes (game fully playable)

Identical model (Opus 4.5) and identical prompt ("build a 2D retro game editor"). The only difference is the harness: from "bare run" to "planner unfolds requirements → generator implements feature by feature → evaluator actually clicks through tests with Playwright."

5.5 How to Prevent Premature Completion Claims

1. Externalize Termination Judgment

Define termination conditions explicitly in the harness. The agent must satisfy all conditions before declaring completion. "Done" becomes an objective judgment instead of a subjective one.

## Termination Conditions
- [ ] All unit tests pass (pytest tests/ -x)
- [ ] Type checks pass (mypy src/ --strict)
- [ ] Lint clean (ruff check src/)
- [ ] End-to-end tests pass (playwright test e2e/)
- [ ] Performance benchmarks not degraded (benchmark.sh)

2. Verify-Check Dual Gate

Gate 1 (verify): check whether the code correctly implements the specified behavior. Gate 2 (check): check whether the system-level behavior meets end-to-end requirements. Only passing both gates counts as done.

3. Runtime Feedback Signals

Log output from program execution, process status, health checks — these form the objective basis for the harness to judge completion quality.

4. Completion Priority Constraints

Verify functional correctness first, then handle performance, then handle style. Refactoring is not allowed before core features are verified.

5.6 Feature List as Scope Control

A Feature List is an effective tool for controlling the agent's scope:

{
  "project": "my-app",
  "features": [
    {
      "id": "auth-001",
      "priority": 1,
      "title": "User Login",
      "status": "passing",
      "verification": ["POST /api/login returns 200", "JWT returned"]
    },
    {
      "id": "auth-002", 
      "priority": 2,
      "title": "User Registration",
      "status": "in_progress",
      "verification": ["POST /api/register creates user", "Email sent"]
    }
  ]
}

Rules:

• Do one feature at a time
• Don't mark a feature done unless verification passes
• Don't modify code outside the current feature's scope (unless a blocker forces a narrow support fix)

5.7 Chapter Summary

• Agents are systematically overconfident; external verification is needed to replace "feeling"
• Three-layer termination check: lint/typecheck → tests → end-to-end flow
• Green unit tests ≠ task complete; need verify-check dual gate
• Separating "generator" and "evaluator" is key to addressing self-assessment bias
• Feature List controls scope; do one feature at a time
• Completion priority: functional correctness > performance > style

🧪 随堂测验

点击你认为正确的选项。答错时会展示正确答案与原因解析。

1. What is the core cause of premature completion claims?

2. In the verify-check dual gate, what does the "check" layer examine?

3. In Anthropic's experiment, what is the main advantage of the three-agent architecture over a single bare-run agent?

4. What is the primary purpose of a Feature List?

🛠️ Hands-on Practice

1. Write a complete termination-condition checklist for a simple feature, including at least three layers of verification.
2. Implement a verify-check dual gate: Gate 1 runs unit tests, Gate 2 runs end-to-end tests.
3. Create a Feature List JSON to track the status and verification evidence for 3 features.

Next chapter: Observability and Session Cleanup