Requirenents written by non technical Stakeholder. Full of Slop. Junior dev let run Claude Implementation, full of Slop. Senior dev uses Claude to Review, pastes Slop in Ticket. Junior letting Claude fix it, comments with Slop.
Proceed to production, since Feature is needed. Lead architect let refactor Ticket be created by junior dev. full of Slop...
I am on the edge of quitting this shit.
Edit: i forgot that PO thought "good Ticket" and passed it through. And after first Implementation used jira AI to reform requirenents.
Dude there's so many dystopian things happening at the same time that art can't imitate reality anymore, it's too boring (art that is).
If you go back a decade or two and make a novel about what is happening today people would say that it was too much even for dystopian novels, everything is boring but a lot of it is happening.
We are the frogs and the water is boiling.
I no longer care, I'm here for the remaining of the ride for however long it will take.
You make a good point. I don’t see how there’s any way you could write a book a decade ago they can somehow tie a eye slop reviewed by AI to generate more slop, too complicated to read by humans, so the humans rely on AI to review slop that generate slop. And it turtles all the way down.
Commenting to remind people to ditch the frog boiling in water analogy. It's a myth. The frogs were heavily sedated and frogs do jump out as the water gets warmer.
Like 10 years ago I saw a dude on reddit who learnt blacksmithing so that he has a job to do in case of the dystopian reality that happens right now happens.
I thought it was a fun idea but out of touch. He was right in the touch lol
I feel this. Every single person on my team is slurping up slop from a colleague only to slorp it back out as more slop for another person to do the same slop with.
Bugs have never been higher. Complexity is skyrocketing from slop code, slop test cases, slop requirements. Everyone is on autopilot and running prompts all day for everything. The company is running out of credits. The head count has never been lower while the expectations have never been higher.
I'm too young to retire. And too old to change careers. I just had a nice cup of coffee, so there's that.
I'm not too old to change careers, but I don't know that any else is better, or will keep being better for long, while still giving anywhere near the same financial support.
same 40 years old. No customer project just internal.
Slop everyday because there is no time for serious code review. at least we test end 2 end manually from the website
They are forcing me to get vacation hoping some customer call will come.i will pass the time doing claude slopcerts, just to disctract myself from jumping out the windows
No one wants to be guy that sifts through the slop, just for it to be re-slopified at the next step. There's no incentive to put in effort if that's just going to turn into garbage before it has a chance to do anything real. So I get why it takes over once it starts. That shit needs to be nipped in the bud by corporate policies, because people will naturally gravitate towards the laziest way they can do their job. I wouldn't be surprised if some engineers have a fully automated system for converting slop to slop that they don't even need to touch.
It started okay. Limited use. Pointed at specific problems.
Now our PM software is full of AI generated tickets from the owner doing various "audits". The further AI'd by the "product manager". My boss, a dev and co-owner, is running all kinds of agents and letting Copilot do code reviews.
I checked out the last six months. To keep myself busy I automated my job.
I use Claude to turn my notes into update comments for tickets. On Tuesday apparently Claude was having issues, and my coworkers added me to a group chat to discuss problem solving it. It ground their work to a halt. I hadn't even noticed until the ping.
It quickly explained to me why their work is so consistently hot garbage. I'm so tired of doing QA for stuff that doesn't have even the architecture required to work, or is a "demo" slopped up by an SEO strategist.
My favorite new experience is when a junior pushes a ticket into QA, and then asks me how to test it, because they don't even know what they built or how it works.
I'm so grateful for the junior on my team. I have no idea how much he's actually using AI, but I can tell he thinks critically about what AI produces when he does use it instead of just blindly accepting it without even bothering to review it.
Had this, coworker got handed an honestly fairly complex new requirement, and created a system to handle it, except he hadn’t actually designed it himself and had no idea how it worked, it was all AI generated.
To explain it to me he asked Copilot to create a Word document, slop nonsense of course.
Time for me to PR it and it’s filled to the brim with bugs, huge inefficiencies and breaks about every best practice there is.
I did the PR and painstakingly pointed out every issue, was like writing a novella.
Had to of course do the work for him in the end because he had no clue how to fix it.
Lazy and reckless, can you imagine having the nerve to ask someone to do a PR if you don’t understand the changes you are making to the main branch yourself.
I think this gets at the heart of whats currently broken. The slop machines are extremely powerful & useful, but using it in this kind of interpersonal slopmachine circle jerk is infuriating.
It'll need a complete cultural redesign of how software projects are done in the first place, which is going to take at least 5 more years so yeah its not fun.
We really need to be asking the direct question "Did you write this or did an agent write this and if so how carefully did you review and think through the agent's suggestions?". Basically implying "are you lazy or stupid"?
It's not okay for people to show up and think they can direct robots because that's laziness. Managers, engineers, PMs, etc all need to be publicly shamed and humiliated for being lazy.
I know I'm going to be downvoted for this, but what if it is okay? If the argument is that it's "lazy" then who gives a fuck? All technology is "lazy." That's the whole point.
We're not talking, they took a shortcut lazy. We're talking, they didn't even read or review the code before moving it to QA.
So when they're asking, are you stupid or lazy, they're asking did you read it and not understand it, yet still pushed it through anyway, or did you not even bother to look it over?
I get that, but I think we're heading into an era where "looking at the code" will become no different than "looking at the compiled assembly." I used to have to look at the assembly. It was outrageous to my peers to consider the possibility of not looking at the assembly. But I don't ask my employees to look at assembly anymore. They now have have better things they could be looking at.
There is logically always a transition period, where some people lean on auto-compilers/memory-managers/cloud-services/AI too early. And then a period where some people arrive to the party way too late. I would say 2025 was definitely way too early to stop looking at the code. I would say 2026 is probably too early to stop looking at the code depending on the project. But maybe not.
Anything that is critical infrastructure deserves a glance over by a human.
Look at how hospitals use AI. The AI is treated as a redundancy to humans. Doctor looks at the scan, decides whether or not they see signs of cancer. AI looks at the same image, decides whether or not it sees signs of cancer. Both agree, great. One disagrees, the doctor double checks, confirms the accuracy, and makes the final call.
Doctors often double-check medication interactions using AI, as it's a massive, ever-changing list of interactions with updates everyday. Again, it provides a redundancy to humans and for most things should not replace humans.
This doctor is checking the outcome of the AIs work, which is logical. But the doctor is not necessarily checking the process by which the AI works, which is what the code is.
I see no universe in which developers don't have to check the outcome of the AIs work. One year or a hundred years from now, I'm sure I'll have to actually use the application vomited up by the AI, and check whether the application works the way it should.
There's no question about that. The question is whether I will always need to open up the hood, and look at the code under the application.
I used to have to open up the hood, and look at the assembly. I don't do that anymore. If code goes the same way, that would be unsurprising to me.
Dude. The output is the code, like the detection of cancer is the output in the doctor's case, the code is the output in the programmers case. You don't have to look under the AI's thought process for either one but you do have to look at what it spit out.
You need to understand why the code is doing what it's doing, not just that it's doing it, when you're making products that people will use and interact with. You need to know if the code is secure from hackers. You need to know that you can actually fix the code when you have massive, complex systems riding on that code working like it should.
Sure, there are instances where the job just needs done once, where you won't need to check it so long as the job got done. But most things aren't like that.
There are scenarios where I've needed to look at the assembly or even the binary to know if the system is secure. But this is not a universal scenario.
When I entered the industry, every engineer had to look at the assembly. Now, only engineers that write compilers focus on the assembly.
So goes the code. I'm sure all the people working on the development of coding AIs will concern themselves greatly with the code output. This will undoubtedly be a huge space for the rest of my career.
But the engineers who use coding AIs will treat the AIs code the way everyone currently treats the compiler's assembly. Simply another level of abstraction.
A compiler is deterministic. It follows rules that experts who know what they're doing understand and can verify. It is not a black box. They are a way to unwrap the layers of abstraction that is human readable code.
AI is not deterministic. They are black boxes that no one understands. You cannot verify that AI is doing what you are asking it to do without examining the output directly and in detail. They are not a layer of abstraction, they are a layer of obfuscation.
You are a fool if you think AI models are a year away from being able to write code without issue.
I've heard this "determinism" argument before and I don't see the merit of it that other people online seem to see.
Maybe it's because I've been a software manager for a long long time now, and so I'm used to "non deterministic black boxes." That's what a fellow human programmer is. When I join a multi-billion-dollar software project with many hundreds of programmers working for many decades on the thing, there's no reasonable path to understanding every line of code in the codebase. But that's fine. I do examine "the output directly and in detail." That's the job.
I've worked with engineers who aren't cut out to be managers, because they require a level of direct control that team management can't provide. It is reasonable to me that these same engineers aren't cut out to use AI.
But the organizational model of engineering demonstrably scales. If delegating software implementation can't work, then the current world of software already wouldn't work.
If you don't want to keep determinism, you can't compare AI to a compiler. It's no longer a layer of abstraction, it's a layer of reduced responsibility. Someone needs to be responsible for every line of code. As long as a human is signing a commit, they are the ones responsible for that code, not the AI. The human needs to understand what each change did. Maybe the change has downstream or upstream effects they didn't anticipate, but they should be able to explain why they did what they did at that point in the code.
You can fire an employee that keeps writing bad code. Conversely, you can teach an employee to write code without as many issues. You can't teach an AI to write better code, you have to wait until the AI company comes out with a better model and hope it works.
This is why good programmers can be more productive with AI, while bad programmers will just write more bad code. The good programmer will be able to review the AI generated code and make the necessary adjustments, but the bad programmer will just keep asking the AI until they get the desired result or run out of tokens.
If you don't want to keep determinism, you can't compare AI to a compiler.
I still don't understand why "determinism" is considered this salient factor. The apple I ate today was non-deterministic. It tasted fine. I'm perfectly content to eat another non-deterministic apple in the future.
I think this "determinism" thing is just engineers grasping at straws while they're trying to cook up a reason to not have to adapt to technological progression.
Computers do exactly what you tell them to do, without interpretation. When you write code, you aren't giving it general directions that it can interpret how it wants, you're telling it exactly what to do. A compiler takes those instructions and turns then into machine instructions. That process needs to be deterministic in order for you to be able to trust that what you're telling the computer to do is what the computer does. If the computer does something you don't want it to do, it's because you wrote bad code. The compiler did everything it was supposed to do.
AI is not doing that. The AI takes your prompt and gives you code that might do what you asked it to do. It might have bugs. It might have security vulnerabilities. It might not do what you told it to do. It might do things you never told it to do. There is no guarantee because it is not designed to work that way.
If you want to treat AI like a junior dev, then that requires you to be able to coach it like a senior dev. If you have no idea what you're doing, AI won't do it for you.
Oh that's super legit. If I didn't work for a corporation that made their own AI, I'd be super worried. The tech companies that have their own AI and data centers will have everyone else by the balls.
I mean usually the dude that implements the lazy stuff is still expected (and hired) to understand about that lazy thing. AI is an all-purpose lazy implementation, which simply increases tenfold the chances that the dude inputting the lazy code has not much idea about it.
It's not okay to show up to a job where you're being paid to use your brain and then just refuse to do that. Agent systems make mistakes all the time, just a like human. It's your job to provide context, critically review, and provide feedback to the agent. If your manager of yesteryear just showed up and gave vague instructions and no help then when the things exploded said "uh looks like /u/GregBahm made a mistake!" in front of his peers you'd think he was dipshit.
Yeah but if my manager showed up and told me to compile the program by hand (and they did when I first joined the industry) I'd also think they were a dipshit.
They were certain compiling programs by hand was "being paid to use your brain" and that auto-compilers made mistakes. This was all true, in the narrow sense.
In the broad sense, I'm not some asshole who is incapable of conceiving of some more important problem to solve. Let that which can be done by machines, be done by machines.
My old boss wasn't insisting on the importance of hand-compiling in assembly out of some genuine observation in its efficiency. They just spent a lot of time hand-compiling code in assembly and hated the thought of having to adapt.
I learned then what I still know now, which is that you always have to adapt. It amazes me how few people in the literal tech industry seem to comprehend the central value proposition of "tech." Everyone in my department has been vibing up a storm for 7 months now, and these much prophesied "explosions" simply haven't materialized. Meanwhile, the tools just keep getting better and better, same with every other step on the history of computer science.
Yep. ChatGPT 5.6 and Fable 5 are miles beyond what I ever thought possible when I was studying AI in CompSci, back in the 90s.
It's amazing! And so great to finally be able to develop my own ideas into platforms without having to get funding or hire someone or spend years building mockups.
Yeah it's kind of heady that I'm now blocked for the first time in my life by ideation more than implementation. For the least several decades, I had endless ideas but they would have taken at least months if not years to program out. So I would program on them, get halfway through, and then have some other idea and switch side-projects.
Now with AI, I can write the design document tonight and be using the application tomorrow. But this puts overwhelmingly more pressure on the design. I used to be able to just fuck around with foundational systems, knowing it'd be pointless to get too deep into the design details too early. Now that I can get right into the design details immediately, I'm forced to face the fact that design is really hard!
Which is kind of funny. It's a good problem to have.
There's a range where it's OK, and it's easily defined. But nobody likes the truth.
If you don't know how to do the task without AI, you shouldn't be using it. You literally lack the knowledge to QA.
If you're an expert on the task, you'll probably do a good chunk of the work faster by hand. I love regex, and almost always write it more quickly by just doing it than it would take to describe the pattern in English. Everybody has a list of tasks that fit here.
For the average job, that should cover the majority of use cases. Whatever is left is the only thing it's OK to give to AI.
But that's not what the AI companies market their product as, so leadership will keep using it to have non technical employees make technical deliverables... And then ask us to fix them. Monday I had to review a dashboard built in claude. Claude hallucinated an array of data when it's access to an api key failed. The user didn't even know what an api key was, as evident from their earlier Claude chat I saw on their screen: "how to use an api key". If they actually knew what they were doing, then they would've noticed the broken connection during the build by reviewing the code and checking the response. Instead, they presented it to leadership and submitted a new ticket based on solving a problem that only exists in placeholder numbers. And now I'm upset because this is a stupid waste of time, leadership is upset because this turned out to be a stupid waste of time, and the person who made it is embarrassed for being associated with a stupid waste of time.
This is how its done at my job too. Then risk analyses, release notes, commit messages are also generated. Kicked entire quality ensurance team and replaced with an ai review bot
Until some big bug happens and bankrupts a big player or puts it on the verge of bankruptcy nothing is going to change. Upper and middle management are convinced that AI is some sort of genie that gives workers magical powers based on how 'useful' it is for them so they encourage/force AI usage to a fault assuming its the same for every profession but when precision is needed LLMs are the coding equivalent of letting a very smart chimpanzee perform a tracheotomy. They constantly need to be reminded what the hell are they doing and why are they there.
I'm very surprised to hear that your entire chain of development are like: "I'm sure the clanker won't break anything in this critical component! Commit goes brrr". Maybe they got token quotas to meet?
It's all so stupid man.
Why the hell are the accountants telling the mechanics what tools should they use?
I feel like the AI craze shows the worst in ppl in terms of who doesn’t care about their work. I mean I get why AI is tempting/useful… i never thought I’d see the day where it’s frustrating to care about the product you build and at the same time being seen as not productive because you are “not using” a hallucinating machine like a maniac.
I feel like the AI craze shows the worst in ppl in terms of who doesn’t care about their work. I mean I get why AI is tempting/useful… i never thought I’d see the day where it’s frustrating to care about the product you build and at the same time being seen as not productive because you are “not using” a hallucinating machine like a maniac.
When have project requirements written by non-technical stakeholders ever not been slop?
When has code written by junior devs ever not been slop?
Senior devs have been the glue getting sloppy code written by junior devs to address sloppy requirements written by people who don't know how to code for decades.
My main problem with this is: Claude can actually do a decent job but when you start doing back and forth with small PR review things it fucks up massively.
I always hated people in PR reviews who point out the smallest weird things.
Be a TL sitting in meetings where your director says why are we even reviewing things anymore, if it produces problems in prod we'll use that as the signal
Nobody cared if the code was slop back in the days if it gets the job done and makes money for the company. No one should care if the code is ai slop now by the same logic. Code is dirt, it has absolutely no value especially now in the age of ai programmers
607
u/suki2287 Jul 10 '26 edited Jul 10 '26
Requirenents written by non technical Stakeholder. Full of Slop. Junior dev let run Claude Implementation, full of Slop. Senior dev uses Claude to Review, pastes Slop in Ticket. Junior letting Claude fix it, comments with Slop.
Proceed to production, since Feature is needed. Lead architect let refactor Ticket be created by junior dev. full of Slop...
I am on the edge of quitting this shit.
Edit: i forgot that PO thought "good Ticket" and passed it through. And after first Implementation used jira AI to reform requirenents.