Yeah. It does this. Pretty consistently and replicably depending on the issue, in fact! Yet I can point exactly where it fails.
Why are we not showing the bad choices? On my computer I have hundreds of diffs stored by my agent code review tool that point to style/architecture failures (and in the end, the result of that iteration on the AI output)
I'm not quite sure how people are generating unsalvageable outputs. I'd never ship the result of a first AI pass, either. I review all the code and the architecture, within reason (eg: in Rust I don't preoccupy myself anymore with precisely scoping pub, or whatever, unless I'm making a library crate). I sent a "changes requested" prompt+json to my agent, and it interactively fixes everything (even style, even comments with manual patches with my in-review-tool editor)
Jesus! Claude could've told this guy all these things. People underestimate how much the average malloc implementation does and how many considerations it makes. Or how much IO sucks.
Claude often does things in more detail, and even better, than I would, in the first pass. But I don't understand how anybody stands comments generated by an LLM?
It's seriously the thing that worries (and bothers) me the most. I almost never let unedited LLM comments pass. At a minimum.
Most of the time, I use my own vibe-coded tool to run multiple GitHub-PR-review-style reviews, and send them off to the agent to make the code look and work fine.
It also struggles with doing things the idiomatic way for huge codebases, or sometimes it's just plain wrong about why something works, even if it gets it right.
And I say this despite the fact that I don't really write much code by hand anymore, only the important ones (if even!) or the interesting ones.
Also, don't even get me started on AI-generated READMEs... I use Claude to refine my Markdown or automatically handle dark/light-mode, but I try to write everything myself, because I can't stand what it generates.
> Also sorry to sound egotistical but I think I was an outlier that drifted into doing educational things, many or most kids will spend every moment they get just playing video games.
I am in the same predicament as both of you, having grown up with unfiltered internet access, and not wanting it to have went any other way (I love my life, actually!)
There is a condescending tendency when people hear what I said above, to tell me that I am an outlier, or, God forbid, a "genius", and other equally worrying conclusions regarding my character.
I agree that, today, there are millions more ways that children can fall for objectively negative things, that have been completely, and intentfully engineered to be terrible in a way which can be exploited for profit.
But also, I simply think that, with enough access to mind-numbing content, for long enough... people will simply realize that, actually, they don't want that. At least, not just that.
Adults are not a good term for comparision in the matter of less aggressive addictions, like with social media, because they already have lives they want to escape, with responsibilities and whatnot.
These are not scientifically sourced claims, but, in my experience, children have a lot more time, energy, curiosity, and will/intent to create, for one reason or another, and they have been doing those things since time immemorial.
This is just a consequence of having access to ~the entirety of all human knowledge at their fingertips, with no restrictions, and with an incredible amount of free time at their disposal.
This doesn't sound like a particularly difficult problem for some scenarios.
It's definitely convoluted as it comes to memory obtained from the stack, but for heap allocations, a debugger could trace the returns of the allocator APIs, use that as a beginning point of some data's lifetime, and then trace any access to that address, and then gather the high-level info on the address of the reader/writer.
Global variables should also be trivial (fairly so) as you'll just need to track memory accesses to their address.
(Of course, further work is required to actually apply this.)
For variables on the stack, or registers, though, you'll possibly need heuristics which account for reusage of memory/variables, and maybe maintain a strong association with the thread this is happening in (for both the thread's allocated stack and the thread context), etc.