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"
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.
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) .
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".
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.
I wouldn't mind being fired at this point though, my job feels like a joke.
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.
Get used to, or opt out of it all.
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.