Are You a Developer, or Just the Cable Between the AI and the Terminal?

The day goes something like this. A test blows up in the terminal, so you select the stack trace and paste it into a chat window. The model spits out a fix, so you copy that and paste it into your editor. Run it. New error. Copy. Paste. Thirty round trips later, the bug is dead and the PR is green — and you’d struggle to explain what you actually did today.

Someone on Hacker News put a name to it: meat proxy. A human relay carrying packets between an AI and the systems it can’t reach on its own. The phrase landed hard in developer circles, and not because it’s funny. It stings because it’s accurate.

What “being a proxy” actually means

In networking, a proxy takes a request, forwards it somewhere else, takes the response, and hands it back. It doesn’t evaluate anything. That’s the whole point of a proxy — and it’s also why proxies are trivially swappable. Nobody gets attached to a particular nginx instance.

A meat proxy is that same box with a person sitting in it. The model asks what’s in config/database.yml, so you open it and paste the contents. The model suggests a command, so you run it and paste the output back. You are busy. You are typing constantly. But every one of those actions shares a property: no judgment enters the loop.

The trap is that it feels productive. The screen never stops moving. Commits pile up, tickets close, the burndown chart looks healthy. But run the ratio — how much of the day was hands versus head — and at some point it tipped hard toward hands without anyone announcing it.

How we ended up here

There’s a real technical reason for this shape, and it’s mostly historical. The first wave of AI coding tools were chat boxes. A chat box can’t read your filesystem, can’t run pytest, can’t check whether the thing it just wrote compiles. So a human had to do all of that. You weren’t collaborating with the model — you were its I/O device.

That constraint is gone. Agentic tools read files directly, run shells, execute test suites, and iterate on their own failures. A large share of the copy-paste treadmill is already technically unnecessary.

And yet the copy-paste continues. Partly habit — muscle memory outlives the tool that created it. Partly nerves, because handing a process write access to your repo and shell is a different kind of trust. And partly policy: plenty of enterprises still block agentic file access outright, which means their engineers are stuck being I/O devices by mandate.

This is the fork in the road. Eliminate the shuttling and you free up capacity for the work above it — deciding what to build, verifying that what came back is actually correct, judging whether this approach survives contact with next quarter. Eliminate the shuttling and immediately fill the gap with more shuttling, and all you’ve built is a faster proxy.

“But I review the code”

The obvious objection: I read what the model writes. I review it. That’s not relaying, that’s engineering.

Fair. But there’s a scaling problem hiding in it. Review quality degrades as throughput climbs. 200 lines a day and you read every one. 2,000 lines and you skim. 20,000 lines and you check whether CI is green and move on. Tools keep getting better, which means the number keeps going up, which means the review keeps getting thinner. Nobody decides to stop reviewing. It just erodes.

Which makes the finger on the approve button part of the proxy too. Approving because you understood the diff and approving because nothing bad has happened the last forty times look identical from the outside. They’re nearly identical from the inside, too. Auto-approve isn’t only a setting in a config file. It installs itself in your head, and it doesn’t ask for confirmation.

What’s actually left

Framing this as “will AI replace developers” produces nothing but noise. The more useful question is narrower: what, specifically, in my work can a machine not do?

A few things hold up. Defining the problem correctly in the first place — models are excellent at answering the question you asked and indifferent to whether it was the right one. Deciding which requirement to sacrifice when two of them contradict each other. Having a feel for who gets hurt, and how badly, when this code fails. And owning the outcome. That last one matters most: when the service falls over at 3 a.m., the model does not get paged. You do.

The other side of the list is just as clear. Boilerplate, syntax fixes, log wrangling, mechanical refactors across forty files — hand all of it over. Clinging to that work isn’t craftsmanship. It’s just inefficiency with a nice story attached.

Three questions to run on yourself

Skip the grand framework. A quick audit is more useful.

One: name three decisions you made today. Not tasks — decisions, meaning there were alternatives and you picked one. If nothing comes to mind, that’s the signal.

Two: when did you last reject something the model produced? If you can’t remember, review has quietly become approval, and those are different jobs.

Three: what percentage of today’s copy-pasting would disappear if you changed a tool setting? That portion is pure waste. There is no reason a person should be doing it, and you can delete it this afternoon.

The point

“Meat proxy” is uncomfortable because it isn’t a prediction. It’s a diagnosis of the present tense. Nothing new is happening — something you’re already doing just got a name.

But the phrase is useful as a sorting tool, not a stick to hit yourself with. It’s a line between the work worth handing off and the work worth keeping. Doing things a machine can’t do doesn’t make you a proxy. The dangerous state is grinding through another day of copy and paste without ever having written down what those things are. Take five minutes before you log off and list five of them. If you can’t get to five, you’ve just found the thing to work on.