Claude Code Creator's Advice: For Big Changes, Align Before You Code

Why the Claude Code Creator Actually Tells You Not to Rush Into Writing Code

In an era of increasingly powerful AI programming tools, a counterintuitive piece of advice comes from Boris, the creator of Claude Code himself: for big changes, don't rush to have AI write code.

Claude Code is a command-line AI programming assistant launched by Anthropic. It runs directly in the terminal, understands the full context of a code repository, and performs file read/write operations, runs commands, and more. Unlike completion-style tools like Copilot, Claude Code is closer to an "AI developer colleague" — you can talk to it in natural language and have it complete complex cross-file tasks. As its core creator, Boris Cherkasky has first-hand knowledge of the product's capabilities and best practices.

This sounds paradoxical. If AI can automatically generate code, why not just throw out requirements and let it write away? Boris's answer is straightforward — when you haven't understood the repository or aligned on direction, the faster you write, the more rework you might face. When you simply toss out "finish this feature," AI might charge down a wrong path, and by the time you spot the problem, a mountain of code needs to be thrown out.

This video breaks down Boris's official talk, focusing on one core question: what's the right way to collaborate with AI on big changes? This isn't just about usage tips — it's a fundamental shift in how we think about working with AI.

Step 1: Ask Claude Code Questions First — Don't Rush to Modify Code

Boris's first piece of advice for newcomers: The first time you use Claude Code, use it to ask questions about the codebase. Don't rush to make changes.

What kinds of questions? For example:

• Where's the entry point for this feature?
• Where are the related tests?
• Why is this logic written this way?

This kind of questioning serves a dual purpose. On the surface, you're having it help you locate files and clarify structure. On a deeper level, you're actually probing how much it truly understands — what it genuinely grasps and where you still need to keep an eye on things yourself.

This step is critical. AI output quality is highly dependent on its understanding of context. AI models process information through a "Context Window" — the maximum number of tokens the model can process in a single pass. Even though modern models have expanded their context windows to hundreds of thousands of tokens, for large codebases (often hundreds of thousands of lines), the model still can't "see" everything at once. It needs to strategically retrieve and understand relevant files. If its understanding of the codebase is off, the code it subsequently generates will only amplify those errors. Calibrating its understanding through questions essentially helps the AI focus its limited attention on the most critical context — it's laying the foundation for the entire collaboration.

Step 2: Have AI Present a Plan First — Confirm Before Coding

Suppose you want to add a feature that touches multiple files. The worst thing you can do is toss out a one-liner and let it freestyle.

A more reliable approach is to have it explain clearly: which files will it change? Why those changes? Once you have the plan, if the direction is off, correcting it at the planning stage is usually far less painful than waiting until all the code is written.

This logic is essentially the same as "design review" in software engineering. Design Review is a mature quality assurance practice in software engineering, built on the core idea that the earlier a defect is found, the lower the fix cost. Industry data shows that problems found during the requirements phase cost roughly 1/10 to 1/100 as much to fix compared to the coding phase. In modern development workflows, RFC (Request for Comments) documents and ADR (Architecture Decision Records) are extensions of this philosophy. In traditional development, we conduct technical design reviews before writing code because modifying a document costs far less than refactoring a pile of code. The same principle applies to AI programming collaboration — one course correction at the planning stage can save dozens of code rework cycles later.

Step 3: Verify Immediately After Writing — Close the Loop with Results

Once the plan is aligned, you move into the actual coding phase. A key point Boris emphasizes: verify immediately after writing.

• If you wrote an API, run the tests.
• If you built a page, check the screenshots.

Why is verification essential? Because Claude Code needs to see results to know what to fix next time. In control theory and systems engineering, a system without feedback signals is called an "open-loop system" — its output cannot self-correct. When AI generates code without test results or visual feedback, it's performing a classic open-loop operation — it can only guess correct answers based on patterns in training data, unable to adjust based on actual runtime behavior. Test results and page screenshots serve as feedback signals for AI iteration. Introducing these signals transforms the open loop into a closed loop, significantly improving iteration accuracy. At the same time, you can use these results to verify whether the feature truly meets requirements.

This forms a complete closed loop: read the repo → produce a plan → write code → run verification → feed results back. Each step has clear outputs and checkpoints, rather than treating the entire task as a black box. This is essentially applying agile development's rapid feedback loops to human-machine collaboration — the shorter each iteration cycle, the less room there is for errors to compound.

A Reusable Claude Code Prompt Template

Combining the above workflow into a single prompt, you can write something like:

First read the repository, tell me the feature entry points, related tests, and files that might need changes; show me the plan first, I'll confirm before you write; after writing, run the tests and return the results together.

This prompt chains all four stages — "understand → plan → code → verify" — together, keeping the AI working within a controlled process rather than running wild. It's worth noting that this structured prompt design approach also applies to other AI programming tools — whether Cursor, Windsurf, or other agents, the core logic is using clear stage-based instructions to constrain the AI's behavioral boundaries.

When to Follow the Full Process vs. When to Just Write

You might not have noticed, but Boris never said every task needs this full workflow. The decision criteria are the scope of the task and the certainty of direction.

• Small tasks with clear implementation: Just write directly — no need for layer-by-layer confirmation.
• Large scope or unclear direction: Review the plan first, confirm what it understands and how it plans to make changes.

This is a very pragmatic stance. Process is a tool, not a dogma — over-engineering the process actually slows you down. The key is learning to judge — when to hit the brakes and when to let go. A simple rule of thumb: if you can clearly envision the impact scope of a change in your head (which files are involved, which modules' behavior will change), then go ahead and write; if you're not sure yourself what the ripple effects will be, that's when you should look at the plan first.

Conclusion: The Core of AI Programming Collaboration is "Align Before You Act"

Looking back at Boris's entire set of recommendations, the essence can be distilled into one sentence: For big changes, don't rush the AI to write — first confirm what it understands, how it plans to make changes, and finally see what evidence it provides that it's done.

This reflects a deeper cognitive shift — in the AI programming era, a programmer's value is no longer just writing code, but serving as the guardian of direction and the validator of results. AI handles execution speed and breadth; humans handle judgment of direction and quality. This is similar to role evolution during multiple historical technology shifts — from assembly to high-level languages, programmers no longer worried about register allocation; from handwritten SQL to ORMs, developers no longer manually optimized every query. Each rise in abstraction level pushes practitioners toward higher-level decision-making roles. In AI programming collaboration, judgment, architectural thinking, and validation capabilities are becoming core competitive advantages.

So next time you face a complex requirement, ask yourself: when should I stop and review the plan first? When the scope gets large or the direction starts feeling uncertain — that's the moment to hit the brakes.

Key Takeaways