Lesson 08 · Loop Engineering

Staying the engineer

Three problems get sharper as the loop gets better, not easier.

Every earlier lesson made your loop more capable. This one is about what capability does not buy you. Osmani is direct: the loop changes the work, it does not delete you from it.

1. Verification is still yours

A loop running unattended is also a loop making mistakes unattended. The whole reason you split the verifier from the maker (lesson 4) was to make the loop's "it's done" mean something — and even then, Osmani writes, "done" is a claim and not a proof.

Your job is to ship code you confirmed works. Addy Osmani, Code review in the age of AI

2. Comprehension debt compounds

The faster the loop ships code you did not write, the bigger the gap between what exists in the repo and what you actually understand. That is comprehension debt, and a smooth loop makes it grow faster — unless you read what the loop made. There is no clever mitigation here. Reading is the mitigation.

3. Cognitive surrender is the comfortable trap

When the loop runs itself it is very tempting to stop having an opinion and just take whatever comes back. Osmani names this cognitive surrender, and notes the cruel symmetry:

Designing the loop is the cure when you do it with judgement and the accelerant when you do it to avoid thinking, same action, opposite result. Addy Osmani, Loop Engineering

Two people build the identical loop. One moves faster on work they understand deeply. The other avoids understanding the work at all. The loop does not know the difference. You do.

Also: cost Osmani flags token cost in his opening paragraph, and again about sub-agents. Usage patterns vary wildly depending on whether you are token rich or poor. Check the spend of your first loop after one week, before you scale it.

The balance he actually recommends

Not full automation. Osmani closes by saying direct prompting is still effective and it is all about finding the right balance. Loops are for recurring, well-understood, verifiable work. Keep prompting directly for the work where your judgement is the value.

Check yourself

Which risk grows faster as your loop gets better?

What decides whether a loop helps you or harms you?

Write the rule you will hold yourself to before merging anything your loop produced.

A workable rule is specific and cheap enough to actually keep. For example: "I read every diff line, and I can explain the change to someone else without opening the file." Vague rules ("I'll review carefully") are the first thing to go.

Read the source

Primary source: Cognitive surrender and comprehension debt by Addy Osmani. For the full argument, his O'Reilly book Beyond Vibe Coding covers specs, harnesses, evals and context.

Now take it outside

You have the knowledge and the skills. Wisdom comes from other practitioners. Take your loop design to one of these and let it be argued with:

Ask me. Bring me your loop design and I will argue against it before you post it anywhere. That is what I am for.