The conversation

philboHNSource author
Lessons learnedExperience excerpt · English

For decades, engineers understood that large code reviews are harder than small ones

For decades, engineers understood that large code reviews are harder than small ones. Out of both politeness and a desire to receive better code reviews, we learned to break our large changes into smaller chunks. Some engineers took things even further and replaced code reviews with pair programming. But then LLMs showed up and everyone seems to have forgotten those lessons. They can be still be applied now using coding agents, if you're willing to push back against the default setup and change your mode of thinking a little bit. Of course it doesn't help that an entire industry is dedicated to persuading us that maximizing token spend is the only way to get shit done. I appreciate this probably seems like an extremist take, but I wrote some more about it here in case there's anybody out there who identifies with it: https://philbooth.me/blog/agentic-coding-and-mental-models

Original discussionAutomating Myself Out of Development85 source comments · at import
3

What was this responding to?

Parent context · original excerpt

GN
gnunicornHN

Interestingly, despite it being much more detailed and a lot more process and procedure than what I currently do - which is more akin to the version 0 described, but in parallel - we come up at the same final problem: reviews and quality assurance. I sign off the code I merged, part of company policy but also just to be sure it is actually decent. But reviewing has become the real draining bottleneck: even stacked PRs, if that total 5-6k lines is not a 5min job. Even if I brainstormed and set the plan, that's really the part that doesn't scale right now for me in this. But the author is very shy about that: either the changes arent that big in the end or they trust the process enough to review in a more casual manner. Being equally untrusting I can't do that ...

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 3

Direct replies available in this import. Original-language excerpts.

AO
aocallaghan17HN

Agree with this completely. This push for more autonomy I think is the complete wrong direction for how to use LLMs. I want less code to maintain not more that I don't even fully understand. I think research and very supervised coding with lots of guardrails is the way to actually gain productivity from these tools.

Full original
FI
firegodjrHN

I think that's reasonable. My only gripe is that making small sets of changes is often faster to do by hand than waiting on llm reasoning, so I've found it amounts to very little speedup.

Full original
GI
girvoHN

> They can be still be applied now using coding agents, if you're willing to push back against the default setup and change your mode of thinking a little bit. Of course it doesn't help that an entire industry is dedicated to persuading us that maximizing token spend is the only way to get shit done. Yeah the problem is the executives and managers around us are demanding we ship massive features as quickly as possible, and I like having a job and dread having to find a new one in this market...

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.