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.
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.
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
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
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