I’ve largely automated the process between a user submitting a bug report for any of my apps to the fix going live on the App Store–and any related support and marketing materials being updated. I’m involved at several points along the way as a reviewer/editor/approver and ultimately the responsibility for the output of the process still rests with me, but much of it is done by AI.

I think many jobs will look like this sooner or later.

That’s it. That’s the post. If and only if you’re interested in all the gory details, read on. But I warn you: it gets pretty dry from here on out.

OK, you were warned.

I have a new process for building Overflight App Store releases and it’s quite insane. This morning I woke up to an interesting Slack notification:

🐛 supportbot: suspected new bug — overflight: “Overflight problem report” — filed https://github.com/cwooddgr/overflight/issues/8

You see, supportbot is my AI-powered bot that reads all email sent to support@dgrlabs.co. It analyzes the body of the email and any attachments, including the debug logs automatically included in Overflight and CD Wally problem reports, and drafts a reply. (It never sends anything itself.) And if it looks like the user has actually found a bug, it also files a GitHub issue with its own diagnosis (and the debug log attached) and posts a notification like the one above to Slack.

First I lightly edited the draft email reply to the user, promising a fix soon, and sent it.

Then I fired up Claude Code and told it to look at the most recent issue. It agreed with supportbot’s findings and went to work on implementing a fix. It tested the fix, tested the whole app for regressions, found none, and committed the fix to Git.

So far so amazing. But wait, there’s more.

I wanted to get this fix out ASAP as I had promised the user, so I told Claude Code to cut a new App Store build, v1.5.1, for both iOS and Apple TV. (It also picked up a few small fixes that had already been queued since 1.5.) And since it was a minor bug-fix release, it should keep the “What’s New” content, both in the App Store and in the app, the same as v1.5, but add a “Minor bug fixes” bullet point.

Claude Code made the changes, archived and uploaded new builds for iOS and tvOS, created the App Store version records, attached the builds, and submitted them for review through the App Store Connect API. It also wrote up a factual inventory of everything that had changed since the last App Store build. Then it kicked off new Claude Code sessions for supportbot and for marketroid (my bot that handles all marketing) and handed each of them that inventory so they could update their own materials.

Supportbot did two things. First, it immediately added the bug to its live knowledge base, marked as known and fixed in v1.5.1, pending App Review. That way if anyone else reports the same bug on v1.5 it will tell them a fix is on the way rather than filing a duplicate GitHub issue. Second, it staged a second set of updates, covering the new behavior in v1.5.1, to be applied only once the release is actually live.

Marketroid looked at the inventory, checked it against the website and press kit, and decided it didn’t need to change anything, which it recorded as an explicit “no marketing changes” verdict. If it had needed to update any content on the website–including screenshots, screen recordings, and the zipped up press kit–it would have authored those changes and staged them too. Same for any other marketing materials: feature/benefit lists, messaging pillars, brand voice, and so on. The one rule is that nothing marketroid stages goes public without my sign-off, so Claude Code showed me the no-op summary and asked for approval, which I gave.

Finally, Claude Code switched on a cloud routine that checks the App Store once an hour until the new build is live. The moment it is, the routine applies supportbot’s staged updates to the live knowledge base, flips the known-bug entry to “fixed, please update your app”, applies marketroid’s approved changes to the live site, sends me a message on Slack, and switches itself off. If I had forgotten to approve the marketing changes, it would keep nagging me in Slack every hour until I did.

In the future I might automate the step between the GitHub issue being created and the fix being coded. Right now it’s manual: I fire up Claude Code and tell it to look at the most recent issue. That could be optimized so my only role is reviewing the issue and the already-coded fix, and approving or rejecting it, plus reviewing anything customer-facing.

The moral of this story is that I suspect a lot of jobs are going to collapse into this kind of reviewer role. At least until rejections become unheard-of, at which point there will no longer be a need for a human in the loop, unless it’s only to have someone to hold responsible when something inevitably goes wrong.