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.
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.)
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.
Recently I was looking at building a gnarly form, that had some really complex interactions and data behind it. It just kept being subtly buggy in all different ways. I threw Claude at it, went down so many rabbit holes, it was convinced there were bugs in all the different frameworks and libraries I was using because it couldn't find the issue in the code (that it had written most of).
After a couple of days of tearing my hair out, I eventually dug in and rewrote it from first principles myself. The code afterwards was so much shorter, so much clearer, and worked a hell of a lot better (not going to say perfectly, but, well, haven't had a single issue with it since).
> All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
as they really deserve, the problem would disappear really fast.
So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).
If it happens a second time? A stern talk from their manager.
A third time? PIP or fired.
Let your manager be the bad guy. That's part of what they're for.
Your manager won't do that? Then your team is broken in a way you can't fix. Appeal to their manager, first, and if that fails put your resume on the street.
In my experience, the stern talk would probably go to you, for making the problem visible. The manager wouldn't want their manager to hear of any problems in the team. Makes them look bad, and probably lose on bonuses.
Happened to me often enough. What you described I would call a lucky exception.
> Your manager won't do that? Then your team is broken in a way you can't fix.
If you apply this standard, then most teams are broken.
They are usually verbose/include things like "how to run a virtual env for python"
Can't be any compilation errors in a README, no need to worry about bugs. And if they're long and boring enough, no one will ever read them.
AI generated READMEs = free metrics bonus points, for the performance reviews :-)
Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.
The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.
Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!
After you made your colleagues upset submitting crappy code for review, you start to pay attention.
> LLM-written ones are almost entirely additive,
Unless you noticed that code has to be removed, and you instruct the LLM to do so.
I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.
If the only thing keeping you from submitting crappy code is an emotional response from coworkers, you are not a "good programmer", no matter what you instruct your LLM.
I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn:
fn foo(bar)
fn foo(bar) // Never called
fn foo_with_frobnitz(bar)I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.
That principle can be applied to both LLM slop and handcrafted rubbish. Eventually most people will get it.
Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.
> Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”
LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence.
As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.