Comment

Comment by rDr4g0n

my technique to get a similar benefit is to write a quality PR description.

a good PR description should be compact and helpful. describing something complex in a compact and approachable way requires understanding.

the process of writing the description often leads me to understand hidden decisions the LLM made and occasionally uncovers bugs.

my PR descriptions separately answer the following questions:

Why is this change being made? a sentence or two about the problem, objective, etc, and a link to more detail (tickets, docs, etc) if available

What does this change accomplish? typically describes observable changes, requirements, etc. crucially this section avoids describing how the change is implemented. the act of separating what from how isn't new, but it's crucial in the LLM era

How does this change accomplish its goal? the answer to this question is "read the code", but the job of a PR description is to provide a quick hand drawn map before dumping the reviewer into the jungle. drawing a good "how" map requires understanding the jungle and the new path through it.

the risk with LLMs (or any outsource) doing the work is the loss of understanding. this exercise encourages understanding.

parent rDr4g0n 23 days ago

No comments yet

Be the first to share your thoughts.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton