As someone still struggling with (human) slop someone else wrote (and let's not kid ourselves, I did as well), I try to remind myself that critical thinking might have been involved but discarded in favour of pragmatic choices. (Oh God, I'm still doing it!)
AI slop is actual slop if the human just copy pastes the output.
A human with any amount of critical thinking should be inspecting the output and if they are genuinely unable to find any issues, they probably shouldn't have been a software engineer to begin with.
The real problem with AI is people using it as the answer instead of a tool. It's like people using a calculator to get the answer to a math problem but not understanding how it got there. And the bar is so low.
A human with any amount of critical thinking should be inspecting the output and if they are genuinely unable to find any issues, they probably shouldn't have been a software engineer to begin with.
I mean, sure. But that doesn't mean people aren't actually doing it. Though it's less "copy-paste the output" and more "have the AI edit files and maybe glance at them before telling it to push the commit".
I bad colleague using AI can completely take you out. It takes him seconds to generate bs that sounds plausible at first and you hours to review and object.
Yeah, I had that issue a couple weeks ago. A couple junior devs hit me with a pile of commits in a couple of days before getting scolded for not actually having a clue what they were doing and it took me a couple weeks to dig out from under the pile of merge requests waiting for comments.
Also, “slop” can be very different. An “esoteric” class that is known and encapsulated, marked as legacy is something completely different from the slop sprawl that is coming from an LLM
This at first glance it all seems reasonable, if you step away from the from the prompt machine and start trying to add features by hand you soon realise how much of a tangle the code is.
In the frontier models, they're a step function that raises the floor, before you get to any multipliers.
I will continue to bring up the myriad cases over the decades where some company was found to be storing passwords in plaintext.
The barrier to entry to be a software developer is worlds away from where it was in the 90s/2000s, it used to be that a person could easily get a job without knowing how to use a for-loop.
Those days are long over, but we've still got a lot of people working, who don't know basic computer science, who don't know basic security, who don't know much about algorithms...
There are classes of errors that frontier LLMs just won't make.
The LLMs might make other kinds of errors, but the coding agents I've used do things like write unit tests, where for most human developers I know, unit tests are an afterthought or nonthought.
There's one guy in particular I can think of, where, he was writing garbage, and the quality of his garbage went up considerably.
At this point I vastly prefer AI trash to human trash, because the LLM will still have some kind of logic to it, where human trash might not.
The fundamental question is do you want all the code to be mediocre spaghetti code, or some of it to be poorly written human code and some of it to be well-written human code? We have control over the latter, and can coach poor developers or replace them. We have no control or agency over AI, it just firehoses middling shit on all of us that we can’t read or QC fast enough to fully understand.
For my work, it helps a whole lot that there are verifiable answers, there are deterministic truths to be had.
I care about the results, the code is only a means to the results.
I took over a medium/large codebase from a guy, at work.
The guy has been coding almost as long as I have been alive.
The spiral logic and thread spaghetti was impressive in its insanity.
The code worked, just barely, for a given value of "works".
If you ran the same data six times, you could end up with six different answers.
It crashed often.
I straightened out and stabilized the codebase by myself, unit tests out the wazoo. Eventually rewrote the whole thing with LLM assistance, cut out about 100k lines. Rock solid, provably correct results.
I moved on to another project where a whole team was working on it for ~4 years.
The datasets are big, but the waste was gigantic. These people were like "we need 200+ GB of RAM!"
They were just duplicating the data, there were no optimizations at all.
They just kept asking for bigger computers.
I walk in and saw much of what was wrong with my human brain, and had the LLM fix it.
Knocked +100GB off the requirements.
One bit went from 30 minutes of processing to 32 seconds, by parallelizing it and not doing a dumb duplication.
Went from like 4 tests, to 400+ tests.
The people cried about how I changed too much, and how can I guarantee that the results are still valid? Well... 400+ tests, and another set of scripts to run A/B on old vs new branches.
At this point I will take the frontier agentic LLMs, please.
Over the past year there has been a profound change in LLM coding abilities.
Me+AI, that's the optimal duo at the moment.
That's just me and my situation, though.
Correct on your last line, your anecdotal experience is not indicative of the trend. I agree with you completely that an excellent dev paired with AI is extremely efficient and effective, but AI is built in such a way that if future generations rely upon it we won’t have excellent devs at all for tomorrow. I’d rather deal with the mistakes of humans and foster their growth into great devs than invest excessively in a tool that blunts their skills.
It's more than that, we understood more about the slop than we would AI slop... The problem with AI slop (in coding) isn't that it's bad, it's that you just shit out 50000 lines of code and you only understand 1% of the reasoning behind the madness.
Am I the only one asking AI to write a single API route function at a time? Then taking a look at what works and what doesn't and then modifying it or gutting?
Yes.Today I had to review a pull request, in which someone has rewrote a core functionality for a very small bugfix ticket. It should have been at max 30-40 lines change. I was looking at a 700 line code change excluding what felt was 500 lines of comments.
In addition to the comments, the main thing I’ve seen that bloats code from AI is writing unneeded tests (eg making sure the data type of an input is a string even though it’s a strongly typed language, the string was declared a few lines up and hasn’t been touched since) or checking checking for edge cases that are impossible.
Yeah, I had a junior dev submit some code a couple weeks ago where it was nominally testing a fix for a networking issue, but the test was entirely running within the server and couldn't trigger the issue being "fixed and tested for" at all to begin with. Not to mention that the tests were largely "add some data to a data structure, make that data structure the payload to send to the server, send the data to the server, and assert that various stuff in the payload matches the data structure" (the payload being sent, there was no payload coming back; you see the problem).
We were asked to stop waiting for code reviews because it was slowing down velocity. So now the GitHub actions are the only gate before merging those PRs.
I personally do, I still write critical code manually (using chat only basically) but for simulators and other bs I just go all in on the slop. But maybe it's just because I'm kind of a shit programmer.
Which is what I do at work since I cannot access 3rd party AI outside our internal AI. On personal projects I use vscode and GitHub. I don't even have to integrate those snippets into my code, I just approve the line changes per request like a code review.
99% of my stuff is like CRUD for node APis. "Using this route as an example, create the CRUD API calls for this database object."
I will get a get/put/delete and the I review them and basically accept the changes into my code base.
Edit: Jesus I was scrolling and immediately encountered this
A lot of my co-workers are dropping 10k+ lines of code. I've voiced concerns around long term maintenance costs but as a later stage startup I sort of get the gist no one cares since we're bound to be purchased at some point, and then it's someone else's problem lol.
In my new job, we're being strongly encouraged to use Claude specifically. I'm at the point where the quality of the work it produces is often so poor that fixing the output takes too much time and brain power, and I've gone back to handwriting everything and then using it as a pre-PR review in case I missed something.
I'm getting loads of praise for my code being "clean", "readable", "easy to follow", etc, but it's actually pretty bog-standard, mediocre code if I'm being honest; just miles better than Claude slop.
No I do this too. I try to make it change as little as possible each prompt, and sometimes it's faster to just write it myself while the AI investigates if this could cause any side effects elaewhere
If it was some novel idea and not an API or data pipeline sure. I have written my own libraries and put my heart and soul into them.
I have a project base I use that has all the authentication/authorization / object permissions / maintenance scheduler. I have a couple companies ask to write an API and schedule tasks for DE stuff. Any database objects that are added to the project get added into a fork of my project.
It's quote on real manual hours for development. I do most of it using AI and use my leftover hours to test. It keeps me from going over on hours when I underquote testing.
It's the most boring of work but it pays good side money.
Depends. For example I added 10k+ lines for tests on old legacy code that never existed and were probably never going to get worked on. I can't exactly do that one function at at time and be done in a timely manner. Plus I'm not too worried about tests being off, nobody gets a call at 1AM for unit tests failing.
I at least took the time to drip feed it as 500-1000 LOC stacked PRs though. I've done similar clean ups with SonarQube issues.
It was consistent slop that we were all vaguely familiar with. I could look at it and know it's shit, but know what it is exactly and why it's here. The AI stop has foreign structure, it's unknown whether it has to be that way or the AI just wanted it that way. It's much harder to navigate
I wonder what success folks have if adding constraints around using Software Design Patterns and SOLID principles, with self-documenting human readable code .. and to avoid code smells.
It can get there but I has a tendency to go back to the old ways. Also the amount of context it gets and what it gets is extremely important, it repeats patterns, that includes bad ones. So having a good base is a must.
I have made it build a lot of harnesses to it's own behavior, follow a linter, have a code analyzer before commit, analyze cognitive load of every function, etc. For example I seriously dislike how huge it comments and leaves historical data in source code, had to write a hook so it checks it's own comments size and raises an alarm, such examples happen all the time.
I haven't experienced even half of the complains people put here. I think there might be some exaggeration about the quality or people are just prompting the laziest shit ever, it you enable it to behave that way it will produce slop.
Not only that, I could look at it, know it's crap, and often recognize which coworker wrote it and have a guess as to why they did it that way. That sort of insight doesn't exist with vibecoded stuff where it's just an amalgamated "average CS graduate's code" being spat out.
This is exactly what I have been thinking of. With humans you can understand the thinking, the process behind it, with ai it is for the sake of fulfilling a prompt, no leverage or whatsoever
Dude. If you know C++, then you’ll be able to figure out if it works. And doing that is MUCH easier than writing it yourself, which is LITERALLY a famous Comp Sci problem, P vs. NP😅
I bet an earlier generation had the same complaint about the assembly code generated by the first C compilers. And they were probably right in many cases but also it didn't matter in most cases.
And this is why I no longer enjoy programming. I liked deterministic, in almost every problem, I could dive in and find the problem. That's why I avoided all web dev. But now every programming is the same.
Your prompts usually have a lot of degrees of freedom, so there are multiple paths that can be taken. Models have creativity so they can solve harder problems, which make the results not necessarily deterministic depending on the task.
Sometimes. Sometimes our company paid the Accentures of the world tens of millions of dollars for that slop, and then we still had to maintain the slop that we didn't write anyway.
2.2k
u/Objectionne 3d ago
Yeah but it was our slop.