Whitepaper: Why Asking AI to "Think Harder" Makes Brownfield Refactoring Worse: The Cognitive Split Hypothesis

By Ivan Stankevichus, AI Engineer at ModernPath

When an AI coding assistant produces a refactor that breaks a legacy system, the conventional response is to use a "stronger" model, ask it to think longer, or add more reasoning tokens. The logic seems sound: more compute should equal better output.

However, in brownfield codebases, this approach often has the opposite effect. Adding reasoning tokens without increasing grounding signals doesn't improve quality; it simply accelerates Assumption Drift.

To prevent this, teams should move away from the "single prompt" workflow and adopt a role-based architecture paired with a strict evidence protocol.

The "Reasoning Momentum" Trap

Between 2024 and 2026, the industry shifted toward test-time scaling—using additional inference-time compute to let models deliberate longer, sample multiple candidates, and apply search before answering. While this works for greenfield projects with clean specs, it introduces a dangerous failure mode in legacy systems.

In brownfield codebases, requirements are rarely fully documented. They live in the "tribal memory" of the code: timing dependencies, obscure data contracts, and operational side effects. When a high-reasoning model encounters these gaps, longer reasoning chains do not surface hidden constraints; they generate coherent narratives that fill in missing facts.

This is Reasoning Momentum. The model commits to a plausible story about how the code should work and then optimizes for internal consistency rather than for ground-truth correctness. The result is Semantic Drift: the code reads well and may even compile, but it violates a hidden invariant that crashes production weeks later.

The Cognitive Split: Discovery vs. Synthesis

To fix this, we must recognize the Cognitive Split Hypothesis. Reliable AI-assisted coding requires two fundamentally different kinds of cognition that should never be merged into a single model call:

• Strategic Reasoning (Synthesis): Deciding what should change, evaluating trade-offs, and sequencing the plan.

• Operational Grounding (Discovery): Querying the environment—running grep, reading logs, and tracing execution—to find the actual constraints of the system.

The Rule of Thumb: Use the strongest reasoning model for Synthesis, but only after the agent has completed tool-grounded Discovery. If you increase reasoning compute without increasing verification constraints, you are just searching harder in the wrong direction.

Why Brownfield is Structurally Different

Brownfield refactors are uniquely vulnerable because the cost of being wrong is asymmetric: a "clean" refactor that compiles can still break critical production systems. Three epistemic gaps explain why long reasoning alone fails:

• Hidden Constraints: Legacy requirements live in unwritten behavior and existing tests.

• Incomplete Context: Models rarely have the full operational picture, including deployment shapes and SLO constraints.

• Non-local Effects: Small refactors can change emergent system behavior, such as timing and concurrency, across untouched components.

A Practical Framework for Grounded Refactoring

To prevent Assumption Drift, teams should move away from the "single prompt" workflow and adopt a role-based architecture paired with a strict evidence protocol.

1. The EIA Protocol (Evidence-First Planning)

Before any code is changed, the Architect must label every key claim in their plan using the EIA Protocol:

• EVIDENCE: Facts cited directly from the repository, snippets, or test outputs.

• INFERENCE: Logic derived from evidence that is still reviewable.

• ASSUMPTION: Any claim lacking proof that must be validated before proceeding.

Standard Procedure: No ASSUMPTION is allowed to drive a code change until it is converted to EVIDENCE via a tool query or a "spike" test.

2. Role Specialization

• Architect (Planner): Clarifies intent, identifies constraints, and sequences the plan using the EIA protocol.

• Builder (Executor): Implements small, mechanical patches (defaulting to <200 lines) with a focus on minimal churn and mechanical safety.

• Verifier (Evaluator): A skeptical, independent "judge" that tries to disprove equivalence, probes edge cases, and demands evidence for every change.

The Economics of Inference-Time Compute

In professional software engineering teams, "better" results are achieved by treating inference-time compute as a budget with explicit stop conditions.

The objective is to minimize the Failure Tax: the cost of wrong patches, debugging time, and production incidents. As risk increases, the workflow should escalate along the Compute Budget Ladder:

• Level 0 (Low Risk): Minimal compute and strong existing tests.

• Level 2 (Higher Risk): Multiple candidates, independent judges, and targeted test creation.

• Level 4 (Critical Systems): Heavy discovery, staged rollouts, and incident playbooks.

Implementation Pipeline

A verified AI-assisted refactor follows a concrete four-stage pipeline:

1. Pre-flight: Gather ground truth, call sites, and invariants.

2. Plan: Produce a small-step plan with explicit EIA tags and per-step verification.

3. Patch: Implement one step at a time under a strict diff budget.

4. Verify: Run gates (build, tests, lint) and independently critique the patch.

Conclusion

The path to reliable AI engineering in legacy systems is not "always use the smartest model". It is the disciplined combination of role specialization and executable reality. In brownfield codebases, the winning strategy is to think in plans, act in small diffs, and verify constantly.

Stop asking the AI to "think harder" and start asking it to show the evidence.

The full paper

The complete white paper covers what this post introduces but does not resolve: the five recurring failure modes in brownfield AI refactoring and how to detect them early; a practical three-role framework (Architect, Builder, Verifier) with role-specific grounding requirements and model selection rules; a rule-based compute allocation policy that requires no ML training; the EIA assumption-accounting protocol for preventing confident plans from becoming fictional specs; a concrete four-stage pipeline (Pre-flight → Plan → Patch → Verify) with implementation patterns applicable to any model vendor, IDE, and repository; and a cost and latency model for treating inference-time compute as a budget with explicit stop conditions.

Ivan Stankevichus is an AI Engineer at ModernPath. ModernPath builds the enterprise platform for architecture-driven AI development in brownfield systems.