Grumpy Claude is the best Claude

I have a new favourite prompt and it’s full of sass.

All you have to do is tell Claude to consult a “grumpy senior software engineer” for feedback. It sounds counter intuitive, but I find the type of feedback I get from grumpy Claude to be both more direct and more actionable. Grumpy Claude pulls no punches and will give you the pessimistic view on the code you have written. It will tell you where you’ve not handled errors, or where the user experience has problems, or where your code is just not clean.

Examples

1. “Get a grumpy software engineer to review this codebase.”

In this instance it really lays in, and comes up with a numbered list of problems with actual snippets from the codebase to prove the point. It goes both broad and deep. I have truncated some detail to get the main points across.

🤬 GRUMPY SOFTWARE ENGINEER CODE REVIEW

Alright, let me put on my grumpiest hat and tear this codebase apart like it owes me money...

🔥 CRITICAL FAILURES - SHOW STOPPERS

1. BROKEN IMPORTS EVERYWHERE

Are you KIDDING me? The main application won't even START because of broken imports! This isn't some minor linting issue - YOUR APP IS LITERALLY BROKEN. How did this even make it past the first python src/main.py test?

…

🎯 THE FUNDAMENTAL PROBLEM

This codebase suffers from "Demo-ware Syndrome" - it looks like a real application from the outside (great README, proper project structure, comprehensive tests) but the actual implementation is mostly empty shells and mocked functions.

You've built a beautiful house of cards that collapses the moment someone tries to actually use it.

🔨 IMMEDIATE ACTION ITEMS (In order of urgency)

1. FIX THE BROKEN IMPORTS - Make the app actually runnable

2. IMPLEMENT THE CORE FEATURES - Replace TODO comments with actual code

3. FIX THE FAILING TESTS - All tests are currently broken

4. SECURE THE SECRETS - Remove credentials from git history

5. PICK ONE ARCHITECTURE - Stop trying to be everything to everyone

6. CLEAN UP THE DIRECTORY STRUCTURE - Organize files logically

Bottom line: This codebase has good bones but needs major surgery before it's ready for any kind of production use. The gap between what's promised and what's delivered is massive.

2. “I want to get rid of firebase functions. Let's just use google cloud run, cloud tasks and containers. Can you clean this up please. When you have a plan, run it past a grumpy senior software engineer.”

In this instance, I’ve got Claude Code in planning mode. What happens is that it comes up with the plan that it’s going to tackle, but then the senior engineer kicks in and reviews it. This then gets Claude to update the plan to mitigate any issues found.

📊 Grumpy Senior Engineer Review

Potential Issues to Address:

1. Resource contention - Heavy processing in same container as web UI

2. Memory usage - Multiple concurrent AI/Gmail operations

3. Error handling - Ensure failed tasks don't crash web interface

4. Monitoring - Need comprehensive logging and alerting

5. Scaling - Cloud Run cold starts vs Functions auto-scaling

Mitigations:

- Container resource limits and horizontal scaling

- Async processing with proper error isolation

- Structured logging with correlation IDs

- Health checks and graceful degradation

- Cloud Tasks for reliable retry mechanisms

“Using the persona of a grumpy senior software engineer, review PR (123) on github.”

I find this approach really good for your work-in-progress branch. If you don’t have a draft PR up, it can also work locally if you tell it to compare the current branch against your “main” branch. Again, I’m leaving out the meat of the review as it’s quite long.

adjusts glasses and cracks knuckles

Oh great, another "simple" feature addition that touches half the damn codebase. Let me walk through this XML processing PR...

…

Missing Pieces

1. No schema validation - You're trusting that XML structure blindly

2. No performance considerations - What happens with a 50MB XML file?

3. No rollback plan - Feature flag is nice, but where's the monitoring?

4. No documentation - Future developers will hate you

The Verdict

This feels like a "make it work" implementation that'll need a complete rewrite in 6 months. The architecture is decent but the implementation is sloppy. You're adding complexity without considering the maintenance burden.

Grade: C-

It works (probably), has tests (barely), but it's the kind of code that creates tech debt faster than you can pay it off. Ship it if you must, but schedule the refactor now.

adjusts glasses and returns to keyboard clicking

Now get off my lawn and write some proper TypeScript interfaces!

As you can see with these examples, the feedback is to the point, it’s generally pretty pragmatic, and has helped me think through my code before even talking to peers. I have also used this with mixed success to review architectural design documents, and user experience flows.

What about the other LLMs?

Frankly they all lack any sort of enthusiasm for this approach. Google’s Gemini out right refused to consider being grumpy. Open AI’s GPT models were just too polite about it and never really dug into the issues. If you want actionable feedback, right now you want to use Claude (July 2025).