Every Night I Asked Myself: Did I Make the Right Call Today?
I have been doing solo development for twelve years, but in the first few months after adopting Claude Code, I made a habit of replaying the day's decisions every night before sleep. The question was always the same: did I make the right call when I delegated this task, or should I have done it myself?
Decisions branched constantly. Should I split this work into sub-agents, or is it faster to push through in the main context? Should I stop in Plan mode here, or let it run and just review the result? Should the tests come before or after the implementation? Each one looks like a matter of taste from the outside, but the wrong call meant chasing bugs at 2 a.m.
This article shares seven decision points I now have a clear answer for, after a year of getting them wrong, recovering, and slowly building a personal rulebook. These are not textbook answers; they are the working judgments of a solo developer who has been burned a few times.
Decision 1 — Delegate to Sub-Agents, or Think It Through in Main?
Sub-agents are powerful, but splitting every task is a trap. When I over-delegate, the holistic view that lives in the main context simply does not transfer, and the sub-agents return implementations that contradict each other.
The criterion I use today is simple: delegate when the input and output have a clean boundary. Tasks like "write five test cases for this function" or "search this directory for code that looks similar to X" are independently evaluable, and sub-agents excel at them.
Tasks that involve design judgment or whole-system trade-offs stay in the main context. "Decide the refactoring strategy" or "choose which layer this feature belongs in" requires understanding the codebase as a whole and recalling past decisions. The main agent, with all its accumulated context, gives noticeably better answers.
I learned this the hard way. One day I tried to rewrite an authentication layer by splitting research, design, implementation, and testing across four sub-agents. The research agent recommended JWTs as the standard. The design agent decided session cookies fit the app better. The implementation agent merged the two halfheartedly. The fragmented context produced a fragmented result.
Decision 2 — Stop in Plan Mode, or Let It Run?
Plan mode is one of my favorite features, but using it for every task breaks the rhythm of development. I now invoke Plan mode only when at least one of the following holds:
- The change spans three or more files
- It touches database schema or an API contract
- The domain has bitten me with bad judgment calls before
- The blast radius of failure is high (payments, auth, persistent data)
For everything else — style tweaks, copy changes, adding a small new file — I skip Plan mode and let Claude Code run. Reviewing a plan for every minor change creates context-switching overhead that adds up.
The compensating discipline is smaller commits, so that I can review changes after the fact through diffs. It is a trade-off between reviewing before versus after, and the right answer depends on what is at stake.
Decision 3 — TDD First, or Implementation First?
Test-driven development is beautiful in theory, but in solo development I find it is not always optimal.
I use TDD when the specification is fixed and the input/output mapping is logically derivable: validation functions, data transformations, business rule implementations. Writing tests first is faster and produces sturdier code.
For UI components, API handlers, and external service integrations, I implement first because the right interface only becomes clear after I see the code in motion. Once I have something working, I lock the behavior in with regression tests.
I also phrase the request to Claude Code differently. For the first case: "Please write tests for this spec, then implement the minimum to pass them." For the second: "Please write the smallest working implementation. After I verify behavior, I will add regression tests." Vaguely saying "also write tests" produces tightly coupled implementation and tests, which becomes painful when the spec evolves.
Decision 4 — How Far Do You Trust AI Code Review?
This question is especially heavy for solo developers. With no teammate, the temptation to lean on AI review is strong. I do ask Claude Code to review my code often, but I draw a clear line.
Auto-fix is fine for low-judgment issues: coding style, unused variables, obvious logic bugs (off-by-one, missing null checks). Letting the AI find and fix these saves time.
I always decide myself on design judgments, naming, error handling strategy, and performance trade-offs. AI review is treated as a hint set — "here is a perspective you might have missed" — but the final call is mine.
Without this discipline, six months later I could not explain why my own codebase looks the way it does. Long-term maintenance is my responsibility, and I want to be able to defend every meaningful choice.
Decision 5 — Refactor Alongside the Feature, or Separately?
Asking Claude Code to "also refactor while you're at it" produces commits that mix feature changes with refactoring, and reading the diff later becomes a nightmare. I learned this lesson several times before it stuck.
My current rule is to refactor in a dedicated commit before the feature change. I tell Claude Code clearly: "Reshape this function to make the upcoming feature easier to add — without changing its behavior." If tests already exist, I confirm they still pass before and after.
The feature change comes as a separate commit. If I later need to revert the feature, the refactoring stays. If I decide the refactoring went too far, the feature change is unaffected.
It feels like extra ceremony, but for code that I will maintain for years, the separation pays off.
Decision 6 — How Verbose Should Comments Be?
Left to its own devices, Claude Code writes overly polite comments. Lines like // increment this variable by 1 clog the file and make code harder to read.
The prompt I now use is: "Comments should answer 'why', not 'what'." Anything obvious from reading the code itself does not need a comment; only intent and background that cannot be recovered from the code should be left behind.
I do, however, ask for comments that capture:
- The trade-offs that were on my mind when I wrote this
- Why I rejected the alternative options
- Side effects that future-me should watch for
- Cross-references to related code that influences this one
Structured comments — JSDoc, docstrings — are a separate matter. I gladly let Claude Code generate those, because I want to read type and parameter information through editor hover later.
Decision 7 — Hand the Error to Claude Code, or Read It Myself?
When something breaks, the temptation to drop the error in chat and say "fix this" is real. But there is a branch here too.
Errors I delegate are concrete and locally scoped. "Property 'foo' does not exist on type 'Bar'" or "Cannot find module 'baz'" — Claude Code resolves these with one round trip.
Errors I read myself are abstract or span multiple systems. "Internal Server Error" or "The operation could not be completed" rarely lead to the right fix when handed to AI alone, because the symptom and the cause live in different places.
The scariest pattern is when the AI proposes a symptom-suppressing fix: adding a null check that swallows the error, wrapping the call in try-catch and logging nothing, marking the test as skipped. The error vanishes from the output, but the root cause remains, waiting to bite later.
For non-trivial errors I always start with: "Please explain three possible root causes for this error. I'll decide on the fix." Once I know which cause is real, I let Claude Code implement the fix.
Claude Code Is a Partner, Not a Replacement
The seven branches above all share the same underlying belief: Claude Code is not something that thinks instead of me — it is a partner that accelerates my thinking.
Delegate boldly where delegation is right. Decide deliberately where judgment matters. When that line blurs, the codebase loses coherence and six months later you cannot maintain it. When that line stays sharp, a single solo developer can run multiple projects in parallel without losing quality.
I still face these branches every day, and the criteria above are still being updated. Three months from now they may look different. But putting them into words helps future-me, and I hope it helps anyone in a similar position.
If tomorrow you catch yourself thinking "wait, this is a different call than yesterday," that small awareness is, I believe, what growth as a solo developer actually looks like.