Engineering in a compressed loop.

Every engineering loop has the same four beats: decide what to build, build it, check it, learn from it. For most of our careers the build beat was the slow one, so it hid the others.

Agents collapsed that beat. A change that took an afternoon now takes minutes, and you can run it ten times before lunch. What did not compress is the part that decides whether those ten runs were any good: understanding the problem, reading the result, and knowing when to say no.

So the bottleneck moved. It used to be how fast you could write a correct solution. Now it is how fast you can recognise one. That is a different skill, and it is what the rest of this digest is about.

An agent is a superb pattern matcher. Ask it for a retry and it reaches for the most common retry on the internet. That is habit, at machine speed.

First-principles thinking is the counterweight. Before choosing a solution, reduce the request to the few things software is actually made of: data that must stay true, time and ordering, failure, and the people who read and run the system. Then build up from there.

With agents this matters more, not less. A model will produce a fluent answer to the wrong question. Four questions catch most of the expensive mistakes before any code gets written. Pick a request.

The science half is what you can prove: a test that fails before the fix, a load profile, an invariant, a hypothesis you tried to break. The art half is what you can only judge: names, boundaries, what to leave out, how a change will read to the next person.

Agents are strong at the science when you ask for it. They will produce evidence on demand. They are weaker at the art, because taste is not in the average of their training data. It lives in the specific choices your team made, and in the reasons behind them.

Too far in either direction and quality falls. Drag the slider to see what each extreme feels like to work in.

Ask that before you write a single instruction for an agent. If you cannot explain how a senior engineer would approach the change, no prompt will explain it for you.

The answer lives on a small shelf of books that used to pay off slowly, one design review at a time. Now every principle you can put into words becomes a line in a skill, and that line runs on every task an agent touches. Their value went up when code got cheap, roughly tenfold.

Read them in this order. It climbs from one function to a whole organisation, the same path pressure travels through a real system.

Two years ago prompting meant coaxing: you repeated yourself and hoped. Today’s models hold a written system across hundreds of steps, made of rules, a way of thinking, and the values that settle ties.

That moves the leverage. A clever line buys you one good answer. A coherent system buys you consistent behaviour on tasks you have not seen yet. Good systems have three parts: a Law (a short set of rules grouped by concern), a Bar (what a result must clear before it counts as done), and Field sense (how far beyond the edited file the agent has to look).

Every file read, failed attempt and stack trace stays in the window. After enough turns, the rule you wrote at the start is competing with forty screens of noise, and it loses.

Three things drive this. Attention is uneven, so material in the middle of a long context gets less weight than the start or end. Failed attempts teach the model the wrong patterns, because it sees its own mistakes as precedent. And compaction keeps a summary, which is lossy by design.

The fix is structural, not verbal. Give each concern its own fresh session and pass only the result forward.

A subagent starts with nothing. The brief is the only world it has. Write the brief well and the subagent does focused work in its own window, then returns thirty lines instead of three hundred.

That is what metaprompting means in practice. The main session does the recon, then writes a prompt for another agent. The main session keeps the facts and the decisions. The subagent keeps the mess. Full output goes to a file on disk, so nothing depends on remembering a conversation.

If one session is too crowded, the tempting fix is a chain: analyst, architect, planner, builder, reviewer. Each gets a clean window. Each also gets a summary of a summary.

Two forces pull against each other. More sessions give each agent more headroom. More handoffs lose intent every time. At ninety percent kept per handoff, four handoffs keep about two thirds of what you meant. Drag the sliders. The best point is usually a small number of owners, each of whom re-reads the code rather than trusting the agent before them.

Here is one shape that works. An orchestrator with Staff-level judgement does the recon himself, writes two briefs, reads two handoffs and closes. He never edits production code, so he has no attachment to any diff.

The pairing is the design. Author and critic share one context, so nothing is lost between them, and a forced change of hats keeps the critic honest. Two loops are bounded on purpose: one plan revision, two defect loops, then stop and report.

The build skill builds. The audit skill reads. It runs the suite for a baseline, states the system’s invariants in its own terms, splits the codebase into three to ten vertical scopes, and investigates each one in isolation.

Its value is the discipline around false positives. A finding needs a real trigger, a traced path with line numbers, and a named attempt to disprove it. Then a second, independent pass tries to kill it again. What survives is a short list of real pressure points. That is what you need to plan a refactor before it turns into an incident.

Every system has a few places where a small mistake costs a lot. They sit at every level, from the bits on disk to the pixels on screen, and they converge on a handful of vertically integrated paths.

Each level needs its own probe and its own agent. And each needs your instruction about how much is enough, because an agent left alone will either skim a layer or gold-plate it. Pick a layer.

For years, features got a brief, a design, a review and an owner. Testing got whatever time was left on Thursday. In a compressed loop that habit breaks, because code now arrives faster than confidence does.

So treat verification as feature work. The test strategy, the load profile and the user journeys are deliverables with a brief, an owner, a review and a definition of done. If you would not ship a feature without a plan, do not ship a test suite without one either.

QA is also where parallel agents pay off most, because the runs are independent. One agent writes and runs a k6 load script. Others walk user journeys in a text browser, which shows the page the way a screen reader and a crawler see it, and turns UI into plain text an agent can diff between releases. Another checks accessibility. Each one writes a report file, and a single pass merges them.

Agents make both failures cheap. The under-built change passes its test and forgets the second caller. The over-built one adds a layer with one caller and an option nobody asked for. They are the same failure: a change that does not fit its problem.

The cure is to build testfully, which is different from building with lots of tests. Write the one test that fails before the fix and passes after, at the lowest level that can see the bug. A suite that never fails proves nothing, and a thousand generated assertions are bloat, not safety.

An overloaded skill reads like a policy binder. The agent tries to satisfy all of it at once and satisfies none of it well. A good skill is small, specific to your department’s needs and values, and written in your team’s own words.

Write values first, heuristics next, steps last. Then let real failures grow it: every time review catches something the process missed, add one line under Lessons. Cohesive, simple, evergreen software comes from guidance that stays the same way.

When you brainstorm a feature with an agent, it fills gaps with plausible inventions. The cure is a map it can read in one pass, not a three-level wiki it has to summarise. Keep one high-level domain map: each domain, what it owns, and what it depends on. Detail stays in the code, where the agent should be reading anyway.

The first version of a good skill is an afternoon’s prompt. The version worth sharing comes from running it on real tasks, reading what broke, and writing down why. Most of that time is understanding: failure analysis, explainers, documentation, QA on real repositories, and keeping the domain map and architecture intact so future brainstorming stays grounded.

Fifty hours of study and fifty hours of practice will teach you subagents, skills, briefs, MCP and hooks. That knowledge is real, and it plateaus quickly.

The part that keeps growing is the ability to evaluate what comes back, and to write your taste down precisely enough that an agent can apply it. That is worth roughly ten times the tooling, because it decides whether this week’s hundred fast diffs are an asset or a liability. It comes from the shelf in chapter four, from production incidents, and from years of reading code with care.