A few times a week, someone pings me asking why an agent did something weird. The most recent was a teammate asking why our test authoring agent reached for a custom XPath selector unprompted. I didn't know and had to dig — when I did, the reasoning trace explained it. The choice looked odd from outside the session but was a coherent reaction to a failure earlier on.

I keep seeing this pattern with the coding agents I work with day to day, too. Decisions that look bizarre in isolation almost always have an internal logic once you read the thinking that led up to them, even when the decision itself is still wrong. Reading the trace is how I tell which kind of weird I'm looking at — a principled-but-incorrect step, or something actually broken.

What's worked better than trying to talk an agent out of its defaults has been to figure out what it's already inclined to do and shape the system around that, so the weird move isn't warranted in the first place.

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.