AI-assisted engineering · evidence first · 2025–26

10x is a loop, not a prompt.

Read across the people worth reading on this — Anthropic's agent guidance, the METR trial, Simon Willison, Mitchell Hashimoto, Armin Ronacher, and Addy Osmani's "70% problem." The answer is not "prompt better." It is: build the loop the agent runs in, and stay the one who judges.

The one idea

The multiplier comes from a verification loop the agent can run without you — while you keep architecture, review, and taste.

1

The number

−19% measured speed with AI, experienced devs on familiar code (METR RCT: 16 devs, 246 real issues)

They predicted +24%. They experienced −19%. Afterwards they still believed +20% — a 39-point gap between feeling and fact. AI feels fast; the measured cost was waiting on it, evaluating plausible-but-wrong output, and fixing it.

Read the scope before despairing: experts, on code they knew intimately — AI's weakest terrain. Where it measurably shines is the other side of that boundary: unfamiliar code, greenfield, prototypes, and projects that would never have justified the time at all. The lesson isn't "AI slows you down." It's that unverified AI use can slow you down while feeling like acceleration.

2

Close the loop

The single most repeated instruction in every source: give the agent a check it can run itself — tests, a build, a lint pass, a screenshot diff. Anthropic: "the difference between a session you watch and one you walk away from." Willison: "if you haven't seen it run, it's not a working system."

Open loop — where the −19% livesAgent works → "looks done" → stops.You are the verifier. Every mistake waits for you to notice it. You can't leave.
Closed loopAgent works → runs the check → reads the result → iterates until it passes. You review evidence at the end — not every line as it's typed.

Demand evidence, not assertion: "ran the tests" means showing the output. Ronacher's tooling rules feed the same loop — tools must be fast (a 5-second compile wrecks iteration), loud on misuse, observable via logs the agent reads.

3

Keep vs delegate

You keepArchitecture and interface decisions · the plan (interview first, edit by hand) · final review of every line that ships · breaking deadlocks (after ~2 failed corrections, change strategy) · the last 30% of polish and taste.
You delegateFirst drafts against a scaffold · research and codebase archaeology (in subagents) · test generation, migrations, mechanical refactors · the iteration grind — the agent never tires of "again, but…".

This is the knowledge paradox: seniors use AI to accelerate what they already understand and can judge; juniors use it to substitute for understanding — and hit the 70% wall, where every fix spawns new bugs in a system nobody in the loop actually knows.

4

Context is scarce

Reset
Clear between unrelated tasks. Two failed corrections → the context is polluted with bad approaches; start clean.
Plan → fresh
Interview and plan in one session, write the spec down, execute in a new session holding only the spec. The chatter is disposable.
Subagents
Research burns context. Delegate exploration to subagents that report summaries; keep the main window for building.
Prune memory
CLAUDE.md holds only what the agent can't infer. Test each line: "would removing this cause mistakes?" Bloat makes it ignore the rules that matter.
5

Start Monday

Mon
Add a check. Give the agent something runnable that returns pass/fail and tell it to iterate until green. Ask it to show the output.
Tue
Prune memory. For each line of CLAUDE.md: "would removing this cause mistakes?" Delete half. Watch adherence improve.
Wed
The 2-strike rule. Corrected the agent twice on one issue? Stop. Clear the session, write one better prompt.
Thu
Plan, then fresh. Have the agent interview you, write SPEC.md, then execute in a brand-new session that reads only the spec.
Fri
Delegate the reading. "Use a subagent to investigate X and report back." Keep your context for the build.
6

Check your model

Sources: Anthropic, Claude Code best practices · METR, RCT on AI & experienced developer productivity (2025) · Simon Willison · Mitchell Hashimoto, "Non-trivial vibing" · Armin Ronacher, "Agentic coding recommendations" · Addy Osmani, "The 70% problem." Public sources; no proprietary information.

← Aping   Press g for the grid