Six months of daily use, mapped into 8 workflows that actually replaced something.
That’s what one developer shared on Reddit this week, and it’s one of the more grounded AI workflow breakdowns I’ve read. Not theoretical. Not a list of prompts to copy. A real accounting of what changed, what didn’t, and where Claude Code failed.
The pattern they found: Claude Code wins where the work is “spec a behavior, get the implementation.” It loses where the work is “the spec is in your head and you don’t know it yet.”
That one sentence explains more about where AI coding tools actually fit than most long-form guides combined. It’s also the thing nobody says out loud when they’re selling you on AI-assisted development.
The 8 workflows that survived 6 months of real use
Listed in order of daily frequency:
Every day 🛠️
- Test generation. Paste the function, describe the behavior you want covered, ask for tests in your framework. Test count went 3x at the same effort cost. The key is being specific about the cases you care about: boundary values, null inputs, error states. Vague requests get vague coverage. Breaks down on stateful systems where the setup itself is the hard part, and no amount of prompting changes that.
- Code review of your own diffs. Paste the git diff, ask for review on bugs, edge cases, missed null checks. Replaced the self-review that always felt thorough but never was. The blind spot in self-review isn’t laziness, it’s familiarity. You wrote the code, so you read what you intended, not what’s there. Claude reads it fresh every time.
- Debugging unfamiliar codebases. Paste the stack trace, paste 2-3 relevant files, describe what you tried. Replaced an hour of grep and git blame archaeology. Especially useful when you’re touching a service you didn’t write and the original author isn’t available. You get oriented in minutes instead of half a morning.
Weekly
- Refactoring legacy code. Describe the new shape, ask for a refactor that preserves behavior. 30-90 minute sessions now take 10 minutes plus careful review. Always run tests after. Claude will quietly drop edge-case handling if the original code was implicit about it. The refactor will look correct and compile clean and still be subtly wrong. Tests are not optional here.
- Migration scripts. Database migrations, config rewrites, codemods. Works well because input and output schemas are explicit upfront. The more constrained the transformation, the better the output. Open-ended migrations with business logic embedded in them are a different category entirely.
- CI failure summarization. Paste 4,000 lines of CI output, ask for the actual root cause and the 5 lines worth looking at. Replaced scrolling. On large monorepos where CI output is genuinely unreadable, this alone is worth the subscription cost.
- Generating mocks and fixtures. Describe the shape, paste a real example, ask for variations covering edge cases. Replaced maintaining a fixtures directory by hand. Particularly useful when the fixture needs to cover a combination of fields that would take ten minutes to think through manually.
Monthly
- Tech spec drafting. Describe the feature, get a one-page spec with goals, non-goals, design questions, and rollout plan. Edit heavily. Replaced the blank-page problem on every new project. The output is rarely right on the first pass, but it gives you something to push against, which is faster than starting from nothing.
What they tested and quietly dropped 🚫
Three workflows didn’t survive fair testing:
Pair programming for new features. Claude is good autocomplete and a bad pair. The framing makes developers lazy about thinking through the problem before writing code. You end up reviewing output instead of designing a solution, and those two activities require completely different headspace. Better to spec the behavior first, then review the output.
Reviewing someone else’s PR. Claude catches style issues. It cannot tell you whether the change is the right shape for your team’s roadmap, whether it introduces a pattern the rest of the codebase shouldn’t follow, or whether it’s solving the right problem at all. That’s the actual hard part of code review, and it requires context no prompt can supply.
Open-ended exploration. “Help me figure out what to build” never ends well. Claude generates plausible options. None of them are yours. The options look reasonable until you realize they’re optimized for sounding reasonable, not for fitting your actual constraints.
The old way vs. the new way
Before: developers used AI as a general-purpose thinking partner. Results were inconsistent. Trust in the tool quietly eroded because the failures were unpredictable. You’d get great output one day and confidently wrong output the next, with no clear signal for which was coming.
After: use Claude only where the spec is clear, the output is verifiable, and the previous method was pure grunt work. Test generation, CI triage, fixture building, self-review of diffs. That’s the bucket where the returns hold up because you can immediately check whether the output is correct. Verification is fast. The feedback loop is tight.
A commenter in the thread put it cleanly: “It’s excellent at compressing grunt work and mediocre at pretending it knows your product.” That’s the entire framework in one sentence.
If you’re still using Claude Code as a pair programmer for open-ended work, the evidence here suggests you’re applying it to the wrong category of problems. The fix isn’t a better prompt. It’s a clearer job description.
Frequently Asked Questions
Q: Should I combine Claude Code workflows or use them separately?
Combine them. Running spec → code generation → diff review in sequence catches way more issues than treating each step solo. The review layer compounds the value of the initial implementation.
Q: How do I stop Claude from refactoring clever code patterns as if they’re bugs?
When diving into unfamiliar codebases, ask Claude to infer intent first before suggesting changes. Frame it as “preserve this subtle behavior” rather than “clean this up.” With existing code, subtle patterns often do real work, Claude doesn’t always see that.
Q: How can I make Claude Code’s review more accurate without explaining my entire codebase?
Pass architectural constraints as a <system_rules> block before the diff. Example: “All DB queries must include tenant_id” or “We don’t use React Context for state management.” This trains Claude on your specific constraints without needing the full context dump.
Q: When does test generation actually fail?
Test generation is solid when the setup is straightforward. But with stateful systems where initialization is the hard part, Claude struggles, it nails the assertions but gets the setup wrong about half the time. Hand-writing those setups is often faster.
8 Claude Code workflows I run daily as a working developer — what each one replaced
by u/AIMadesy in PromptEngineering