Last Tuesday I spent three hours designing a label taxonomy for routing production errors into the right Jira buckets automatically. The week before that, I built a plugin that generates worklogs from git commits so I never have to fill timesheets again. This morning I'm writing this article.
A year ago, those three hours would've been spent chasing a config bug across four tenant databases. The week before that would've been manually copying error details from Sentry into Jira tickets. And writing? Not a chance.
Something shifted. Not in what I'm capable of — in what I'm asked to do with my day.
The Treadmill
I maintain a multi-tenant platform that serves about a hundred small businesses. Each has its own database, its own edge cases, its own way of breaking things on a Tuesday afternoon. For years, a significant chunk of my week looked like this:
Tenant reports a bug. Open Sentry, find the trace, cross-reference with the tenant's database, figure out which config value drifted, fix it, test across affected environments, push, confirm with the tenant. Repeat. Some days that was the whole day.
The work wasn't hard. That's the point. It required my context — I knew the system, the tenants, the patterns — but it was the same problem over and over. Necessary work. Real work. But repetitive enough that it filled the day by itself, and the other kind of work — architecture, tooling, product thinking — got squeezed into margins. Late nights. Weekends. The couch at 11pm.
I kept telling myself I'd get to that stuff once things calmed down.
Things never calmed down.
What Changed
AI coding tools didn't replace my job. They made the repetitive half fast enough that the other half finally fits in the day.
The shift happened gradually. First it was small — generating boilerplate, writing tests I'd been putting off, drafting PRs for straightforward changes. Fine. Useful. But not transformative.
The real change came when I started trusting the tools with the context-heavy but cognitively simple work. The kind where 80% of the effort is understanding the situation and 20% is the fix. AI is surprisingly good at that ratio — give it the right context and the execution is reliable. I don't hand-hold config changes across tenant databases anymore. I describe the pattern, point at the right files, review what comes back.
That freed up something I hadn't had in years: uninterrupted blocks of time for hard problems.
The Work That Was Always on the Backlog
Here's what my weeks look like now. I'm building an orchestration system for how AI agents work on my codebase — not just prompting, but structured workflows with recon phases, planning phases, review gates. I'm designing error routing pipelines that turn raw Sentry noise into contextualized, actionable tickets without me in the loop. I'm writing about what I'm learning.
This isn't a productivity hack. It's a shift in what my day looks like. The bugs still get fixed — faster, actually, because the tooling around them is better. But now there's room in the week for the work that used to get postponed indefinitely.
And the irony is that a lot of that work is building the tooling that handles the repetitive stuff. The loop feeds itself.
The Honest Part
I want to be careful here because this narrative has a seductive version that isn't true. The seductive version: "AI does the grunt work, I do the thinking, everything is better." Clean and flattering.
The real version is messier. Some of that "boring" work was how I stayed close to the system. Chasing bugs across tenant databases taught me patterns I wouldn't have seen otherwise. There's a real risk of abstraction — of building a layer between yourself and the details, then losing the intuition that made you effective in the first place.
I don't have a clean answer for this yet. What I do is review everything that comes back, and I make sure I still read raw error traces regularly even when I don't have to. It's a discipline, not a default. The tool wants to abstract. You have to choose not to let it abstract you.
The Meta Layer
This post was written the way I described in the first article — a brainstorm conversation that turned into a structured brief, then a focused writing session. Except this time, the writing session itself was collaborative. I described the thesis, laid out the beats I wanted to hit, and Claude helped me draft it. I edited, pushed back, restructured, rewrote the parts that sounded too clean.
Same pattern. Creative intent is mine. Execution is shared. And the thing that makes it work is the same thing that makes the code work: I know what good looks like, so I can steer. The tool is fast. Taste is the bottleneck. Not typing speed.
A year ago I wouldn't have had time to write this. Writing is hard — same as coding, same as anything worth doing well. But the real problem wasn't skill. It was that the calendar was full of work that didn't need a blog post — it needed a patch and a deploy. Now the patch gets handled and I get to think about things worth sharing.
That's the real shift. Not doing more. Doing better.
— Mariano, building at brolio.dev