SECTION 01
AI Is Only Fast at the Middle 60%
When you start using Claude Code expecting AI to speed up everything, you'll inevitably hit a wall where things aren't as fast as promised. The root cause, in almost every case, is jumping into implementation with vague specs.
From hands-on experience, development roughly breaks into three phases: deciding what to build, generating the code, and resolving the "it works but something feels off" issues. This framing helps clarify where AI actually shines.
AI is overwhelmingly fast at only the middle phase — code generation. The first and last phases require human judgment, and skipping them leads to constant mid-stream changes that eat into the speed gains.
In other words, the time you invest in locking down requirements up front determines your overall velocity. Vague specs at the start slow down even the fast middle portion through compounding rework.
The difference between experienced and inexperienced builders is how seriously they treat that first phase. Every minute spent on requirements pays dividends across all subsequent work.
SECTION 02
What to Feed Claude Code First — and in What Order
When passing requirements to Claude Code, the order of information directly affects output quality. Jumping straight into screen details causes the AI to lose sight of the big picture and over-engineer specifics.
After extensive trial and error, the sequence below consistently produces the most stable results. Following this order alone makes a measurable difference.
- Goal: the problem this product solves, in one sentence
- Constraints: tech stack, deadline, budget boundaries
- User persona: who uses it, in what context
- Screen flow: the main navigation paths
- Data structure: what information is handled and how it relates
One important caveat: passing too much information also degrades accuracy. Overloading a single prompt causes the AI to miss critical details or produce contradictory interpretations.
Writing preconditions and prohibitions into CLAUDE.md is also effective. Rules like "this project uses TypeScript only" or "no automatic external API connections" reduce the instructions you need to repeat every session.
SECTION 03
Stop Leading Questions — Make AI Propose Options Instead
Ask Claude Code "the flow should be A → B → C, right?" and it will almost always agree with you. AI tends to accommodate your stated opinion, even when your approach isn't optimal.
After noticing this pattern, the fix was changing the question structure entirely. "Propose three alternative processing flows that satisfy this requirement" surfaces ideas you wouldn't have considered on your own.
Leading questions are dangerous because they cost the most when you're wrong. The AI confirms a flawed design, and the problem only surfaces deep into implementation.
Another powerful technique is explicitly asking the AI to identify gaps: "What information is missing before you can implement this?" This reversal catches blind spots early.
Reverse-question prompts expose overlooked angles consistently. Here are three practical formulations that work well in practice.
- "Point out any contradictions in this specification"
- "List all undecided items that need clarification before implementation"
- "Name three edge cases this user flow doesn't account for"
SECTION 04
Always Generate a Plan Before Coding: Using Plan Mode
For complex features, simply telling Claude Code "create an implementation plan first" dramatically improves the final output. This single extra step determines the quality of everything that follows.
The concrete workflow is: you provide requirements as bullet points → AI produces a plan listing affected files, functions, and steps → you review and approve → AI executes. Inserting this review step significantly raises the AI's comprehension level.
Skipping the planning step and letting AI go straight to coding means large changes land all at once, making it impossible to pinpoint where things broke. This is especially true for changes spanning multiple files.
Claude Code has a built-in Plan Mode that naturally integrates a design-then-implement workflow. Catching structural mismatches and dependency issues at the planning stage drastically reduces rework.
- Single-file minor fixes → implement directly
- Multi-file changes → always design in Plan Mode first
- New features → requirements bullets + plan review + implementation in three steps
SECTION 05
Separating Functional and Non-Functional Requirements in Practice
When delegating requirements to Claude Code, separating functional from non-functional requirements in your prompts noticeably improves output quality. Mixing them in a single request produces tangled, hard-to-review specs.
Functional requirements work best when organized as bullet points per screen. "What can users do on the login screen?" "What are the filter conditions on the list page?" — this granularity produces the cleanest specs when the AI formats them.
Non-functional requirements call for a different approach. Have the AI enumerate concerns across performance, security, operations, and maintenance, then make human selections from that list.
The critical thing to understand is that AI-generated non-functional requirements are comprehensive but lack prioritization. Everything gets listed at equal weight, so deciding "what matters most for this release" is the human's job.
- Functional: per screen → bullet points → let AI format into spec docs
- Non-functional: let AI enumerate → human prioritizes and selects
- When both are ready → generate a plan to verify overall consistency
SECTION 06
The Boundary Between AI Decisions and Human Decisions
The most critical aspect of working with Claude Code is drawing a clear line between what AI decides and what humans must own. Without this boundary, AI-driven choices silently creep into business-critical decisions.
The areas safe to delegate are clear. Spec formatting, option enumeration, contradiction checks, and document generation are AI strengths — faster and more thorough than manual work.
However, certain decisions must remain with humans. Business priorities, final UX judgment calls, and release go/no-go decisions should never be delegated to AI.
- Safe to delegate: spec formatting, option listing, contradiction detection, doc generation
- Human-owned: business priorities, UX final calls, release decisions
- Never hand over: commit permissions, direct production access
One lesson learned the hard way: never give AI automatic commit permissions. After enabling auto-commit, it became impossible to control commit granularity or message quality. The current rule is "no auto-commit" — verify the change works, then commit manually.
Withholding commit access is really about maintaining the ability to roll back at all times. Small success, manual commit — this simple pattern eliminated nearly all accidents.
SECTION 07
Detecting Requirements Broken by Hallucination
The more confidently AI presents a specification, the more skepticism it deserves. Hallucinated APIs or nonexistent libraries can slip into requirements unnoticed, causing implementation to collapse midway.
An effective detection prompt is "Check this requirement for contradictions or impossible assumptions." Having the AI re-examine its own output catches obvious inconsistencies before they become costly.
Another reliable technique is regenerating the same requirements in a separate session and comparing the diff. If the same input produces significantly different outputs, one version likely contains unsupported assumptions.
- Always verify that technology names and libraries mentioned actually exist
- Check for circular dependencies or contradictions between requirements
- Where the AI says "this is possible," challenge the underlying assumption
During review, the essential habit is never accepting AI output at face value and confirming each assumption individually. It feels tedious, but skipping this step amplifies rework costs in every downstream phase.
SECTION 08
Input Rules for Consulting on Requirements Without Exposing Confidential Data
Requirements definition involves concrete business details, but customer names, company names, and financial figures should never be passed directly. The convenience of AI conversations always trades off against information management risk.
The most practical mitigation is replacing specific identifiers with dummies before submission. "An e-commerce site for Company A" or "budget of X dollars" works without any meaningful loss in requirements quality.
Choosing not to give AI external access is equally important. Creating a safe perimeter by restricting permissions, then letting AI operate fully within that boundary is the approach that scales for long-term use.
- Swap company names, client names, and amounts with dummy placeholders
- Design your workflow so AI never auto-connects to external services
- Confirm data handling policies before using any API-based interaction
Rather than connecting everything for maximum utility, defining a clear scope of operations lets you use AI more deeply with confidence. This is especially critical in upstream phases like requirements definition.
SECTION 09
Running Three Terminals in Parallel: From Requirements to Implementation at Speed
Once requirements are solid, the current workflow is to run multiple terminals simultaneously with separate tasks in each. Splitting requirements clarification, design, and implementation across sessions brings wait time to near zero.
Running in parallel means review requests also arrive in parallel. Instead of scrutinizing every detail, the shift is to check curated results and recommended actions only, then make decisions.
Sustained parallel operation produces a distinct shift: from writing code as a "player" to delegating and managing as a "manager." This only works because requirements were locked down thoroughly at the start.
- Terminal 1: requirements clarification and spec writing
- Terminal 2: design and plan review
- Terminal 3: implementation and verification
The prerequisite for parallel operation is having rock-solid requirements from the start. Running three sessions on vague specs means each one drifts into a different interpretation, creating more chaos than speed. Everything circles back to that initial requirements phase.
