Meat Proxies in Software Engineering: Do We Still Need Them?

For those of you who have managed to avoid this term so far: “meat proxy” is a derogatory label for someone whose only job is to hand tasks from a ticket backlog to a coding agent like Claude or Codex and, once the work is done, move the corresponding ticket along. Before generative AI, we had the term “code monkey” for a very similar role. It was about simply translating tasks into code and then creating a pull request.

I know people who sometimes enjoyed playing code monkey. I know people who voluntarily take on the role of a meat proxy. And I know companies that, in the age of generative AI, see these people as candidates for the chopping block. “What they do, an agent can do too.”

“Meat Proxies” in the Wild?

A few weeks ago, my assumption was: engineers who voluntarily hand over their expertise (and responsibility) to a coding agent were people I surely wouldn’t run into at an expensive software conference like GOTO Copenhagen. I had assumed the attendees would be architects, designers, managers, freelancers, and engineers who want to keep growing. I had expected not to meet anyone there whom many companies today would see as a candidate for the chopping block.

To my astonishment, what I encountered there was exactly the unease I had actually wanted to get some distance from. During a panel discussion about how engineers use generative AI in their day-to-day work, audience members had the opportunity to ask questions and share their opinions. For this, they used a small tool built specifically for the conference, which made questions and comments appear directly on the large screens behind and next to the stage. Here are a few examples of comments and questions, some translated and paraphrased:

• I’m tired, boss.
• I’m still tired, boss.
• If agents write the code, what’s left for me?
• Why do we still need juniors?
• Let the slop developers do the slop tasks; we’ll do the fun tasks by hand, “the old-school way.”
• I hate this timeline.
• What even is our job anymore?

I was surprised. Naively, I had assumed that we, as conference attendees, would look ahead and together find ways to move our industry forward in the new reality (that of coding agents)—and suddenly here were people who were still grappling with a much more fundamental question: What role do we even play in this reality anymore?

Many Questions, Hardly Any (Direct) Answers

In stark contrast to the people who seemed almost lost in this new reality were speakers who did exactly what I had expected: they accepted this new reality without judgment—agents write the code, and we as an industry have to solve the problems that come with that. Questions that were touched on and partly answered included:

• How do we eliminate the code review bottleneck?
• Is code review even the primary bottleneck, or is a much bigger one hiding behind it?
• How do we deal with the context switches?
• How do we make sure we keep learning and continue to foster our cognitive abilities?
• What can we create today that was unthinkable before?

What did not get answered were precisely the questions mentioned earlier: “What do we actually do all day now? And what for?” The veterans among the speakers in particular (several of whom I sorely missed this year) simply didn’t talk about code anymore and looked to the future almost without a care, at least when it came to the question “Is my job safe?”

An Attempt at an Explanation

Why is that? One coherent story you can tell yourself, and one that surely explains part of it, is this: the veterans have long known that a software engineer’s responsibilities include far more than just writing code. They have spent the last few decades developing, applying, and teaching methods that cover the entire value chain in software development. Even before Claude and Codex, conferences like GOTO were already about design patterns, performance, security, ways of working, software architecture, agility, communication with stakeholders and customers, maintenance, delivery, and much more. How many of these topics does generative AI make obsolete? Answer that for yourself.

So the much bigger question is: How many of these topics are actually part of the daily work of an average software developer at an average company? If I take the questions in panel discussions and the comments on the screen during some of the talks as an indicator, then the answer is:

Too few!

The veterans I mentioned will surely agree with me when I say: Many companies, consciously or unconsciously, ignore large parts of what the industry has built up over decades. They have created hierarchies and structures in which engineers are small cogs in giant machines. Engineers in these organizations receive detailed and supposedly “complete” tickets with the task of translating those requirements into code. They don’t talk to customers. They have no room to make creative decisions. They can hardly experiment, iterate, learn, and continuously improve. Often they don’t even know any part of the roadmap or the overarching goal of their work, and so they can’t work with foresight either.

Coding Agents (and Humans) in the Forest and in the Desert

These are the engineers who are suffering right now. Sure, there are also those who love the craft of coding and who enjoy their work much more when they’re the ones writing the code. You have to respect that, too. (That said, you could also ask yourself how many engineers love code this much only because it’s all their organization has left them.)

Generative AI exposes the gap between what veterans have been preaching for years and how companies actually work. Still, you have to look closely to draw the right lessons from it. The message for companies is not “We don’t need engineers anymore,” but rather: “Hm! Maybe we’re not making the best use of our engineers.”

How do you make the best use of engineers? Of course, the answer depends in part on the organization. A few proven approaches:

• Don’t wait until a fully written Jira ticket exists to involve engineers. That way, you can spot technical constraints early and reduce feedback loops.
• Let engineers talk to customers and stakeholders regularly so they can understand problems better.
• Create room for experiments (and with that, for innovation).
• Involve engineers in creating the roadmap so they can make future developments technically possible without building them ahead of time (optionality).

Coding agents free up time for these tasks, but the company’s structures and processes have to support this change and be challenged accordingly. That isn’t easy, but it pays off. For years, research like the DORA studies has confirmed the link between user-centricity, good organizational conditions, and the performance of software organizations.

Kent Beck, who thankfully was in Copenhagen again this year and gave a great closing keynote, would say: You’ve lived in the desert long enough. Maybe it’s time to move to the forest.