Diffblue Agents

You will like the discipline more than the speed. Nothing survives that fails to compile, fails to pass or fails to add coverage, so what lands in your branch has already cleared three gates before you look at it, and that filter is the deciding trait, because the usual failure of generated tests is volume rather than quality.

Pick it if the work is regression suites over an existing codebase in a language it supports. Pick Qodo when you want tests generated interactively while you write the code they cover.

The dependency is unusual and it is real. This does not do the generation itself; it orchestrates a separate agent platform that you license, configure and update independently, which means a change in that platform's behaviour propagates into a workflow you bought from someone else. When output degrades, the two vendors have every incentive to point at each other, and you own the reconciliation.

What it does right: the supported platforms are named explicitly rather than described as any agent, which is a bounded claim in a category full of unbounded ones.

1. The workflow scopes, partitions, verifies and rolls back, so failed partitions are discarded rather than merged, which is a genuine verification loop and rarer on this board than it should be. 2. The acceptance criterion is mechanical and therefore reliable, and it is also weak: a test that executes a line without asserting anything meaningful satisfies all three conditions.

No benchmark and no study of the resulting suites' defect-detection ability are published. The observation: measuring in covered lines makes the product auditable and makes the metric gameable, and both follow from the same choice.

Charging by output aligns the vendor with the buyer more honestly than any seat price, and it is much harder to run, because the vendor now carries the cost of every failed attempt. A company willing to take that risk is signalling confidence in its verification loop, and the volume packages above the entry commitment suggest the real business is large estates rather than teams.

Likely acquirer: an enterprise platform vendor with a large installed base in this language. Position: durable niche, strong pricing model, and growth bounded by how many such estates remain.

One sentence on the demo: everything it showed me had already been verified, which I appreciated. Then the procurement reality. I cannot trial this without a purchase, so the first conversation is a commitment rather than an experiment, and the language coverage means most of our services are outside its scope entirely. What it does well is fit our pipeline, because it commits verified output and rolls back what fails without a human in the loop.

Onboarding is a week including the underlying platform. Approved with conditions: one language, one service, a fixed commitment.

The arrangement is unusual. The model and the agent doing the work are mine, licensed and configured by me, and this vendor sells the harness that drives them. So the inference stack is under my control while the orchestration is a closed binary I cannot inspect, which inverts the usual complaint without resolving it.

There is no tool protocol here, no local model story of its own, and no source to fork if the company stops shipping. What I would keep in that scenario is the tests it already wrote, which is not nothing and is not ownership either.