DEV Community

무적이
무적이

Posted on

Stop Boring Code Reviews: 2 CLI Tools That Actually Make You a Better Developer

#devtools #cli #opensource #productivity

Your Code Review Process Is Broken

Let's be honest about code reviews.

You open a PR. Skim the diff. Leave a comment like "looks good" or maybe "nit: missing semicolon." Approve. Move on.

Meanwhile, the function that's 200 lines long? The nested callbacks three levels deep? The variable named data2? They all slide through.

It's not that you don't care. It's that code review fatigue is real. After reviewing your third PR before lunch, your brain stops noticing patterns. ESLint catches syntax. TypeScript catches types. But nobody catches the actual problems — the code smells, the architectural red flags, the "why does this exist?" moments.

What if your terminal could do that for you?

Today I'm sharing two CLI tools that changed how I think about code understanding: roast for brutally honest code reviews and git-why for understanding the history behind mysterious code.

🔥 roast — Gordon Ramsay Meets Your IDE

The pitch: An AI-powered code reviewer with the personality of an angry celebrity chef.

Your linter tells you what's wrong. Roast tells you why you should be ashamed.

Install 

npm install -g roast-cli
Enter fullscreen mode Exit fullscreen mode

Requires an OPENAI_API_KEY environment variable. Works with any OpenAI-compatible API.

How It Works

Point it at any file:

roast server.js
Enter fullscreen mode Exit fullscreen mode

That's it. You'll get back savage (but accurate) feedback on real code problems — not just style nits.

The Three Severity Levels

This is where it gets fun. Roast has three intensity modes:

--severity mild — The friendly mentor. Good for PRs where you want to stay diplomatic:

roast --severity mild utils.py
# "Hey, this function is doing quite a lot. 
#  Maybe consider splitting the validation 
#  logic into its own helper?"
Enter fullscreen mode Exit fullscreen mode

--severity medium — The sarcastic senior dev. Perfect for your own code:

roast --severity medium handler.go
# "Oh cool, a 150-line function. I see you 
#  subscribe to the 'why have many function 
#  when one function do trick' school of thought."
Enter fullscreen mode Exit fullscreen mode

--severity harsh — Full Gordon Ramsay mode 🔥:

roast --severity harsh legacy-code.java
# "THIS FUNCTION IS SO RAW IT'S STILL MOOING! 
#  You've got TEN nested if-statements! My 
#  lasagna has fewer layers than this!"
Enter fullscreen mode Exit fullscreen mode

Why It Actually Works

Here's the thing — humor makes feedback stick. I've been running roast on my own code for weeks, and I catch myself thinking "Ramsay would hate this" before I even commit. That's behavior change no linter ever achieved.

It also works in CI pipelines:

# Roast staged changes before committing
git diff --staged | roast --diff

# JSON output for CI integration
roast --json src/index.ts
Enter fullscreen mode Exit fullscreen mode

Real Talk: When To Use It

Scenario Roast Level Why
PR review for a junior dev mild Constructive, not crushing
Reviewing your own code medium Honest mirror
Friday afternoon entertainment harsh Pure joy
Legacy code archaeology harsh You need to laugh or you'll cry

🔍 git-why — Because git blame Only Tells You Who

You open a file. Line 87 has a bizarre regex wrapped in a try-catch. The variable is named tempFix_v2_FINAL.

You run git blame. Now you know who wrote it and when.

Congratulations. You still have zero idea why.

Install 

npm install -g git-why
Enter fullscreen mode Exit fullscreen mode

How It Works 

git-why src/validators.js:87
Enter fullscreen mode Exit fullscreen mode

git-why analyzes the git blame, commit messages, surrounding diffs, and PR context — then uses AI to explain the reasoning behind the code. It turns raw git history into a human-readable narrative.

Instead of:

a1b2c3d (john 2024-03-15) const re = /^(?=.*[A-Z])(?=.*\d).{8,}$/;
Enter fullscreen mode Exit fullscreen mode

You get:

This regex was added in PR #234 "Add password validation" 
on March 15, 2024. The commit message references ticket 
SEC-102 requiring passwords to have at least 8 characters, 
one uppercase letter, and one digit. The try-catch was added 
two days later in a hotfix after the regex threw on null input 
in production.
Enter fullscreen mode Exit fullscreen mode

Now you actually understand the code. You can make informed decisions about whether to refactor it, extend it, or leave it alone.

When git-why Saves Your Day

  • Onboarding — New to a codebase? Stop guessing why things are the way they are.
  • Refactoring — Before you "clean up" that ugly code, understand if there's a reason it looks like that.
  • Code review — When you're reviewing a change to a file you don't own, get instant context.

Before vs After: The Code Review Workflow

❌ The Old Way

  1. Open PR → skim diff → 15 minutes
  2. Notice something weird on line 87 → git blame → find commit → read message → check PR → 20 minutes
  3. Leave 3 style nits, miss the actual architecture issue
  4. "LGTM 👍"

Total: 35 minutes. Value delivered: minimal.

✅ The New Way

  1. git diff main | roast --diff → instant feedback on real problems → 2 minutes
  2. git-why suspicious-file.js:87 → full context in seconds → 1 minute
  3. Leave meaningful review comments based on actual understanding

Total: 10 minutes. Value delivered: actual code quality improvement.

Try Them Today

Both tools are open source and free:

# Brutally honest code reviews
npm install -g roast-cli

# Understand the "why" behind any line
npm install -g git-why
Enter fullscreen mode Exit fullscreen mode

Links:

This is Part 2 of my CLI Tools for Developers series. Part 1 covered curl-to-code, json-to-types, readme-gen, and cron-explain. More tools coming soon.

Built by MUIN — an AI-native company building developer tools.

Top comments (0)