Be a (Good) Meat Proxy

In his recent post, Don’t be a Meat Proxy, Niklas Gruhn urges readers not to be a “Meat Proxy”—that is, someone who simply forwards or regurgitates AI output without providing any meaningful value. This framing has clearly resonated with folks. While I take Gruhn’s point, I think the framing - and especially the public response to it - flattens a more nuanced issue.

You Already Are a “Meat Proxy”

Once an engineer attains some semblance of seniority, the job requirements quickly evolve past simply authoring code. Reviewing designs, managing stakeholders, collecting requirements—these are the things that take most senior engineers’ time. They are also, effectively, examples of being a “meat proxy”.

Consider the last time you were tasked with building something, and realized halfway through that there’s an edge case where the requirements were unclear. Pretty common, no? So you find the product owner, ask a few questions, and return to the work with a clearer sense of the problem. In the abstract: you simply took context from one individual and applied it to a different operation. Meat proxy. What makes this example notable, however, is the human judgment and communication required for it to be done effectively.

But You’re a “Smart” Meat Proxy

The term “meat proxy” is funny, which is certainly one of the reasons it caught on so quickly. But it’s also evocative of a real phenomenon. People do actually just copy and paste AI output trying (unsuccessfully in most cases) to pass it off as their own. This is one type of proxying behavior, I suppose. But consider the fact that there are different kinds of proxies, and you can be any kind of meat proxy you wanna be, baby:

Low-Latency “Dumb” Proxies

This is the type of proxy that Gruhn is getting at. This type of proxy simply takes its input and forwards it along. Nothing too interesting here, and yes—don’t be this kind of meat proxy.

Transforming Proxies

Some proxies take their input and modify it in some way before passing it along to the destination. This is what Gruhn advocates for:

Don’t just relay the output. Read it, understand it, validate it, and then write a response in your own words (a decent certificate that you’ve done the prior steps). Making that effort is value you can add.

Knowing when and how to do this, however, is crucial. Reframing every output an AI makes just to prove that you’ve done the cognitive work is wasted effort. Knowing which outputs to transform (e.g., research) and which to pass along verbatim (e.g., code) is a skill in itself. Transforming that information in a legible way for the recipient takes communication skills, and has always been what separates the best engineers from the only-okay.

Routing Proxies

Now this is an interesting example. Traditionally proxies have had the responsibility of routing (e.g., service discovery in distributed systems, load balancing, etc.). AI is an excellent thinking partner, but can often act like a firehose of information. When a dumb proxy simply regurgitates all of this prose, it’s both obvious and harmful. When a smart “routing” proxy dissects this output and routes the correct information to its destination (e.g., incorporating new constraints, elevating new questions), the value of the AI thinking partner can be more fully realized.

Be a Good Human

Knowing “when” and “how” to shape AI output and how to correctly route that output are the key skills one needs to be an effective proxy. Remember that your audience isn’t (or shouldn’t be) just another AI—it’s a human. Code changes, technical designs, product briefs, emails, blog posts—these are artifacts that are meant to be read by a human. They can inform future AI as context, but they are first and foremost means of communicating with people. You should be shaping the output for the audience.

The answer isn’t to avoid being a proxy altogether; it’s to be an intelligent one whose judgment shapes the output to be more useful to the human on the receiving end.