mabl has written the clearest short argument for separating the agent that writes code from the system that checks it. In What Is Agentic Development?, the test automation company defines an agentic development lifecycle in which agents “carry approved work across those stages, respond to feedback, and escalate decisions that require human judgment,” and then names the problem that follows: “A coding agent may also help generate the tests used to assess its work. That creates a structural trust problem. The author cannot be the only verifier.”
There are no figures in the post, which makes it easier to read on its merits. The risk list is concrete and honest: overconfidence, where “an agent may report success while important work remains incomplete,” completion bias, validation lag, excessive access, incomplete product context and weak traceability. The worked example is small and right: an agent adds a checkout field, an API test fails because the service rejects the new field, the agent adjusts and reruns, and a person approves. The vendor part is the remedy, mabl’s Active Coverage and Deep Quality Context as the independent signal. The principle survives without the product: governance defines what an agent can do, testing verifies what it did, and they should not be the same process.
The catalog shows mabl exposing the surface an agent would need to call that independent check. The Mabl provider page lists 11 API pages, and the post’s workflow maps onto them: the Mabl Test Runs API and Mabl Tests API for running checks, the Mabl Deployment Events API for wiring them into CI/CD, the Mabl Issues API for failures, and the Mabl Credentials API for the access boundary the post warns about. The mabl agentic access profile counts 36 operations, 18 of them acting. The post names MCP servers as part of the stack, and the catalog has the MCP server dimension lit.
mabl scores 28.4 on the Kin Score, thin band. Discoverability is 66.7 and contract quality 48.7; contract governance is 0.0, access clarity 15.8 and operational transparency 10.5. Agent Readiness is 30.1, agent-ready, with spec presence, MCP server, rate-limit signal and protected resource metadata lit, and error semantics, idempotency and reversibility unlit. That is the tension worth naming. mabl’s own risk list is about agents that report success when they have not succeeded and teams that cannot reconstruct what changed. Error semantics and reversibility are exactly how an agent calling a test platform learns that a run failed and what it can undo. The argument is sound; the record has not yet measured mabl’s API living up to it.