‹ BackHN Continuity

Thread

Jev Based Code Review

48 points · 57 comments · namanbhulawat

  1. lm2s · · focus · HN ↗
    I think your engineering process is fundamentally broken if you are generating PRs with 230 files changed so regularly that you need to bolt on more AI. You’re solving the wrong problem.
    1. ncruces · · focus · HN ↗
      Welcome to 2026.

      My dev branch got broken when I rebased to main after a week of drift.

      I had to bisect over around a million commits to the monorepo to find the culprit.

      1. pjc50 · · focus · HN ↗
        This is bananas. I've seen 25 year old software systems that haven't broken the 100k commits barrier. It feels like that ought to be enough for entire product lifecycles. What's going on that isn't simply wheelspinning?
        1. figassis · · focus · HN ↗
          This happens. I catch claude and codex committing broken code all the time, and then stacking micro fixes on top, still broken. You can go very long if you're in a harness until you realize it's just committing everything. Sometimes if you give it a goal, or a long task, this happens too, every little argument with itself, every finding, adjustment, is a new commit. None of them make sense, they happen anyway. One line nonsensical change, 20 line reassuring comment, committed.
          1. ianmarcinkowski · · focus · HN ↗
            My teammate insists that prompt and "context" engineering solve this. You just have to tell the agent "don't make any mistakes" and "keep it simple" and "don't add fixes on top of already broken code"
        2. ncruces · · focus · HN ↗
          Doing stuff at the 1e100.net scale.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.