Comment by jasonkester
14 hours ago
I just can’t understand why this is not a fireable offense.
Like, I can see getting a strong warning the first time somebody notices you do this, then if you persist you’d have to be let go.
Just like anybody else who is clearly not doing their job.
Why would you tolerate this sort of behavior at your company?
what is often overlooked in corporate culture: if you take a step back, two coworkers refusing to cooperate, regardless of the reason, is a typical "corporate kindergarten" scenario for the manager to take care of.
To avoid rushed or incorrect decisions, conflicts intentionally move through gradual escalation. If someone behaves unprofessionally, for example by submitting a code review they do not understand, the first step is to establish the likely cause.
They may ultimately be at fault, but that does not absolve the surrounding environment. The culture may be toxic, deadlines unrealistic, or communication poor.
The best course of action for someone directly affected by uncooperative coworkers is to avoid assuming ill intent. Get them on a call and let them explain their pull request, however trivial the issue may seem. Even if the gesture is misinterpreted, you still have a far stronger position than righteous indignation.
This, I totally agree with you having a call and letting them explain the changes. One of my coworker used claude to write and push PR's and the message was so cryptic, it's not really understandable. I got him on a call and let him explain the PR. He also actually couldn't really interpret the PR message. I warned him not do this again. Now he writes by hand. I think communication between humans should be written by only humans. AI is not really good at communication.
That here.
I once worked in a place where a guy would pick on me in code reviews, he wasn't really higher position, but had been with the company longer than I was.
He was just an asshole asserting his dominance and needed to be taken a notch down by a manager and it turned out he didn't understood (or more likely didn't try to understand) the PR when confronted.
You are absolutely right to push back...
Because engineers don’t decide on hiring and firing. The managers all have KPIs to transform the org into AI-native. This is the kind of behavior that organizations encourage right now.
The psychosis is largely coming from the top.
Fish rot from the head, as they say.
I get it’s annoying and I personally hate it but firing someone for it is ridiculous. Are you expecting everyone to rewrite everything from an AI before they share it because that doesn’t sound a good use of company time either.
No. I’m expecting everyone to answer direct questions that they are the only one who can answer by thinking up the answer with their own brain then writing or speaking that.
If someone asks you a question at work, you answer them, or explain why you won’t/can’t.
If they wanted an AI answer they could have asked it themself.
I think that’s not an unreasonable expectation. Don’t share raw LLM output with other people.
Firing somebody for it is ridiculous? If you say that, then you are also obliged as a customer to keep giving your money to companies who do not perform as expected. You have no right to choose a different lawyer if your lawyer makes an AI-generated report for your case. You have no right to walk past a restaurant which is using AI-generated billboards, you shall eat there.
[dead]
It’s just a fancy version of previous tools. Imagine a coworker instead does a refactor by grepping the entire codebase and doing a find-and-replace.
Do they ensure that it didn’t accidentally overwrite something it shouldn’t have?
Or do they just throw up a PR and assume their little refactoring bash command works fine, then expect their coworkers to debug it for them?
The 1st one, of course, that is the whole point. AI is increasing the 2nd one by an order of magnitude. People think they shouldn't have to do the 1st one anymore.
It seems that this is largely coming from higher ups who are probably (consciously or not) testing the waters for LLMs being able to replace the people they're dumping the walls of text on. I don't mean in any sort of malicious penny pinching scheme either, but simply people wanting to be able to do things quickly and as close to their own demands as possible, while getting rid of the 'middle man.' It just so happens that as LLMs become ever more capable of delivering on e.g. software tasks, software engineers start to become the middle men.
My experience is it’s over eager engineers who we would have historically considered not strong who suddenly feel able to contribute in a different way
I know exactly the persona you’re describing. It’s unfortunate because they have a great learning tool now. I always felt bad for over eager engineers who were not strong. They had the right attitude but I thought lacked the learning resources and perhaps the learning skills others stronger engineers had. Before if you found yourself in an area you don’t understand. Some people make it all the way through school without learning how to learn on their own. Or at least have underdeveloped skills in that area. Once they enter the workforce and no longer have a syllabus that outlines learning plan for a subject, and an instructor and TAs that hand hold them through the learning process, learning becomes really difficult. AI could really solves that. But maybe I misunderstood the original problem.
3 replies →
Those engineers are annoying but I'm so sad about the previously great engineers who are doing this and now contributing slop everywhere.
1 reply →
I doubt higher ups wanna babysit agent software engineers all day long, it's not fun and its pretty time consuming and cognitively demanding. They'll let humans handle it - but their dream is way less humans will be needed than before.
Because it's harder to fire managers. And even harder to fire executives.
Who goes when companies need to downsize? Rarely executives; they'll always find a way to be retained...hell, they're the ones with the power to decide who goes.
How can it be a fireable offense when it's actively encouraged and rewarded?
Let me give you a scenario and see if it is in this same fireable offense line:
An Ops person who deals with company code base but is not a SWE in the code base regularly has to work around issues with this software (They are OPs). However they have read access to the source.
In the past, they see a bug and open a jira with how it was found for the dev team, and it may or may not ever get looked at.
Now ops can point claude to the repo and it can most likely [but not always] find the issue.
So this ops person can do most of the work of reproducing the bug and finding the problem/solution but doesn't understand the code. Should they not produce the findings for someone else to read/validate? Should they go back and just open the ticket the old way?
> Should they not produce the findings for someone else to read/validate?
No, they should not. They should not waste others time with output that they themselves do not fully understand. That is not even remotely helpful. The other party can use claude just as easily as they can. Using claude does not add any value in and of itself.
"Hi claude said this thing that I don't really understand please look at it for me" is never useful.
> Should they go back and just open the ticket the old way?
Yes. They should do their damn job while respecting the time of the other people they interact with who have their own different jobs to do.
I agree, they shouldn't just proxy the Claude output directly to the SWEs. THey can use Claude all they want, but the output of their effort (which goes to the SWEs) should be understood (maybe even written by) the Ops engineer. The Ops eng can use Claude to dumb it down for them to understand and can even be taught by Claude on the issue further... so Claude to the rescue still.
Replace claude code with your cousin or another employee as a thought exercise.
So write to a colleague asking to finish what your cousin/another employee thinks needs to be done. I think most people would say describe the problem clearly so that I can solve it and be responsible for the fix or let your cousin/other employee finish the job and own the solution.
This is offloading of accountability while denying credit.
Really, you are comparing the latest claude opus/fable vs my cousin with 0 knowledge of the application (user or developer)?
I'm not sure how to reply to that.
2 replies →
Yes, just file a ticket and let the people with relevant expertise and context handle it - obviously. Do software engineers ask Claude for recommendations on handling network outages and bug IT with “AI” slop? Do accountants bring “AI” slop advice to electricians wiring a building? Do lawyers use Claude to try helping physicians diagnose illnesses?
By providing a bad “AI” slop solution that you can’t evaluate, you’re actually creating more work for the people responsible for doing the thing. Now they have to understand the slop you’ve given them, explain why it’s wrong/won’t fit in the existing architecture/has other issue you can’t see without deep context. Or, they have to play politics to ignore your slop without angering you and creating more problems down the line. Either way, it’s harder than just letting them do their job.
Without understanding they have no way of judging the competence of Claude and the slop it generates. So yes they should just file a ticket the old way, after doing the actual hard work, which is reproducing the bug.
I see no harm with sharing an AI analysis in the ticket; it might save the engineer time.
as long as you've humanly verified the correctness of all the analysis first, yeah
That would make execs who asked staff to tokenmaxx look even sillier than they already are.
[flagged]