Anthropic's engineering team just published a firsthand account of what agentic coding does to CI: job volume up 25× in six months, and a homegrown test-selection service that broke three times on the way. Buried in the middle is one sentence that names, without naming, an entire market:
"This isn't an uncommon practice, and there is a category of vendors with offerings in this area."
— Anthropic Engineering
We are that category. Deterministic test selection trained on your own build and test history, run as a managed service, with flaky test detection built in: that is Predictive Test Selection (PTS). Organizations running PTS today skip a substantial share of test execution time per change, typically on the order of 25-50%, while still catching nearly all test failures. See how Netflix uses PTS to save test execution time.
This post isn't a retelling of Anthropic's article. You should read the original; it's an informative piece on Anthropic's strategy for scaling its CI infrastructure. The short version is that maintaining it is expensive, even for Anthropic. Their homegrown service kept breaking, and each fix held for less time than the one before: 70 days, then 29, then less than one day.
The question their article leaves on the table for everyone who isn't Anthropic: they proved test selection is now mandatory at agentic volume, and they proved what it costs to build and maintain your own. Which side of that trade are you on?
Predictive Test Selection works based on the following:
Test history. Selection quality is a function of the depth and fidelity of per-test history across every branch, toolchain, and module. PTS trains on your own build and test history captured by Develocity, and that history compounds from the day capture starts.
Test flakiness. A test that fails and then passes on identical inputs is noise. If your selection layer can't tell the difference, the selected flaky test that fails will block your PRs while not providing any meaningful signal, exactly as Anthropic experienced. Develocity's flaky test detection becomes an input to Predictive Test Selection, reducing incorrect selections.
Observability. Every selected or skipped test links back to a Build Scan®: full inputs, environment, failure classification, attribution. When an engineer or agent asks why a test was skipped, the explanation is captured in the published Build Scan.
If you choose to build a test impact analysis service yourself, that is only one side of the coin. The other side is the maintenance cost, which never ends: running it day to day, fixing it when it falls behind, and re-architecting it each time volume grows another order of magnitude. That is headcount committed indefinitely to a system that isn't your product; at Anthropic, "no one wanted to own another piece of infrastructure." With Predictive Test Selection, that development and maintenance bill is handled by Develocity.
At 25× job volume, this isn't a nice-to-have decision. It's the difference between a CI bill and a CI crisis.
The article closes with advice we would give verbatim: "Whether you build or buy, assume your architecture will be at a 25x load within two quarters."
Buying gets you there faster than building. Predictive Test Selection handles test selection for you, trained on your own history, with flaky test detection built in. Behind it sits rich Build Scan history, which you can serve to your agents.
When every test is run for every change, "CI gates get increasingly long, expensive, and untrustworthy." Three questions for engineering leadership:
- Expensive: How much CI compute was wasted last quarter executing tests that had no chance of failing for the change they ran against?
- Long: How many minutes do your developers and agents wait for tests on CI before every merge and locally on every iteration? What does that look like at 25× the volume?
- Untrustworthy: When a build goes red, do your developers and agents believe it, or just rerun it? How many of last quarter's red builds were flaky tests?
Every one of those is a line item that Predictive Test Selection and flaky test detection were built to address.
Anthropic wrote the process manual for the AI-native software development lifecycle (SDLC) in August. In September, they published what it costs to build one line of that infrastructure yourself. Both documents point in the same direction:
Verification is the new constraint, and the organizations that treat it as a product, built or bought, are the ones whose AI velocity will scale.
Develocity's Predictive Test Selection, flaky test detection, and Build Scan data form the verification layer for AI-era software delivery.
