Types, linters and fast feedback

Tests tell the agent whether the behaviour is right. Types and linters tell it, in seconds, that something is wrong before it even gets there.

An agent runs its checks many times per task. The faster each loop, the more loops it gets, and the fewer mistakes survive to your review.

The feedback ladder

One command to rule the loop

If your repo needs four commands in a specific order to validate a change, the agent will skip one sooner or later. Wrap the fast rungs in a single check command and tell the agent about it in your repo instruction file (lesson 2.2).

## Verifying your work
- Run the check command after every change: it formats, type-checks,
  lints and runs unit tests for the files you touched.
- Before you say you're done, run the full test suite once.
- Never add lint-disable comments, type-escape hatches or skipped
  tests to make a check pass. If a rule seems wrong, stop and ask.

Types and lint rules are specs too

Strict types turn whole classes of mistakes into instant errors. Rename a function and miss a call site, pass the wrong shape, forget a null case: the type checker tells the agent before any test runs.

Lint rules do the same for conventions. Every rule you encode (“the UI layer never imports the database module”) is a line you no longer have to repeat in every brief.

Play: which check catches it?

Sort each mistake by the cheapest check that would catch it reliably.

🎮 Types, linter or tests?

1 / 10 · Score: 0

Type checkerLinterTests

Next →

/ 10

↺ Try again

Before you move on

✅ Key takeaways

0 / 4 completed

• My fast checks run with one command, and the agent knows it exists.
• The agent runs fast checks every iteration and the full suite before handing back.
• I encode conventions as lint rules instead of repeating them in briefs.
• 'No new suppressions' is part of my definition of done, and I search diffs for them.

↺ Reset