I am Masaki Hirokawa, an artist and indie developer. Since I began using Claude Code daily, the biggest change has not been speed — it is that designing software stopped feeling like a solitary activity. I no longer use Claude Code as a code dispenser. I use it as a sparring partner for the design decisions I am still chewing on. After making that shift, the quality of what I ship clearly improved.
But this only works if you treat questioning as a craft. If you ask Claude Code "how should I design this?" you will get a textbook answer that ignores your actual situation. That is not Claude Code's fault — it is mine, for not handing it the materials it needs to think with me.
In this article I want to share the questioning patterns I have built up while running four sites in parallel (Claude Lab, Gemini Lab, Antigravity Lab, Rork Lab) and several mobile apps as a solo operator. The goal is not to extract better answers from Claude Code, but to use Claude Code to make your own design judgment stronger.
"Delegating design" and "thinking together" are different modes
When I first started using Claude Code, I was unconsciously in delegation mode. "I want to add user auth — design it for me." "Design my billing flow." Whatever Claude Code returned, I mostly accepted. It feels efficient. It is also dangerous.
The danger is that no judgment grows inside you. Whatever Claude Code produces will look reasonable, but it has no idea about the constraints that actually shape your project. In my case those constraints are things like "this runs on Cloudflare Workers with OpenNext", "I am a one-person team so operational load must be minimal", "I want billing to live entirely inside Stripe Checkout". Unless I say these things explicitly, Claude Code cannot account for them.
Once I noticed this, I deliberately switched into "thinking together" mode. Concretely, I stopped asking Claude Code to produce designs and started asking it to argue against the designs I had already drafted. That is the sparring metaphor. The stronger the partner, the better.
A vague prompt that taught me a lesson
Let me start with a concrete failure. About six months ago I was redesigning the billing layer for Dolice Labs and threw this at Claude Code: "design something on Stripe that handles both per-article purchases and subscriptions."
What came back was a textbook webhook-centered architecture. As a greenfield design it was fine. But for my actual situation it was over-engineered. I wanted to avoid long-running work because of Workers' execution limits, and as a solo operator I did not want to add more event-driven failure points.
What I learned that day was: when I do not have an answer in mind, Claude Code cannot give me a good one either. Claude Code is a dialogue partner, not a fortune teller. With no prior shape from me, the only thing it can return is the most generic answer.
After that, I changed my workflow. Before talking to Claude Code, I spend about thirty minutes alone, sketching three rough options on paper. Then I bring those three to Claude Code and ask "compare these — where is each option's worst weakness?" Just doing this transforms the dialogue.
The first three lines of your message decide the rest
In my experience, the quality of a design dialogue is almost entirely determined by the first three lines you write. If you put these three things at the top, the resolution of Claude Code's responses goes up dramatically.
Line 1: what you are building (the project context) Line 2: the specific choice you are wrestling with right now Line 3: which option you are leaning toward, and what is making you hesitate
Rewriting the billing example above, I would phrase it like this:
I run a personal blog platform on Cloudflare Workers and want to add per-article purchases (¥250) and a monthly subscription (¥580) on top of Stripe Checkout. The choice I am stuck on is whether to store purchase entitlements in (a) Cloudflare KV only, or (b) KV plus a redundant signed cookie. I am leaning toward (b), but I am not sure how to balance the cookie tampering risk against the behavior when KV has an outage.
When the prompt is at this level of specificity, Claude Code stops giving me generalities and starts engaging with my situation: "I understand why you lean toward (b), but isn't that judgment overestimating how often KV actually goes down?" That is sparring. The partner is pushing back on my hidden assumptions.
Question shapes that pull comparable options out
Here are some patterns I reach for repeatedly. They are all designed to force the answer into "comparable options" rather than vague advice.
Where do options A and B differ most, evaluated specifically by which one lowers ops load three years from now?
I am about to commit to option A. Give me three concrete reasons I might regret it within six months.
Re-evaluate this architecture under the constraint that it will be run by one person on weekends with no on-call team. What changes?
The trick is that I am the one fixing the evaluation axis: ops load, regret horizon, solo operator. By embedding the axis in the question, I force Claude Code to respond on that axis only. This is not a limitation — it is the mechanism that makes the dialogue useful.
If instead you ask "which is better?" Claude Code will safely list pros and cons of both. That is a summary, not a dialogue.
Be suspicious when Claude Code agrees with you
The biggest payoff of sparring is when Claude Code points out a weakness you did not see. Because of that, I have learned to become slightly suspicious whenever Claude Code agrees with my plan.
When the response is "great idea, let's go with A", I push back:
For option A, what are the weaknesses I am most likely missing? Give me at least two — be harsh.
The phrase "be harsh" matters. With that one keyword, Claude Code stops hedging and points at real weak spots. Several design decisions across my four sites have been overturned in this "harsh mode." The biggest payoff was realizing that an abstraction I thought was elegant was actually inflating maintenance cost for a one-person operation.
What matters here is not handing the decision to Claude Code. It is taking the criticism and re-thinking yourself. Even when Claude Code's critique misses, articulating why it misses sharpens your own judgment one notch further. Welcome the disagreement instead of fearing it. That is what turns design dialogue into real sparring.
Save the dialogue back into CLAUDE.md
It is wasteful to consume a good design dialogue in the moment and let it disappear. I save the meaningful exchanges into CLAUDE.md or a memo under _documents/.
The format I use looks like this:
## 2026-04-15 — Billing flow design call
### Options considered
- A: entitlements in KV only
- B: entitlements in KV + signed cookie (redundant)
- C: a user table in D1
### Chosen
B (KV + cookie)
### Reasoning
As a solo operator I do not want to depend too tightly on KV's SLA.
Cookie tampering is filtered by Stripe's verify-session step, so the
UX hit from a tampered cookie is smaller than the UX hit from KV being down.
### What Claude Code surfaced
- Cookie payload must be append-only (a list of purchased slugs,
not a single value), or per-article purchases will overwrite each other.
- "Deny by default" must be preserved when KV is unreachable.If you keep accumulating notes like this, six months from now when you revisit the same decision you can reconstruct your own past judgment axis. Claude Code does not carry memory across sessions, so preserving the history of your judgments is your job. Conversely, a thick CLAUDE.md raises the precision of sparring whenever you start a new session.
What changes when sparring becomes a habit
Let me close with what has actually changed for me after about six months of using Claude Code this way.
First, design speed and conviction now coexist. Situations where I would have spun in circles alone now resolve faster, because one round of sparring with Claude Code shortens the path. And because the final decision is still mine, I can explain to myself — and to readers — why I chose what I chose.
Second, my own judgment axis gets put into words more often. To explain things to Claude Code I have to write the constraints down, and that act surfaces what I actually care about. It generalizes beyond design into product direction and value-setting for each site. For an indie developer, having a clear judgment axis is the foundation that lifts the quality of everything you ship.
Third, the feeling of "relying on AI" has faded. Because I use it as a sparring partner, the decision is always mine. Claude Code is something that sharpens that decision, not something that replaces it. Once I settled into that distance, I stopped being pushed around by the tool and started using it sustainably.
Claude Lab publishes premium articles that go deeper into using Claude Code as a long-term partner — dialogue craft, long-running operations, the design judgments unique to indie development. They live in our membership, alongside an ad-free reading experience that also helps cover Cloudflare, Stripe and domain costs across the four labs. If this article was useful and you would like to support that, the membership invitation at the bottom of the page is the place to start. It really helps.