3 ms·
> It's asking somebody who writes code to now read and debug others code. This has been a big part of the job for anyone on a team for at least 20 years. I do
by christophilus 6d ago
> It's asking somebody who writes code to now read and debug others code.
This has been a big part of the job for anyone on a team for at least 20 years. I do agree that it’s the hardest and worst part of the job, and has now become the majority of the job for anyone who isn’t vibe coding. So, that sucks.
- phrotoma 6d agoIt's a different of degree, not kind. Anybody who has reviewed pull requests can tell you that sooner or later you approve a PR after many rounds of changes because it's finally "good enough". Fighting with a robot to just do the damned thing is less fraught because they don't get offended by critiques but it takes more round trips to get them pointed in the direction you want.
- thw_9a83c 5d agoFighting with a robot requires also a different kind of attention. When you're reviewing the human code, you can quite easily guess an overall seniority and competency level of the author and then you can adjust your level of attention to every detail. E.g. if the solution requires an understanding of some core idea, ones the human understands this core idea, you can be quite sure that it is consistently implemented everywhere. With AI, 90% of the PR could be expertly implemented but then, for no obvious reason, 10% could be low-quality surprise. I've never seen such unbalanced output from human programmers.
- zahlman 5d agoIf 90% of it was fine, maybe it would be better to just fix the 10% yourself rather than "fighting with a robot" to try to get an automated fix.
- thw_9a83c 5d agoYes, but those 10% of a problematic code is not easy to find without a very detailed study of the whole PR. And since most of the code looks (and usually is) very well-written, the human brain somehow doesn't expect to find those low-quality or sub-optimal parts in such code. That's why I wrote that reviewing the AI code requires different kind of attention.
- OptionOfT 6d agoDisagree. At least back in the day there weren't endless comments about how this widget is load-bearing, and how honestly the other widget carries the derived widget, referencing decision ADR-100 that is nowhere to be found. All these comments matter because once accepted as part of the codebase the next LLM takes these comments as canonical. The largest problem these days is the volume of code developers are expected to review. The volume went up significantly.
- Daishiman 5d ago> At least back in the day there weren't endless comments about how this widget is load-bearing By far the biggest problem 90% of developers have with AI is that they should be turning off comments, as it's clear that the training data they have is no good for developing a theory of mind for an engineer who has to read them. I've turned them off and add them myself at review time and am quite happy.
- zahlman 5d agoRequiring the coding agent to (try to) iterate on code clarity until comments are no longer necessary, probably doesn't hurt either. Save the commentary for conversation logs, agent Markdown files, and other sorts of documentation.
- theshrike79 5d ago> the next LLM takes these comments as canonical This is the best and worst thing about LLM coding agents. They trust comments way too implicitly. And then the errors just keep compounding. Or a temporary hack that becomes "load-bearing" because the agent doesn't figure out that it's supposed to be a temporary testing shim - instead it keeps building on it until it basically duplicates what it's mocking.