Hacker News Reader

Comment by clintonb | Hacker News Reader

I am contemplating code review within my own organization, and the question I return to is:

> Does this organization prioritize human learning?

That has been my primary motivator for code reviews. I want to teach and learn from others, especially given the decreasing levels of collaboration due to increased AI usage.

The sad truth is that all of my feedback just goes straight to agents. Maybe 10% is reacted to by a human, so I’m left wondering if there’s any value to a real review aside from poorly training robots to do my job, and further atrophying the abilities of my team members.

View on HN

Well, I can tell you that at my current job we had something of a crisis over the summer when we realized that nobody could make changes without fear of breaking things anymore because we lost the ability to tell which existing behaviors were and were not safe to change.

Previously the knowledge needed to discern that sort of thing would be disseminated through both design and code review sessions. But plan mode and AI code review largely put an end to that.

So we put our heads together and came up with some new policies about project management and how we use AI, and things have steadily getting better since then.

(Though, in fairness, the one guy who seems to actually enjoy getting paged after hours seems to be having less fun.)

What plans did you put in place? What did you do to ensure knowledge transfer?

"We reinvented everything and called it a success"

Strict WIP limits, all non-trivial projects need two human collaborators who are both responsible for understanding and signing off on the project plan, docs, code, test strategy, etc., and regular sync-up meetings.

So do you still have humans doing code review? What did “sign off on code” look like in practice? (We’ve been thinking about this a lot too)

Yes, human code review is back. AI is allowed to help, but we require that two actual humans actually understand every change. And yeah, it did speed things up. Not the rate at which we were shipping code, of course. But the rate at which we were shipping usable product.

This is actually in line with a well-established Six Sigma practice. When you've got a poorly performing value chain, the first thing to do is find out which step is struggling and then force the step immediately before it to slow down. If the reason why isn't obvious, search for a clip of the I Love Lucy chocolate factory scene on YouTube for a perfect explanation.

Reply on news.ycombinator.com