Stop Making Claude Do the Work

The Tar Pit

My journey into all this had to do with managing PRs for a group of engineers. The ask seemed simple, at first: keep an eye on any languishing PRs. Poke folks if they’re assigned to a PR that hasn’t gotten any movement in a few days.

Simple. A GitHub filter, done. Annoying, but not a big part of my morning.

Then leadership got involved. They wanted to know average time in PRs, how often they languished, who was not picking up reviews, all sorts of information.

Sure, let’s make a shared spreadsheet in Google Sheets. Leadership loves spreadsheets (spoiler alert: I love spreadsheets, too. Not in a weird way, they’re just great).

The morning burden grew. GitHub lacked some of the nuanced filtering I wanted, but it was good enough. I could make up with time what the tools didn’t provide.

Around that time, we had a mandate handed down to use our AI tools. This seemed like a good testbed. After a bit of back and forth with Claude, I was able to wire up some MCP servers and get Claude looking at our PRs. It would do the more nuanced filtering I wanted, and spit out some data.

In the mornings, I’d run the process and paste the results into the Sheets.

Ah, even better! I could tie in another MCP for Google Sheets, and now it’s all handled automatically. No more cut-n-paste.

Now Claude was fetching data from GitHub, putting it into a shared Google sheet, showing me lists of languishing PRs, and it was all getting lost in the noise of other morning tasks I had it running.

It didn’t matter. In the mornings, I’d review the spreadsheets so that I could go hassle some folks. Easy.

It was fine.

Complexity began creeping in. Team members changed, certain PRs became exempt, other emergency PRs had to be fast-tracked. There was a difference between PRs that had been picked up vs. those that had never even gotten a reviewer assigned. And what if the reviewer had to be someone off-team? Or if it was a priority fix, that had to jump the queue to a subset of reviewers? The process continued to grow.

The data started to get away from me a bit, but Claude would merrily chew on my request every morning.

But it was getting slower, more chaotic. It was gobbling up more and more tokens, which seem to increase in usage no matter what model I chose or where I set the thinking level.

Worse, if I didn’t watch it closely, it started to get helpful.

It would rearrange data on my spreadsheets, pull PR data from other teams, ooze into the ticketing system to pull “corroborating data” that I never asked for. And always, the constant ping of permission requests.

Claude wanted to keep expanding the scope of its work. It kept forgetting things. It would, occasionally, wander off into happy fields of completely unrelated tasks and start picking daisies.

I built skills to try and hammer things back into line, and that helped, but my process was becoming heavier. It got flakier, losing track of my preferences, of the way I’d been doing things. I started looking at agents and subagents and the expanding spiderweb of complexity.

Then one day, I was digging in a little and my stomach dropped.

The data was wrong.

It’d been wrong for weeks. Subtly, but those inaccuracies had compounded, grown, spidered out into the furthest reaches of my workflow. In reports to leadership. In confident assertions I’d made in Slack.

I sat back, staring blankly at the reams of output Claude was throwing across my monitor. Maybe the Amish were not so far off the mark, after all.

All of this stuff was supposed to help.

I’d walked into a classic tar pit: I used a single tool for all my needs. As a veteran developer, I knew better than that. I should have, anyway.

Fortunately, there was a way out.

More Automation Doesn’t Mean More Claude

Stop using Claude, duh.

The solution was easier than I’d ever realized, and I felt a little dumb once I figured it out. Just stop using this stuff. But the expectations of reporting and speed of surfacing stuck PRs were set now. I couldn’t go back to manual data.

I couldn’t not automate this stuff.

But as it turned out, I could.

One Million Tiny Scripts

I love little shell scripts. They’re super-handy and give me exactly what I need, when I need it. They’re fast and focused.

Unfortunately, a well-written shell script looks like a mechanical keyboard came out on the losing side of a fight with an industrial blender. They’re hard to write, hard to reason about, and easy to screw up.

Worse, you’re never quite sure if the hours you spend tweaking and debugging a script were a net time savings. Especially when you start tripping across bugs, or your process changes and you have to start tweaking bash code you wrote six months ago.

You can move to a better scripting language like Ruby, which helps a lot, but introduces its own problems and largely doesn’t fix the issues, it just pushes them further down the line.

If only there was some kind of system that could write little scripts quickly and easily–

Ping. (sound of light bulb going off over my head)

Don’t try to make Claude do the work. Make Claude build the tool that does the work.

I took an afternoon and broke down my PR tasks into discrete parts: fetching the GitHub data, pasting data into a Google sheet, surfacing languishing PRs, and poking folks about them in DMs.

I had MCP servers set up to talk to these systems. Claude could get to all of them for me. But if they had MCP servers, then they also had APIs.

I quickly had Claude knock together a few scripts. One to fetch PRs for our team within a given time frame. One to feed a specific format of data into a spreadsheet. One to list out languishing PRs. (Sending Slack messages I kept for myself–I still like to eyeball the list of PRs so that I keep up with what’s going on).

Now Claude couldn’t color outside the lines. The scripts only return a specific set of data. If it can’t put it in the spreadsheet, it catches itself and figures out what it did wrong. If it can’t get the PRs, it checks into why and lets me know.

There were several rounds of refinement. I didn’t realize some of the nuances and contradictions I had been missing, but they cropped up as we worked through the scripts.

It was the agile process strapped to a rocket ship.

I’d look at the result, request a tweak to the data or the format it returned, ask for more calculations, and before long, I had a series of scripts that handled my PR routine for me.

Now, I have Claude run the scripts in the morning. It still tries to be helpful, and honestly, it is. When GitHub has a hiccup, it’ll try again, or check GitHub’s status and let me know their API is down.

All that, and I didn’t have to dig into the details of GitHub’s or Google’s APIs. I didn’t have to fight with their bugs or confusing, out-of-date documentation or service disruptions.

My morning routine narrowed from an hour or more to a few minutes. Leadership still gets the information they want, I’m more confident in the data, and I’m saving tokens for stuff that matters more.

The process still changes, and when it does the scripts can’t pivot like Claude can. But when there’s a shift, I go back to Claude, and in a few rounds of prompting and testing, my scripts are once again aligned with the latest process.

And the next morning, I have spreadsheets I can trust, generated by code I can read.