Your Agents Are Fast. Your Guardrails Are Not.

Coding agents stopped being autocomplete a while ago. They now clone repos, edit files, run tests, and rewrite languages. The speed is real. The problem is that the checks around them still move at human pace. Let me catch you up on what changed this month and what it means for the way your team ships.

Eleven days that used to take a year

Bun, the JavaScript runtime, moved its whole codebase from Zig to Rust. That kind of migration usually eats one to two years. With an AI tool called Fable, it took 11 days and about $165K. Read that again. A rewrite that would have owned a roadmap for a year got done in under two weeks.

Before you get excited, note the fine print. Bun pulled this off because the project was thoroughly tested. The tests were the thing that let the agent go fast without breaking everything. No test suite, no safety net, no 11-day rewrite. The speed came from the guardrails, not around them.

So the lesson is not "agents are magic." It is that your test coverage is now the ceiling on how fast agents can safely work in your codebase. If your tests are thin, that is your real bottleneck.

The blast radius nobody planned for

When agents work this fast, they hammer your infrastructure too. Thomas Dohmke, the former GitHub CEO, built a whole startup around this. His company Entire calls it "the strain of billions of agents and developers hammering a central server", showing up as rate limits, latency, and outages.

Entire's answer is a distributed network that mirrors your repo so agents pull from a faster, closer copy. It raised a $60M seed, which Felicis called the largest ever for a dev tools startup. You do not need to buy anything today. But the signal matters: the load your agents put on shared systems is a real line item now, not a footnote.

Ask your infra lead a plain question this week. If agent traffic doubles, what breaks first? If nobody knows, that is the gap.

The record of who did what

Here is the part that hits product teams. When an agent writes code, do you know why it made each choice? Six months later, when something breaks, can you trace it back? Dohmke's team is betting you can't, which is why Entire stores the agent's reasoning right next to the code, with tools like Entire Blame that trace a line back to the agent conversation that produced it.

His line is worth repeating to your team: "Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code." That is a design decision, not a tooling one. If your agents leave no paper trail, your team is shipping code nobody can explain.

Let it write, make code enforce the rules

The cleanest pattern this month came from Hugging Face. They went from releasing every 4 to 6 weeks to once a week, using an agent to draft release notes. The trick is what they built around it. A script pulls every PR in the release and saves it as ground truth. The model drafts. Then code checks the draft against that list for anything dropped or invented, and hands mismatches back to the agent to fix.

They call it "a non-deterministic model wrapped in deterministic guardrails." The model writes prose. Code enforces the facts. A human reviews only the last mile, turning a half-day of writing into a 15-minute edit. Cost per release: about $0.25.

The same shape works in your product flow. Let agents draft. Let hard rules catch what they get wrong. Put the human at the one spot where judgment actually matters, not everywhere.

Two modes, one habit

The OpenCode setup makes the guardrail concrete for anyone running an agent daily. It has two modes. Plan mode reads everything and can change nothing; the editing tools are physically off. Build mode has full powers. You read the plan first, like a suspicious landlord reads a lease, then approve.

That read-approve-build loop is the whole game. A model with edit powers and a vague prompt is fast, confident, and wrong in bulk. Reading a plan is a question your team can actually answer before any file gets touched. Make that the default for anyone letting an agent near production.

The deep cut

The teams moving fast are not trusting the agent more. They are trusting it less, in a specific way. Bun leaned on its test suite. Hugging Face leaned on a script that checks the model against ground truth. OpenCode leans on a plan you approve before edits happen. In each case the agent got faster because a dumb, deterministic check sat between it and the damage.

So the move on Monday is boring and it works: find the one place in your product flow where a wrong agent output would hurt, and put a hard check there before you speed anything up. Speed follows the guardrail. It does not come before it.

Three questions for your team

1. If an agent rewrote a core service tomorrow, would our tests catch the breaks? If not, what coverage do we fix first?
2. Can we trace any agent-written line back to the prompt and reasoning that produced it? Where does that record live today?
3. Where in our flow does a human review right now, and is that the spot where judgment actually matters, or just where we always put a person?