You've set up your tools and you understand when to use each one. The next thing that matters is how you ask the AI. With the very same Claude Code, the quality of what you get back can vary many times over depending on how you phrase your request. In this chapter, we build the skill of "asking well" around the two major styles of working with AI — vibe coding, where you build casually through conversation, and spec-driven development, where you decide the specification first and have the AI build precisely from it. This is the single most important knack in AI coding.
The mantra: "small and exploratory → vibe, large and precise → spec"
The quality of your instructions decides the outcome
The first thing people trip over in AI coding is usually not "operating the tool" but how to ask. The AI can't read your mind. Hand it a vague one-liner and it will guess at the missing pieces and fill them in on its own, returning code that looks plausible but drifts from what you meant. Conversely, if you can convey precisely what you want built, why, and how, it will finish the job with startling accuracy. The quality of your instructions becomes the quality of the result — that's the message running through this entire chapter. And there are two broad styles for how you ask.
Vibe coding — build while you chat
Vibe coding is a style where you don't lock down the detailed design in advance, but build through trial and error while chatting with the AI. You roughly say "I want something like this," look at what comes out, and layer on "a bit more like this," "fix this part" — shaping it by feel (the vibe). It's quick and exploratory, and its greatest appeal is turning an idea into something concrete in one burst.
🎨 Picture it: Like shaping clay by hand and feeling out the form, rather than drawing a blueprint first. Because you "think while making," you can take even an idea that isn't yet fully formed in your head and simply start moving your hands to test it.
Let's line up where it fits and the pitfalls to watch for.
- Small things: one-off scripts, simple tools, single-screen apps.
- Prototypes: when you want to see the form before deciding. Experiments you plan to throw away.
- Learning and practice: when you're getting a feel for a new technology.
- The overall design wobbles: direction sways from one exchange to the next, and consistency is easily lost.
- It breaks down as it grows: the more files there are, the harder it gets for both the AI and you to hold the whole picture.
- The internals become a black box: code that works but that you can't explain piles up.
💡 In a word: Vibe coding is unbeatable for "trying things fast," but it's not suited to "growing big or maintaining long-term." Use small, disposable, exploratory as your yardstick — those three words — and you'll rarely go wrong.
Spec-driven development — decide first, build precisely
Spec-driven development is the opposite style to vibe coding. Before you start writing code, you write down "what to build and how" as a specification, then hand that spec to the AI to implement precisely. Rather than chatting your way forward on the fly, you run the AI along an agreed-upon blueprint.
The method is simple. First you draft the specification in consultation with the AI, place it in the project (often as a file), and then proceed with implementation while having the AI reference that spec.
Put the purpose, features, inputs/outputs, and constraints into words. It's faster to have the AI draft it and then revise.
Read the spec yourself before implementation and stamp out gaps and contradictions. This is what separates good quality from bad.
Instruct: "Implement according to this spec." When it drifts, go back to the spec to fix it.
- Somewhat larger things: development spanning multiple features and multiple files.
- Quality-focused work: things that would be a problem if they broke later, things you'll maintain long-term.
- Read by a team or others: the spec becomes a shared point of reference.
- Don't aim for perfection from the start; start the spec small too and grow it.
- The spec is something you must read. A spec left entirely to the AI tends to be full of holes.
- When the implementation drifts, don't patch it ad hoc through conversation — fix the spec first, then redo.
📐 Why it works: The AI only sees "this current conversation." By placing a spec first — a standard you can always return to — the direction doesn't wobble even when the conversation drags on, and gaps and rework in the implementation are reduced. In essence it's just "hand the AI a blueprint before having it build," but the effect is enormous.
Choosing between them — small and exploratory, or large and precise
This isn't about which is superior. The right answer is to choose based on the "scale" and "purpose" of what you're building. Let's contrast the two styles across a few axes.
| Scale | Small |
| Purpose | Prototyping · exploring · learning |
| Approach | Trial and error through chat |
| Speed | Very fast |
| Weakness | Breaks down as it grows |
| Scale | Medium to large |
| Purpose | Quality · maintenance · production |
| Approach | Spec → implementation |
| Speed | Slow to get going |
| Weakness | Overkill for small things |
✅ In practice, you "move back and forth." There's no need to lock yourself into an either/or. First prototype quickly with vibe coding, and once you've got a solid sense that it's viable, write it up as a spec and move into the real implementation — this flow is the most powerful in real-world work. Small exploration is vibe; the growing stage is spec. Switch styles within a single project as you go.
5 tips for better instructions
In either style, better instructions (prompts) to the AI produce better results. Here are five basic tips you can use starting today, laid out as cards. For a deeper dive, head to the practical guide to prompt engineering.
Not "make it nice," but spell out what you want done and how. The more you state numbers, conditions, and targets, the higher the accuracy.
Tell it the language, framework, related files, and constraints you're using. The more background it knows, the more on-point the AI becomes.
Don't ask for this and that all at once. Break it into small pieces and ask one at a time, and both checking and fixing get easier.
Show the form you want up front (function names, return values, output examples, format). Share the goal and it's less likely to drift.
Don't aim for perfection in one shot. Looking at the output and layering on specific "change this to that" fixes is faster.
Words alone are hard to grasp, so let's put the same request side by side as a "bad instruction" and a "good instruction."
"Build a login feature."
The language, where to store data, and behavior on success/failure are all unknown. The AI fills it all in by guessing and returns code that clashes with your assumptions. A recipe for rework.
"Add an email-and-password login feature to my Laravel project. Use the existing users table. On successful authentication, go to /dashboard; on failure, show an error message. Match the passwords to the existing hashing scheme. First propose just the routes and Controller; implement only after I've reviewed them."
Purpose, context, success conditions, output scope, and approach are all spelled out. All five tips are in there.
🧩 Going a step further: The idea of designing not just "what to tell the AI" but what information to deliver and how across the whole project is called context engineering, and the idea of shaping the entire environment the AI works in (tools, permissions, instruction files) is called harness engineering. When you feel like leveling up, take a look.
When the AI ignores your rules
Claude Code has a mechanism for gathering per-project instructions into a file like CLAUDE.md and having the AI always follow them. Yet in actual use, you run into situations where "the AI ignores rules you supposedly wrote." There are several causes.
When the rules are vast, the important ones get buried. Cut the count and make priorities clear.
If there's room for interpretation, they won't be followed. Write them in a specific, verifiable way.
As the exchange drags on, the initial instructions fade. Reminding it at key moments is effective.
💡 The gist of the fix: Write rules "short, specific, and prioritized." And for the important rules, remind the AI again within the conversation when the moment calls for it. For a detailed breakdown of the causes and concrete ways to fix them, see why the AI ignores CLAUDE.md rules, and how to fix it.
- Instruction quality is result quality. The AI fills missing pieces by guessing, so the more precisely you ask, the more accurately it responds.
- Vibe coding = trial and error through conversation. Strong for small, disposable, exploratory work. Breaks down when scaled up.
- Spec-driven development = decide the spec first, implement precisely. Strong for medium-to-large, quality-focused work.
- The rule of thumb: "small and exploratory → vibe, large and precise → spec." In practice you move back and forth.
- The tips for good instructions are the five: specificity, context, one task at a time, output examples, and iteration.
- The AI ignores rules because instructions are long, vague, or the conversation is long. Keep them short and specific, and remind it.
Once you understand how to ask, AI coding steadies dramatically. Even so, the moment you actually start working, you'll inevitably hit errors and dead ends. In the next Chapter 5, "Getting Unstuck," let's systematically cover the causes of common errors and how to work your way out of them.