Agentic Engineering: What Agents Can Safely Own

August 30, 2026

Two posts back, I used Kent Beck’s 3X framework to argue that agentic engineering gets read at different phases of maturity depending on how far you sit from the code. Last post, I argued that more code isn’t enough. Agents compress execution to nearly free, but judgment is still as critical as ever: deciding what to build, owning intent, understanding the result well enough to steer the next loop.

When the cost of coding collapses, lots of other activities become visible. Some of what’s left is critical and shouldn’t be outsourced: judgment, most of all. The rest is process we built up when writing code was the expensive part and a lot of it was never questioned because the coding cost dwarfed it. That’s the part to re-examine.

Will Larson landed in the same place from the org side: very little work is genuinely constrained by execution bandwidth anymore. It’s constrained by approvals, by handoffs, and most of all by missing decisions. His prescription is a roadmap of decisions, not dates — stop scheduling software around calendars, and start accelerating the decisions the work is actually waiting on.

If that’s right, the highest-leverage move isn’t making agents faster. It’s growing the share of work whose decisions are already closed. The work an agent can pick up and run without stopping to ask what you meant. That’s the work that ships in a day. Everything else waits on human decision latency, exactly like it always did. Perhaps that’s the bottleneck we should examine.

Let’s focus on a narrow, practical question: what makes a piece of work agent-shippable, and how do you tell before you hand it over? The failure mode here isn’t an agent that writes bad code. It’s an agent that confidently runs work that was never ready — at volume. Which means the first act of judgment isn’t reviewing the output. It’s deciding what should have been allowed to run unattended in the first place.

I’m in the middle of exploring this at work: a real triage, on a real backlog, with real arguments about which traits actually matter. We don’t have a playbook for this yet, so I’ll revise and update as we go. We’re starting with a set of criteria we’re testing against the work.

The Right Conditions Aren’t New

Same-day start-to-deploy was always possible, but only for work with a specific profile:

Clear requirements, or a problem the developer already understood
Small scope
An unambiguous definition of done — no second-guessing
The developer already held the model of the code — the frameworks, systems, and patterns
The developer had everything needed to build, test, and verify

Every one of those is a proxy for the same thing: reducing the person’s thinking-and-typing load. The constraint before agents was code generation: how fast one person could hold a problem in their head and produce correct code. All five traits focus on that constraint. Small scope shrinks it. Clear requirements remove upstream thinking. Existing context removes ramp-up.

Two things were bundled inside that one person, and they’re the whole reason the profile is changing:

The generator was also the decider. Small judgment calls got made in-flight, at zero latency, by the same person writing the code. Nobody wrote them down, because nobody had to.
Verification was partly internal. An experienced developer carries a running “this looks wrong” sense; formal checks only had to cover the gap that instinct didn’t.

Give code generation to an agent and those two split apart. The in-flight decisions now have to be written down as intent or context, because the agent won’t make them the way you would. The internal “this looks wrong” has to be externalized as mechanical checks, because the agent doesn’t have it. This is why the intent and verification pillars from the last post stop being nice-to-haves. They existed in someone’s head, and now they can’t.

When a developer holds the model of the code, it’s really two things. The first part is judgment: knowing, from principle, which approach is right when the situation is new. That stays with the developer. The other part is patterns: knowing how this codebase does a thing, what the established shape of a change looks like here. Patterns are extractable. Judgment isn’t.

Which makes Patterned a first-class condition that we can leverage with agents. The second instance of anything is cheap, because now there’s a pattern to copy; the first instance is where the judgment comes into play. So build the first instance deliberately and slowly, then fast-track the rest. The first one is you deciding the shape, the rest is the agent matching it.

An agent can go exactly as fast as your feedback loop allows.

That’s also why the same model produces excellent output in one repository and slop in another. Agent-shippability is a property of the codebase, not of the model. It’s something you build, not something you buy. Which is also why swapping harnesses isn’t the silver bullet.

What Qualifies Now

A unit of work can be started and deployed in a day by an agent when it’s:

Decision-closed. No judgment calls remain in-flight, or they’re pre-encoded as written policy the agent can consult.
Mechanically verifiable. “Done” is checkable by a machine, not by taste, not by a human reading the diff carefully.
Blast-radius-bounded. Cheaply reversible, behind a flag, an additive migration, an isolated module.
Context-resident. Everything the agent needs will physically fit in what it can take in.
Patterned. The change matches a shape already in the repo, so the agent has examples to copy rather than a principle to work out.

Those five are all properties of the work. There’s one more, called out in Larson’s post, that’s a property of what stands around the work: approval-clear, meaning no human-latency gate sits between merge and deploy. A change can be decision-closed and patterned and still not ship today because it’s waiting on a security sign-off or another team’s review.

This list is an all-or-nothing requirement. Work must clear every single trait to qualify, not just hit a good average. One specific pairing often trips people up because two of these traits seem completely unrelated. Cognitive load and blast radius are independent. Adding an index to a 400-million-row table, or changing persisted data, could be trivially simple: minimum thinking, maximum clarity — and also a one-way door. “It’s a small change” is an argument about cognitive load; it says nothing about whether you can revert it. Decision-closed and patterned can both be true while blast-radius-bounded is flatly false. The work that feels safest to wave through is often exactly the work that isn’t.

Ambiguity Is a State You Can Change

Reading the list and it sounds like work either qualifies or it doesn’t. Sort the backlog into two piles and hand one to the agents. But the most valuable work almost never starts in the qualifying pile. Interesting work is ambiguous work: the decisions aren’t closed, the definition of done is soft, nobody’s holding the full model yet. If you only ever fast-track what’s already decision-closed, you’ve capped the payoff and it’s usually the least interesting work you have.

The trap is treating decision-closed as a fixed property the work. It isn’t. It’s a state you can move work into, and the move is cheaper now than it’s ever been.

Larson calls this the iterative application of judgment: you don’t resolve a hard, ambiguous decision by thinking harder about it, you resolve it by prototyping until the options collapse. The answers get obvious not because you got smarter but because a working artifact makes the constraints explicit and eliminates the paths that don’t survive contact with them. One big fuzzy decision becomes a series of small clear ones. That’s decision latency attacked at the source, not by deciding faster, but by making the decision easy.

Prototyping was always the right answer to ambiguity. It was just expensive enough that most teams didn’t have time for it. That’s the part that changed. I’ve written before about how agents turn a multi-week probe into an afternoon one. Discovery phases that used to produce documents now produce working scaffolding, and a POC can unblock an architecture decision in days instead of weeks. When a prototype costs an afternoon, “prototype until the decision closes” stops being a luxury and becomes the default way you qualify ambiguous work.

So there are two ways a unit of work becomes agent-shippable. It was already decision-closed, rare, and usually the boring stuff. Or you spend a person’s judgment up front, cheaply, to close it: prototype the ambiguity, encode what you learned as the constraints the agent will follow, and then fast-track the rest. It’s the same as creating a pattern, except here the first instance is the thinking, not the code.

The share of your backlog that qualifies isn’t a number you measure. It’s a number you grow by spending cheap, up-front judgment to move work across the line.

One caveat, because this is exactly where enthusiasm gets people hurt: a prototype that closes the decision is not the thing you ship. The artifact you built to think with hasn’t been verified, isn’t reversible, and hasn’t earned the other traits just because it answered the question. Closing the decision qualifies work to enter the fast path — it doesn’t let it skip the path. The moment a POC that “works” gets rushed straight to production is the moment you’ve traded the discipline for speed.

The Number Worth Growing

Post one made fun of “percentage of code written by AI” as a KPI — a gameable metric that inflates the exact review burden that’s already the bottleneck. Here’s a metric that isn’t gameable: qualification rate — the fraction of incoming work that clears the bar to run agent-shippable, trending up over time.

You can’t fake it by generating more code. The only way it moves is by doing the work underneath it: closing decisions before they reach the agent, building the first instance so the next ten are patterned, tightening verification until “done” is machine-checkable, keeping blast radius bounded. Every one of those is a piece of judgment spent up front.

It’s also a decent answer to the executive question from that first post: is this working? Not “how much code did agents write,” but “how much more of our work is now the kind of work an agent can safely own than was six months ago?” That number going up is a real transformation.

Once you can classify work, and grow the share of work that qualifies, you need a system that actually routes it. Send qualified work onto an agent-fast path, everything else onto the slower, more mindful one, with judgement and decisions. That’s how we get to really start Expanding and Extracting value.