ITzWorking
All pillars
// Pillar 03 of 05

Verification

Closed-loop feedback, not vibes.

An LLM is confidently wrong by default. The only way to catch it is verification: automated, cheap to run, trusted by the team. Senior engineering with AI starts by building the loop, then writing the code.

// Without it

The intern's loop

A junior runs a feature locally, sees it work, and merges. AI happily generates code that compiles and runs the happy path while silently breaking three boundary cases. Without tests, the regression lives until a customer finds it. With flaky tests, the regression hides in a yellow CI run no one trusts. Either way: the loop is broken.

// The practice

Loop before code

Tests come first. Not as ceremony, as a verification surface the LLM can actually use. The loop runs locally, in seconds, before anything reaches CI. The model is taught it exists: scripted access, a CLAUDE.md note, a tool the agent can call. AI runs the suite immediately, sees the failure, and self-corrects before any human reviews the diff. CI catches what's left. Fast, local, trusted: a feedback signal, not a pipeline.

// Outcomes

Green, or broken. No third state

A test suite that runs in seconds locally, blocks merges in CI, and covers the paths that actually matter, not the email input field tested fifteen ways. Quantity isn't quality: the tests that ship are the ones whose failure means something real broke. The loop is short enough for the LLM to self-correct within the same prompt cycle. CI is green or it's broken. There is no third state.

// Self-check
  1. 01Does your test suite run locally in seconds, not just in CI in minutes?
  2. 02Can the LLM actually run your tests: does it know they exist, and can it invoke them?
  3. 03Does CI block merges, or just produce yellow warnings the team has learned to ignore?
  4. 04Can you trust a green CI run on first read, or do you re-run things to be sure?

Tight specs, hard deadline, real users?

Start a project