We wanted to know how mabl engineers actually track a PR through CI now, so we polled the team: do you watch the GitHub Actions UI, or just ask Claude in the terminal where you made the change? It came back almost exactly 50/50.

Half the team still opens the dashboard, watches the checks spin, clicks into a red job, scrolls the log. The other half doesn't open the browser at all: they ask "where's my PR, is it green, what failed," and let the agent watch the run and report back the line that matters. Same task, two completely different interfaces, split right down the middle.

So which way does that split move? Is there a lasting place for a dashboard in the dev workflow, something you look at? Or does the whole thing get orchestrated through the chat interface, where you ask instead of watch? I genuinely don't know yet, and I want to see how it evolves over the next few months.

It's not an idle question for us. The answer shapes our own product integration priorities, how much we invest in things you watch versus things you talk to. We'll watch closely in the coming weeks to see how the split shifts internally and across our customer base.

I've been deleting a lot of code lately and I cannot tell you how good it feels. I cleared out about 400 stale translation keys — the kind that accumulate over years and that nobody dares touch, because who still knows what references them? The agent knows; it checks every reference in seconds, so the sweep I'd always filed under "someday" turned into an afternoon. And Eugene and Jeff finally pulled out Bootstrap (BOOTSTRAP! the framework we've been trying to get rid of for years!) — thank you both, truly. I re-ran our UI library market share report afterward and that's when the impact really landed: Bootstrap is finally gone.

What surprised me is how the agents change the math. Migrating class components to function components with hooks, ripping out an old framework, pruning dead i18n — these were always "we should do this eventually" jobs that lost every prioritization fight. The cost of removing code and cleaning up our codebases dropped enough that now we just... do it. I keep catching myself opening diffs hoping they're mostly red.

My ideas used to end up as markdown notes in a folder, which is a polite way of saying they ended up nowhere. Filing a real ticket is more effort than I want to spend in the ten seconds I actually have the idea.

Now I say /new-idea and describe it in a sentence. It interviews me — what's the problem, what does done look like, what's explicitly out of scope — and it stops as soon as the ticket is unambiguous, then files it under my epic and assigns it to me.

At the same time, another session — [on a stable worktree, remember?](https://fab.mabl.com/posts/2026-05-06-dario-i-had-20-worktrees-and-no) — is running /idea-loop. It picks the oldest idea up, moves it to in progress, and we build it: plan, tests, review, PR. From there the ticket walks its own states, and a morning check only marks it shipped once a production tag actually contains the commit.

A PR landed on our CLI with ~550 lines of new probe code. Its entire product effect was one debug log line, and the number it existed to measure was one the PR's own limitations section admitted it couldn't measure. My six-lens /deep-review panel read it and did good work: safer, quieter, better named. Not one of the six asked whether it should ship at all.

The reviewers weren't the problem. Every mechanism in that panel is anchored — a finding needs a file:line, a fix needs a before/after. "This file shouldn't exist" has no anchor, so there's nowhere to file it, so nobody says it. Each lens does the one thing the harness makes easy: improve the code in front of it.

So every lens now returns a scope verdict — ship-as-is, split, or cut — and that gets settled before any fix is applied. Order matters: hardening code that's about to be deleted makes the deletion look expensive. And a cut doesn't authorize anything. The panel rules; I still press delete.

For years the pundits said "data is the new oil," so we hoarded it: API logs, cluster utilization, billing exports, error traces — all in hope that one day we'd have time to actually make use of it. That day is here, and it belongs to the agents. Want to optimize application opex? You could clear your calendar, check into a remote alpine retreat, and spend a week reading the code, the 27-page cloud vendor pricing page, and the 7 pages of "limits" and gotchas — then build a massive spreadsheet crossing all of that with your usage data. But that smells like 2024 thinking. It's 2026: wire up the proper MCP servers and ACLs, offer your agent the code, docs, and data with precise marching orders, and go to bed. Do your vendor's billing docs include set theory notation and lots of linear algebra? Perfect — agents love math. In the morning, review the LLM's citations, pat yourself on the back for saving the operation a few hundred grand — all while you slept.

You're no longer limited by what you know how to do with your data lake, but simply by your own initiative and imagination. LFG.

823 PRs merged across our repos this month. Same 28 days last year: 218. Same number of people.

Everyone got faster once we leaned into the AI tooling, and the review queue got the bill. I stopped being able to keep up with mine, and I don't think I was alone. Writing the code wasn't the slow part anymore. Reviewing it was.

What made review slow wasn't the hard parts, it was getting to them. Most of a big diff is a rename, a function moved between files, a regenerated snapshot. The two hunks that decide whether this ships are buried in the middle of it.

So I wrote /review-with-me. It tells me what the change is for and why, picks the hunks carrying real risk, walks me through them one at a time, and turns whatever I say into inline comments on the PR.