Thread

1. zug_zug · 1789908167 · focus · HN ↗

   I think this is a bit of a simplistic mental approach. I've certainly seen a lot of "The engineer owns the outcome, AI is just a tool, don't release anything you don't vouch for."

   However, I just don't think that's realistic. It's asking an author to suddenly become an editor. It's asking somebody who writes code to now read and debug others code.

   It can actually be harder to find the the bug in a tricky piece of code than it can be to write your own correct code from scratch. I see AI introduce all sorts of bugs all the time in my personal projects that I would never introduce, and would never think to test for, especially around anything graphical.

   1. christophilus · 1789908765 · focus · HN ↗

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

      1. phrotoma · 1789910868 · focus · HN ↗

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

         1. thw_9a83c · 1789976778 · focus · HN ↗

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

            1. zahlman · 1789984370 · focus · HN ↗

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

               1. thw_9a83c · 1790003456 · focus · HN ↗

                  Yes, 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.
      2. OptionOfT · 1789919170 · focus · HN ↗

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

         1. Daishiman · 1789961337 · focus · HN ↗

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

            1. zahlman · 1789984218 · focus · HN ↗

               Requiring 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.
         2. theshrike79 · 1789988245 · focus · HN ↗

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

Unofficial Hacker News client; not affiliated with Y Combinator.