Reviewing code you didn't write | Hacker News Reader

Reviewing code you didn't write

coles.codes

16 pointscolescodes6 comments

I am writing far less code than I used to and I’m finding that reviewing is a different skill entirely (and one I need some work on). I have always worked by myself and my past reviews were the sleep on it and see how it reads in the morning variety.

I liked the article because what I struggle a little bit with is where to start (even though I wrote the ticket before I pointed the agent at it and often stay in the sessions to supervise and direct). There’s something that just feels bewildering about code I didn’t write.

One thing reviewing does make me more disciplined about is making the agent write small diffs and descriptive commit check points. Probably the default for many of you who work on teams, but something I didn’t really follow when I had the entire code context and changes in my head.

I have been making use of git-absorb. Leaving a really tidy git history is satisfying.

https://github.com/tummychow/git-absorb

The bewildered feeling is doing real work, I think. Reading my own code I'm checking it against a design I already have in my head. Reading someone else's I have to rebuild the design first, and that's where most of the bugs turn up.

What surprised me is that writing the ticket myself didn't help much. The agent satisfies it in ways I wouldn't have picked, so I'm still rebuilding.

git-absorb is new to me, thanks.

Author here. This came out of the last couple of weeks at work, where review has crowded out writing code because teammates and agents both produce it faster than anyone reads it. The short version: review the approach before the lines, and give AI-generated changes less benefit of the doubt, since fluency no longer signals correctness.

review the outcome, not the code... if the world continues to be dominated by AI coding agents, the code will increasingly become irrelevant.

The outcome might not be deterministic (edge-case, race condition, weird error path). This is also true with human but at least a decent engineer can sit in a review board walking through their reasoning on why did they do what they did and their rationale

Good luck asking AI on "why use X, why X and not Y", yes they will answer but it is based on their current, ad-hoc deductions, not their past reasoning

I guess the same can be said for legacy code base where the original author had left years ago and currently running a kebab shop in Dagestan but my point still remains

The Dagestan kebab shop guy left a trail though.

Commits, has a PR thread, maybe a ticket. There's something to dig into, and an agent is decent at excavating it.

Ask the agent why X and not Y about its own code and you get a fresh answer made up on the spot with no connection to what happened when it was written.

Reply on news.ycombinator.com