A year ago I’d have told you it was impossible. Ship a whole feature, database and backend and API and a UI a human can actually click, in a day. Maybe two. This time last year that idea seemed absurd to me. The tooling caught up. Now, with Fable and Sol, a coding session stopped being a small, discrete, don’t-complicate-the-context, one-slice-of-a-ticket kind of thing. Now I run a session with sub-agents that isolate context, do the review, do the development, and keep a clean global context so I can stay up at the level of feature planning and interactive testing. The impossible thing is Tuesday now.

So how do we manage the impossible? How do we hold onto our roles as the magicians and the unicorns when you don’t always know where the magic is coming from?

Luckily, we still live in a human society. Human software is built by humans and for humans, and even agentically developed software is still trained on human data, on human software, on human conversations. It will never be perfect. There’s some Muskian future where everybody’s agents talk to everybody else’s agents and abundance just falls out of the sky and the world rearranges itself around you… maybe. We don’t live there. We live in the transition, right here, right now. And in the transition, the only things that have ever delivered software at scale are the things that have always delivered software at scale: tests, well-documented flows, regression tests, end-to-end tests, performance tests. Observability. Metrics. None of that changed.

What changed is who has to remember it. The agent already knows all of this. It has read more about testing discipline and observability and regression suites than any of us ever will. And it won’t reach for a lick of it unless you tell it to. That’s your guardrail. That’s how you make a very capable model use what it already knows, every time, without being asked twice.

Your job isn’t the keyboard

Agents can code. Moderately well, and getting better on a schedule that should scare the doubters. They can follow a process: verify, self-review, improve, record the debt they just took on, and move. So your job is no longer piping lines of code out through your fingers. Your job is to produce the concrete artifacts the agent needs to produce code at the quality we want. The plan. The spec. The examples. The definition of done. The guardrail.

It comes down to this: doing is cheap now, deciding and verifying are not, and the scarce resource is comprehension. Your value moved to the scarce thing.

You’ve heard of the speed-quality-price triangle. It still applies. But agentic development makes the triangle much bigger. You can push so much more through it that you actually have room to play, and the human sitting above the agents is the one choosing where on that triangle we sit. Price, in this world, is mostly tokens. That’s your dial. Learn to turn it.

And nobody runs one agent at a time. So the job climbs another rung, into coordination and orchestration. You’ve become something bigger than a single developer. You’re running a small school of agents underneath you, and you’re the one who understands the whole system, reinforces the whole picture, and stands as the backstop when an agent can’t reason about a corner of the infrastructure that was never written down or put in code.

Some of this is personal. We all work differently. You’ll have your own prompts, your own rhythm, your own way of catching yourself. Good. Lock it in. Skills, scripts, a wiki file, a hook, whatever fits your hands. Your process becomes an artifact too, something the fish next to you can read.

The guardrails, in tiers

I keep a philosophy doc for exactly this work, and its root is a line I’d hang on the wall: you cannot make the world reliable, so you engineer the two things you actually control, which are how loudly you find out you’re wrong and how cheaply you can be wrong. That is what every guardrail here is for. And two rules sit on top of all of them. A guardrail you can’t trust is no guardrail at all. A guardrail you can’t see is no guardrail either.

I think about them in tiers of enforcement, strongest first.

Hooks are the strongest tier, because they aren’t optional and they aren’t slow. Don’t run your tests in a hook. That’s too much delay in the loop, and you’ll start disabling it, which defeats the point. Run formatting. Run type checks. Run the linter. Pair it with an auto-memory setting that feeds the standard back to the model over time so it stops making the same class of mistake. Cheap, fast, relentless.

Next tier: self-review and review agents. These are genuinely strong now. In both personal and professional coding projects, I still burn more review cycles than I’d like, and it’s because there’s no golden standard and new bugs emerge regularly in places we don’t control. The bar for tests, linting, and formatting can sit low in a codebase, and the agent inherits whatever bar it finds. Raise the bar and the review cycles shrink.

Top tier: interactive testing. You can do a lot of this agentically, but to start it needs a human in the loop, and I don’t think that changes soon. Human software is built for humans by humans. The human interaction is the thing you’re trying to capture. Automate it away too early and you’re not testing your product, you’re testing a simulation of it. Maybe a simulation built on real production traffic, sure. Still a simulation.

The bug rate scales too

Here’s the part nobody wants on the slide. If feature velocity goes up exponentially, the bug rate goes up exponentially, because there are always things we didn’t think about, didn’t consider, or knowingly punted on for speed. That’s the method being honest with you. The stuff we skip to go fast doesn’t evaporate. It comes back as bugs.

If you inherited a codebase that wasn’t written agentically with strong guardrails from day one, you have to keep pushing change through the whole system, and you have to accept that the rate of change will produce stress, pressure, and fracture faster than you’ve ever felt it. The real fight is balancing revenue-driven work against revenue-stabilizing work, and that’s a hard pill for a business team to swallow when the demos look that good.

“Done” still means done

I could write a whole separate post about how the failure to actually adopt DevOps, the culture and the mindset and not just the tooling, is going to burn agentic teams forever. Done doesn’t mean the agent wrote it. Done means shipped to production, tested in production, and monitored. Agent completion is not task completion, and I have that written into three separate config files because I kept needing it. The model announcing “done” is where verification starts. A codebase that understood that from the beginning can enforce it. A codebase that didn’t is biased against it, and it delivers immediate agentic reinforcement to avoid the guards rather than investigate and resolve what tripped them.

Somebody’s going to say “throw Fable at it.” Fine. Now hand a 500-file, 200,000-line pull request to a human or an agent and ask either one to actually understand it. Neither can. That request is awful on its face. So the contract changes. Small changes, executed rapidly. Push more of the interpretation out to the edge, because with LLMs everything can be interpreted now, and a chat agent can help your user revise what they were even trying to do. The work becomes getting out of work: closing the thing in front of you, and investing so the future thing closes itself. That investment is the crucial part, and it’s the part that gets cut first when nobody’s guarding it.

So here’s the expectation I actually care about. Feeling ahead of your work is the wrong thing to measure. The thing to measure is whether you understand your work from every angle you can find. A sampling of the angles I mean:

  • a CEO grinning at a beautiful button that does 500 things
  • the user who’s going to hit that button 500 times, because doing 500 things at once takes a while
  • the pager that’s about to explode because 250,000 jobs just fired at once
  • how a “simple prompt” could generate that much churn in the codebase
  • what signal your agents have access to, because you’re not going to click 250,000 “stop” buttons fast enough
  • how to get an emergency fix into prod at agent speed

You have to gain that understanding somewhere in the loop. Nobody hands it to you, and the pace will not wait for you to pick it up later. Not to mention security. When you find the edge of what you understand, write it down. Undeclared debt is theft from whoever arrives next, and that is usually you. Your agents should be writing it down in tickets and working with you to get it into a sprint.

Part of slowing down is sitting with Claude and iterating on your own process, your philosophy docs, your configs. It’s worth the tokens. Actively managing your agentic configuration, and keeping it a living, breathing system, is part of the job now, not a side quest.

And speaking of living, breathing systems: that’s a good sign in a codebase too. A stable, unchanging codebase is not automatically a healthy one, especially at agentic speeds. Healthy systems move.

What it looks like when it works

A concrete one, from my own tools. I’ve been building the tooling I use to do this work, and it develops itself, which is its own kind of proof. I shipped a couple of features recently: automated pull request review, and a Codex integration. I thought I’d built both of them out fully. What actually shipped were incomplete versions of both, because I hadn’t accounted for all the specifics of my own workflow. I told myself I was just moving something I already did into a new place. Turned out it needed a lot more wiring than I expected.

Here’s the good part. The turnaround on the urgent, breaking pieces was absurdly fast, because the tool works on itself. Claude finds the additional bugs and the friction, files them as issues into a sprint, and by the time I have a new version ready to install, a day or two later, the stuff is already fixed. That’s the loop I want the team living in. It wasn’t perfect on the first pass. It self-corrected fast enough that the first pass stopped mattering.

If you want the receipts, the tool’s own git history tells the whole thesis back to me.

It opened with a genesis sprint in February. 69 commits in ten days, features dumped as v2, v3, v4, v5, each one immediately chased by a “fix: address code review findings” commit. Fast, and a kitchen sink. By the end of the month I stripped it back to the core workflow and pruned the sprawl, then went nearly dormant through March. That is the bill for an unscoped burst, and I paid it in full.

Then in April I did the thing this whole post is about. I put in the guardrails. Every change became an issue and a merged PR, and from there 611 of the tool’s ~688 commits carry a PR number. A month later there was a written contract for headless ticket-to-PR runs. In May came a native background daemon, ADR and RFC discipline, forensic debugging skills, and per-client model pinning, which was the first real cost lever I had. Then orchestration: wave dispatch, a work queue, cost tracked per task. June came out to 253 commits, the peak month in the tool’s whole life, and orchestration is the entire reason. The school could finally move in wide parallel waves without colliding, so more shipped. My typing had nothing to do with it.

The quality guards landed right alongside. A “green local, red CI” incident turned into a documented seven-gate local sequence that killed a whole class of wasted round-trips. Sixteen specialized review agents and a pre-flight hardening skill stopped the ambiguity bounce-back, the whack-a-mole where an autonomous run burns tokens chasing a ticket that was never clear to begin with. By late June the cheap stages were pinned to cheap models by policy, not by hope.

That is guardrails compounding. Every one I added let the next batch of work move faster and cost less, and the history is just that, over and over. The speed came from the guards, every single time.

Build guardrails

To survive a sea of impossible requests and still make it to Milliways for dinner, build guardrails. Survival at agentic pace requires guardrails, and what counts as one is a moving target, especially early. At the start, speed matters. Get something that looks good, that does a thing, that proves the idea. I mean that. But at some point, and you’ll feel the point arrive, quality starts to matter more, because quality is the thing that lets you last.

Here’s the reframe that matters. Fixed budget, full throttle, maximum quality. They are not in tension, and believing they are is the most expensive mistake on the table. Rework is paid in the same currency as work. Quality is how a fixed budget goes furthest.

Yes, you’ll slow down when you start caring about quality. You’ll see the stress and the friction and the cracks in the system all at once, and it’s a lot. If you can take the breath, step back, and ask “okay, how do we actually care for this thing,” you’re doing something most people never get to. Not everyone can. If you can, that’s where sustainable gets built.

We’re being asked to handle 5x, 10x, 30x, 50x, 200x what we used to handle, for no reason other than the code comes out that much faster. Sit with that number. It means we have enormous room, as an engineering team and an engineering culture, to push for quality, to advocate for quality, and to prioritize it over the other pressures that come for us. That room is the gift in all of this. Don’t spend all of it on speed.

A school moves fast because it moves together, and because somebody keeps a pulse on the water. Build your guardrails. Watch your water. That’s what lets us move this fast without coming apart.