Agentic Engineering on Claude Code

There’s a story going around that AI coding tools removed the bottleneck in software engineering, and that the bottleneck was typing.

That’s wrong, and it was wrong before the agents showed up. Nobody’s project ever slipped a quarter because their team couldn’t type fast enough. Projects slip because the data model was wrong, because two services disagree about who owns a piece of state, because the retry logic turns a partial outage into a full one, because nobody decided what “done” meant. The bottleneck was system design. It still is.

What changed is that the cost of producing code fell to roughly zero, so the constraint that was always there is now fully exposed — with ten times the throughput running at it. If your design is muddy, you no longer find out in three weeks. You find out in an afternoon, across forty files.

So the interesting question isn’t how to get the agent to write more code. It’s how to run it so your judgement stays in the loop at the points where judgement is the scarce resource.

The loop is the unit of work

Addy Osmani has a good framing for this in Practical Loop Engineering: stop thinking in prompts, start thinking in loops — act, evaluate against a check, feed the result back, repeat until a stopping condition fires.

A loop has three parts you can get wrong: the goal (what finish line, stated so a machine can tell whether you crossed it), the check (what evidence closes it), and the bound (what stops it when the check never goes green). Most bad agent sessions are a loop with a missing part. No goal: it wanders. No check: it declares victory on vibes. No bound: it burns forty minutes rewriting the same function four ways.

Weak checks and strong checks

This is what actually separates people who get value from these tools from people who don’t, and it has nothing to do with prompting.

A weak check is the agent’s own assessment — “I’ve updated the component and it should now render correctly.” That’s a prediction, not evidence. Every frustrating session I’ve had traces back to accepting one.

A strong check is external and falsifiable:

Refactor the data-fetching in Dashboard.tsx.
Done when: `pnpm typecheck` passes, `pnpm test:dashboard` is green,
and Lighthouse LCP on /dashboard is under 1.8s.
Stop and report if you can't get there in three attempts.

Typecheck, tests, linter, a curl against a running server, a screenshot diff. The agent can run all of these itself, which means it closes its own loop instead of handing you plausible-looking guesses.

Hence the observation that keeps surprising people: your test suite is now an agent-productivity feature. Teams with fast, trustworthy checks get enormous leverage. Teams without them get a very confident intern with commit access.

And notice what “define the check” actually is. Deciding what correct means, what latency is acceptable, what the invariants are — that’s system design work. It didn’t go away. It moved to the front and became the thing you type.

What I actually delegate

I sort work by how good the available check is.

Delegate freely when a strong mechanical check exists: migrations across many call sites, tests for existing behaviour, type errors, dependency bumps, “find every place we construct a StripeClient,” codemods.

Delegate, then review properly when the check is partial: features behind existing interfaces, bug fixes with a failing test to go green, refactors inside one module.

Don’t delegate the decision when no mechanical check exists: schema design, service boundaries, auth models, anything touching money, concurrency semantics, the public API you’ll be stuck with.

That last group isn’t off-limits to the agent — it’s good at drafting options and arguing both sides. But the choice is yours, because no test tells you a boundary is in the wrong place. You have to already know.

Maker–checker

The highest-leverage pattern I’ve adopted: the agent that wrote the code doesn’t get to review it. Fresh subagent, no context about the implementation, one job — try to break this.

It catches a genuinely different class of problem, because the implementing agent spent its whole context window convincing itself the approach was sound. So did you, if you watched it work. Same reason we don’t let people approve their own PRs.

Two other things worth the setup cost: a CLAUDE.md that is falsifiable (“package manager is pnpm, never npm install” — not “write clean code”), and hooks for anything you’ve asked for twice. If you’re requesting the formatter a fourth time, that’s a configuration bug, not a prompting problem.

What loops don’t buy you

A correct design — a green check on a bad data model just arrives at the wrong place faster, with better test coverage. Understanding — you can ship a subsystem you couldn’t explain under questioning, and you’ll discover this at 2am. And taste: knowing the plausible suggestion falls over under concurrency, that this abstraction becomes a liability in six months, that the requirement as written is the wrong requirement. None of that is in the loop. It’s in you, or it’s nowhere.

Which brings me to certificates

I spent most of my career mildly dismissive of certifications. When a GitHub profile and a whiteboard were the signal, a PDF from a training provider was noise.

I’ve changed my mind, for one reason: the old signals got much noisier. A green contribution graph used to imply sustained effort. A well-factored PR used to imply taste. A working side project used to imply follow-through. All three are now cheaply generated. When cheap signals get noisy, expensive ones get valuable — and a credential requiring a proctored exam or a hands-on lab is expensive in exactly the way that makes it informative.

Worth it	Why
Cloud platform certs (AWS/GCP/Azure, associate and up)	Hands-on, proctored, and they map to real operational responsibility.
Security certifications	The one domain where “the agent wrote it” is the start of the conversation, not the end.
Kubernetes / platform certs (CKA, CKAD)	Performance-based. Real cluster, real problems, against a clock. Hard to fake.
The distributed systems and databases coursework you skipped	Not a certificate. Compounds harder than any of the above when you’re reviewing agent output.

Not worth it: anything you can pass by watching a video at 2× speed. No lab, no proctor — it’s a receipt, not a credential.

But signalling is the smaller half. The bigger half is that studying for a hands-on exam is one of the few remaining structured excuses to build depth in exactly the areas agents let you skip. You cannot delegate your way to understanding why the health check is failing, or what your database does under write contention — and that depth is precisely what “define the check” and “don’t delegate the decision” draw on.

Where this leaves us

The job didn’t get easier, and it changed less than people claim. The hard part was always deciding what to build and knowing when it’s right. That part is now the whole job, running against a code-generation firehose.

Define goals a machine can check. Make the checks strong and the feedback loops fast. Keep the decisions that have no test. Then go rebuild the depth the tools make it easy to skip — because the loop closes on your judgement, and nothing else.

---

Related reading: Addy Osmani, Practical Loop Engineering — the loop/goal framing above owes a lot to it.