Keep the Feedback Loop Tight
The faster you can see whether a change works, the faster you and the AI converge on something correct. A slow loop — where you wait minutes to know if something broke — quietly multiplies every mistake.
- Make "run it" a single command.
npm run dev,make test, whatever it is, document it in your context file so the AI can run it too. - Lean on fast tests. Even a handful of unit tests give the AI a way to verify its own work without you babysitting.
- Use a linter and formatter. They catch a whole class of errors instantly and keep style arguments out of your reviews.
- Show errors back to the AI. When something breaks, paste the actual error message. Specific feedback produces specific fixes; "it doesn't work" produces guesses.
The pieces of an AI workspace form one connected loop — the edits the repo, the editor and language server report problems, the runs the code, and every result flows back to the agent:
┌──────────────────────────────────────────────┐
│ │
▼ │
┌─────────┐ edits ┌──────────┐ runs ┌──────────┐
│ AGENT │ ─────────────▶ │ EDITOR │ ────────▶ │ TERMINAL │
└─────────┘ └────┬─────┘ └────┬─────┘
▲ │ │
│ ▼ ▼
│ ┌──────────┐ ┌──────────┐
│ │ LSP │ │ REPO │
│ │ (errors) │ │ (commit) │
│ └────┬─────┘ └────┬─────┘
│ │ │
└─────────────────────────┴──────────────────────┘
feedback flows back
The deepest version of this idea is to let the AI close the loop itself. Instead of you running the command, reading the failure, and relaying it, give the agent permission to run tests and the typechecker after every change and react to what it sees. The cycle becomes: edit, run, read the failure, fix, run again — all without you in the middle. Your job shifts from courier to director: you set the goal and the guardrails, then watch the loop spin. When the AI can edit, run, see the failure, and fix it on its own, you've built a loop that does real work while you stay in the director's chair.