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.
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"