The agentic prerequisite

Two teams turn on the same agentic coding tool in the same month. One of them has spent two years actually able to trust a green build. A failing test in their suite means something broke. A passing one means it didn't, no exceptions, no "oh that one's just flaky, ignore it." The other has a test suite that's technically there, green most of the time, and everyone on the team carries a private, unspoken list of which failures to ignore. Six weeks later, the first team is shipping faster with no increase in incidents. The second team is shipping faster too, and quietly accumulating a debt they won't see the bill for until it's large.

Nobody on either team would have described "our test suite's honesty" as the variable that decided this outcome.

It was.

The prerequisite nobody names

Every conversation about getting ready for agentic development is a conversation about the tool. Which model. Which agent loop. How much autonomy to grant. What the rollout plan looks like. All of that matters. None of it matters if the thing sitting downstream of the agent, the check that's supposed to catch a bad change before it ships, can't actually tell a real failure from noise.

A test suite that's mostly honest was always a liability, just a slow-moving one, because a human generating one plausible change a day has time to notice when the suite's crying wolf, and develop the instinct to double-check by hand. That instinct is the actual safety net, quietly, and almost nobody credits it, because it doesn't show up as a line on any dashboard. Take the human out of the generation loop. Let an agent produce five plausible diffs in the time a person produces one. That instinct has no time to operate anymore. The suite is now the only thing standing between a bad change and production, and if it's been lying even a little, agentic development doesn't create that problem. It just finds it. Immediately, at a volume no team was braced for.

What "taking care of your tests" actually means

Not coverage percentage. A team can sit at ninety-five percent and still not trust their own suite, because half of what's covered is a getter checking that it returns what was set on it. What matters is whether a red build is still information. Whether, when something fails, the honest response in the room is "something's actually broken" rather than "which one is it this time, probably nothing."

If that second response is the normal one at your company right now, agentic development isn't ready to arrive at volume. Not because the tools aren't good enough. Because the check you're relying on to catch what they get wrong has already stopped meaning what it's supposed to mean. You're about to ask it to do that job at ten times the pace, unattended, more often than anyone's attention can shadow. Elsewhere on this site that's the same audit, run at the team level, before scaling adoption at all.

The other way a suite lets you down

Flakiness is the failure everyone can name, and it isn't the only one. A suite can be entirely honest, green for the right reasons and trusted by everybody, and still not be checking the thing that takes you down.

An index gets dropped as part of a schema change. Correctness holds, because an absent index doesn't change what a query returns. Nothing fails, because at test-data volume that index was never doing any work in the first place. It reaches production, where the data is large enough that the index was the only thing keeping the query cheap, and the degradation arrives fast.

That change was written by a person and reviewed by a person, and the suite said yes to all three of them. Which is the part worth sitting with, because it reframes the question. Your gate already leaks at the volume one human can produce, with two humans watching. Asking whether it will hold once agents arrive is the wrong question. The real one is what happens to a leak that size when the thing feeding it stops having a working day.

The response that works isn't tightening the review, which is the instinct and which scales nowhere. It's answering one question every single time something reaches production that shouldn't have: what wasn't validated in CI. Name that thing and add the check. The defect is the gap in validation, not the change that happened to find it.

The order of operations, stated as bluntly as I can

Fix the suite first. Quarantine every flaky test the week it's noticed, don't let it sit on a backlog, because every day it survives is another day teaching your team that red doesn't necessarily mean stop, and that lesson is exactly the one you cannot afford to have absorbed the week your review queue triples. Get to the place where a failing test, unqualified, means something is actually wrong, for every test still in the suite. Delete the ones that don't meet that bar rather than tolerating them, because a suite people have learned to partially ignore is worse than no suite at all. A team with no tests knows it's flying blind. A team with a suite it's stopped fully trusting thinks it has instruments and doesn't.

Then keep pruning, because a suite that only ever grows gets slow, and a slow suite gets routed around, which is flakiness arriving through a different door. Remove low-value tests deliberately. Split the runs, parallelise them, get selective about what genuinely has to run on every change. Speed and completeness are the two properties worth maintaining and neither survives neglect. The framing that makes this stick: CI work is a first-class part of an agentic development workflow, not the tax you pay for having one.

Do that work before you scale agent adoption, not while you're scaling it and definitely not after. It isn't the interesting part of getting ready for this. It's the part that decides whether everything else you do afterward is trustworthy or just fast.