So, I just bumped my local CLI to the new Claude Code, version v2.1.202,
and, uh, they've gone and completely rewritten how code reviews work.
It-it's a massive shift in how the slash commands behave.
Oh, nice.
Well, before we dive into the nuts and bolts of v2.1.202, this quick lightning talk
is brought to you by Jellypod AI.
Now, Lachlan, when you say they rewrote it, are we talking about a complete
deprecation, or did they just, like, split the workflows up?
They split them right down the middle, mate.
See, it used to be that when you typed /review, it would spin up this massive,
multi-agent pipeline that took ages and absolutely chewed through your tokens.
Now, /review is back to being just a fast, single-pass checker.
Super lightweight.
If you want that deep, heavyweight agent pipeline, you have to run /code-review now.
It's its own separate beast.
Ah, that makes so much sense.
I mean, running a full four-agent pipeline every time you just want a quick syntax
check is total overkill.
So, under the hood, is /code-review still doing the whole parallel processing thing?
Like, how does it actually decide if a bug is real?
Yeah, it's pretty wild how they've set it up.
It runs four parallel agents.
You've got two agents strictly checking for compliance with your CLAUDE.md file,
one agent hunting for obvious bugs, and another one digging through your git blame
and history to get context.
Then-and here's the kicker-it has an eighty percent confidence score threshold.
If the agents don't agree with at least eighty percent confidence,
it won't bug you with it.
And they categorize everything into three severities: red circle Important,
yellow circle Nit, and purple circle Pre-existing.
So you know exactly what you actually broke versus what was already dusty.
Wow, eighty percent.
That actually keeps the noise down.
And I love that they call out "Pre-existing" stuff so you don't get blamed for
legacy technical debt.
But, okay, what do we actually do with these findings?
Is it just a report on the screen, or can we, you know, actually execute on them?
Oh, you can absolutely execute.
If you run /code-review --fix, it will actually go ahead and auto-apply those
verified fixes directly to your local files.
But-and please, listen to me on this, fellas-do not run /code-review --fix on
dirty files.
Commit your work first, otherwise you'll be crying into your coffee when it
overwrites your unstaged changes.
Yeah, git commit is your best friend there.
What about CI/CD or PR workflows?
Can we push these comments upstream?
Spot on.
You can run /code-review --comment, and it'll format and post those findings as
inline comments straight onto your GitHub PR.
Now, a quick heads-up on the wallet front: this deep code review is currently a Team
and Enterprise preview, and it does not run on ZDR-you know,
Zero Data Retention-organizations.
Also, if you automate this in your CI pipeline, expect it to cost around fifteen to
twenty-five bucks per run on average.
So, uh, local run control is definitely your friend here.
Oof, twenty-five bucks a run can stack up fast if you have a noisy main branch.
Definitely keep that local first.
Hey, did they do any of those smaller, quality-of-life updates in this version?
Because the previous SSH sign-in flow was a bit of a nightmare with wrapped URLs.
Oh, they fixed that!
They've gone to single-hyperlink sign-in URLs now, so if you're on SSH,
it doesn't wrap and break the link.
They also added OpenTelemetry workflow tags-like workflow.run_id and
workflow.name-so you can actually trace these parallel agents in your APM tools.
And in /config, there's a new "Dynamic workflow size" setting.
It's not a hard cap, just a friendly guideline to tell Claude whether to think
small, medium, or large.
Oh, and if you use voice dictation and it fails to capture your audio a few times,
it now pauses automatically instead of endlessly hanging.
Those trace tags are actually huge for debugging agent loops.
Alright, so the play here is: update to v2.1.202, use /review for your quick
sanity checks, and save /code-review for right before you push-and always,
always commit before running --fix.
Too right, mate.
No one wants to lose half a day's work to an overzealous agent.
Keep it clean, commit early, and let the tools do the heavy lifting.
Catch you on the next one!