I use Claude with the mabl MCP to create mabl tests. A lot.
New CLI feature? Sure, I write the integration test. Then I also ask Claude to create a mabl test that proves the feature works for real.
This week I'm improving the flow merge page. To work on that page I need a merge conflict, and a merge conflict takes some setup. Create a test with a flow. Branch it. Edit the flow on the branch. Go back to master and change the same flow there. That's a lot of clicking just to reach the screen I want to fix.
So now I type "Claude, use mabl and do that for me!" My job is to fix the merge page, not to make merge conflicts by hand.
Time to optimize your cloud estate. "Ship it" is no longer the end of development.
Dust off the 12 optional optimizations you never shipped because they died in Jira. Feed the fallow tickets into the agent forge. Now is the time for the work we never had bandwidth to do.
Last week, I dusted off an old ML pipeline—long considered too complex to replumb. No problem: select the fanciest LLM model, crank it to MAX effort, and feed it some good ideas.
Flatten and optimize queries? Done.
Materialize all views? Done.
Cache expensive calls in Redis? Done.
Vectorize computations and push down to machine instructions? Done.
Build a comprehensive end-to-end validation harness and suite to ensure these changes break nothing? Check.
OK... 98% cheaper? Pencils down.
It's time to revisit everything you've ever shipped. Juice that lemon until it turns to diamond. Capacity and expertise are no longer the limit. With agent weights and your horse sense, 98% optimization is table stakes.
7 days in a week, 7 days in a token budget. Why is your agent at the beach on Saturday? Think of all the chunky tech debt projects nobody ever has time for. That's what agents are for.
I had an API with hundreds of endpoints, and I wanted to refactor every one of them to a more modern, robust, faster framework. Who has time to rotely refactor controllers and re-validate that _nothing_ broke? Claude does, with a /goal.
The whole thing is unlocked by tests we wrote years ago. Thousands of API-level validation tests and end-to-end suites for the web apps that consume the API — that's the feedback signal a /goal actually needs. "Get the suites green without changing the clients or the interfaces, only the server implementation." That's it. From there our CI does the rest: every PR spins up a deploy preview, fires the full cloud regression suite, and reports back. The agent runs permutations across branches in parallel and validates each one on its own.
While you were at the beach worrying about how much sand your kids would track into the car, Claude burned down a major chunk of the tech debt backlog. LFG.
I rewrote the workspace menu on a branch this weekend, swapping a Bootstrap dropdown for a Material-UI button, and the mabl remote MCP told me — in the PR, before I'd merged anything — that I'd just broken every mabl-on-mabl test that goes through login. The agent walked the chain: get_mabl_deployment surfaced the failing deploy preview runs, analyze_failure produced the root-cause synopsis, and get_mabl_test_details located the offending step. Our "App - Login" reusable flow asserts on a specific selector to confirm the workspace dropdown is present. My rewrite replaced that control with one mabl's intelligent find recognizes natively — so the right fix is to delete the brittle assertion and let intelligent find do its job. The agent proposed both: a one-line backwards-compat id to unblock the PR today, and a follow-up to clean up the e2e flow at leisure. Ten seconds in context. I'd have caught this at deploy time without the MCP; I caught it while I was still in the diff.
I've been thinking about where verification belongs in an agentic pipeline. The shape I keep coming back to is a quality validation sub-agent that runs before PR submission — its job is to come up with and verify a validation plan for the change, including running the relevant mabl tests, capturing evidence, and attaching that evidence to the PR. Then the PR review agent enforces the existence of the validation plan, not the rules underneath it. Then the full mabl suite runs on merge, and when something breaks, a failure-analysis skill identifies which PR introduced it and suggests fixes.
The reason for that structure: at our throughput, "did the engineer remember to validate this" is the wrong question. The right question is "does the PR carry evidence that validation happened, and does the evidence hold up?" Sub-agents do the validation; the review agent checks the evidence; the merge gate trusts the chain. None of the layers is doing checklist work — each one has a specific decision to make. Most teams that try to add AI to their existing CI/CD end up with checklist agents because that's the shape of CI/CD. I don't think that's where this lands.