Being a meat proxy for AI should be grounds for getting people fired
swiftrocks.com
swiftrocks.com
ps. The assumption is that there was empathy at play to begin with, which realistically speaking many people don't have. They would be calling for co-workers to be fired on several grounds: merit (or "merit"), skill, color-skin, dna, etc.
The one forced to do their work for them, are the teammates. Not the manager. The manager only care of it to be done. How it is done: doesn't matter.
I would argue that one of the main reason for meat proxy, is security boundaries.
In the majority of companies with a certain scale, no one can run an AI agent that will do the project from A to Z. You always need to raise at one point ticket to someone else, a human, it cannot even be done by an automated system (technically it could of course, but acceptable by governance... unfortunately no) .
I am happy for you that you weren't exposed to such managers.
What I've seen personally, together what some friends have told me and also what's here in HN (e.g. PR metrics from Anthropic, OpenAI, et al.).
The managers that swallowed the AI pill seemingly genuinely and non-ironically believe:
- 10x performance is possible now. Literally - 1 dev must do 10 developers work, also cross disciplinary. Dev will do full-stack: FE, BE, DBA, UI, UX, PM, you name it.
- Projects that have previously taken months of consideration, planning and development, now must be done in a week, by one person or at best very small team;
- Those managers don't have any tools how to measure performance - only tools are PR/commit counting mechanisms and shadow quotas of multiple hundreds PRs per week, that you will be remind of during next 1on1 or whatever;
- PR reviews? What reviews? Code quality/efficiency? What code quality/efficiency?
- Definition of done is ever changing. "You must do 10x slop", but by the end of the week "Why product looks like AI slop?". "Deliver project/task/feature", but by the end of the week "Why there's not every feature done that I could've thought of on the spot right this moment?";
Some even dared to say that asking questions to team-mates face to face is a waste of everyone's time, "just ask Claude instead". Though they will mandate return-to-office "to encourage collaboration" at the same time.
I don't act as a meat proxy since I have some respect for myself and my coworkers. However, whatever interest in programming I ever had, was completely gone after a couple of years on the job.
That being said, I am, in fact, speedrunning early retirement.
Okay, now that that is out, let me ask politely: in what way do you avoid acting as a meat proxy for AI?
EDIT: re reject, you can do that while acting as accepting it, by saying something like, yeah, let's do that but before starting, we will look at the problem, it's a game of shifting responsiblity to other people. For me that was a corporate game that has nothing to do with programming.
Your job was never code.
We may not be quite there yet, but what if automations using LLMs can do it faster than software engineers who look at the code can, and to an acceptable standard?
> all while the same people acting like they’re productive.
Are they delivering features, capabilities, updates, refactors etc? Faster than those who are "looking at the code" ?
Don't get me wrong, I've spent 25 years reading and writing code, I'm pretty sure I'm quite good at it, though I wouldn't claim to be any sort of superstar. My job has changed immeasurably in the last year, and I'm starting to wonder if "reading the code" won't go the same way as "verifying the assembly that the C compiler spits out to make sure it's correct"
Like a carpenter won't get more money for their cabinets if they make them all painstakingly by hand, not using a single power tool. (OK, some do but it's more of an art piece than a functional thing).
It's like complaining about a chef who make all their food from fresh ingredients instead of buying off-the-shelf processed versions. People will pay more for that freshy made food.
I think that's the difference though. I commented on a similar topic earlier, but I think the issue is that people are using these tools for both the coding AND the problem solving. They've turned over both ends of the workflow to the bots. When you ask them "Why did you add these new libraries to our project to solve this?" you get "I dunno, Claude did it". When you ask "Why did you avoid using our entire DI system for these static vars?" they respond "I dunno, Claude did it. But the tests pass!".
If you still tackle the problem solving part, that's great. Thank goodness. But I wouldn't assume that's how the rest of the lazy gits are using LLMs as well.
The company seemingly has no issues with this as it’s almost always blatantly obvious that AI was used for the output.
For example, Copilot has a very distinctive and obvious color scheme and format it uses for Word documents and diagrams that are almost always orders of magnitude more complicated than is warranted (which makes all of this coming from people who have zero understanding of what we’re doing even more absurd).
Nevertheless they do it every day and send AI-generated summaries of documents out to the team for review without even reading them first. I’ve railed against this for nearly two years to the point it’s nearly driven me mad but so strong is the AI adoption religion that suggesting that it’s poor practice feels like blasphemy and by suggesting real work be done that I’m somehow doing things the wrong way.
This has allowed these types of people to remain in their jobs and thrive and so when the AI bubble finally bursts I fear it will reveal largely hollowed out companies where top lower level people have either been pushed out or left.
That this is still happening seemingly without organization-level consequences has me questioning my sanity. Does anything we do matter enough that doing it badly with lazily prompted LLMs causes problems? I was sure the answer was “yes” but looking at the bottom-line investor perspective it’s hard now to make that argument.
Now that long running agents like Dots are available without any effort to set up I think the days of interacting with actual humans over Slack or any async medium are soon to be in the past. This can’t end well…
LLMs and agents allow for you to deliver at the rate. But you also have risk associated with that. If you don't like the output, fix your culture before you start blaming people for being "meat proxies".
I wouldn't mind being fired at this point though, my job feels like a joke.
Get used to, or opt out of it all.
But there are results. Why didn't you do that yourself first then? Why are you wasting meat proxy's time?
> I always saw the software engineering field as being comprised of two groups of people: people who are devs because they are passionate about building software, and people who don't actually enjoy software but joined the field because it's a job that pays well.
There's a third motivation hiding in there, people who were passionate about coding, rather than building software. It's a subtle difference but an important one. Folks whose primary focus is building and delivery are having a field day with LLMs because they've found a way to build and deliver in far less time with far less resource. Folks who have been more passionate about the coding itself are finding that their legs have been shot out from under them, because what they enjoyed and where they thought their value lay is becoming less relevant.
I absolutely get the frustration here, but conversely I think some companies now are seeking to remove the human from the loop as much as possible. That interactive AI-assisted workflow? That's a mid-state, why not instead have a multi-stage automation pipeline, to digest a set of requirements, build granular jira tickets for the work, come up with acceptance criteria, implement test harness additions for those, build the code, test it, iteratively review the code from several different viewpoints (security, minimalism, performance etc), and post it as a PR? Sure, you probably want a plan-review checkpoint, and the agents should stop and ask when they need to know something from their human overseers, but ... we're going more automated in general.
There's a few at my work who only reply with copypasted LLM output and that is completely despicable.
Also, practically speaking, if the codebase is well designed and has good foundations, being a meat proxy might actually work. If someone puts careful, meticulous thought into getting the foundations of the project right and then turns into a meat proxy because the thing is so well laid out, it practically builds itself, should they be fired?
If this is the case, then developers have the incentive to create a rotten overengineered foundation, then the AI won't be able to get anything done without human guidance. Great way to make yourself indispensable as an engineer.
What the author is suggesting isn't only immoral, in practice, it's not going to work. It's why we're in the mess we are in now with projects with millions of lines of code with new critical vulnerabilities popping up daily. Show me the incentive, I show you the outcome.
Managers who promoted people based on how much code they wrote and how many PRs they merged are going to get their punishment soon. Whatever metric you use to coerce engineers into working in a particular way is going to create problems later. You can't coerce people into producing quality engineering.
If you ask an experienced farmer to plant a crop but you insist that they must dig holes using their nose because that's your way of doing things, don't expect them to be productive and don't expect them to stick around very long.
There is a maxim somewhere in here, but I'm not going to keep trying to get it just right, instead, here are some more specific elements of it:
- I might want to put little effort into my work, and poorly execute on AI offerings to amplify my output.
- I might want to put little effort into my work, and put together a nice prompt/context/harness to amplify my output.
- Ambitious laziness is the driver of countless effective products and services.
There is a broad spectrum of AI uses and practices, and we need to keep hammering away at figuring out how to make technology serve all people.