Brakes Before Speed

An F1 car can top 350 km/h (about 220 mph). But ask an engineer what actually lets it go that fast and they won't start with the engine — they'll start with the brakes. Carbon-ceramic discs that bite at 1,000°C (around 1,800°F) and can shed more than 120 km/h (75 mph) of speed every single second. The car is quick on the straight because the driver trusts it to stop for the corner. Take the brakes away and the top speed on the spec sheet becomes irrelevant: nobody drives flat-out toward a wall.

That relationship shows up everywhere we've learned to move fast. Japan's Shinkansen — the bullet train — has run at speed for sixty years with a near-perfect safety record, and the headline engineering isn't propulsion but the automatic train control that's continuously computing whether the train can still stop in the distance it has. SpaceX doesn't get credit for launching a rocket; anyone can launch a rocket. The hard, valuable part is bringing a booster back through re-entry — controlling that fall from over 8,000 km/h (roughly 5,000 mph) and decelerating safely to an upright landing. Even a skier or a cyclist bombing a descent is really running a stopping system — edges, an emergency stop, a line they can bail out of. In every one of these, speed is a downstream property. The thing you actually build is a way to stop reliably. Stopping power buys you speed.

Here's the uncomfortable version for our industry: you don't get to go fast until you can stop. The brake isn't what slows you down. It's what lets you commit to speed.

Agentic software engineering has skipped the brakes

For two years the frontier labs have been in an engine-building arms race. Bigger models, more autonomy, longer task horizons — an agent that could hold a few files in its head now refactors across a whole repo and runs for an hour unattended. That's the engine getting more powerful, and it's genuinely impressive.

But almost none of that work went into the brake. We shipped agents that can go without building the thing that lets a human commit to letting them go. A coding agent has no perception of "slow down here" — no signal that it's wandered outside the task, that the change got riskier three files ago, that this is the moment to stop and check in. It will merrily drive at full speed straight into the wall, produce 600 lines of confident nonsense, and report success.

So teams get pushed to one of two bad places. Either you let the agent run and accept the wreckage — the silent scope creep, the plausible-but-wrong diff, the Friday-afternoon surprise in production. Or you refuse to trust it at all and babysit every action, approving each edit and command, which throws away the entire reason you reached for an agent. Both are what happens when there's an engine and no brake. You either crash or you crawl.

What a brake actually is

It's worth being precise, because "add a brake" gets misread as "add friction," and friction is exactly what nobody wants. A real brake is not a stop sign, and it is not a permission prompt on every action. Those just add friction everywhere — they slow you down at every step without ever earning the trust that would let you speed up. A brake worth the name has three properties:

1. A known stopping distance. When you engage it, you know roughly where you'll come to rest. F1 drivers hit their marks because the car's stopping distance is predictable. An unpredictable brake is one you can't plan around, so you never build speed in the first place.
2. It engages at any speed. A brake that only works when you're already going slow is useless — that's the per-action approval model, which only "works" because the agent was never allowed to move. The brake has to bring a fast-moving process to a controlled stop.
3. It's trusted enough that you don't ride it. This is the whole point. You brake into corners and then get off the brake on the straight. A brake you have to hold the whole way down the hill isn't a brake — it's you, doing the stopping, by hand. Real trust in the stopping mechanism is what lets you take your foot off it and go.

Put those together and you get the actual definition. A brake is a stopping mechanism predictable and trustworthy enough that you'll stop riding it — and that is what unlocks speed. Verification, not generation, is the bottleneck in agentic engineering. The engine was never really the constraint.

Designing the brake, not just the engine

This is the problem Pleach is built around, and the reason we don't lead with model benchmarks. A brake can't be bolted on after the first wreck; it has to be part of the chassis. So the unit an agent works against is a ticket — a bounded, status-tracked piece of work — and the brake is designed into it.

Concretely, a ticket does three things that map straight onto the properties above:

• It bounds the work, which is what gives you a stopping distance. The agent isn't loose in your codebase; it's executing against a scoped ticket with a defined outcome, so "where does this come to rest" has an answer before it starts moving.
• It has checkpoints where control returns to a human. An agent on a Pleach ticket posts its plan before it builds, opens a pull request rather than pushing to your main branch, and runs the tests — and permissions and approvals stay with you at each of those gates. That's the brake engaging mid-motion: a fast-moving process brought to a point where a person can inspect, redirect, or halt it, without hovering over every keystroke.
• It makes the work verifiable, which is what earns the trust. Every checkpoint produces something a human can actually check — a plan to approve, a diff to review, a test run to read, a PR to merge — instead of an opaque hour of autonomous edits you have to take on faith.

That's the organizing principle: verification first. Bound the work so it has a stopping distance, put the checkpoints where a human can engage the brake at speed, and make every step something you can verify rather than trust blindly. Do that and you can finally take your foot off the brake on the straights — let the agent run on the parts that are bounded and checked — because you know exactly where and how it stops.

The engine will keep getting better; that race will take care of itself. The teams that actually move fast with agents will be the ones who built the brake first.