Nothing Stops the Train: Engineering Systems in the Age of Cheap Execution

I've been spending a lot of time lately on the velocity of AI-assisted engineering — practicing it, teaching it, and pushing on how fast a single person can actually move. And the more I do it, the more I keep circling back to one uncomfortable question: what does an engineering organization look like when the hard part is no longer writing the code?

Because that's the shift. For decades, the entire shape of enterprise engineering was built around one assumption: execution is expensive. Writing code was slow and costly, so it made sense to spend heavily on everything around it — the specs, the designs, the reviews, the sign-offs. If the code itself took weeks, a few extra days of process was a rounding error, and it bought us confidence.

That assumption has flipped. Execution is now cheap. An engineer with agents can produce more in a week than a team used to produce in a quarter. And when execution gets cheap, the coordination around it — the talk, the queuing, the waiting — becomes the bottleneck. All the process we built to protect expensive code is now the most expensive thing in the system.

So I want to lay out where I think enterprise engineering systems need to be in twelve to eighteen months. Not some distant future — this is a one-to-two-year target for real teams working in large, brownfield codebases.

The philosophy: nothing stops the train

Here's the principle everything else hangs on: nothing stops the train from moving.

You want a review process? Fine. But it runs alongside development, not in front of it. You want a UX review, a security review, an architecture review? Great — they all happen while the work keeps moving forward. There are no hard blocking gates in the development flow. None. The only legitimate hard stop is the final release to production, where legal and compliance sign-off genuinely protects us. Everything from development through pre-production, and often through preview, keeps moving.

This isn't recklessness. It's a recognition that the cost of stopping now exceeds the cost of occasionally being wrong and redoing the work.

Reviews become a run-along, not a gate

Think about how many reviews live in a modern engineering org — and I'm only counting the engineering ones. Spec reviews. Design reviews. Architecture reviews. Security reviews. UX reviews. And then, on every single pull request, code reviews. Every one of them is a place where a human can stop the work.

That model made sense when one engineer opened a PR every couple of weeks. A two-day review was fine; the engineer just worked on the next thing while they waited. Two tracks, sustainable, done.

Now picture an engineer running agents that open ten pull requests a day, across multiple machines, touching tens of thousands of lines in a week. Putting a human blocker in front of that flow — preventing code from reaching integration, from reaching preview stakeholders, from being validated — is absurd. It's not a bottleneck, it's a dam.

So reviews stop being gates and become an adjacent process. The engineer creates the PR, pushes it, and merges it. Reviewers get notified that something has landed in their queue. They then have days — for large features, even weeks or months — to do their review. But they do it on integrated, merged, pre-production code. Not on code frozen inside an unmerged PR. Not on code that's blocked. On code that already exists and already runs.

The obvious objection: if nobody blocks, how do we protect quality? That depends on the kind of quality we're talking about.

Quality is automated, not adjudicated

The things a review traditionally catches — code quality, security, database design, edge cases, logical defects, non-functional concerns — those should be fully automated. Not mostly. Fully.

Anyone who has an opinion on quality gets to encode it. Write a rule. Write a script. Write a skill. Do it deterministically with static analysis, or non-deterministically with an agent, or best of all as an automation test that actually verifies the behavior. All of those checks are allowed to block the PR in process.

That's a crucial distinction. A check can block the PR; a person cannot. If my PR fails your automated check, that's fine — my agent resolves it and moves on. A human being telling me "you can't merge until I look at this" is exactly what we're removing. Humans can still inspect later. They just don't get to hold the queue.

Architecture and design: only for the doors that close

Now the harder question — what about architecture and design? And here I mean low-level component design, not user experience.

Start by asking whether you even need it up front. If you're building into an existing platform with an existing architecture, how the new pieces fit is usually something an agent can work out. For most smaller features, and even some larger ones, you don't need an architecture phase before you start.

Why? Because the cost of getting it wrong is now small. If a bad architectural call means a big refactor, so what — I throw out a week of agent work and redo it. In the meantime I validated ten other things and nothing stopped me. In the rare case we get it wrong, we revert. What we don't do is freeze the whole train to guarantee we never take a wrong step.

Architecture that genuinely must happen before code is the exception, and it has a specific signature: the door-closing decision. The choices that are extremely expensive to reverse — external contracts, infrastructure, anything that creates backward-compatibility obligations the moment it ships to a customer. Those warrant a stop. Automate the check if you can; if you can't, that's one of the few things worth blocking on. Almost nothing else qualifies. If it's just "I might have to swap a library" or "I might redo a component," we handle it later. Tell the agent, revert the PR, move on.

UX is the same story

User experience follows the identical logic. A PM and an engineer can throw together screens that reflect the APIs they've designed, and it's previewable today. And in an agentic world, a huge share of features may not need a UI at all — sometimes the right surface is an API, with a nicer interface attached later.

So when does UX actually block? Only when getting it wrong is enormously expensive — and specifically when the user experience defines the architecture. Some products are so experience-heavy that until you work through how it's presented to the user, you don't truly understand the concept, and the UX has to come first. But that's the minority case. Most of the time, UX rides alongside development and never blocks it.

Cross-cutting concerns: build them in, don't delegate them

Every enterprise platform has its non-negotiables — privacy, security, encryption at rest, roles and permissions, governance, observability, the promises we make every customer for every feature. Historically we pushed these onto each feature team to implement and then policed them at review time.

Stop doing that. These belong in the platform as infrastructure and automation. If every entity must be encrypted at rest, and you know your endpoints because they flow through a common infrastructure layer, then you can automatically verify that every storage account, database, and queue is configured correctly. Better still, build it in so the feature owner never has to think about it at all.

The reason we used to delegate this was that building the shared infrastructure to guarantee it was too expensive, so we let each team fend for itself. That math doesn't hold anymore. Build it in as infrastructure, as automation, as a test layer — deterministic or not — but don't make it another human gate. Don't stop me for it.

Where the bottleneck goes — and why that's good

All of this, including integration into pre-production and often preview, happens during development. The engineering team delivers to pre-production and moves on. From their perspective, they're done. Control over the final flip to production shifts to the reviewers, who make that decision and turn the switch when they're satisfied.

Here's the elegant part. If the queue starts backing up at that production switch — if we're chronically short of humans to complete reviews — that's not a mystery, it's a signal. It isn't a tangled graph of crisscrossing dependencies anymore. It's a clean, linear queue, and you can see exactly where it's clogged. So you do what you'd do with any clogged queue: add resources to drain it, or figure out what's causing the backup and remove that step entirely. Either way, the diagnosis is obvious and the fix is mechanical.

Onboarding and environments should be instant

Now the part nobody likes to talk about: environments. Onboarding a new engineer — or even a seasoned one moving to an unfamiliar product — routinely burns weeks. Reading wikis and READMEs, installing toolchains, cloning repos, wiring up services. Even an expert who just needs to reimage a machine or spin up a second environment loses a day or two.

That's unacceptable now. If a small codebase can be opened in a ready-to-go cloud editor and you just start working, that's the bar for every feature. If a feature needs specialized dependencies, fine — you grab a pre-provisioned dev box that's already set up. I open it and go. I don't need to understand the codebase or the prerequisites. I need to understand the business, know how to direct my agent, and know how to verify the result. The agent itself handles the rest of the ramp-up — it tells me what's expected, because it already knows and I don't have to.

Trust comes from verification, and verification comes from deployment

Which brings us to the real question underneath all of this: how do I trust an agent enough to stop reading every line of code?

The answer is that I hand the agent everything I would have done to check it manually. This is what people are starting to call loop engineering — the more of my own judgment loop I can push into the agent, the more I get done. I used to manually verify; now I tell it to run the review and verify itself. Every step I would have performed, I delegate.

And verification has a shape. It starts with linting, and it ends with a fully deployed, end-to-end environment where we actually call the APIs, drive the UI, invoke the interface, and confirm the whole thing works the way a customer would experience it. In between: compilation, unit tests, a local deployment, integration tests. But the loop only truly closes when the code does what it will really do in production — which means it has to be deployed, with migrations and everything else, into something as close as possible to a real environment.

So the thing I owe my agent is a fast path to a realistic, integrated, deployed environment. It doesn't have to be production. It has to be quick. Because then the loop runs itself: push, deploy, verify, fix, push, deploy, verify — over and over, as many times as it takes, while I'm asleep. I wake up and the code is done.

The one question that governs everything

Underneath the whole philosophy is a single discipline. The philosophy is don't stop me. The discipline is a question you ask constantly: do we actually need this?

Is this process, this meeting, this review, this sign-off a genuine requirement — or is it an artifact of an era when execution was expensive and predefining everything up front paid for itself? Verification is always worth it. But most of the ceremony around it was a hedge against slow, costly code, and that code is no longer slow or costly. Stopping the train is now usually more expensive than occasionally redoing the work.

So every time we hit a procedure, we ask: do we need this? Do we need this meeting? Do we need this gate? And every time the honest answer is no, we get rid of it.

That's the whole game. Automate what you can, build the guarantees into the platform, let reviews run alongside instead of in front, give people instant environments and trustworthy verification loops — and keep asking, relentlessly, whether each remaining step still earns its place.

Nothing stops the train.