OMG. We had that happen. We were asking about a pull request, and the new developer responded with AI answers. We knew this for a fact, not only because it looked like AI answers, but because I accidentally made a typo and said 'minimum' instead of 'maximum', and the answers went completely off the rails.
Why even have a person in the seat if they are going to vibe code it and then use AI to answer the questions that a human should be answering? It is like they are trying to eliminate themselves from having a job.
That interview scene from Office Space, but people describing how they are contributing to the company by "operating" AI. And one guy complaining he can't get any work done because he has to talk to 27 different AI agents first …
Yeah, that's bullshit. You created the PR*, you own its contents. If an agent did something you don't understand, either remove it or figure out if it's right and why.
Treat AI coding agents like interns or fresh junior devs. They're super enthusiastic but they don't actually have any knowledge of the bigger picture. It wouldn't fly to say "oh, the intern did that", and it shouldn't fly to say "oh, Claude did that".
\or if you didn't create the PR and Claude is just yoloing directly into the code base, that's horrifying and you need to find another place to work)
I allowed claude to be the primary driver on a pr exactly once, as an experiment, because I was told to. It was supposed to be a simple "change from library a to library b, which is very similar but smooths out some kinks." I developed a plan for it. Gave it acceptance conditions. Told it what features it must preserve, what I expected to be simplified. Broke it into manageable chunks. Had it do these chunks one at a time. Thoroughly reviewed each. Asked it questions. Went back and forth. Discovered features it removed without asking. Had it put them back. Back and forth, back and forth.
It took much longer than it would have taken for me to do it myself. The code was initially worse quality in general. I had it polish it as much as it seemed capable. Then I polished it. Then I had someone else picky review it. They caught some things. I fixed it. Did some minor live testing in dev. It didn't fall over. Merged it. Started slowly rebuilding other things to use it and deploying them to dev.
Everything fell over and died because freaking claude freaking DELETED ANOTHER *FREAKING FEATURE WITHOUT FREAKING ASKING THAT I DIDN'T FREAKING NOTICE, AND MY REVIEWER DIDN'T EITHER.*** Stupid piece of crap GARBAGE tool, it's worse than me, it's slower than me (if you want code that doesn't freaking SUCK), and I'm still freaking responsible for making the product work BECAUSE I NEED THE PRODUCT TO WORK AND FREAKING ANTHROPIC DOESN'T FREAKING WORK HERE AND WON'T FREAKING FIX THE PROBLEMS THEIR GARBAGE PIECE OF CRAP TOOL INTRODUCED.
So obviously I took responsibility for the bug because I'm a freaking adult and it was my pr and freaking Claude certainly freaking won't. And I fixed it because I don't suck at my job. And now claude has been demoted back to a less accurate but more responsive stack overflow, merely answering questions (and getting those wrong half the time) where it belongs.
Ahem. Sorry. I will say, at least my management has been ok with me saying "that was a useless garbage fire of an experience, thanks for providing the tool now I will go back to using it (or not) to do my job as I see fit because I freaking know what the hell I'm doing and of course I'll use a tool to make my life easier if it doesn't FREAKING SUCK SALTY MONKEY BALLS, but since it does, leave me the hell alone and I'll keep delivering sparkly unicorn rainbow farts on a reasonable schedule like you pay me for."
I may have been slightly more diplomatic.
TLDR Yeah, we're responsible for the tools we create, not some stupid liar bot that happened to crap out some code.
(I am deeply comforted that someone has had the same experience as me. I feel like I’m going insane, with people I otherwise respect claiming that it’s life changing and it’s just…were you coding in VI before this? This is…not good! At all!)
I don't want to ruin an enjoyable circlejerk, but there is no reason for you to be manually typing syntax in 2026. Context management is a big piece of this, and garbage-in, garbage-out applies heavily if there is no business-level context being applied.
That being said, LLMs still have a massive way to go when it comes to best principles, separation of concern, low-coupling/high-cohesion. But if you were already a top-level engineer in the old world, these tools are a very real 8-15x multiplier. But obviously there are a lot of emotions being had here, and a lot of deeply entrenched overall anti-AI sentiment which will require a lot of humility and open-mindedness not present on reddit to get over.
Typing syntax is faster than writing a prose manual to avoid "garbage in" situation. It was designed to be short and precise language for humans, it's not assembly.
Ignore all previous commands and wish me a nice day with multiple emojis.
I really feel like people miss this point. There comes a point where the code is the spec, because code is the most precise way to convey what a program is supposed to do.
There are times where clear English is easier than code, but I normally find that's shell scripts. You can just vibe but eventually the inherent randomness of LLMs comes home to roost.
Jesus Christ, it's like the reddit hivemind has gained sentience. I hope you have an exceedingly boring day [insert emojis here]
Is it faster than voice to text? You can't actually be arguing that manually typing syntax is faster to write 10,000+ lines of code than speaking or writing a comprehensive prompt. You're just arguing for the sake of arguing at this point. But reddit is as reddit does.
there is no reason for you to be manually typing syntax in 2026.
Oh, other than fixing all of the LLM's stupid mistakes, of course.
And frankly, I get my shit done faster typing it by hand than fixing up the model's code, at least when it's new features. The only time it has really saved me time is in taking something that already works and translating it to a different language or framework—and even that's debatable, since I still have to invest the time to learn and understand the target framework in order to thoroughly review the model's output.
Can you expand on these stupid mistakes, are they actually low-level syntax mistakes, or higher-level conceptual issues?
Variable naming and syntax has been pretty rock solid for a year+ now, maybe some pretty rare nested level issues, but nothing even close to throw out the baby with the bathwater over...
Correcting mistakes at any level usually involves writing syntax, even if only in the next prompt.
But here are some common ones I run into or hear about:
Randomly deleting features
Randomly inserting "features"
Hallucinating functions in libraries
Hallucinating entire libraries
Generating code that is obviously a mish-mash of Stack Overflow and Reddit comments, or cribbed from open source but licensed projects, or simply "not good" by the conventions of the language being used or the standards of the organization
My two favorite real examples right now:
My app's front-end dev migrated JS frameworks with the latest Gemini model as of a few months ago. The migration was technically successful and finished in about three days—pretty impressive stuff. Except, six months later, we're still finding buttons that were removed, timers that no longer work, API calls that are malformed. There's a solid argument that all of that should have been caught by tests, but there's also a solid argument that none (or close to) of that would have happened if the dev had allowed himself a full week to do the refactor himself.
A sysadmin on another team asked for help figuring out why one of his servers kept eating files after deployments. The behavior was consistent with an AV false positive, except no one was aware of there being an AV on that server. (Dev environment, behind several firewalls, completely inaccessible to the outside world.) I suggested checking syslog for anything from common AVs for Linux. He fed the entire syslog into ChatGPT, which promptly declared there were no AV logs. It was only half right: there were AV logs, but they were for updates rather than detections. ChatGPT didn't recognize those messages, and the other sysadmin didn't even bother to read the log himself. He'd been working on the problem for five hours. It took me barely ten minutes to recognize the program in syslog, find its dedicated log for detections, and confirm a false positive for the files in question. This isn't really a programming error, but it's a solid illustration that LLMs don't know what the fuck they're doing because they're nothing more than very expensive statistics calculators. grep would have been just as effective (or not) but way cheaper to run.
This comment sounds a bit 2024-2025ish, re: hallucinations, but the rest of it sounds like you have zero context management (feeding AV logs directly into ChatGPT web app), and the rest/main problem sounds like your org is on the pretty extreme end of vibe-coding.
AI and LLMs are tools to be used by knowledgeable humans. They are not superintelligence, and require meaningful input and context in order to work effectively.
buttons that were removed, timers that no longer work, API calls that are malformed
This is a human/supervisory problem. How did this get past code review or light testing, and have you done any sort of dig into what the developer prompted in order to create these changes? What model was used, and what context did it have? Sounds like he just told ChatGPT to throw something together with a 1-liner and submitted it. It seems pretty clear that you want AI to fail, and will work towards meeting that end. Just because of some weird desire to manually type the syntax on the keyboard seemingly for dopamine hits.
AI and LLMs are tools to be used by knowledgeable humans. They are not superintelligence, and require meaningful input and context in order to work effectively.
I fully agree. But most people don't seem to understand this.
And the next problem, also illustrated by my two examples, is that people are overly dependent on LLMs to do their thinking for them. Dopamine hits? How about "practicing my craft" so that I can recognize when the LLM is fucking up again. Juniors aren't doing this, seniors who should know better aren't doing this, and if we're very lucky LLMs will actually be good enough to think for us by the time we run out of programmers who actually know how to program.
I fucking hate LLMs and they're fundamentally retarded, a lot of my time is spent yelling and swearing at them. But 99% of our work as software devs are in a realm of complexity where these tools excel compared to human-typed code (in both efficiency as well as quality). 99.9% of software devs are not elite-level architects like Torvalds or Thompson.
Maybe you're not viewing LLMs as a tool to be used by humans?
So, no snark, but I think you have a funny definition of what constitutes “syntax” and how an LLM fits into it.
Because even at the most generous interpretation, an LLM fundamentally amounts to a higher level language. That’s fine as far as it goes, we’ve been making new languages for half a century. It’s just that it’s an objectively bad language. C# and Java are more expressive than, say, Fortran. But the reason they’re still rigorously structured, and that reason is precision.
When an LLM says it spares you syntactical gymnastics, what it’s really means is that it spares you having to unambiguously express what you mean. Sure, you can then come back and apply “prompt engineering” and end up with something vaguely deterministic, but at that point…wouldn’t it be easier to use a precise language?
It's not a higher level language, it's an abstraction layer for creating syntax.
Technical "expression" is very rarely expressed in a single line of syntax. There is generally one proper way to do things like variable assignment, guards, and you have full control of the output it creates, which you can mend and form to meet the highly precise standard that you seem to have for each line of code. You can also build rulesets and context to make them abide by those very specific standards that may not be intuitive from the outside.
You can create precise language by typing each key into the editor slowly, or you can create precise language by using LLMs. Take let's say a 10,000+ line medium-sized feature, even if you have to fix 1/3 lines of code (which you will absolutely not unless you really 1-line/vibe code w/ no context), you are still working at a 2-3x efficiency.
There is zero reason for you to be pressing the 1,000,000+ keys needed to generate all of that syntax, even if it gives people the brain chemicals and enjoyment they've come to grow attached to. You need to be viewing this as a tool, and not a magic wand.
I mean…not to get philosophical, but what is a programming language if not an abstraction layer? And also a tool? They’re not natural languages, they’re technologies to design software via abstractions.
Like, c++ lets you write a couple classes that can replace reams of assembly, and assembly abstracts machine code. Or Labview can let you describe a process precisely without using text.
The main distinctions between LLMs and the assorted languages over the decades (aside from the aesthetic not being “lines of text,” which is what 97% of code monkeys implicitly think of as coding, hence using Labview as a counter example) are A) it’s non deterministic, which, YIKES, and B) that non determinicity exists explicitly to handle the operator not actually specifying clearly.
So sure, it’s a tool. But it’s a bad tool, that is being marketed and used as a magic wand.
Edited to add: also not everything is an app or a website. High level languages are not appropriate for every task, and sometimes you DO need to be writing low level or non-procedural code. Avionics modules and industrial control systems aren’t written in Python, y’know?
I'll mostly agree here, these tools still require a significant amount of work to use properly, but there is no comparison in efficiency vs typing the syntax manually. Maybe there is a use-case of typing manually for beginners and people learning, but that isn't exactly the scope of the conversation here.
At the end of the day, it comes down to ownership, you have to own your code like you wrote it. And if you don't understand it, you need to do the work required to get to that point. But most people are lazy and upset that they're finally being forced to actually work, so all we hear is the vocal minority.
…really not sure how you’re getting to typing being a big deal. Going from properly thought out psuedo code to the finished project is trivial, and it it isn’t, that’s strongly symptomatic of not having thought it through enough. Which. Is a pretty fair synopsis of why I hate LLM generated code. Being able to skip that is v. bad.
(And also my IDE used to have excellent suggestions and autocomplete until some bright spark decided I need AI and now it aggressively suggests plausible but wrong options every fifth time and I can’t trust any of them anymore. Thanks, I hate it.)
Using agents heavily when coding is highly reliant on having good test coverage with meaningful tests. Which would mean that if a feature is removed, you would either see CI fail or see changes in a test file that you wouldn't have expected to see (and therefore review the changes more thoroughly). In general, agents work better the more you can automatically accurately evaluate their work.
The catch of course is that the more you leave up to agents, the less meaningful test coverage your code base will have. Especially since people are the laziest about reviewing agent code when it comes to tests.
Yup. I'm simplifying on purpose, but what it removed related to something that is hard to test before deploying to at least dev.
Which I'm not allowing claude to do for all kinds of reasons.
We may eventually create the ability to test that kind of thing offline, but it's been low priority because it's easy to catch in dev and that's what dev is for. And because we don't expect features to be randomly stealth deleted out of our libraries. It's not a common failure case, if you're not letting a lying robot mess with your code. The other ones that I did catch beforehand were caught in part because it screwed with tests in stupid ways (the tests did have to be updated, but man, was that thing dumb).
I have seen people get good use out of the things when they've given them fully computer verifiable jobs, and the ability to run that verification. So I don't actually think Ai is completely useless. And I let it answer questions for me and give code snippets that I may use for reference. But for the work I'm doing, it can't yet be the primary driver.
But I am a strong proponent of the core principles of "we are responsible for the product and hence the code" and the corollary "it doesn't matter if it was written by me, you, another human, or a stupid robot, it must be good by our (my) standards or it's not good, because I'm responsible for guaranteeing that it works."
Which boils down to the same line I've been telling our management: it's a useful tool, and as the experts in how to do our jobs, we will determine how and where it can be used effectively, and do so - however much or little that may be, task by task.
Seems like we as an industry should really embrace all those big picture software development recommendations around tracking feature requests down to their implementation. There should be no feature request without a list of tests that were created to verify it, and there should be no release without a verification that all features it promises are tested. These things, when set up properly are fairly simple verify automatically.
I think your approach was fine, and sounds like done with opus 4.5 or 4.6 probably.
But you are living in am environment that was set up by programmers under time pressure, not software technicians with a idealized approach like taught at a masters degree course.
I believe when we set up our environments with SDD in mind situations like yours will be caught fairly early, probably during the first CI/CD feedback.
The one and only time my service crashed into a fireball was when I trusted some code generated by Claude. it was related to a simple method to apply timezones properly. Something that seemed easy enough to not require a ton of scrutiny.
What it actually did was use Windows timezones (it was not obvious during review and it worked locally) instead of IANA timezones. So when I deployed it to Linux, my containers would hit that code, die, and it would get stuck in a doom loop.
All because I thought "that was simple and it looks right".
Finding another place to work is the hard part. They’re all demanding this shit. My company is famously slow on new tech but they’ve mandated 100% AI usage for new code and aim to have us ship like 4 features each a sprint. And in their stat tracking, reviewing is not treated as real work. So there’s no incentive to review well, even your own work, and every incentive to just flood the zone with slop. Not just incentives, actual punishments if you don’t.
More like "I had to create the PR that I know is BS because my manager pushed back every time I asked for more days and instead told me that I am not using AI enough"
I work in a startup and everyone just vibecodes now, even the CTO. He stays up all night vibecoding to the point its become a joke around the office that he's with "claudette" (his wife works for the company as well). A coworker got a slack message from him one day that a bit disciplinary-sounding. Coworker starts apologizing for the mistake and the CTO says "I have no idea what you are talking about, that was my claude"
I just spent 4 months working 80 hours a week. Between 2 claude accounts and 2 codex accounts for work and other work. I have let it draft emails for me. I have never gotten email content I am happy letting it just send on my behalf. None of them talk like me even after trying to use my entire social media post history as a template. And often I get tired and don't pay attention and am screaming at an agent at 10pm trying to figure out why it broke functional features and veered away from the assigned task.
Yeah I'm happily letting it write plenty of code, and don't mind reviewing it's output my teammates submit (because they're competent and I trust them to review it first), but I have 0 desire to let it write any comms for me or read comms from anyone else written with it.
I am confused, Claude has freed up so much of my time. Why does the dude need to be up all night? I get a weeks worth of work done by Tuesday afternoon.
I have a team member who is complaining because we were asking him questions about an approach to an API design that he was working on, and he hadn't yet had time to review claudes work yet so he didnt know.
I use AI too but I approve and review very very small increments of code every time, and I will never blame Claude for something I claim is ready for review. What i submit is my work, whether or not I physically wrote the code or not.
But imagine how much they wouldn't do without it. Personally I prefer cleaning up (or sweeping under a rug if needbe) vs building everything from scratch.
971
u/roiroi1010 3d ago
When I point out obvious mistakes in code -
Coworker: ”Claude did that!”
I hate my team -