I'm just a meat proxy

I feel like AI-related blog posts should all begin with a disclosure as to how cooked the author is. On a scale of 1 to 10, I'm apparently now at "built a custom software factory and has fooled himself into thinking it actually works." So I guess that makes me an 8 or a 9? Not full-blown psychosis, I hope, but consider yourself duly warned.

My agents are currently shipping 20 to 40 issues a day across the dozen or so iOS apps I'm building. Today, I'm going to show you a bit of my app, MeatProxy, and how it governs my software development process. I'm not going to let you download it (you don't want it, trust me), but at the end of this post, your agent will find instructions for building its own Meatbag Management System.

Over the last year, I've fully embraced my role as a full-breadth developer. Product direction? Mine. Strategy? Mine. Taste? There may be no accounting for it, but… extremely mine.

What about the actual mechanics of staring at an editor, running tests, and debugging software? That's not my role anymore. Programming computers is a computer's job now. Agents plan more thoroughly, code more intelligently, and verify more relentlessly than I ever could. After playing with Fable 5.2 all day, I'm as convinced as ever that we're not going back.

All that said, my involvement is still necessary for agents to deliver work that's any good. Once I've set the product direction, they still need me for three things:

• Only I can explain whatever it is I meant in my own incomplete, contradictory, and otherwise incorrect feature requests and bug reports
• Only I can perform QA tasks the agents can't do themselves. Computer use and vision models still aren't good enough to judge the tactile feel of a swipe action or the subtle timing of an animation
• Only I can dish out sick burns that drip with the requisite invective and paternal disappointment to convey how unsatisfied I am with an agent's work. (Aside: the fact I'm never satisfied with anyone's work, least of all my own, is a real superpower in this new era.)

I alone own the product vision, and so I will always greedily claim for myself every decision that I choose to care about. But when it comes to executing that vision? No thanks. I'm content doing the minimum amount of manual drudgery needed of me until some future harness or model manages to fully replace me in that regard.

As my implementation role has diminished, so has the complexity of my preferred tools. I started with Vim, then VS Code and Cursor for basic AI enhancement, then Claude Code and Codex for a chat-driven workflow, then Paseo for a way to control it all from my phone. I suppose I've graduated into a new level of irrelevance, because I've moved on to a custom app that more closely resembles an e-mail client than an editor.

In fact, no step in the Searls Development Lifecycle (SDLC) requires me to sit in front of a computer anymore. My entire workflow now consists of using my apps like any other user would, filing bugs and feature requests, waiting for my agents to ship builds to TestFlight, and unblocking whatever work arrives each morning in my MeatProxy inbox.

1. In-app issue reporting

Every one of my apps has a "Darn it!" button in its settings screen, thanks to an internal Swift package called darn_it. When I see anything I don't like, a global keyboard shortcut or 4-finger gesture is all it takes to file a quick issue and keep moving.

Most of darn_it's code is there to provide as much context and evidence as possible for the implementing agent:

• Each report includes a rolling recording of the last minute of screen activity and microphone audio, so the agent sees the bug and my narration of it (for the sake of token efficiency, the screencast is converted to a timestamped contact sheet of keyframes and the audio is transcribed and timestamped to match)
• Build identity, device analytics, console logs, and network activity are all automatically attached to each report
• Each app specifies an elaborate-by-human-standards internal URL routing scheme so that bug reports can include a URL that navigates directly to whatever state the app was in, saving the implementer from first clicking through a dozen screens to arrive at the relevant view
• Attachments and telemetry are uploaded to S3 and a GitHub issue is filed against the relevant app's repo

Then I put my phone down and forget about it. The backlog ebbs and flows based on how much I'm using each app in the suite. And because I'm filing every issue in the course of real-world use, none of it is speculative and none of it feels like work.

2. Distributed worker dispatch

So now that my job doesn't involve sitting at a computer, what are my computers doing all day? Well, both my Mac Studio and MacBook Pro spend their time chewing through all those issues I'm filing.

The scheduled jobs in my launchd_agents repo keep the agents busy with everything I ask for and, importantly, everything I don't. Every few days, the apps get a thorough performance, correctness, and factoring audit. Every week, the dependencies are brought up to date. Every night, a different persona performs an interactive exploratory test across multiple apps (and almost always files an issue or two that get fixed before I've woken up).

Each issue I file with darn_it gets a fresh agent:

• Bugs get reproduced first, then fixed, with before and after screen recordings submitted as proof
• Features get built, tested, reviewed, merged, and shipped to TestFlight
• Spikes get whatever research is necessary, plus written findings and recommendations
• Design questions get two or three interactive SwiftUI prototypes to choose from

The biggest unlock was also the dumbest: an iPhone 17 Pro connected to the Mac Studio and an iPad mini tethered to the MacBook Pro, always on and always available for UI automation. Now, when DeviceHub's simulators are insufficient, an agent can install the build on real hardware and check its own work with an interactive WebDriverAgent session.

Whenever I sit at my desk, I get annoyed by all the devices strewn about. Agents will take over the computer while I'm trying to type. Bursts of audio startle me as background copies of my apps start blaring podcasts or TV shows. These disruptions sometimes get on my nerves until I remember that my desk is no longer mine. That's usually about the time I grab my iPad Pro or walk away and do something more interesting with my day.

3. The meatbag in the loop

Each day, 6 to 10 issues get a human label slapped on them because an agent got stuck on something only I can answer. When my direct involvement is needed to unblock the agents, I open MeatProxy and start working through the day's backlog.

Here's a bit of what it looks like:

That middle screenshot deserves a second look. MeatProxy cards aren't limited to images and videos. They can contain real interactive SwiftUI prototypes, too. While apps submitted to the App Store aren't allowed to download and run Swift code, development builds have no such limitation. So for any nontrivial UI feature, the agent builds a few interactive demos and sends them over the air to my dev build of MeatProxy. That way, I'm not just looking at a visual comp or screwing around with a preview in Xcode. I'm actually tapping and swiping through SwiftUI views on physical hardware.

Here's what that looks like in motion:

Daily retrospectives

MeatProxy also grades its own homework. Every morning, an agent reads the last 24 hours of the loop's records (worker logs, my verdicts, what shipped, what got reopened) and writes a retro that quantifies throughput, judges code quality, and tallies what went well/poorly. It picks one or two things to change, then tells me the next morning whether they helped.

Earlier this week, my MacBook Pro sat idle for most of a day. The next morning's retro identified and repaired the watchdog that should have killed the stuck agents that caused the logjam. The loop was fixed before I was aware anything was even broken.

One funny consequence of the increasing capability of coding agents is that I actually expect MeatProxy to shrink in scope over time. Almost everything I do in the app is a silent confession of something the agents can't yet do, but someday might.

While I'd never be able to fit all my opinions into a 1M-token context window, MeatProxy does try to encode my most useful takes as a matter of course. For example, I was repeatedly filing issues against SwiftUI sheets whose buttons had custom text labels instead of the system's standard dismiss and confirm toolbar icons. One day, MeatProxy asked whether I wanted to enforce that convention going forward. I did, and so it was added to a durable ledger that every future reviewer will (hopefully) enforce.

Simulators still fall over, agents still make messes nobody asked for, and I'm almost certainly accumulating a mountain of technical debt a future agent will have to pay off someday. But for the first time since I started working with coding agents, my job doesn't feel like babysitting. It feels like deciding what I want and then getting it. Eventually.

So if you're still parked at a terminal approving diffs one at a time, here's my unsolicited advice: figure out which parts of your job truly need a human, route all of them to one place you can reach from anywhere, and then spend your energy shrinking it. For decades, great programmers have made their mark by eliminating repetitive manual tasks that the computer could be doing for them, and this is no different.

You don't want my app

In the before times, this is where I'd announce that I'd dropped everything, scrubbed the proprietary bits out of these tools, and open-sourced the whole lot so you could file issues and submit pull requests for me to ignore.

But I struggle to see what either of us gets out of open-sourcing tools like this anymore.

The hard part now is figuring out exactly what you need. Building it to fit your exact circumstances is the easy part. MeatProxy is only good because it's custom-tailored to my personal proclivities and coupled to this specific endeavor: every piece encodes something about me and these particular apps, and sanding that down to suit a general audience would only make it worse.

So instead, here's a spec. Hand it to your agent of choice, ask how feasible something like this would be in your case, and take it from there. With any luck, you'll build something that works. And maybe you'll even find the courage to let the agents manage your activities instead of insisting it should be the other way around.