---
description: "CodeWiki Coding in the AI era pitfalls and review checks"
globs: []
alwaysApply: false
---

# Coding in the AI era rules

This track covers more than one language, so no file globs are inferred. Apply these rules manually when they are relevant.

- Sending every reachable file consumes the context budget with dependency trees, generated output, vendored code, and repeated documentation.
  Why: It also increases the chance that credentials or irrelevant imperative text enter the model request.
  Source: [Agent context management](https://codewiki.com/ai-era/agent-context-management/)
- An embedding index, IDE cache, copied excerpt, or earlier tool result may point to the right file but contain an older revision.
  Why: Applying an edit from that snapshot can erase another change or repair code that no longer runs.
  Source: [Agent context management](https://codewiki.com/ai-era/agent-context-management/)
- Do not assume this is safe: a local function can look wrong while its callers depend on the current behavior, a schema constrains its output, or configuration selects another implementation.
  Why: Editing the first matching file produces a coherent patch with an unexamined blast radius.
  Source: [Agent context management](https://codewiki.com/ai-era/agent-context-management/)
- A fluent session summary can drop a negation, merge two revisions, or present a suspected cause as established.
  Why: Repeating that summary in later turns makes the unsupported claim feel increasingly authoritative.
  Source: [Agent context management](https://codewiki.com/ai-era/agent-context-management/)
- Do not assume this is safe: tests that passed before the patch, type information from before dependency installation, or status from another worktree do not describe the current artifact.
  Why: Long sessions make this temporal mismatch easy to miss.
  Source: [Agent context management](https://codewiki.com/ai-era/agent-context-management/)
- Do not assume this is safe: "Follow best practices" and "test thoroughly" do not identify a repository decision.
  Why: Conflicting root and subtree rules leave the model to guess which maintainer intent is current.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- Do not assume this is safe: a team writes only `AGENTS.md` and assumes every agent product will discover it with the same hierarchy and precedence.
  Why: Some sessions silently receive no rules; others combine a different set than the author expected.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- Do not assume this is safe: a guide says "never access production," but the connected process still holds production credentials and a general network tool.
  Why: A mistake or injected instruction can reach the resource despite the prose.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- Tools such as `run_shell`, `query_database`, or `http_request` compress many unrelated capabilities into a free-form string.
  Why: One approval or validation bug then exposes every operation supported by the underlying transport.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- A call can satisfy its schema and still name another tenant's object, escape a directory through a link, produce an oversized response, or repeat a non-idempotent mutation after a timeout.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- A narrowly named tool may still return full environment dumps, database rows, or logs containing tokens.
  Why: Once the result enters model context, later prompts and connected services may receive data the original task did not need.
  Source: [Agent instructions and MCP](https://codewiki.com/ai-era/agent-instructions-and-mcp/)
- Steps such as "inspect the code," "make changes," and "test everything" record motion but provide no state a reviewer can confirm.
  Why: An agent can claim each activity happened while leaving the original goal unresolved.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- A detailed plan based on guessed file ownership becomes stale after the first search.
  Why: Agents then force the repository to fit the plan, editing named files even when the real contract lives elsewhere.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- Do not assume this is safe: a focused regression test may pass while type checking, integration behavior, or unchanged callers fail.
  Why: Treating one result as final completion lets the agent stop early.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- Replanning can quietly turn a discovered constraint into new authority.
  Why: An agent that finds an incompatible dependency may edit the lockfile, public API, or deployment configuration even though the original task never allowed those changes.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- "Try again until tests pass" has no finite failure state.
  Why: The agent may repeat the same edit, churn between two patches, consume its budget, or weaken tests to escape the loop.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- Reaching a turn, token, time, or cost limit says only that the execution budget ended.
  Why: Reporting the task as complete at that point replaces missing verification with an accounting event.
  Source: [Agent task planning](https://codewiki.com/ai-era/agent-task-planning/)
- Do not assume this is safe: a prompt asks an agent to “choose the best behavior” when stakeholders have not agreed on the rule.
  Why: The agent turns missing product authority into a plausible implementation, and passing tests merely encode its guess.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- A fully specified rename or row transformation is sent through an agent loop.
  Why: The result varies between runs, consumes review time, and may touch unrelated files even though a short deterministic program could express the whole rule.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- Do not assume this is safe: “Do not read secrets” appears in the prompt while the process can read credentials and use the network.
  Why: A mistaken tool call or prompt injection can still cause data leakage because text does not revoke capabilities.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- Do not assume this is safe: a reviewer approves “terminal access” or “writes” without seeing complete arguments and targets.
  Why: The approval silently covers operations with different consequences, including publication, deletion, or writes outside the intended workspace.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- Do not assume this is safe: the agent reports that the change is safe and all tests pass, but the record lacks commands, exit codes, skipped checks, and a reviewed diff.
  Why: Confidence and fluency are being used as substitutes for environment evidence.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- A tiny task triggers broad exploration, repeated retries, and a lengthy review.
  Why: The agent finishes, but the total attention and compute cost exceeds direct work and creates no reusable automation.
  Source: [Agent use boundaries](https://codewiki.com/ai-era/agent-use-boundaries/)
- "Refactor this module" doesn't state the behavior to preserve, files that may change, or a stop condition.
  Why: The agent may keep widening the task, or declare completion after little more than renaming symbols.
  Source: [AI coding agents](https://codewiki.com/ai-era/ai-coding-agents/)
- Adding files indiscriminately crowds out the definitions that matter and can pull in generated output, stale documentation, and third-party instructions.
  Why: The model may then change correct code to match an obsolete interface.
  Source: [AI coding agents](https://codewiki.com/ai-era/ai-coding-agents/)
- The name `run_command` hides enormous differences between its arguments.
  Why: If a test, upload, and recursive deletion share one permanent approval, prompt injection can turn directly into a system side effect.
  Source: [AI coding agents](https://codewiki.com/ai-era/ai-coding-agents/)
- Do not assume this is safe: a generated report can say "all tests passed" when the command never ran, ran in the wrong directory, or had its failure swallowed by `|| true`.
  Why: Green wording in a log isn't an exit code.
  Source: [AI coding agents](https://codewiki.com/ai-era/ai-coding-agents/)
- If two agents edit one checkout at the same time, one session's tests may read the other session's half-finished work.
  Why: A later write can also overwrite the earlier patch while both logs claim success.
  Source: [AI coding agents](https://codewiki.com/ai-era/ai-coding-agents/)
- Do not assume this is safe: starting a tool from a parent directory or home directory can widen file discovery, bypass project rules, and run relative test commands in the wrong place.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- `cat .env | ai-cli`, pasting a complete diagnostic bundle, or passing the entire environment to a subprocess can place tokens in model context, session logs, or a remote service.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- A model-generated command may contain broken quoting, platform-incompatible options, command substitution, redirection, or destructive globs.
  Why: A plausible explanation does not prove that the shell's actual parse is safe.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- Do not assume this is safe: a generated response may say “tests passed” even though the command never ran, output was truncated, it ran in the wrong directory, or `|| true` swallowed a failure.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- Uncommitted changes that predate the session become mixed with the AI-generated diff.
  Why: Automatic formatting or bulk fixes may also rewrite out-of-scope files, leaving reviewers unable to attribute changes.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- A command that expects a TTY, login prompt, or manual approval may hang in CI, or non-interactive mode may apply broader or simply different permission defaults.
  Source: [AI coding CLIs](https://codewiki.com/ai-era/ai-coding-cli/)
- Do not treat "open in the editor" as "the model definitely saw it." Automatic context may include only the selection, part of the current file, or retrieval hits; other open tabs may not enter the request.
  Source: [AI IDEs](https://codewiki.com/ai-era/ai-ide/)
- Using repository instructions as actual permission control.
  Why: A model can misread natural-language rules, and repository content may contain prompt injection that tells it to ignore a boundary.
  Source: [AI IDEs](https://codewiki.com/ai-era/ai-ide/)
- Accepting a whole multi-file change after reading only the model-generated summary.
  Why: The summary can omit lockfiles, configuration, public APIs, or changed test assertions, and it will not tell you which files are formatter noise.
  Source: [AI IDEs](https://codewiki.com/ai-era/ai-ide/)
- Do not treat a green inline diagnostic or the model's "tests passed" as repository completion.
  Why: A language service may not cover the runtime path, and the model may have run the wrong command, used the wrong directory, or selected a suite that silently skipped tests.
  Source: [AI IDEs](https://codewiki.com/ai-era/ai-ide/)
- Attaching credential files, production logs, customer data, dependency trees, or generated directories to "provide enough context." Extra material displaces relevant code and may send sensitive content to the model provider configured for the tool.
  Source: [AI IDEs](https://codewiki.com/ai-era/ai-ide/)
- Pasting an exception into a chat and asking "fix this" encourages the model to match the error to a familiar edit.
  Why: The returned patch may suppress the exception, change the fixture, or add a fallback without showing that it affects the original failing execution.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- Do not assume this is safe: a model can quote a line of code and produce a convincing causal story without observing its runtime value or whether the path executed.
  Why: Repeating that story in later prompts gradually turns an inference into an apparent fact.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- Updating a dependency, simplifying the fixture, disabling a feature flag, and editing the suspect branch in one run can make the symptom vanish.
  Why: The run doesn't tell you which change mattered, so reverting or porting the fix remains guesswork.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- Generated debug logs often dump whole request objects, tokens, customer data, or large collections.
  Why: Extra logging can also change timing, consume storage, or make a race stop reproducing.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- One passing check can be consistent with several causes.
  Why: A cache clear, for example, may temporarily fix stale data whether the defect lies in the key, invalidation, or cache ownership.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- An AI may update an expected value, catch a broad exception, remove an assertion, or increase a timeout.
  Why: The suite turns green because the definition of success moved, not because behavior returned to the intended contract.
  Source: [AI-assisted debugging](https://codewiki.com/ai-era/ai-assisted-debugging/)
- Verbs such as “fix,” “handle,” “support,” “optimize,” and “clean up” don't say what changes for a caller.
  Why: An agent may add a fallback where the product requires rejection, or cache a result where freshness matters.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- “Use a class to make retries reliable” names a structure but doesn't define reliability.
  Why: The generated class can still duplicate side effects, retry permanent failures, or ignore cancellation.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- API can mean a function signature, JSON schema, HTTP status, event topic, CLI output, or all of them.
  Why: An edit can preserve one surface while breaking another consumer through error text, field omission, or call ordering.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- Do not assume this is safe: “Balance never becomes negative” is ambiguous if pending holds, concurrent requests, or an external ledger can temporarily disagree.
  Why: The implementation may enforce the rule at the wrong stage or only in memory.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- Asking to “return an error” can lead to a thrown exception, rejected promise, tagged value, sentinel, HTTP response, or logged message.
  Why: Callers behave differently for each representation, and logging alone doesn't transfer failure to them.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- A dense request can combine “adapter,” “repository,” “atomic,” and “pure” even when the team uses those words differently.
  Why: The vocabulary then creates false confidence rather than shared meaning.
  Source: [Code prompt vocabulary](https://codewiki.com/ai-era/code-prompt-vocabulary/)
- An agent can state “all tests pass,” paste plausible output, or add a test that shares the implementation's mistaken assumption.
  Why: The transcript may refer to another revision, working directory, runtime, or no process at all.
  Source: [Code provenance and verification](https://codewiki.com/ai-era/code-provenance-and-verification/)
- Do not assume this is safe: a matching digest proves byte equality with a recorded value, not authorship, safety, or license compatibility.
  Why: A valid signature authenticates a signer under a policy, not the correctness of everything signed.
  Source: [Code provenance and verification](https://codewiki.com/ai-era/code-provenance-and-verification/)
- A generated manifest may add one approved library while its lockfile resolves dozens of transitive, optional, platform-specific, or install-time components.
  Why: Their licenses and executable scripts still affect the delivered system.
  Source: [Code provenance and verification](https://codewiki.com/ai-era/code-provenance-and-verification/)
- “Adapted from the internet,” a search-result URL, or a default branch cannot reconstruct the code that a reviewer saw.
  Why: The page may change, disappear, or carry several files under different licenses.
  Source: [Code provenance and verification](https://codewiki.com/ai-era/code-provenance-and-verification/)
- An SPDX identifier makes a license machine-readable, but it doesn't decide compatibility with every linking model, modification, distribution, patent, notice, or customer obligation.
  Why: Missing or custom terms make a simple allowlist even less reliable.
  Source: [Code provenance and verification](https://codewiki.com/ai-era/code-provenance-and-verification/)
- A prompt can require a dependency upgrade, forbid changes to manifests and lockfiles, and limit edits to one source file.
  Why: The extra detail sounds rigorous, but no valid patch satisfies the intersection.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- Do not assume this is safe: “Avoid unnecessary changes” and “keep it simple” do not identify what the requester considers unnecessary.
  Why: An agent can still justify a helper extraction, rename, formatting pass, or dependency as necessary to its chosen design.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- An exact allowlist may omit the only legitimate test or generated output, while “change whatever is needed” removes the review boundary.
  Why: Both forms push the agent toward an avoidable failure: unverified code or an oversized patch.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- Do not assume this is safe: “Maintain backward compatibility” does not say whether callers rely on a signature, error class, JSON shape, ordering, timing, or runtime floor.
  Why: A generated patch may preserve the visible happy path while breaking an automation script or strict decoder.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- Requiring a class, pattern, helper count, and exact control flow can freeze incidental structure while still leaving behavior ambiguous.
  Why: It also blocks a smaller repository-native solution and makes generated tests mirror the prescribed implementation.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- Do not assume this is safe: a prompt can list excellent acceptance commands, yet the agent may skip one, run it from the wrong directory, accept a nonzero exit, or replace it with a weaker check.
  Why: The command text alone proves nothing.
  Source: [Constraint-rich prompts](https://codewiki.com/ai-era/constraint-rich-prompts/)
- A single successful input encourages the shortest familiar generalization.
  Why: The generated function may hard-code a sample constant, use truthiness, or treat every category like the one shown, yet still reproduce the example exactly.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- Five free-shipping examples that are all large French standard orders look like coverage but test one region repeatedly.
  Why: They do not decide the exact threshold, expedited precedence, foreign destinations, or invalid amounts.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- Mixing valid contrasts with malformed inputs hides two different contracts.
  Why: An agent may correctly reject a string while still applying the wrong rule to a valid boundary value.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- Asking an agent to implement the function and invent all expected outputs in the same pass can reproduce one mistaken condition on both sides.
  Why: Passing generated tests then confirms internal consistency, not product intent.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- A case that asserts helper names, branch order, log wording, and object identity can reject a correct refactor.
  Why: The agent learns to imitate the current implementation instead of preserving caller-visible behavior.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- “Here are some examples” can be read as permission to decide everything else.
  Why: Generated code then trims whitespace, accepts unknown enum values, or assigns precedence without making the new policy visible.
  Source: [Examples and counterexamples](https://codewiki.com/ai-era/examples-and-counterexamples/)
- One example such as “a €60 order ships free” permits `subtotalCents > 0`, `>= 5000`, or a hard-coded answer to pass.
  Why: It says nothing about the threshold, override rules, invalid values, or unsupported destinations.
  Source: [Executable specifications](https://codewiki.com/ai-era/executable-specifications/)
- A generated test computes `expected = subtotalCents >= 5000 ?
  Why: 0 : 500` and compares it with production code containing the same expression. A mistaken requirement or copied operator appears on both sides, so the check stays green.
  Source: [Executable specifications](https://codewiki.com/ai-era/executable-specifications/)
- Assertions about private helper calls, branch order, temporary objects, or exact query text can reject a behavior-preserving refactor.
  Why: An agent then optimizes for matching the test's internal script instead of the public requirement.
  Source: [Executable specifications](https://codewiki.com/ai-era/executable-specifications/)
- Do not assume this is safe: “Invalid input fails” does not say whether failure means an exception, a validation result, an HTTP status, or no state change.
  Why: Generated code may catch everything and return a plausible default that makes positive checks pass.
  Source: [Executable specifications](https://codewiki.com/ai-era/executable-specifications/)
- A suite can pass while omitting accessibility, compatibility, concurrency, migration, or operational constraints.
  Why: Old checks can also faithfully enforce behavior the product no longer wants.
  Source: [Executable specifications](https://codewiki.com/ai-era/executable-specifications/)
- A hunk can look correct while relying on an import, invariant, cleanup block, or caller behavior outside its visible context.
  Why: Deleted checks are particularly easy to miss when attention follows the added code.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- A model can change code and tests to make the same mistaken assumption.
  Why: It may assert a snapshot it just updated, mirror a branch condition, or remove the assertion that would fail.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- Reference search misses string keys, routes, serializers, reflection, templates, shell scripts, fixtures, and external consumers.
  Why: A clean language-server result can therefore leave a stale runtime caller.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- Generated patches often rename, reorder, reformat, and alter behavior together.
  Why: The volume makes a one-character condition change or removed guard harder to see and harder to revert.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- Do not assume this is safe: one passing suite may exclude the affected package, reuse a cache, skip integration tests, or exercise only default inputs.
  Why: It says nothing about untested migrations, permissions, latency, or operational cleanup.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- A long list of naming preferences can obscure a correctness or security defect and encourage superficial patch churn.
  Why: Generated code can satisfy stylistic comments without repairing the violated contract.
  Source: [Generated change review](https://codewiki.com/ai-era/generated-change-review/)
- A diff can look locally safe while relying on an unscoped caller, permissive middleware, dangerous serializer, or privileged deployment identity.
  Why: An explanation limited to the changed functions hides the controls that must exist elsewhere.
  Source: [Generated code security](https://codewiki.com/ai-era/generated-code-security/)
- A well-formed tenant ID, file name, or resource ID says nothing about whether the caller may use it.
  Why: Generated handlers commonly validate syntax and then fetch by a request-controlled identifier without checking action and object scope.
  Source: [Generated code security](https://codewiki.com/ai-era/generated-code-security/)
- A model may paste a real credential into a fixture, build argument, troubleshooting prompt, or example environment file.
  Why: It may also log a whole request or configuration object whose nested fields contain tokens.
  Source: [Generated code security](https://codewiki.com/ai-era/generated-code-security/)
- Do not assume this is safe: familiar naming does not prove publisher identity, resolved registry, integrity, transitive content, or lifecycle behavior.
  Why: Generated code may add a package for a trivial helper and quietly expand what executes during install or build.
  Source: [Generated code security](https://codewiki.com/ai-era/generated-code-security/)
- A `200` response for the intended user proves neither denial nor isolation.
  Why: Mocks can bypass the real policy adapter, and snapshots can approve leaked fields without expressing why they are safe.
  Source: [Generated code security](https://codewiki.com/ai-era/generated-code-security/)
- A team keeps ten polished demo prompts, edits the system prompt until all ten look good, and reports the same prompts as evaluation.
  Why: The score measures familiarity with those cases, not performance on the intended request distribution.
  Source: [LLM application evals](https://codewiki.com/ai-era/llm-application-evals/)
- A judge receives "rate quality from 1 to 5" and its average becomes the gate.
  Why: Raters can disagree about whether quality means correctness, style, completeness, or safety, so a score change has no stable diagnosis.
  Source: [LLM application evals](https://codewiki.com/ai-era/llm-application-evals/)
- Do not assume this is safe: hundreds of easy answers lift the mean above threshold while one output leaks private context or calls an unauthorized tool.
  Why: The arithmetic is correct, but the release policy is wrong.
  Source: [LLM application evals](https://codewiki.com/ai-era/llm-application-evals/)
- Baseline and candidate each run once with stochastic decoding.
  Why: A lucky candidate sample and unlucky baseline sample look like an improvement, while a rerun reverses the conclusion.
  Source: [LLM application evals](https://codewiki.com/ai-era/llm-application-evals/)
- Expected answers, hidden labels, or private production text enter the application prompt, retrieval index, or model-tuning data.
  Why: This data leakage can inflate scores and expose information beyond the eval system.
  Source: [LLM application evals](https://codewiki.com/ai-era/llm-application-evals/)
- A generated regression test repeats the successful reproduction input but omits the adjacent boundary, failure state, and forbidden effect.
  Why: The agent can hard-code or narrowly special-case that input while breaking the surrounding behavior.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- A test asserts private helper names, internal call order, or an intermediate object even though none is part of the public contract.
  Why: A safe refactor then fails while a behaviorally wrong implementation with the expected shape passes.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- Do not assume this is safe: an agent makes its patch green by deleting an assertion, changing expected output to match the defect, adding a broad skip, or moving the new test outside discovery.
  Why: The final message mentions passing tests but not the altered protection.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- Do not assume this is safe: a new test passes before and after the fix because it invokes the wrong path, mocks the subject, catches every exception, or asserts a value already true under the defect.
  Why: Its presence looks like regression coverage but contributes no constraint.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- A unit suite passes while the real database collation, clock, queue delivery, browser, or provider protocol behaves differently.
  Why: The completion claim silently expands beyond the environment the tests exercised.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- Do not assume this is safe: one large scenario covers many behaviors but fails with a generic timeout or snapshot difference.
  Why: The agent receives weak feedback, retries unrelated edits, and a reviewer cannot tell which contract was violated.
  Source: [Tests as agent guardrails](https://codewiki.com/ai-era/tests-as-agent-guardrails/)
- Linear reading spends attention on code unrelated to the behavior and makes it hard to distinguish reachable paths from merely similar helpers.
  Why: Large utility files can consume hours without proving which application entry point calls them.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)
- A function named `validateOrder` may normalize only one field, and a comment promising retries may describe code removed months ago.
  Why: Generated explanations amplify this problem because they connect familiar names into a fluent but invented control flow.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)
- A returned success object can hide a database write, cache mutation, emitted event, metric, or imported singleton update.
  Why: Reviewing only the return path misses duplicate effects and partial failure states.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)
- One successful run proves little about missing fields, empty collections, boundary values, exceptions, retries, or repeated calls.
  Why: Collapsing several branches into a single clean narrative hides those differences.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)
- Do not assume this is safe: characterization tests can accidentally freeze incidental details such as object identity, log wording, helper order, or a known defect.
  Why: The next safe refactor then fails tests that never represented a supported promise.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)
- Install hooks, test setup, migrations, and development scripts may write files, start containers, contact services, or consume credentials.
  Why: “Run the tests to understand it” is not automatically a read-only step.
  Source: [Unfamiliar code reading](https://codewiki.com/ai-era/unfamiliar-code-reading/)