Reviewing code you didn't write
colescodes
14 points
3 comments
July 22, 2026
Related Discussions
Found 5 related stories in 494.7ms across 14,736 title embeddings via pgvector HNSW
- How to Kill the Code Review tonkkatonka · 14 pts · March 03, 2026 · 61% similar
- Code Review for Claude Code adocomplete · 67 pts · March 09, 2026 · 60% similar
- I Forgot to Code horatio_thomas · 18 pts · April 28, 2026 · 59% similar
- The primary purpose of code review is to find code that will be hard to maintain ColinWright · 338 pts · July 02, 2026 · 58% similar
- Reading code instead of writing code: The underestimated senior discipline goloroden · 23 pts · May 16, 2026 · 56% similar
Discussion Highlights (2 comments)
colescodes
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.
springtimesun
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