19 pointsby sevenseacat4 hours ago8 comments
  • ro_sharp31 minutes ago
    Why do so many people think that code reviews are primarily about mistrust or spotting mistakes?

    IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..

    • mitxela28 minutes ago
      We don't need shared understanding and agreement in the AI era. The AI will do that for us.
      • nullisland004 minutes ago
        Until the cowboy at the prompt adds something you don’t want and your product is on the hook for it.
    • rdevilla24 minutes ago
      [dead]
  • thefz3 minutes ago
    > Deep expertise in a specific technology is a lot less valuable when you have a collaborator that has read all of the source code for that framework and can answer any question about it in a few seconds. This is another case (like what I mentioned above) where knowledge is less valuable, but where judgement is still important.

    How can one judge on something they don't know?

  • artico_chewyan hour ago
    Something's wrong with that code review strategy. There should be knowledge share.

    And yeah perverse incentive is a thing when you grad your own homework.

    And these two things combine. Who decides what "done" means? If everyone faces consequences for getting that wrong the next day it's probably fine, but they probably don't.

  • bengold1443 minutes ago
    To your note about nobody doing code reviews. I've found that to be fine in fairly straightforward applications and/or small teams where individual SWEs can own verticals.

    As soon as you have larger teams with complex architectures trying to make decisions and push larger initiatives forwards, decisions made in one part of the stack really matter in other parts as they get built on and have momentum that can be hard to reverse, even if code is cheap.

    Not to shill my work too much (https://www.archme.io) but I think for the reason above the importance of code review has moved from code to architecture, and code in general is the wrong abstraction to be working with as a human engineer in 2026+.

    • vachina19 minutes ago
      This is why you should start with design spec before starting a line of code.

      If the spec cannot resolve ambiguity you refine the spec not the code.

  • Artooooooran hour ago
    And that way, bit by bit, we become dependent on a few global corporations that own the brain that we used yo use. Brain as a service, dammit. Don't get banned on a whim or you'll lose your ability to think.
  • lelanthran25 minutes ago
    > Bad ideas that aren't bad anymore

    ...

    > About a month ago we changed that [PR process] completely.

    ...

    > And it’s been working great!

    How can you tell it's not a bad idea in just a month? How can you tell that it's been working great in just a single month?

    Seems that all you are measuring is short-term gains, not long-term liabilities.

    You can see the same "gains" in any endeavour if you're willing to eat the seed-corn.

  • fahrvrgnugen31 minutes ago
    [dead]
  • Animatsan hour ago
    They were only bad ideas for puny human brains. But for super intelligences...

    Experience has less value now.