Picture this. You lead a small team, and your coding agent has just told you the checkout work is done. It added a new field, wrote the tests, ran them, and reports success. You are about to approve it. Then a question stops you: who checked the agent's work, if the agent also helped write the tests?
That is the question mabl, the test automation company, puts at the center of a post called What Is Agentic Development? It describes an agentic development lifecycle in which agents "carry approved work across those stages, respond to feedback, and escalate decisions that require human judgment." Then it 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."
The post has no figures, so you read it on its merits. Its risk list is concrete and honest. There is overconfidence, where "an agent may report success while important work remains incomplete." There is completion bias, validation lag, excessive access, incomplete product context and weak traceability. Any one of these could be sitting behind your "done" message.
The worked example is small, and it matches your situation. An agent adds a checkout field. An API test fails because the service rejects the new field. The agent adjusts and reruns. Then a person approves. The failing test is the independent signal, and the human decision comes after it.
The vendor part is the remedy. mabl offers Active Coverage and Deep Quality Context as that independent signal, and that is a vendor's pitch. The principle holds without the product. Governance defines what an agent can do, testing verifies what it did, and they should not be the same process.
So you check whether an agent could call that independent check. The APIs.io catalog shows mabl exposing the surface it would need. The provider page lists 11 API pages, and the post's workflow maps onto them. The Mabl Test Runs API and Mabl Tests API are for running checks. The Mabl Deployment Events API is for wiring them into CI/CD. The Mabl Issues API is for failures. The Mabl Credentials API is 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.
Here the story turns, and the turn is about mabl's own record. The catalog scores mabl 28.4 on the Kin Score, in the thin band. Discoverability is 66.7 and contract quality is 48.7. Contract governance is 0.0, access clarity is 15.8 and operational transparency is 10.5. Agent Readiness is 30.1, labeled agent-ready, with spec presence, MCP server, rate-limit signal and protected resource metadata lit. Error semantics, idempotency and reversibility are unlit.
That gap matters to you. mabl's own risk list is about agents that report success when they have not succeeded, and about 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.
What you take away is practical. Do not let the agent that wrote the change be the only voice saying it works. Keep a separate check, and keep a person at the approval step. When you pick that separate check, look at more than the pitch. Ask whether its API tells an agent clearly when something failed and what can be undone. mabl makes the case for independent verification well, and the catalog shows where its own API surface still has to prove it.
Read the original: https://apis.io/2026/10/27/mabl-says-the-author-cannot-be-the-only-verifier/