Talk Through a Problem with Claude Before Writing Any Code — Pair Programming Style
The best pair programming sessions don't start with coding — they start with a conversation. Use Claude Code the same way. Describe the problem, not the solution, and let a dialogue sharpen your thinking before any code gets written.
> I need to add a notification system to the app. Users should get
> notified when someone comments on their post, when their order
> ships, and when they get a new follower. I'm not sure whether
> to use database notifications, push notifications, or both.
> What should I consider?
Claude doesn't just start coding — it asks questions that reveal requirements you haven't thought through:
- "Should notifications be real-time, or is polling every few minutes acceptable?"
- "Do users need to mark notifications as read? Do they expire?"
- "Should different notification types go to different channels — email for orders, in-app for comments?"
- "What's the expected volume? A few per user per day, or hundreds?"
Each answer narrows the design space until the implementation becomes obvious.
This works for any decision that has tradeoffs:
> I'm thinking about adding caching to the product listing page.
> Walk me through the options and tradeoffs before we implement anything.
> We need to handle file uploads. Should we store them locally,
> use S3, or go through a service like Cloudinary? Think through
> the pros and cons for our use case.
> The admin wants a reporting dashboard. Before I build it, help
> me think through what data structure and queries would support
> the reports they'll want.
Once the conversation reaches a clear direction, then you ask Claude to build it — and it builds exactly the right thing because it was part of the design conversation.
> ok, based on what we discussed — database notifications with
> email fallback for critical ones — build it.
The best code comes from clear thinking. Use Claude as a thinking partner first, a coding partner second.
via Claude Code
Log in to leave a comment.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.
After Claude makes changes to your code, ask it to explain what it did and why it made specific choices. This turns every coding task into a learning opportunity — you understand the reasoning behind the approach, learn patterns you can apply yourself, and catch any decisions you disagree with before moving on.