AI Coding in Zero-Tolerance Distributed Storage: Meituan's Review, Debug & Automation Practices

1. Background: Why Distributed Storage Demands Cautious AI Coding

Since early this year, with the spread of agents, AI Coding has become usable in feature development, test generation, script writing and execution, and troubleshooting: reading code faster, letting AI produce a first implementation and tests, and offloading miscellaneous tasks. Efficiency rose, but the quality accounting must be redone. With the same headcount, a release delivers more features and more code changes; even if AI-written code has the same defect density as human-written code, the absolute number of defects introduced per release still grows. Therefore the goal of AI Coding cannot be just writing code faster; while accelerating, code quality and verification thoroughness must exceed normal development standards.

Distributed storage amplifies this problem. The codebase is large, inter-module relationships are complex, and consistency, concurrency, persistence, failure recovery, and performance are all intertwined. A seemingly local change may behave normally until a node restart, disk anomaly, network jitter, or high concurrency exposes it. When issues arise, they affect not just one feature but upstream business data availability and system stability, sometimes even data correctness. Storage services underpin many upstream businesses; fault blast radius is large, repair is hard, and defect tolerance is extremely low.

Meeting such quality requirements means AI code generation alone is insufficient. AI code review, AI testing and verification, AI debugging, and controlled automation must be built together so that AI-generated code can enter the development pipeline with confidence. This article combines the storage team's practices in AI review, AI debug, and AI automation to discuss how to use AI for speed while enforcing stricter review, testing, debugging, and automated verification to guard stability and data correctness in high-complexity, low-fault-tolerance systems, hoping to provide reference for similar systems adopting AI Coding.

2. AI Code Review: Useful Supplement, But Cannot Replace Human Judgment on Design Context

2.1 Where AI Review Excels

1. Cross-file consistency detection

Example: ENABLE_UNITTEST controlled test mock variant compilation branches at three call sites, but the CMake migration renamed it to WITH_UNITTEST; the old name was never assigned again. No single file showed a problem; the bug existed only in the gap between files.

2. Constructing executable evidence

Example: After flagging "missing boundary check here," AI did not stop; it crafted a malformed packet declaring a 1 GiB payload but containing only 5 bytes, sent it to the real decode entry, and captured the crash site.

3. Admitting what it cannot prove

Example: For a suspected concurrency race, AI could only find a suspicious path via code walkthrough. It explicitly stated that confirming the interleaving required ThreadSanitizer, which the current toolchain could not run, so it marked the item "unverified" instead of labeling it a defect.

4. High recognition rate for common concurrency patterns

Example: A "read-validate-then-write-advance" update without mutual exclusion in between was consistently identified across multiple reviews, with consistent fix direction (merge into a single atomic operation). Such common concurrency patterns are recognized stably and can be codified as fixed check items.

5. Never misses deleted code in a PR

Example: A refactor merged an interface into a single RPC and incidentally deleted the old logic that cleaned local cache on success. AI pointed out this would leave a brief window where stale data could be read. Humans are least sensitive to deleted lines.

6. Reviews incremental changes against existing codebase

Example: Before reviewing, AI analyzes the existing codebase. In a large PR, new code might incidentally fix an existing issue; human reviewers often mistake such incidental fixes for new problems. AI lists "pre-existing, already fixed in this change" separately and declares them not to be reported as issues.

7. Review not limited to code changes

Example: In a PR, three repositories' build files referenced each other via feature branch names without pinned versions; wrong merge order or branch cleanup would break trunk build. This is a "merge orchestration" issue most likely missed by humans looking only at the PR page, but AI treated build files as review objects too.

2.2 Where AI Review Goes Wrong

Most AI misjudgments stem from inability to see things outside code: operational processes, design decisions, team conventions. Our practice revealed issues in fix suggestions, signal-to-noise ratio, severity grading, and evidence selection.

1. Code reachable ≠ operationally reachable

Example: A report flagged an expired-epoch code path as a real risk. Human review questioned not the code itself but whether surrounding systems would ever produce input that reaches this branch: "EPOCH_NOT_MATCH only occurs in migration split+1; after split the old region no longer exists; after migration the src doesn't exist either, so EPOCH_NOT_MATCH theoretically never reaches this branch."

Same situation appeared for a one-day expiry timer flagged as a race window: "Migration is manual; production never has a migration initiated but not succeeded for a day; it requires manual intervention; the one-day expiry solves this." AI can model the timer but not the manual process wrapped around it.

2. Treating intentional deviations from common practice as defects

Example: A report flagged a production abort() in a consistency check as a correctness risk, suggesting logging an error instead of crashing. We chose abort because storage systems prioritize correctness over availability; in specific scenarios we would rather abort than let the request continue and produce extremely hard-to-handle dirty data.

3. AI's attached fix suggestions themselves need review

Example: For a 32-bit overflow, AI suggested validating declared size against actual received bytes. Review found get_size() returns int; sizes between 2³¹ and 2³² become negative, causing the validation itself to silently fail. The individual case was fixed but the same class of problem remained.

4. Cheap "please confirm" items drown real signals

Example: AI review flagged thread pool defaults, renamed config items, removed secondary cache flush switches as "to confirm." Every reply cited the team's own historical benchmark data, unrelated to code defects: "Adjusted per benchmark; background thread count lowered to reduce foreground impact."

5. AI review severity grading is distorted

AI lacks a clear quality gate: the same class of theoretical issue might be graded highest this time and unimportant next time. Receiving an AI report, grades cannot be fully trusted; to be safe one must review every item individually, making it hard to focus on truly high-severity issues.

6. Treating comments, header assertions, and design docs as evidence

Example: Two AI reviews used the same "scenario × constraint" framework but reached opposite conclusions. One simply repeated a header assertion to judge the implementation correct; the other cross-checked the actual implementation and judged it wrong. Another example: blindly relying on a design doc's required version continuity check that had no reference in the code.

The code examined was identical; the difference was whether the "explanations" themselves were verified.

2.3 Making Review Conclusions Actionable: Build Tests, Integration Tests, Runtime Logs

Static review only shows "this path exists in code." Whether it actually fails, whether existing protections catch it, whether it has happened in production — these need three additional evidence types.

2.3.1 Build + Unit Tests: Turning Reasoning into Red/Green

Experiment: For 117 suspected issues from a full-repo AI review, AI wrote gtest verifications one by one; a test failing on master counted as confirmed. Results: 36 red tests confirmed, 3 falsified (false positives), 41 only verifiable by source inspection, 37 unverified.

Verdict certain. Red tests concentrated in three categories: input triggers abort, error swallowed but success reported, decode out-of-bounds. Severity can be set by failure phenomenon, no need to parse AI wording.

Falsifiable. 3 items overturned by tests — a conclusion static review struggles to give.

Exposes CI issues. E.g., test report hardcoded failures="0"; failed cases not aggregated. AI must build itself and read raw output, not trust CI green light.

Boundaries. Races and UAF need sanitizers; timing issues need scheduler control; fault injection points, constrained hosts, clock skew — gaps remain. The "unverified" list is exactly the test infrastructure backlog. Red tests only prove code can fail, not that production will generate that input: a data migration scenario test confirmed data expiry issue, but human review found the expiry was intentional in the manual process.

2.3.2 Production-Close Integration Tests: Main Value Is Reducing False Positives

We have a project whose class implementation allows launching a real multi-node Raft cluster in a single process, enabling full-repo verification of all "production cluster" scenarios.

Let existing protections participate in verification. An AI-reported issue claimed leader switch would cause delete data loss; an existing integration test happened to switch leader in the delete window, proving safety.

Arbitrate disagreements. E.g., "can snapshot capture split intermediate state?" Two AI reviews disagreed. Writing a test that walks the real change_peer entry with a sync point injecting a write directly decided it.

Fake/mock boundaries are verification boundaries. Fakes must walk real entry points, use production config, and document what was replaced.

Example: A distributed KV hang alert bug wasn't caught because test setup differed from actual production occurrence; network-stage drop protection in unit test was hand-fed timestamps, while production path never sets them.

2.3.3 Runtime Logs: From "Might Happen" to "Already Happened"

Experiment: Fed 11 days of WARN logs from one storage node (678k lines, 34 call sites) to AI to map back to source code; found 5 defects, all manually confirmed true, zero false positives.

Finds issues static review wouldn't suspect. Example: "fail times 1" appeared once in 11 days, indicating a stuck counter so hang alert would never fire.

Falsifies wrong hypotheses. Example: A 19-minute response; sum of stage latencies / total latency ratio consistently 1.0, ruling out clock error, pinpointing missing drop protection in send phase.

Grounds severity in data. Example: Measured stage latency already 1,156 seconds, less than 2× away from int32 overflow for storage latency.

Two defects were not directly triggered by logs; AI discovered them while reading adjacent code to explain logs — equally valid. Real configs and magnitudes from logs may also make adjacent code reasoning more accurate. This is one sample, not proof of zero false positives, but supports a practice: when runtime logs are available, both review and debug should attach them. Log limitations: only covers executed paths; line numbers may mismatch deployed version (must locate by message text and function name).

2.3.4 Summary of Evidence Layers

Static reasoning — Can answer: Does this path exist in code? Cannot answer: Does it actually fail? Is it reachable? Has it happened in production?

Build + unit tests — Can answer: Does it fail under given input? Cannot answer: Races and timing; will production generate that input?

Integration tests — Can answer: Is it still reachable under real interactions and existing protections? Cannot answer: Has it really happened in production?

Runtime logs — Can answer: Has it happened in production? Frequency and magnitude? Cannot answer: Paths never executed.

These four evidence layers complement each other: static review finds candidates, tests judge truth, logs check reality.

2.4 Recommendations for Using AI Review

Output conclusions in four evidence tiers, don't mix them: test-confirmed (attach a failing test on current trunk), test-falsified, source-trace-confirmed (state why not testable), unverified (state specific missing conditions, not vague "needs environment"). Aggregated "unverified" items across reviews become the test infrastructure backlog. Report must distinguish whether each conclusion comes from test, runtime log, or code reading; logs located by message text and function name, not line numbers.

"No issues" conclusions must list checked paths: Write "the following N paths checked, each with line numbers and why counterexamples don't hold; rest uncovered." Same scenario framework, weaker model config gave "no correctness issues," stronger config produced opposite causal chain. "No issues" stops subsequent investigation — the costliest sentence in review.

Review checked-out code, not PR webpage: Any assertion about repo state (what's tracked, committed, conflicts) must attach actual commands and outputs run on real branch. E.g., a PR webpage diff shows only ~2% of real changes; server-side merge preview drops most branch content. Before review, verify the review object itself with three-way diff.

For AI's type or boundary fix suggestions, first list all types along the call chain: Before adopting, enumerate every function signature the value passes through; width mismatches often appear two functions downstream (see 2.2 case 3).

Context: provide stable invariants, not all docs: Many misjudgments root in AI missing background: which invariants are guarded by intentional aborts, which timers wrap manual processes, which designs were long settled. But details are many, implementations change often; stale info misleads AI (we tried feeding project docs and history as knowledge base — both caused misdirection due to outdated content). Better: provide only stable, high-level invariants and key design constraints, maintained alongside code. PR-specific design docs work well with prompts; defect knowledge base (including accept/reject and deferred) prevents repeated false positives (watch for it hiding regressions). After each review, add "what missing context caused AI misunderstanding," not just pile found issues into agents.md/claude.md. Knowledge base effectiveness highly model-dependent: SOTA models filter redundancy; weaker models get misled.

Don't replace correctness judgment with multi-agent voting: Multiple agents read same diff, share same missing background, share blind spots, err consistently in same place. Practice: merged report once took multiple agents' same wrong conclusion as correct, marked highest priority. Vote count reflects overlap, not correctness; cross-review conclusions still need per-item verification.

Require AI to declare if execution degraded: AI review usually starts with code indexing etc.; any step failure may silently degrade to grep-like strategy, lowering accuracy without report mentioning it. Report must state which tools/steps used, which failed or degraded, to assess conclusion credibility.

3. AI Debug: Accelerates Localization, But Cannot Be Root Cause Conclusion

AI Debug's direct value: shortening the path from "see anomaly" to "find direction worth verifying." It quickly correlates logs, metrics, stack traces, code, and config across multiple directions, proposes candidates, generates diagnostic scripts, minimal repros, and controlled experiments. For cross-module, cross-repo issues, it saves significant information gathering and repeated investigation time.

But AI's explanations, no matter how complete or specific, cannot be taken as root cause conclusions. Distributed storage failures often depend on concurrent timing, node roles, persisted state, recovery process, external dependencies, and operational actions; AI usually sees only a subset. It easily finds a code path that "explains the phenomenon" but hasn't proven production actually took that path, nor that other causes couldn't produce the same result.

Better positioning: treat AI as hypothesis generator and verification assistant in debugging: it expands search space, compresses investigation scope, executes controlled verification; humans contribute system semantics, judge evidence strength, confirm root cause, and review fixes.

3.1 Where AI Debug Excels

1. Rapid aggregation of scattered clues

AI can align logs, metrics, stack traces, config, and code changes from different nodes onto a single timeline, then trace producers and consumers of the same state. Cross-file retrieval, normal vs abnormal path comparison, version diff organization — such mechanical work suits it best.

Example: Create succeeds, subsequent operation fails, later retry recovers. AI linked three code repos, found error from "could not find newly created resource." Human added "DB has record, request routed normally, retry succeeds later," narrowing to cache: before create, a machine cached "resource not exist"; after create, cache not updated in time, causing subsequent failure. Periodic refresh later synced cache with DB, retry succeeded.

2. Parallel proposal of verifiable candidates

Same latency, error code, or state anomaly often has multiple explanations. AI can expand from cache, queue, concurrency, network, persistence, replay, resource contention directions simultaneously, listing necessary conditions and missing evidence for each. This candidate set helps engineers decide what to check next, not for AI to pick "most likely root cause."

Example: Old data never cleaned, space growing continuously. AI organized candidates: "cleanup task not running, data still in use, delete failed" with corresponding log clues. Human found: node already working but cleanup module's "startup complete" flag not set, so every cleanup round skipped. AI provided itemized investigation checklist; human confirmed actual cause with on-site logs.

3. Deriving local mechanisms into executable experiments

AI can turn code conditions, thresholds, execution order into explicit experiment expectations, combine with actual inputs and config, check if conditions can hold simultaneously. Experiments must walk real entry points, let system produce the state under verification, and set controls and assertions that distinguish explanations. Thus "looks like it might happen" becomes "reproducible or falsifiable."

Example: Turn "where space lost" speculation into full-chain experiment. On request validation failure, AI used single-point experiment confirming server trims leading/trailing spaces, initially attributing to server. Human demanded client check; AI converted to verifiable comparison: record client's signed content, actual sent content, server's received content for re-signing, compare segment by segment where first difference appears. If content changed before send, "server first rewrite" explanation falsified. Experiment found: client computed signature with spaces, then deleted spaces before sending, making signature mismatch actual sent content. AI corrected its earlier causal attribution.

4. Continuously narrowing problem space with new evidence

AI can combine segmented observations and controlled experiments to stepwise confirm which factors participated and adjust investigation priority. After each intervention, compare results with original anomaly and normal baseline to see what's explained and what deviation remains. If metrics haven't returned to baseline, keep investigating; don't treat local improvement as investigation endpoint.

Example: See 3.1 point 1. "DB has record" ruled out create-not-written explanation; "request routed normally" ruled out wrong destination; "retry succeeds later" further pointed to time-varying cache state. Each new evidence adjusted candidate scope, combined with cache update logic to explain whole process.

3.2 Where AI Debug Goes Wrong

1. Incomplete input, missing evidence, yet gives complete and certain conclusion

Code and logs rarely hold full production state, design decisions, operational constraints. AI tends to fill gaps with unverified premises, write partial deduction as complete causal chain, even qualify without logs, code, or on-site evidence. Must make it explicitly list assumptions and missing info; each key judgment attach verifiable evidence and state which step it supports; no evidence → mark as hypothesis or to-verify. Fluent analysis with line numbers only means it's easy to review, not that conclusion is correct.

Case 1: Partial query missing ≠ ID collision. AI found a pre-create query only returns normal objects, not deleting ones. It treated this as key check preventing duplicate creation, inferred "old object not found → may allow same ID to create again." Human noted: new object ID guaranteed unique by unified allocator; this query not responsible for ID allocation; "same ID re-enters creation flow" premise false, risk conclusion withdrawn.

Case 2: Parallel test failure cause not initial name collision guess. Tests run simultaneously started failing; AI initially blamed random name collision. Human demanded log evidence; analysis confirmed: one test's cleanup deleted another test's resource. Name collision sounded plausible but couldn't replace evidence of actual deletion behavior.

2. Treating single-point fact as causal location

Single-point experiment proves a component has a behavior; doesn't prove this anomaly originated there. Must follow actual processing chain, align inputs/outputs/states at each stage, find first deviation from expected, then verify how later stages propagated or masked it. Upstream/downstream evidence complete → distinguish where anomaly generated vs where observed.

Example: See 3.1 point 3 space validation issue. "Server trims leading/trailing spaces" had single-point experiment support, but couldn't prove this request's spaces first lost at server. Full-chain experiment found difference appeared before send, showing real evidence ≠ correct causal location judgment.

3. Mixing contributing factors, mitigation effects, and root cause

Phenomenon improves after an operation → only correlation; operation may change multiple conditions or clear the scene. Cause of initial error, conditions that surfaced existing problem, factors that amplified impact, measures that restored service — must separate, confirm each via controlled variables and before/after evidence; cannot upgrade "effective mitigation" to "root cause found."

Example: See 3.1 point 1 create-then-fail issue. Request recovered because cache refreshed; but defect of not updating stale cache at create time still exists; same operation sequence may fail again. Explaining "why recovered this time" ≠ solving "why it happened."

4. Mistaking static reachability or green tests for production occurrence

Static analysis finds a dangerous path → only a risk candidate. To judge if it causes real issues, check if trigger conditions can be simultaneously satisfied in real runs, and if system's existing protections can catch or limit impact. To further qualify as this incident's cause, need on-site evidence proving that path was taken then and observed anomaly caused by it. Green tests only prove given env/inputs/assertions hold; cannot say production already saw same issue, nor that system overall is correct. Static deduction, experimental verification, on-site evidence each prove to a different step — must label clearly.

Example: 3.2 point 1 ID collision false positive. AI deduced duplicate creation risk from local query gap, but never proved same ID could be re-allocated. Global ID rules made premise false; deduction neither proves actual risk reachable nor can be written as occurred fault. This case illustrates static deduction's proof boundary.

5. Local optimal patch around trigger case, doesn't solve class of problems

AI often gives fastest fix near current failing line to make test green, without checking if same constraint is violated in other scenarios; resource sharing, concurrent ops, data create/use/recover/cleanup processes especially prone to omissions.

Example: Local fix must cover concurrency, replicas, recovery. In a data splitting design review, AI assumed data versions used in each step stay constant, and once relied on current machine's cache for subsequent init. Human asked: will background task change version? How do other replicas or restart get same info? Design then added version protection, wrote necessary info into recoverable log, cache used only for acceleration. This was a design review correction, not a production incident.

3.3 AI Debug Usage Recommendations: Recommended Workflow

Core principle: preserve facts first, then propose hypotheses; verify causality with experiments; humans confirm root cause and review fixes; unexplained phenomena → keep digging.

1. Fix scene facts, record state collection boundaries

Before analysis, humans and AI together establish a speculation-free fact base: failure manifestation and impact, timeline, runtime environment and operation history, then supplement data, cache, external dependencies, config effectiveness as needed. Raw logs/metrics, business-side retellings, static code deductions — record separately. Each state snapshot must note collection time, source instance, read method; if cannot confirm multiple evidences belong to same moment or same request, explicitly mark, don't stitch into a "simultaneous" scene picture. Restart, retry, cache refresh alter scene — save evidence before acting.

2. Make AI output candidate set, reject single root cause

Have AI write for each candidate: trigger conditions, code path, state changes, what phenomena explained/unexplained, current evidence, falsification method; humans add global invariants, historical design decisions, operational constraints (e.g., who allocates IDs, how roles switch, what state persists, which failures allow retry).

Use these unified terms during investigation to prevent conclusions being silently upgraded in wording:

Observed facts: directly supported by logs, metrics, scene state, raw bytes, or test results;

Candidate: explains partial phenomena, but necessary conditions or causal chain not closed;

Verified factor: experiment proves it participates, but cannot yet qualify as root cause;

Root cause: first error, propagation, protection failure, final user result closed; main alternative explanations excluded;

Amplifying factor: expands impact or prolongs fault, but doesn't generate initial anomaly;

Mitigation: stops bleeding or restores service, but doesn't eliminate root cause;

Unverified risk: statically possible, not yet proven production-reachable or impactful.

This candidate set and classification is a continuously updated investigation map: each new evidence reclassifies, falsified candidates promptly removed with rationale, partial-explanation factors not upgraded to root cause.

3. Reproduce with tests, but limit what they prove

Unit tests suit verifying local algorithms, boundary conditions, minimal timing; cannot prove production requests will take that path; test-environment end-to-end repro verifies multi-component propagation chain, but only the portion where version, config, data state, entry match production can be extrapolated.

Concurrency, timeout, partial failure, recovery issues — prioritize fault injection to control trigger point while observing business results and intermediate states; key verifications must complete red-green loop per Section 5.

4. Trace first error along full chain

For each high-priority candidate, record actual states along "produce → propagate → persist → commit → consume → recover → cleanup"; find first divergence from correct path, then explain step-by-step how it became final user-visible result.

5. Humans confirm root cause, review fixes from global invariants

Before AI conclusion enters incident report or drives fix, module-familiar engineer must review: does on-site evidence prove necessary conditions? Is chain from first error to user result closed? Why did protections fail? Have main alternative explanations been excluded? AI's "high confidence" cannot replace this gate.

Fix review must start from system's key designs and global invariants, solving the class of problems, not just making trigger case green: check locks and references, roles and epochs, persistence and replay, error propagation, and normal/abnormal/recovery/cleanup paths along related call chains; assess compatibility, performance, release risk. Both production and test code changes reviewed.

4. AI Automation: Excels at Verifiable Tasks, But Critical Operations Must Be Controlled

Team tried using AI for automation, letting it continuously handle environment checks, build modifications, failure localization, test regression — tedious but relatively fixed-pattern work. Two such tasks: 1) Distributed KV build system upgrade from Make+Autotools to CMake (scripts hard to maintain); 2) Distributed KV server ARM adaptation for Huawei Kunpeng servers to reduce cost. Implementation paths and verification methods clear, but many details, large workload; manual handling required repeated modify-execute-check cycles. Practice shows AI indeed saved much repetitive labor, could continuously advance based on build/test feedback. But prolonged continuous execution may chase wrong direction, expand modification scope, even achieve "pass" by tweaking test conditions. Direction, boundaries, acceptance criteria — still human-guarded.

4.1 Where AI Automation Excels

1. Cross-file, rule-clear batch transformations

Build migration and platform adaptation pull in dependency declarations, compile options, macro definitions, test directories, CI scripts — many associated changes. AI can clarify these relationships and continuously complete modifications and verifications.

Example: CMake migration covered 31 build files and supporting scripts; ARM adaptation threaded from dependency install, test compile, process startup through to result file integration.

2. Continuous multi-round repair driven by execution feedback

Compile errors, link failures, test anomalies give AI explicit feedback; it can run "execute → locate → fix → retest" loops continuously.

Example: In ARM adaptation, AI sequentially handled missing dependencies, interface bridging, link conflicts, test framework compatibility, saving human cost of repeated command runs and result reading.

3. Regression tests exposing hidden assumptions and latent issues

Changing build method or runtime platform surfaces problems invisible in original environment.

Example: CMake migration test execution exposed hardcoded paths, test state pollution, memory management defects.

Example: ARM adaptation also exposed test out-of-bounds, uninitialized use, use-after-free. AI can keep tracking these; full regression and repeated run verification also done by AI.

4.2 Where AI Automation Goes Wrong

1. Tends toward depth-first investigation, digging deeper along one hypothesis

After finding a plausible explanation, AI tends to pursue that path, adding deductions, experiments, code changes, without first comparing other possible causes or revisiting initial hypothesis. May spend huge time analyzing deep mechanisms while real issue was just compile flag, dependency path, or test config mismatch. Many investigation steps and detailed explanations don't mean direction is right.

2. Tends to blame base libraries or OS when evidence lacking

Facing crashes, memory anomalies, cross-platform differences, AI may prematurely suspect allocator, system libraries, compiler, or OS behavior, overlooking project's own call errors, link config, test defects.

Example: During ARM adaptation, human had to explicitly require AI to retract generalized suspicions about dependency and system libraries, while supplementing existing static libraries, local build methods. Base components can be investigation candidates but need concrete evidence; cannot become default explanation for unknowns.

3. Equating error elimination or test green with problem solved

Example: In CMake migration fix records, AI used _exit to skip global destructors avoiding exit crash, also adjusted assertions after introducing an always-success auth stub; ARM adaptation CI skipped three test cases dependent on real KMS. These workarounds may pass in specific test env but change verification scope; cannot conclude original problem solved or real dependency chain verified.

4. Unnecessarily expanding modification scope to solve local problem

AI may modify source outside task scope, adjust shared build logic, or bypass current failure by relaxing checks.

Example: ARM adaptation saw source and format changes rolled back, also used global linker option allowing duplicate symbol definitions. Current problem bypassed, but may introduce compatibility impact or mask later errors.

4.3 AI Automation Usage Recommendations

1. Define goal, boundaries, acceptance criteria first, then let AI run continuously

Clearly state what can change, what must stay, where dependencies come from, what verification constitutes done. Within fixed constraints, build, test, local repair can be AI-autonomous; changes involving business semantics, shared config, or test standards require human review. Critical operations (modify shared config, delete data, release) always human-confirmed; permission tiering see Section 5. (Addresses 4.2 points 3,4)

2. Compare candidate directions first, then deep-verify; set stop conditions for investigation branches

On failure, first have AI list main candidates, existing evidence, minimal verification methods; prioritize factors directly related to this change with low verification cost. After each experiment round, re-evaluate direction; several consecutive attempts with no new evidence → return to candidate set, don't keep adding speculation to same hypothesis. (Addresses 4.2 point 1)

3. Before suspecting base components, check own usage first

Prioritize verifying compile macros, header and library versions, link order, interface signatures, working directory, test initialization. Only with independent minimal repro, clear version comparison, or direct on-site evidence, further attribute to base libraries, compiler, or OS. (Addresses 4.2 point 2)

4. Preserve verification of original behavior

Keep old build as baseline; verify new/old architectures, different build modes, repeated runs; record root-cause fixes, temporary workarounds, unverified items separately. (Addresses 4.2 point 3)

5. Distill execution process into reproducible, reviewable deliverables

Each round's failure phenomena, modification rationale, retest results retained; final delivery includes code, build steps, environment dependencies, verification boundaries. Human review examines not only code but also automation script operation scope, and whether conclusions exceed actual evidence.

5. Reusable Methodology

Sections 2–4 differ in scenario but share several principles:

Start with low-risk, easily verifiable scenarios: Don't chase full auto-dev; first use AI on tasks where results can be tested or reviewed, then gradually expand scope.

Every conclusion must be falsifiable: Whether review finding, debug hypothesis, or automation fix — write clear trigger conditions ("holds under X condition"), supporting evidence, and how to prove it wrong. No evidence → mark as hypothesis or to-verify.

Tests must be able to turn red: Critical verifications must complete red-green loop: before fix, stably reproduce and turn red; after fix, green under same conditions; revert fix → red again. Reproduction should walk real entry points, let system generate intermediate states; don't directly mutate internal objects or inject values production could never reach.

Test green ≠ problem solved: Changing assertions, introducing stubs/mocks, skipping cases, bypassing cleanup paths — all alter verification scope; must explain reason and coverage change. Review why test passes; from global invariants confirm fix solves a class of problems, not just makes trigger case green.

Explicitize domain knowledge, but only cement stable parts: Architecture docs, key invariants, review checklists, failure cases, test specs — write down for AI, maintain alongside code, so stale info doesn't mislead AI. Concrete approach see 2.4.

Establish tiered authorization: Read-only analysis → controlled modification → controlled execution → human decision; progressively open; root cause confirmation, fix adoption, critical operations human-gated.

6. Conclusion

The above practices boil down to three judgments:

First, AI moved the bottleneck from "writing" to "verification." Code production became cheaper, yet every line still needs proof of correctness. Team's gain from AI depends not on how much code generated, but whether verification capability keeps pace with generation speed.

Second, AI's errors are not in code, but outside code. Overturned AI conclusions were almost all paths that work in code but not in reality: operational processes blocked them, design decisions negated them, team conventions had already discussed them. Filling this gap requires not stronger models, but explicitly written, continuously maintained invariants.

Third, fluency ≠ evidence, consistency ≠ correctness, green ≠ solved. These are the three illusions AI most easily creates. In zero-tolerance systems, every conclusion must be falsifiable; unfalsifiable conclusions, no matter how complete, are merely hypotheses.

So the conclusion isn't "use AI cautiously," but more concretely: AI expands search space and accelerates iterative verification; humans own system semantics and final judgment; the boundary between them must be drawn by evidence reproducible in real scenarios. The clearer this boundary, the larger the scope AI can be entrusted with.