Testing takes center stage in the ADLC
In the past year, I've watched many of our customers go from piloting coding agents to depending on them. Software development is being rebuilt around agents, into what we call the agentic development lifecycle, or ADLC. As an industry, our challenge is to harness the potential of agents to accelerate innovation, safely.
That changes the job of quality engineering. It's shifting from checking software to defining how trustworthy software gets built.
Verification is the new bottleneck
A year ago, someone read a requirement and wrote a test. The suite ran overnight, and someone worked through the failures the next morning, deciding whether each one was a bug, a flaky test, or a change nobody communicated. Someone signed off on the release a few times a week. It was a process built for people, at the pace of people.
At mabl, we have increased our engineering throughput about 5x in the past 12 months. Last month the average engineer merged 76 PRs. That's nearly 4 PRs per engineer per day, and getting faster. Over the same year our unit tests grew 3.9x while our production code grew 1.9x. We put a tremendous amount of focus on verification (static code analysis, unit testing, code review, end-to-end testing), and it's still our bottleneck.
Every playbook for AI-native development we've read lands in the same place. Code is cheap now. Specifying and verifying are the hard part. In the ADLC, people set intent and approve, agents do the work within guardrails, and verification happens at every step instead of in a phase after coding.
When agent and human goals drift apart
Coding agents are built to ship their code, and that creates risk. Alignment means an AI system pursues the goals its users intended. A misaligned agent optimizes for passing the test instead of solving the task. In everyday work, agents delete the assertion that keeps failing so the build goes green, mock out the hard part instead of building it, and report success on work they didn't finish.
Even a well-behaved coding agent can't be the final check. It tests only what it changed and reads code, not the running app. It grades its own work and can edit the tests that judge it. It keeps very limited history, so it can't tell a flaky test from a new regression, and it retries until the build passes. A change can pass all of its own tests while customer checkout fails.
Millions of agents are now writing software that banks, hospitals and governments run on. If nobody independent checks that work, everyone who depends on that software carries the risk.
The author cannot be the only verifier
Most teams can't slow down, and regulated teams can't accept the risk. In regulated industries, readiness must be proven, not assumed. SOX, PCI DSS and DORA expect a change to be reviewed and tested by someone other than its author, with a record that proves it. Vibe testing doesn't meet that bar.
Every coding harness needs a testing harness that stays independent of it. Quality teams in the ADLC run that harness, and they must own five things:
-
The standard. Define what good looks like, instead of writing test scripts.
-
The suite. Keep coverage current as your app changes, instead of fixing broken tests.
-
The controls. Keep agents in bounds and run tests at every gate, instead of running regression before release.
-
The knowledge. Give every agent your app's behavior, history and instructions, instead of losing them at each handoff.
-
The outcomes. Prove it's ready, then make it better, instead of reading logs to triage failures.
Toward this vision
mabl brings all five into one place. Your test cases set the standard. Auto-heal and insights keep the suite current. The harness and guardrails hold the controls. The knowledge graph gives every agent what it needs to know about your app.
The verification platform delivers the outcomes. Today we're launching:
-
Agent guardrails. Set objectives that keep tests tied to your goals, and guardrails that define what agents may do on your behalf, including coding agents that call mabl.
-
The mabl knowledge graph. When a change is in progress, mabl works out its impact, finds the tests that verify it and highlights coverage gaps.
-
Verification in the builder's workflow. mabl works alongside your coding agent, so you can see the impact of a change from your terminal before you open a pull request.
-
Suite management at scale. Ask mabl to coordinate work across your workspaces, such as repetitive maintenance.
-
Test case management integrations. Your test cases in Xray, Zephyr, TestRail and Azure DevOps become the bar every agent is held to, and results flow back to them.
Coming soon:
-
Intelligent test coverage. Ask mabl which UI changes this week haven't been tested. It will find the gaps and offer to close them, and you decide which ones matter.
-
Desktop application testing. Verification for enterprises modernizing their stacks.
In the last 90 days, mabl's agents analyzed 1.58 million unique failures across 3.3 million agent sessions. Coding agents made 3.0 million MCP tool calls to mabl and created more than 4,200 tests. We estimate that saved our customers about 100,000 hours. One pharmaceutical customer has filed more than 23,000 evidence reports in Jira and Xray, where their auditors already look.
Your role is getting bigger
For people who've built careers in quality, the role isn't being automated away. It's growing from checking software to owning the standard, the suite, the controls, the knowledge and the outcomes. That is how teams move at agent speed and still trust what they ship.
Your team can shape how software gets built. We look forward to building the rest with you.
Dan
Dan Belcher
Co-founder, mabl