One Friday, when I stopped working, I had 15 open pull requests. When I came back on Monday, I had 66.
I have an AI subscription, and I want to use the available capacity. I often max out my usage windows during the day. I thought I could use the nights and weekends for things I never seem to find time or attention for. I had an agent work through my backlog while I was away.
This was the result.
I scrolled through the list of pull requests. All the PR titles looked reasonable, but I couldn’t manage 66. It probably would have taken an entire day or two to go through the backlog, and I had more important things to do.
I let the PRs sit and didn’t look at them for two weeks.
Then, I asked an agent to go through and do a first cut: what do we actually need to do here? What do you need me to look at? It closed two PRs where there was overlap.
I had it do another pass: what’s critical? Can we close anything that isn’t helping with my priorities? That time it closed 25. About 40 to go.
I still wasn’t getting to it. I asked an agent to do a full review and CI readiness pass and get everything ready for human review. I carved out a few hours, went through the pull requests, and read through their descriptions.
One PR monkey-patched an open-source library because it had a subtle bug. As I looked through the code, I wondered: was this an error I’d seen a couple times? Hundreds of times a day? Was it causing any alarms to go off? If it was important, I’d need to ship it, take on some technical debt through the monkey patch, and upstream a fix.
I closed that PR. It had only happened a couple times, and it wasn’t really hurting anyone.
Ultimately, I burned through the backlog. Sometimes I would decide, even before reading the code, that the change wasn’t necessary. I shipped maybe 10 of the roughly 50 new PRs.
A few times the agent later said to me, “Hey, you’re complaining to me about this issue, but we had a PR for it and you closed it.” In that case, I revived the PR because a need had come back.
These things had been sitting in my backlog because they weren’t important enough for me to look at. And even after they were implemented, they still weren’t necessarily worth my time. They were done-ish.
I like experimenting with AI, but figuring out how to increase quantity without losing my mind from all the open threads has been hard.
Completing something, really finishing it, is tough.
I’ve stopped having agents do generic ticket backlog runs. I’m looking for lower-risk work agents can do in off-hours.
I have an agent keep a gripe list of things that frustrate them. Example: this environment variable’s wrong, or this query needs these arguments. If I can reduce the friction on my agents, then great.
If I don’t like something in my personal workflow, I can undo it. But if I ship buggy code and it affects other people, that’s not cool. Other humans should not be my QA process.
My rule of thumb now is: if I can do research, look around corners, or clean something up behind the scenes, let’s do it. If it’s adding complexity, risk, or long-term maintenance, I should slow down and think about it, particularly if it affects other people.
An ideal Monday morning would look like this: I come in and there are five new draft pull requests, ready for human review. They’ve gone through review passes and QA, screenshots are there, CI is passing. They’re aligned with my priorities and worth my attention.
The agent should help me instead of making more work for me. I’m not there yet.
If you’ve found a way to do this that doesn’t drive you crazy or require going full-send, let me know.