To Be a Meat Proxy, or Not to Be

Niklas Gruhn's advice is don't be a meat proxy. I have spent a couple of weeks trying to work out whether I already am one.

A meat proxy, in Gruhn's coinage, is the person who takes what an AI wrote and forwards it, unread, into Slack or a pull request. The cost of checking it doesn't disappear; it lands on whoever is next, now with a human name attached. Simon Willison passed the phrase along the same day, and the cure he quoted is hard to argue with: "Read it, understand it, validate it, and then write a response in your own words."

By that test I should be fine. I read what the AI gives me. I rewrite most of it. The catch is what I do with the rewrites. Every edit becomes a rule, every rule goes back into the tool, and the next draft needs a little less of me. I have been building, quite deliberately, toward a draft I won't need to touch. Models get better on their own; I'm also sanding this one down to my taste. At some point a draft will come through and I'll pass it along as-is. Is that the day I become a meat proxy? Or did I become one the day I started optimizing for it?

I wanted a rule. Not a feeling, a line.

I used to have a ruler

For most of my career the ruler was open source. When I needed to know whether I was becoming a decent engineer, I read other people's code and kept what I liked. My GitHub Gist is a record of that habit: a note on getOwnPropertyDescriptor next to Andrei Broder's paper on near-duplicate documents, next to an MIT thesis on simhash. I was trying to build a small searchable data center of my own back then, and thinking about deduplication on write and how metadata should hang together. It's the same itch as the life-sized archive I wrote about last week; it never really went away. The habit of clipping ideas and measuring myself against them stuck, and so did the knowledge, which resurfaced years later in real products full of files, images, and databases.

Architecture worked the same way. The service layer itself was often open source, so you could see which shapes people chose and where they drew their lines. None of this was objective. A style that was right for one team was wrong for another. It didn't matter, because I could say why I wanted to be shaped that way, and the "why" came from something I could look at.

That's the part that broke. I tried to do the same thing with AI: look at how other people use Claude, where they delegate and where they step in, and place myself on that map. There was nothing to clip. The finished artifact is there, but the artifact no longer carries the process. You can't tell from a file how much of it a person read or what they refused. Whatever the human changed and whatever the model produced come out the same color.

Open source has rules now. It doesn't have examples

I went back to open source to see whether projects had drawn the line for me.

They've drawn a lot of lines. The Linux kernel's guidance on coding assistants wants an Assisted-by: trailer on AI-assisted patches and reserves Signed-off-by for humans, in capitals: "AI agents MUST NOT add Signed-off-by tags." A sign-off is a legal certification and only a person can give one. Ghostty's policy is blunter: "If you can't explain what your changes do without the aid of AI tools, do not contribute." The maintainers add that they use AI daily. The problem is people, not tools.

There is a whole catalog of these policies. Some projects ban AI outright (Zig, Gentoo, GIMP, Servo). Some require disclosure (the kernel, LLVM, curl, Django, Kubernetes). Some leave it to you (CPython, Rust, uv, Ghostty). Read the permissive ones closely and they collapse into a single sentence: you have to be able to explain it, you have to be responsible for it, and it has to be worth more than the time it takes to review. A study of a thousand popular repositories found 118 with an AI policy; 74 percent of those require a human in the loop, and almost none say how much human. Nobody has a measurable threshold. They are all standing where Gruhn stands: did you read it, and will you answer for it.

So the thing I was looking for wasn't there. What open source has produced is thresholds, not models. Plenty of "don't do it like this," nothing that shows "this is what doing it well looks like." Even Assisted-by: records who used a model, never how.

I found one exception. Cloudflare's workers-oauth-provider kept every prompt to Claude in the commit log: "Have Claude write an OAuth provider implementation," "Ask Claude to fix its bugs," "Ask Claude not to store clients_list." Then someone read all of it and wrote up what he learned, the way I used to learn from a repository. That's the only place I've seen it happen, and it happened because one engineer chose to leave the process in view. No rule asked him to.

The question flipped on me

With no external line to stand on, I looked at my own loop again. The first post or two on this blog I handed to the model whole. What came back meant what I meant and sounded nothing like me: wrong tone, wrong sections, wrong flow. So I rewrote them, wrote down the differences as rules, and turned the rules into a skill. No em dashes. No bold. One everyday metaphor, carried all the way through. I keep tuning it, and after taste I intend to add something harder: how I want problems diagnosed, because I am the kind of person who needs to know what a bug grew out of, not just how to make it stop.

And that's where the question turned over. The better the skill, the less I fix. The less I fix, the less I read. If a meat proxy is someone who doesn't read, then I've been training for the job. The question I started with was "am I a meat proxy?" The one I ended up with was "am I trying to become one?" Followed, a beat later, by a third: would that be so bad?

The kernel didn't evict the proxy. It put a signature line on it

Half the answer was already in the kernel doc. The kernel doesn't require that a human wrote the code; a model may have written all of it. It requires that a human sign and be answerable. That is an instruction to be a meat proxy with a signature. The kernel left the human in the proxy position and added accountability to it. Gruhn's meat proxy passes things through and takes no responsibility; the kernel's contributor passes things through and takes all of it. Same chair.

So the question needed one more turn. Not whether to be a proxy, but which kind. To an engineer the word was never an insult. A transparent proxy forwards whatever arrives. A reverse proxy terminates TLS, inspects headers, rate-limits, and refuses bad requests. It does not read every byte of the body. It checks at the layer where its policy lives, and nobody calls it lazy.

That picture cut the wire my anxiety was running on. Reading less isn't the failure. The questions are which layer you read at, and whether you can still say no. My skill checks the sentence layer. I check thesis, narrative, and diagnosis. If a rejection can still happen up there, I'm a proxy with a policy. If everything flows through untouched, I'm a transparent one, which is the thing Gruhn named. It's the mirror of what I argued in the hejbro post: we don't trust the AI, we build structure that makes its mistakes cheap. There, the structure absorbed the model's errors. Here, the structure keeps the human in the reader's seat.

A log of refusals

To stay in that seat I built something small today. Every time I reject what the AI proposed, a diagnosis, a narrative, a title, I write one entry: what it offered, why I said no. The skill teaches the model to imitate me; the log makes me keep reading. How much I edit is no longer a useful number, since edits are supposed to fall as the skill improves. Whether refusals still happen, and whether I can give reasons for them, is. It's the closest thing I've found to the line I went looking for: still subjective, but, like the old Gist, a standard I can explain.

It isn't only writing. Building hejbro, the same thing kept happening. Reading code and designs the model had produced, asking a question, refusing an answer, and finding a real bug behind it, more than once. It didn't have a name then. It was a refusal.

The day I wrote this there were several, some about the skill, some about this post's title. I'm not going to list them. What matters isn't what I refused but that the refusals are on record. Those few lines are the evidence that today I was not a transparent proxy. If a meat proxy is a person with no diff, then today I had one.

Which one, not whether

To be a meat proxy, or not to be. Odd to say this under that title, but the question was malformed. I will be a proxy. The model produces; I sign and send; that's the chair. The question that matters is which kind: the one that passes everything through, or the one that reads at the layer where its policy lives and refuses.

Two honest weaknesses in that answer.

First, the rules I've fed the model are my past taste. My taste moves. If I start waving suggestions through, the model will keep reproducing the writer I used to be, and instead of me improving the tool, the tool will hold me in an older version of myself.

Second, mistakes in thought are much harder to catch than mistakes in form. A typo, a tone, a sentence that runs long, those jump out. A wrong idea written in plausible logic, or an argument that has drifted off its subject, slides past a casual read. The better the model imitates my style, the more tiring and exacting it becomes to check whether what it wrote is actually true.

So I think of the refusing proxy as a habit, not a state. If the log sits empty for a while, one of two things is true: the model kept being right, or I stopped reading. I'll hope for the first and keep suspecting the second. That's the line I've drawn. Like the old ruler, it won't be the right one for everyone. But I can say why it's mine.