upvote
The focus on "code" is sometimes too strong. This isn't just a code/quant issue. All of this applies too to any "answer" the LLM gives. Experts very often track their lineage - what teachers they had - because the details and slant of what they were taught guided their way of thinking and defined the "handle" they use to grab a problem. There is no "right way" to do most things - there are ways of approaching. Imagining that you are free-flowing and not in a channel is a rookie mistake! Encouraging this way of thinking is like the uptight enforcer of minor social mores: "Elbows!" no elbows on the table is how things are done and this is reified. Like you said "it takes no effort to produce and immense effort to debunk" and sometimes the stakes are high. I'm convinced that racism, for example, operates exactly like this: 0 friction go-with-the-flow insist it is natural...
reply
deleted
reply
reply
Mark Twain is halfway around the world before Brandolini puts on his shoes.
reply
That particular quote attribution is, literally, halfway around the world: https://quoteinvestigator.com/2014/07/13/truth/
reply
Make it clear that workslop is produced by the human committer and not the Claude. The human has a reputation and this is hurting that reputation.

You can do this in a professional way but still get the point across that they're stealing productivity from others that have to pull up their slack.

If the commits are too big or too dense. Make them break it up, clean up the comments etc. Otherwise they are simply doing a poor job. Not Claude, them.

reply
> Not Claude, them.

Can’t have the cake and eat it too.

If they “solve” navier stokes and mathematics, they surely should be able figure such menial tasks out on their own, shouldn’t they?

reply
deleted
reply
I think it is appropriate to invoke 'in loco parentis' for this.
reply
Sorry the corporate initiative is to use AI for that
reply
Corporate code is typically terrible anyway. For many years (predating LLMs) I’ve looked askance at my bank’s app with its obvious bugs, wonder how many are not visible. It was not always so (consider SABRE back in the 60s)

But it’s the fat part of the bell curve. There’s loads of even worse crap outside corporate code…and at the right end of the bell curve is deeply thought out and the result of long-term maintenance that tends towards as bulletproof as can be possible in this universe, parts of OSes, networking stacks, clocks, and the like.

It’s only because that stuff is so robust and sufficiently general that the rest of the world’s steaming pile of code works at all.

reply
This is why the adverse reaction must be proportional to the effort required to counter the destructive behavior. It must be strongly discouraged.

One of the worst things you can do is pull punches when you get "contributions" that are net-negative because they waste everyone's time.

reply
That's very hard to do in a work environment where you have someone above you who doesn't understand or care about this. Instead of keeping things sane so they can run smoothly, you will be seen as slowing down progress.
reply
If I work for someone else it's not my problem. I should point the problem out to them, but since it will hurt them first and foremost, it's no major concern of mine.
reply
If AI does anything, it amplifies asymmetries. Hacking, scamming, reducing code quality... its really good at making defending against those hard problems even harder.
reply
I’m an advocate for LLMs to code and basically use it for everything now, but just want to say you really nailed that.

It takes effort to debunk because you have to holistically consider what the problem was and actually find the better solution to prove why it’s lacking.

In other words, to debunk it, you have to do the actual work that wasn’t done the first time.

Some people may argue “so what?”

And to that I would just respond that the fast solution implies nobody probably thought about it, which is always risky and generally leads to very bad outcomes. If for no other reason than there is at least no consensus, which for long-term software evolution is deeply problematic.

This has happened many times since this trend has started, and forcing everyone to step back after a year objectively reveals the murder that has been committed that, believe it or not, is not trivially unwound.

In the wrong hands it’s a debt machine that is already killing companies from the inside.

reply
I see increasing amounts of code merged to the codebase that is sometimes wrong, sometimes too brittle, sometimes fixes the symptom without addressing the bug. Two years ago the same code would be criticized harshly and reworked before being accepted.

Also, now people who used to manage the development but not write any code also feel their superpowers to merge LLM slop in humongous amounts. It feels like a ticking time bomb, but I am afraid of calling it out and rain on their parade of 10x productivity (or often AI psychosis). Leaving the team doesn't feel like a good decision because what I hear from many colleagues is much worse. Ah what a time to be alive...

reply
The Bullshit Asymmetry Principle, a/k/a Brandolini’s Law: “the amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it".
reply
Illuminati propaganda!
reply
MJ 12
reply
My strategy is to skim the workshop to find suspicious sections, then prioritize debunking at least one part that makes the creator look bad.

Then respond with that addressed, with a firm but polite explanation that the document has some problems that need to be addressed carefully before we invest time on it.

None of this works if it’s coming from your boss, but it’s very effective at making people think twice before sending you slop.

People only do the workslop thing when they believe the benefits of showing the work outweigh the reputational risks. If they get caught every time they do it and exposed on an email chain, they start doing less.

reply
Sadly not my experience. When I give this kind of feedback on a document, highlight a gap, or give constructive feedback, most of the time this feedback is fed back to the AI and a new revision of the document shows up.

BUT because it is AI it's not that section that's addressed, it's about 90% of the document that now has changed, and I need to spend another gargantuan effort to review it. It's like by trying to be helpful I actually lose more time.

The AI has made it so that the thinking before writing is mostly gone, and shifted that step to the reviewers.

reply
Left this way, every collaboration can turn into what used to be the worst nightmare type with that one unavoidable stakeholder or coauthor who likes to procrastinate and then create an insane fire drill in the final moments before a deadline.

Now, no matter the amount of preparation work, those last rounds can completely rewrite something with no hope of review. No iterative improvement. No ratcheting towards a known quality. Just a bunch of cargo cult review followed by YOLO-style, vibe-everything absurdity.

reply
Sounds like Claude. I haven’t made this experience with the large OpenAI models.
reply
Review burden is increasingly higher for many people, with Tech likely being patient 0 for the rest of the economy.

The ratio of verification capacity to generation capacity, V/G, has broken with LLMs. It’s not simply an issue of more generation or less review.

The impression seems to be that individuals are more productive, but that productivity is someone else’s review burden. So the team/firm as a whole is not better off.

The cheap generation of content does mean that reviewer capacity is now a limited resource.

Unless your firm is aware and is measuring time spent on reviewing slop, there is no incentive or structure to ensure that time is respected and valued.

This is a management and awareness problem since the typical response is “use a bot to review it.”

reply
I believe this is most clearly visible in mathematics. Who is going to review the 700 proofs put out by OpenAI in a single day ? And even if mathematicians could, how will they handle the exponential growth of LLM-generated proofs ?

Not to say these proofs are slop, even if the LLM-generated work is of good quality, what happens when no one knows how it works anymore ? Even if you ask the LLM to explain, which it does quite badly, the time to understand the explanation is incompressible.

So in the end, productivity will probably reach a ceiling that we can estimate as the product of humans, their cognitive capacity and their time. And that ceiling may be lower than what AI companies valuation expect, regardless of the compute and they can pump out and the RSI level they can reach.

reply
Honestly the mere possibility is undermining my trust in my colleagues.
reply
This is about computer code. Debunking is either "it runs or doesn't". Not hard.

Presentation layer code doesn't control how the machine and kernel prioritize anything; so "proof" Ruby code is doing the right thing is proving the machine does the right thing from the factory.

As for abstract theory and math, well shit since any English and any math are...mathematically possible...well shit I guess we gonna have to live in the real world and not inside a rhetorical bubble; religious or atheist philosophy... cause they are not evenly distributed frameworks as religion clearly shows; so why live by the syntax and semantics of some mathematical rando who taught a stats class years ago?

Same shit as living by religious allegory

Goodhart's Law has come for 1900s means of scientific inquiry; every technology follows an S-curve and the same for every social society. In the US we aren't all defaulting to calling ourselves British or speaking Latin.

Physics will always be there. The stupid glyphs and bird song we came up with to communicate about it isn't physics. It's just a human language system.

reply
Debunking can often be 'it runs but it's 100x slower than it should be'
reply
> This is about computer code. Debunking is either "it runs or doesn't". Not hard.

I have to ask. Did you even skim the article you’re commenting under?

reply
... Code can run but not correctly solve the business problem for which it was written, or it can run poorly, slowly, unreliably, etc
reply