Hacker News Reader

Comment by mlrtime | Hacker News Reader

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?

View on HN

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.

I am comparing it with a skilled cousin or another employee, as a thought exercise.

Your personal incredulity aside, if you write code and create a PR, you're expected to know and understand the code you're writing, and you're expected to have done at least some means of verifying correctness. If you can't do that, ask for help from someone who can, earlier in the process, and/or give the task to them for normal prioritization.

Your example reveals a common organization smell: work not going through the normal process for prioritization and planning. If you've done that, and the work is deprioritized, that's because the company has decided that your thing isn't as important for engineering to do. Get over it and be patient, or ask a mentor for help selling the business on the value of your thing. Creating a PR bypasses that process and burdens engineering with more work (having to understand and rework slop) than if engineering had coded the thing to begin with.

tl;dr: if a company is internally strategically unaligned, organizational dysfunction is bound to follow

> 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.

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.

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

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.

Reply on news.ycombinator.com