undefined | Better HN

0 pointsbix61mo ago0 comments

Hi Boris, what is the advantage of using /code-review vs just asking Opus to “code review”?

As a casual user working on hobby projects, I struggle to keep up with the pace of changes and knowing what to use when. My default now is to use Opus for all coding (sonnet is fine but seems dumber) and to prompt it for everything I need. I’ve had great success with this but clearly I’m missing power user functions with the slash commands and such.

0 comments

9 comments · 3 top-level

extr1mo ago· 5 in thread

The advantage is that /code-review supplies a structured idea of how to review and what that process should look like and then launches independent subagents to approach the issue from multiple angles.

It's analogous to how in the early days you could see benefits by telling the models to "think step by step". /code-review is something like "review angle by angle". "Consider removed behavior" and also "Look at language gotchas" and also "Look at test changes"...etc. Yes these are all somewhat implicitly already part of what "code review" means, but the models perform best with explicitness.

If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.

HlessClaudesman1mo ago

We've all spent time -fixing someone's bright idea of a -fix. I'm sceptical of the time saving of applying a -fix before I understand the problem(s).

Outsourcing comprehension to a machine is probably gonna cost you more time in the long run.

extr1mo ago

I don't even bother looking at the code until I've run a code review pass on it. Why waste my time with trivial bug fixes? I find the best way to spend time right now is like:

- Defining the issue/ticket, what "success" looks like (if I have a good idea of this), high level approach guidance 50%

- Dispatch agent to work on it 5%

- Occasionally return and nudge agent + send /simplify or /code-review 5%

- Look at the code/session summary, divergences from the plan, ask followup questions 40%

Occasionally yes there is some solution the AI chose that is suboptimal and I would prefer fixed in a different way. Mostly though it's straightforward.

bix6OP1mo ago

Thank you I will try this!

Is there something equivalent when coding in the first place? Eg /code high “prompt”

extr1mo ago

Are you thinking of the /effort level in Claude Code? I would just go with xhigh as a reasonable default. Most important thing in prompting is specifying what "done" and "success" looks like to you. Ask Claude to help you come up with a well formed request and spend most of your time on that, then paste that into a brand new session.

1 more reply

sdevonoes29d ago

It’s simpler to just use “review code”. It’s also way cheaper

bcherny1mo ago· 1 in thread

/code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.

bix6OP1mo ago

And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place?

This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.

pverheggen1mo ago

As a general rule, I'd give the Markdown a read for any skills/commands you might find useful, it'll give you a good idea of the specifics it adds.

https://github.com/anthropics/claude-code/blob/main/plugins/...

j / k navigate · click thread line to collapse

0 comments

9 comments · 3 top-level

extr1mo ago· 5 in thread

If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.

HlessClaudesman1mo ago

We've all spent time -fixing someone's bright idea of a -fix. I'm sceptical of the time saving of applying a -fix before I understand the problem(s).

Outsourcing comprehension to a machine is probably gonna cost you more time in the long run.

extr1mo ago

I don't even bother looking at the code until I've run a code review pass on it. Why waste my time with trivial bug fixes? I find the best way to spend time right now is like:

- Defining the issue/ticket, what "success" looks like (if I have a good idea of this), high level approach guidance 50%

- Dispatch agent to work on it 5%

- Occasionally return and nudge agent + send /simplify or /code-review 5%

- Look at the code/session summary, divergences from the plan, ask followup questions 40%

Occasionally yes there is some solution the AI chose that is suboptimal and I would prefer fixed in a different way. Mostly though it's straightforward.

bix6OP1mo ago

Thank you I will try this!

Is there something equivalent when coding in the first place? Eg /code high “prompt”

extr1mo ago

1 more reply

sdevonoes29d ago

It’s simpler to just use “review code”. It’s also way cheaper

bcherny1mo ago· 1 in thread

/code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.

bix6OP1mo ago

And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place?

This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.

pverheggen1mo ago

As a general rule, I'd give the Markdown a read for any skills/commands you might find useful, it'll give you a good idea of the specifics it adds.

https://github.com/anthropics/claude-code/blob/main/plugins/...

j / k navigate · click thread line to collapse