It’s never been cheaper or faster to write code. Engineering teams have moved from shipping twice a week to deploying multiple times a day. PRs take minutes instead of hours, and automated agents generate commits on demand.


The Pace Changed, but the Checks Didn't

It feels like magic. When I talk to engineering leaders, I spot a tension underneath. Creation sped up exponentially. Verification is still built for a slower world.

The stakes are real: Gartner research shows that 81% of executives tie software quality directly to customer satisfaction and revenue. And as the team at Cursor pointed out in their essay on the third era of software development, the math has changed. A flaky test or minor bug that a human developer used to work around now halts an agent run in its tracks.

The core bottleneck in software engineering is how fast we can trust it.

The Gates We Built for a Slower World

Look honestly at the quality gates most engineering organizations rely on today. You'll find a familiar set of rituals: manual PR reviews, a senior engineer eyeballing automated test runs, or someone setting a 4:00 PM calendar reminder to check whether today's test failures "look okay."

When you ship once a day, that works reasonably well. A human can sit down, scan the day's red runs, apply context, and make a decent judgment call. It's tolerable, and it feels responsible.

Why "It's Probably Fine" Stops Scaling

That same process breaks down when dozens of PRs merge each day and code ships to production hourly. For PRs, the human reviewer becomes the bottleneck. When inspecting test failures in deployments, engineers are a barricade. Engineers face an impossible choice: slow development to a crawl, or start rubber-stamping releases to keep things moving.

  • At low deployment volume, organizations survive on human judgment absorbing ambiguity. An engineer sees a test failure, shrugs, says "that's always flaky, it's probably fine," and hits deploy. Occasionally they're wrong, a bug slips through, and the team handles the incident. The cost is manageable.

  • At agentic velocity, that same judgment call happens dozens of times a day. The error rate doesn't stay flat. It compounds. "Probably fine" stops being a pragmatic tradeoff and becomes an unmanaged risk spread across every deploy.

Speed Is a Mindset Problem Before It's a Tooling Problem

When pipelines stall, engineering teams reach for new tools first. Faster runners, better dashboards, AI features pasted onto existing workflows. But tools can't fix a structural contradiction. The real prerequisite for shipping faster is a shift in how an organization thinks about failure and quality.

Stop Tolerating Flakiness

For years, software teams treated test flakiness like bad weather, an annoying condition of software development you just live with.

At high velocity, that habit is fatal. A flaky test is a signal that is very often a symptom of flaky code. And that flakiness compounds: imagine you have 20 tests with an 80% reliability that run daily. That alone is 40 failures to investigate or hope the test is flaky. Modern test suites scale well beyond that, and modern engineering teams are shipping multiple times per day.

The commitment is simple but strict: treat flakiness as a defect in either the test or the application. If a test can't produce a reliable result, you fix it. You don't leave it running in the background to erode team trust.

When a Gate Blocks You, You Stop

We recently had a moment in our own pipeline that shows this discipline. A developer ran into a red quality gate right before a deployment. They reached out to the team asking, "what do I do now?" expecting a workaround or a quick override.

The answer was straightforward: you wait. You fix the issue, or someone helps you fix it, but the team doesn't route around the gate.

If a quality gate can be bypassed whenever it becomes inconvenient, it has become a suggestion. Operating at speed requires absolute gate discipline. True emergency break-glass procedures exist for production fires, but they have to be the rare exception.

Trust the System, Not the Vigilance

The ultimate shift is moving from "a careful human catches problems" to "the system catches problems, and a human handles the exceptions." That only works if you can actually trust the system that checks if it still verifies what it was written to verify.

That sounds obvious until you watch it break down under pressure. When a gate goes red and the deadline is closing in, the tempting move isn't to fix the code, it's to fix the test. The suite goes green, the dashboard clears, and everyone moves on. 

A test that was gutted to pass looks identical to one that was actually fixed. You haven't verified anything. You've just spent your credibility to buy a green checkmark, and you won't find out what it cost you until production does.

This is the discipline that makes everything else possible. When our own production suite drifts red, we triage failures one at a time, and the rule is absolute: no fix ships unless the original assertions are still intact and still testing the intent behind them. A green run earns trust only when it holds across multiple deployments.

It's worth reflecting on why this matters so at agentic velocity. When an agent writes the code and also decides whether its own work passed, "green" stops being evidence. The thing checking the work can't be the same thing that has an incentive to call it done. 
Verification has to answer a harder question than "did the test pass?" — it has to answer "did we actually build what we set out to build?" The discipline of never cheating a check is what lets you trust the system instead of standing over it.

Getting Ready for the Next Phase

That's why mindset comes first. Technology only pays off once the organization is ready.

If your automated checks can't be trusted without a human standing over them, adding more automation will only accelerate the chaos.

In the coming weeks, we'll get concrete about what this looks like in practice. We'll dig into why flaky tests hide deeper code issues, how to block on the right tests without stalling teams, and what independent verification looks like in an AI-first world.