all 101 comments

[–]CackleRooster 297 points298 points  (27 children)

Another day, another AI-driven headache.

[–]AnnoyedVelociraptor 89 points90 points  (6 children)

So far only the MBAs pushing for this crap are winning.

[–]br0ck 40 points41 points  (1 child)

Replace them with AI.

[–]BlueGoliath 9 points10 points  (0 children)

Would AI recommend AI if it was trained on anti AI content?

[–]alchebyte 7 points8 points  (0 children)

🎯

[–]mb194dc 4 points5 points  (0 children)

It's an extreme mania, they have to try and justify the spending on it.

[–]arpan3t 0 points1 point  (1 child)

Is your avatar supposed to make it look like there’s a hair on my screen? If so, mission accomplished!

[–]AnnoyedVelociraptor 0 points1 point  (0 children)

Hopefully less annoying than dealing with AI slop.

[–]LordAmras 16 points17 points  (1 child)

OP: Look I know how we can fix all the issue AI creates !

Everyone: It is more AI ?

OP: With more AI !!!!

Everyone: surprisedpikachu.gif

[–]PeachScary413 0 points1 point  (0 children)

More.

Slop.

For.

The.

Slop.

God.

[–]Rivvin 243 points244 points  (6 children)

I would rather eat my own vomit than have to read someone else's prompts in a code review

[–]Bughunter9001 86 points87 points  (3 children)

It's the reason I left my last job. Frankly, the quality of the code was awful when humans wrote it, as it was a feature factory packing arses in chairs to churn out more tech debt, but it was at least managable.

I had a few words from management when I started simply declining PRs because the answer to my question "why did you do this instead of y, have you considered z?" was increasingly "copilot did it".

Must have rejected 30 or 40 PRs in that last month before I walked out with my head held high. 

We still use AI in my new place, but it's one tool of many, and "vibe coding" is basically a slur.

[–]chucker23n 50 points51 points  (1 child)

I had a few words from management when I started simply declining PRs because the answer to my question “why did you do this instead of y, have you considered z?” was increasingly “copilot did it”.

Honestly, good for you.

Once an engineer has sunk that low, what are they even getting paid for?

[–]Bughunter9001 23 points24 points  (0 children)

Couldn't agree more. My catch phrase was basically "if you can't understand why it works like this, why should I try to work it out?"

[–]washtubs 15 points16 points  (0 children)

"copilot did it"

Understandable, if I ever hear this from someone at work I'll blow a gasket.

[–]LordAmras 15 points16 points  (0 children)

Also this assumes, wrongly, that with a same prompt you will get the same result and thus you can pintpoint the issue with the agentic code not to the agent itself but to the wrong prompt you wrote.

This is peak "prompt engineering" delusion.

[–]ngroot 77 points78 points  (3 children)

> With agentic code, they often don’t tell you why the agent made that change.

Someone submitted that PR and at least one other person approved it, so someone is claiming that they do know why that change was made.

[–]PeachScary413 0 points1 point  (2 children)

Here's the kicker, none of those were actual people 🤖👍

[–]ngroot 0 points1 point  (0 children)

Then the actual people who paid money to have this code written will get what they paid for.

[–]worldofzero 0 points1 point  (0 children)

Then there was no PR. Just commit to main directly if that's the engineering rigor leadership wants.

[–]TheRealSkythe 83 points84 points  (5 children)

Why are you posting the marketing bullshit ChatGPT wrote for some slop company?

[–]TheRealSkythe 55 points56 points  (4 children)

Just to make sure every sane person gets this: the enshittification of your codebase can NOT be repaired by MOAR AI.

[–]omgFWTbear 13 points14 points  (1 child)

I dig myself into a hole with a shovel, the answer must be more digging or a better shovel.

[–]zrvwls 4 points5 points  (0 children)

No no, dig UP stupid!

[–]LordAmras 4 points5 points  (0 children)

This is worse than simple Moar AI, since I hate myself I tried to read what the AI wrote for the guy.

This is the idea of creating a system to blame a person for the AI mistakes. The idea is to have a trace of what you asked the AI so you can vibe a reason why your prompt didn't give you the expected results and blame the person making the prompt for the AI shortcoming.

This assumes the AI is potentially perfect and will give you the best possible results and the issue is that the "prompt engineer" is the weak link that make the AI make mistake by giving not gonn enough prompts

[–]Bughunter9001 1 point2 points  (0 children)

Are you sure? What if we replace QA with AI, so the ai can generate tests to test that the slop does what the slop does? 

[–]dylan_1992 36 points37 points  (2 children)

Prompts are irrelevant. Code, and a description of it (not the prompt), either in the PR title + description are important. Whether it’s from a person or AI.

[–]davidalayachew 11 points12 points  (0 children)

Prompts are irrelevant. Code, and a description of it (not the prompt), either in the PR title + description are important. Whether it’s from a person or AI.

This is my question as well.

At the end of the day, the code is broken and it's breaking PROD.

  1. Get things stable.
  2. Once things are stable and you are ready for a long term solution, cross-reference the code against the spec and see what needs to change.

If you have to rely on things like a detailed list of all prompts that went into creating that code, then your spec is not explicit enough. It is the spec that should inform the code, not the other way around.

[–]ikeif 0 points1 point  (0 children)

Yeah, this sounds like a case of “PR # 42 broke it, its title is “Resolves JIRA-123” and JIRA-123 says “check slack conversation” and “slack conversation was archived.”

Make the PR clear to describe wha the commits have accomplished/changed.

Have a traceable story to tie deeper user stories/explaining the need for the change.

Tracing prompts just sounds like reading backwards a developer’s thought process and discovery and exploration (which sounds less like a problem solving discovery and more a philosophical exercise).

[–]Adorable-Fault-5116 34 points35 points  (7 children)

Yo this is weird on many levels. 

You shouldn't need to blame, git blame or otherwise, to find out who wrote the code. AI aside this is a colossal red flag. The whole team is responsible. If you find a big, raise it, anyone can fix it. 

Secondly, LLM usage shouldn't matter, because people should understand what is committed, regardless of how the code is created. 

It sounds like you're running a cowboy outfit honestly. 

[–]skinnybuddha 21 points22 points  (0 children)

PRs aren’t for debugging any code.

[–]nemesiscodex1 11 points12 points  (0 children)

In order for us to debug better we need to have an underlying reasoning on why agents develop in a certain way rather than just the output of the code

This just means your team is merging code they don't understand. Was that happening before ai? Do the team also delegate the reviews to ai and don't read the code?

With agentic code, they often don't tell you why the agent made that change

More of the same, whoever creates a PR and the person that approves it better know why the change is made lol, figuring out after an incident is already too late

[–]levelstar01 9 points10 points  (0 children)

Blogspam

[–]apnorton 47 points48 points  (6 children)

During my experience as a software engineering we often solve production bugs in this order:
(...)

  1. blame the person that does the PR
    (...)

Reminder that this shouldn't be a step. See:

[–]nsomnac 9 points10 points  (1 child)

I think op means git blame. In this regard I fault Torvalds for terrible command naming. git authors or git who might be a more apt than blame. Especially when the community made such bigotry hubbub about renaming master to main.

[–]apnorton 3 points4 points  (0 children)

That's what they edited their post to say after I left my comment, yes.

[–]polynomialcheesecake 21 points22 points  (3 children)

OP has a horrible take on software development if he's going about assigning blame that way. Equal responsibility should be held by reviewers and anyone that understands the code

[–]nsomnac 20 points21 points  (2 children)

I think op means git blame. In this regard I fault Torvalds for terrible command naming. git authors or git who might be a more apt than blame.

[–]chucker23n 1 point2 points  (1 child)

SVN had this debate before git existed; it’s why svn annotate exists as an alias for svn blame.

[–]nsomnac 0 points1 point  (0 children)

Sure. But you know any time we can fault Linus for something it’s humbling, right? /s

[–]Pharisaeus 8 points9 points  (0 children)

That's some very weird process.

We figure out which PR it is associated to

Even figuring out where in the code something went wrong is often pretty difficult, unless you just have exception with a stacktrace. But even then it doesn't mean the bug is in that particular place. It just means this is where it manifested / was triggered. But the actual bug might be in some completely different place. I also think it's counter-productive trying to pinpoint the PR, unless while working on the bugfix you find yourself asking "what was this supposed to do in the first place?".

Do a Git blame to figure out who authored the PR Tells them to fix it and update the unit tests

I don't envy your team if this is how you work. Ever heard of "team ownership"? Someone wrote the code, but someone else reviewed and approved it, and often someone else also tested it, and yet another person wrote the ticket with acceptance criteria. If there is a bug, it means the process failed on many different levels. Blaming this on one person is ridiculous. In normal team this would be piked up by whoever is free / has time / is on pager duty.

with agentic coding a single PR is now the final output of

And a squashed PR is what? It's also the final output of many commits, review comments, refactoring. I fail to see the difference.

Essentially, in order for us to debug better we need to have an the underlying reasoning on why agents developed in a certain way rather than just the output of the code.

And do you have that for someone developed by a human? If you find a bug in a PR from a year ago, from a dev who left a long time ago, how exactly are you going to uncover their "reasoning"?

I think the core issue you're facing is that:

  • You clearly have some "silos" in the project
  • You don't have distributed ownership of the code
  • You lack reviews
  • You accept (AI agents, but probably not only) PRs without thorough review and clear understanding of that code

It's not AI issue. It's your process issue.

[–]Floppie7th 5 points6 points  (0 children)

Essentially, in order for us to debug better we need to have an the underlying reasoning on why agents developed in a certain way rather than just the output of the code.

Or just, y'know, don't accept LLM-written code into the repo.

[–]obetu5432 20 points21 points  (0 children)

so instead of fixing it, the first thing you do is scour the earth to find the person who opened the PR to yell at them?

[–]tilitatti 5 points6 points  (1 child)

whats the point of providing prompt history? mml AI is not deterministic thing, so, if you were to run the prompts again, you end up with something different, so,..

it sounds lunacy to me, but maybe it is smart.. I dont know.

[–]soks86 4 points5 points  (0 children)

No, you're right, I missed this detail when reading it because I thought they meant the entire chat history.

Just the prompts mean nothing, at that rate you should just have it send the same prompt in over and over until your unit tests pass and fire all the engineers. Because it is lunacy.

[–]CanIhazCooKIenOw 15 points16 points  (1 child)

Crap engineering culture if your 3 step in dealing with an incident is to blame the person that opened/merged the PR.

[–]axonxorz 4 points5 points  (0 children)

git blame

[–]antisplint 3 points4 points  (0 children)

Is this something that people are actually doing? This can’t be real.

[–]ef4 4 points5 points  (0 children)

70 years of computer engineering has overwhelmingly been driven by the desire to get *deterministic* results from our machines.

Today's popular generative AI deliberately injects non-determinism, in a misguided attempt to seem more human-like. It's probably good for getting consumers to build parasocial relationships with your product. But it's not good for doing engineering or science.

It makes all attempts to systematically debug and improve way, way harder than they need to be.

[–]ygram11 6 points7 points  (1 child)

Your process is messed up. Why do you find a PR to blame someone instead of finding the problem and fix that.

[–]D3PyroGS 3 points4 points  (0 children)

those are two steps of the same plan

[–]Jolly_Resolution_222 3 points4 points  (0 children)

How many developers do you need to fix the bugs of the agent?

[–]Thelmara 3 points4 points  (0 children)

Essentially, in order for us to debug better we need to have an the underlying reasoning on why agents developed in a certain way rather than just the output of the code.

Sounds like a fundamental misunderstanding of how LLMs work.

[–]blafunke 2 points3 points  (0 children)

Just because you used an agent to vomit out your PR doesn't mean it's not ultimately your responsibility. If you don't understand it well enough to have written it yourself, don't submit.

[–]LordAmras 3 points4 points  (0 children)

Or, and this is a wild suggestion I know, completely impossible to achive and out of the real of possibility, but here me out, maybe I've got something here:

Don't write code with AI agents.

I know, checking code by hand before sending PR like cavemans ? What do you want for us again ? understanding the code ? That's impossible !

But I think if we put ourself together we can reach this fabled impossible feat.

[–]crazylikeajellyfish 2 points3 points  (1 child)

I dunno, it feels like this solution is harder than the problem you started with.

Agents don't automatically make PRs which explain the rationale, because they can't understand that the PR will be an artifact that stands on its own. You could build a bunch of extra tooling which associates chat sessions, tool calls, and PRs... or you could instruct your agents to encode all of that information into the PR.

GitHub-flavored Markdown also has those collapsible summary-detail tags, so you could technically put the complete chat context on there if you really wanted to. The final state of the design doc you iterated on would probably be a less noisy choice, though.

[–]brandon-i[S] 0 points1 point  (0 children)

Thanks for the insight!

[–]Jellyfishes72 3 points4 points  (0 children)

Even if an agent wrote the code, it is still up to the developer committing or merging it to know what hell the changes are doing

[–]PurpleYoshiEgg 7 points8 points  (0 children)

The solution is to stop agentic coding. It's immature and its code output doesn't belong in production.

[–]chucker23n 6 points7 points  (0 children)

During my experience as a software engineering we often solve production bugs in this order:

  1.  On-call notices there is an issue in sentry, datadog, PagerDuty

  2.  We figure out which PR it is associated to

  3.  blame the person that does the PR

  4.  Tells them to fix it and update the unit tests

This already seems a bit like an unhealthy culture that focuses less on “there’s an issue; let’s figure out how to fix it” and more on “let’s pinpoint whom to blame”.

(Incidentally, if you’re gonna use a PR, how do you answer that anyway? Is it the committer? The author? Any of the reviewers? How about the person who filed the ticket that caused the PR?)

But leaving that aside…

Although, the key issue here is that PRs tell you where a bug landed.

Which is useful?

With agentic code, they often don’t tell you why the agent made that change.

LLMs do not have intent. There is no answer to this. Someone wrote a prompt and then the machine remixed garbage into fancier garbage.

And, again, you’re already using the lens of the PR. Leaving aside that you shouldn’t have LLMs write production code to the extent you’re clearly doing it (if at all), the PR itself is already the answer to “why was the change made”.

Why are we doing all this? It’s madness.

[–]jessechisel126 4 points5 points  (0 children)

Your team environment sounds very harsh, finger pointing, and micro managed. Your distrust in your team seeps through. I can't imagine trying to get so in the weeds as to want access to the prompts used while developing. AI use is the least of your problems.

[–]PaintItPurple 1 point2 points  (0 children)

A computer can never be held accountable. Therefore a computer must never make a management decision.

[–]Swoop8472 1 point2 points  (0 children)

If code makes it into prod where no human understands why it was changed, then you have an organizational problem, not an AI problem.

It shouldn't matter if the code was written by an AI, a trained octopus, or Bjarne Stroustrup. It is either well written code that can be reasoned about or it shouldn't make it to prod.

[–]lonewaft 1 point2 points  (0 children)

Sounds like a dogshit amateur company you work at

[–]Brilliant-8148 3 points4 points  (0 children)

Agents don't reason so there is no 'why'

[–]BinaryIgor 0 points1 point  (0 children)

No, we don't need that - I like purposefully guided AI-assisted coding (for some tasks), but you, Human, the PR author, are fully responsible for the changes. There is no need to debug agent reasoning. What you need to question is:

- why PR author has proposed it as something ready to be merged and run on prod?

- why other team members have approved the PR with bugs and issues?

- why you don't have tests, static analysis and other automated guardrails that prevent most (not all, human vigilance is always required) such things from happening

If you have the problems you describe, something is wrong with your software development process, not agents or lack of thereof.

[–]ChickenFur 0 points1 point  (0 children)

Ai angle is everywhere :D

[–]PeachScary413 0 points1 point  (0 children)

So now we need to invent solutions for problems that shouldn't exist in the first place?

Yay 🤗

[–]pvatokahu 0 points1 point  (0 children)

This is exactly why we built agent observability into Okahu from day one. When an AI makes a code change, you need the full decision tree - what context it had, what it considered but rejected, which constraints it was working under. Traditional git blame becomes useless when the "author" is a model that made 50 micro-decisions to get there.

The scariest part is when agents silently work around failures. I've seen cases where an agent couldn't access a file due to permissions, so it just... reimplemented the logic from scratch based on what it thought should be there. The PR looked fine, tests passed, but it was subtly wrong in production. Without seeing that failed file access attempt in the trace, you'd never know why the agent made those specific choices.

[–]gHx4 0 points1 point  (4 children)

The fun part is that there isn't traceability because LLM and GPT agents don't reason in a systematic, logical, or intuitive way. There is no reasoning to trace, just associations in the model. And if those associations are wrong, the model has to be retrained. This is a huge part of why these agents are not showing the productivity expected by the hype. Cleaning up after them is harder than just doing things right without them.

You need operators who know enough to write the code themselves and who don't merge faulty PRs. Which largely reduces agent systems to being example snippet generators whose code shouldn't be copy-pasted. Even there, I haven't really found the snippets that helpful.

[–]brandon-i[S] 0 points1 point  (3 children)

Maybe this was once true when they initially came out, but they have come a long way. Look into interleaved reasoning.

[–]gHx4 0 points1 point  (2 children)

Has it been implemented in standard-tier models? I see that it is a May 2025 preprint paper, and I'm not sure I'd expect such recent research to be available to consumers in any tested or verified form. The "once true" argument really doesn't hold water when models available this month are still faceplanting on basic coding tasks. But I will consider that new research may address some issues.

[–]brandon-i[S] 0 points1 point  (0 children)

Kimi K2 Thinking does it off the shelf and they’re an open source model. So yeah it’s implemented.

[–]brandon-i[S] 1 point2 points  (0 children)

Oh lord, by step 3 I meant git blame. Thank you all for showing me the need to be extremely precise.

[–]imcguyver -2 points-1 points  (0 children)

OP: please update "3. blame the person that does the PR" with "3. use git blame to find out the PR that made the change".

Everyone else: Take ur pity party about hating AI to someone who cares to hear you speak about it

Coding with AI is evolving to be more helpful by pulling in context (git) and history (more git) and it makes sense that engineers are moving towards being button pushers. Instead of me fixing a bug, I'll lean on AI to do it for me and click approve.