Verification Discipline

1. Concept Overview & Systemic Problem

With the advancement of auto-generation tools, a critical gap has emerged between the ease of code creation and its actual reliability qualities. A model may generate 400 lines of impeccably formatted code with plausible method names that appears authoritative but crashes at the first second of execution due to a call to a non-existent method or type mismatch.

Verification Discipline is the primary demarcation barrier between a professional software engineer and an amateur. It is an unwavering internal stance:

• No word from the language model is taken at face value.
• Any generated code is considered potentially broken until proven otherwise by an independent deterministic tool (compiler, linter, test runner).
• The engineer bears personal professional responsibility for every character merged into the repository.

Without verification discipline, a project devolves into a state of "fragile house of cards," where each new feature breaks two previous ones, and the team expends all energy on extinguishing sudden fires in production.

Amateur Approach (Blind Trust):
[LLM: "I've fixed everything, the code is ready!"] ---> [Click "Accept All"] ---> [Commit & Push] ---> [502 Bad Gateway in production]

Engineering Verification Discipline (Evidence-First):
[LLM: "I've fixed everything!"]
          |
          v
[Step 1: tsc --noEmit] -----------------> [Type Error! Return to agent for revision]
          | (Green)
          v
[Step 2: vitest run] -------------------> [Test Failure! Fix logic]
          | (Green)
          v
[Step 3: git diff --cached] ------------> [Extraneous console.log and hallucinated library detected]
          | (Clean)
          v
[Step 4: Smoke Test in Browser] --------> [Physical click on form]
          |
          v
[Conscious Production Commit]

2. Architectural Taxonomy & Mental Model

Levels of Verification Defensive Barriers (The Swiss Cheese Model):

1. Level 1: Static Syntax and Semantic Analysis (Compile-time):
   • Strict compiler (tsc --noEmit, rustc, cargo check).
   • Style and security linters (ESLint, Biome, ShellCheck).
   • Cuts off 70% of hallucinations regarding non-existent fields or methods.
2. Level 2: Automated Dynamic Testing (Dynamic Verification):
   • Unit tests: checking pure functions and edge cases.
   • Integration tests: verifying interaction with a real database or cache.
   • Protects against logical errors and regressions.
3. Level 3: Change Audit (Diff Hygiene):
   • Human-readable line differences through git diff.
   • Goal: detect "junk," accidentally deleted comments, and violations of architectural boundaries.
4. Level 4: Runtime Verification (End-to-End & Observability):
   • Executing a real user scenario through Playwright or manually in a browser/terminal.
   • Monitoring logs post-release for spikes in 5xx errors.

3. Technical Pipeline & Internal Mechanics

Automatic Git Pre-Commit Verification Hook (Husky / Lefthook)

A human may forget to verify code due to fatigue. To protect the system from human factors, the verification outline hardware blocks commits:

# lefthook.yml — reliable and fast validator
pre-commit:
  parallel: false
  commands:
    typecheck:
      run: npx tsc --noEmit
    lint:
      run: npx @biomejs/biome check --staged --apply
    test:
      run: npx vitest run --passWithNoTests

If any test fails or the compiler sees type discrepancies, the attempt to commit code results in an emergency stop.

Manual Diff Audit Checklist (Diff Inspection Protocol)

Before executing the git push command, the engineer checks:

- [ ] Did the agent delete important code in unrelated parts of the file?
- [ ] Are edge cases (null, undefined, empty array, 404) handled?
- [ ] Are there any hardcoded passwords, secrets, or test tokens?
- [ ] Are there random formatting changes in 50 unrelated files in the diff?
- [ ] Do the names of new entities conform to the project's accepted standards?

4. Production Engineering Scenarios

01. Detecting a Sneaky Hallucination in the Financial Module

An agent wrote a function to calculate bank fees and confidently stated, "The logic has been updated according to the rules." The engineer enabled verification discipline and wrote a test for passing a negative amount (amount: -100). It turned out that the function returned a negative fee, allowing malicious actors to steal money from the company's accounts. The bug was fixed before release.

02. Protection Against Silent Deletion of Comments in Legacy Systems

During refactoring, a module contained an important comment: // CRITICAL: do not reorder this call due to Safari bug #19284. The model decided the comment was extraneous and deleted it, changing the order of calls. Thanks to a careful review of git diff, the architect noticed the deletion, preserved the protective workaround, and added a regression E2E test.

03. Full Test Reproduction of a Bug Before Fixing It (Bug Repro First)

Upon receiving a failure report, a disciplined engineer forbids the agent from touching production code. A test is first written that accurately reproduces the bug and fails with a red error (Red Phase). Only after the bug is guaranteed to be caught by the test does the agent make changes until the test turns green (Green Phase).

5. Pitfalls, Common Mistakes & Security

1. "Diff Blindness": When a diff contains over 800 lines, eyes tire, and after 2 minutes of scrolling, the engineer simply hits "Approve." If a PR is too large—never approve it in full. Require breaking the task into atomic parts of no more than 200 lines each.
2. Mocks That Always Pass (Tautological Tests): Agents often generate tests that test their own mocks: mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true);. Such tests are always green but do not test any lines of actual code. Always check the semantics of assertions in generated tests.
3. Ignoring Compiler Warnings: The habit of ignoring yellow linter warnings or implicitly casting types via as unknown as Type completely undermines the TypeScript safety system. Work by the rule: zero warnings in the console.