If you are wasting time you may be value negative to a business. If you are value negative over the long run you should be let go.
We’re ultimately here to make money, not just pump out characters into text files.
The MIT study just has a whole host of problems, but ultimately it boils down to: giving your engineers cursor and telling them to be 10x doesn't work. Beyond each individual engineer being skilled at using AI, you have to adjust your process for it. Code review is a perfect example; until you optimize the review process to reduce human friction, AI tools are going to be massively bottlenecked.
What value is that person adding? I can fire up claude code/cursor/whatever myself and get the same result with less overhead. It's not a matter of "is AI valuable", it's a matter of "is this person adding value to the process". In the above case... no, none at all.
Different projects have other incentives. Dealing with AI slop from internet randos is a very real problem in open-source codebases. I've pretty much just stopped reviewing code from people that I don't know on one project that I work on when it's obviously going to take way more time than it would have done to do the patch myself. There used to be an incentive to help educate new contributors, of course, but now I can't know whether that is even happening.
BUT...
How do have code review be an educational experience for onboarding/teaching if any bad submission is cut down with due prejudice?
I am happy to work with a junior engineer and is trying, and we have to loop on some silly mistakes, and pick and choose which battles to balance building confidence with developing good skills.
But I am not happy to have a junior engineer throw LLM stuff at me, inspired the confidence that the psycophantic AI engendered in it, and then have to churn on that. And if you're not in the same office, how do you even hope to sift through which bad parts are which kind?
We need to focus on architectural/system patterns and let go of code ownership in the traditional sense.
Regarding proof, if you have contracts for your software write them up. Gherkin specs, api contracts, unit tests, etc. If you care about performance, add stress tests with SLOs. If you care about code organization create custom lint rules. There are so many ways to take yourself out of the loop rigorously so you can spend your time more efficiently.
We really need widespread adoption of stuff like design-by-contract in mainstream PLs before we can seriously talk about AI coding.
It is vastly different because there are no (as far as I've ever seen) multi-thousand line blocks of code to cut & paste as-is from stack overflow.
If you're pasting a couple dozen lines of code from a third party without understanding it, that's bad, but not unbearable to discover in a code review.
But if you're posting a 5000 line pull request that you've never read and expect me to do all your work validating it, we have a problem.
Regarding your Luddite reference, I think the cost-vs-quality debate was actually the centerpiece of that incident. Would you rather pay $100 for a T-shirt that's only marginally better than one that costs $10? I certainly would not. People are constantly evaluating cost-quality tradeoffs when making purchasing decisions. The exact ratio of the tradeoff matters. There's always a price point at which something starts (or stops) making sense.
A major problem of the way we have built our society in a way such that the wrong people end up with the most power and authority.
the majority of engineers across the industry feel the same way we do and yet there's little most of us can do unless we all decide to do something together :/
I'm not saying the industry is perfect, but if the scale of the missed opportunity is so large and so obvious to so many engineers, and we live in a world with tens of thousands of VC firms and probably millions of other avenues for funding like angels, incubators, and grant programs, it's hard to imagine 100% of them missing it. And it only takes 1 to take advantage.
The 10$ shirt becomes a much shittier proposal once, in addition to its worse looks, fit, and comfort, you factor in its significantly lower durability and lifespan. That's why the 100$ shirt still exists after all. Nevermind that the example is a bad one to begin with because low-price commodities like T-shirts are never worth fixing when they break, but code with a paid maintainer clearly is.
In an market bubble like the one we find ourselves in, longevity is simply not relevant because the financial opportunity lies precisely in getting off in the train right before it crashes. For investors and managers, that is. Developers may be allowed to change cars, but they are stuck the train.
It's sad how some of the doomed are so desperate to avoid their fate that they fall prey to promises they know to be bullshit. The argument for Wish and TEMU products is exactly the same, yet we can all see it for what it is in those cases: a particularly short-lived lie.
It's bizarre to me that people want to blame LLMs instead of the employees themselves.
(With open source projects and slop pull requests, it's another story of course.)