The Workflow That Made Claude Code Actually Useful

I started this project the way most people start with AI coding tools: just typing prompts, seeing what came out, and adjusting.

Honestly? It didn't work. And the problem wasn't Claude. It was me.

I kept changing requirements mid-session. I wasn't giving it real context. I'd start each new session wondering why things felt inconsistent, why features didn't quite match what I had in my head. I was vibe coding 🤷‍♂️, and vibe coding doesn't get you to a finished, coherent product.

The moment things clicked was when I stopped chasing better outputs and started thinking about how I was setting up the work.

Here's what I changed. 👇

🎨 1. Start with Design, Not Code

This was the biggest one. 🔑

Instead of jumping straight to "build me X," I started every feature with a conversation: help me get my ideas straight and guide me to my vision. I wasn't asking Claude to build anything yet. I was using it to explore what I actually wanted.

That sounds obvious in retrospect, but it's easy to skip when the tool can just write the code. The problem is you end up building something close but wrong, or building the right thing in a way that requires a complete rewrite later.

When I started the design exploration first, describing what I wanted, letting Claude ask clarifying questions, narrowing down to one clear direction, everything downstream got easier. Claude had a real vision to hold in memory across every task, the design stayed consistent, and I stopped second-guessing mid-build.

📋 2. Plan Before You Build

For anything beyond a small fix, I use Claude's plan mode before it writes a single line of code.

Plan mode feels like overhead the first time you use it, but it's Claude actually thinking through the implementation before diving in: checking dependencies, flagging decisions, proposing an approach. For big features especially, this is the difference between a clean implementation and one you'll need to untangle in three days.

🧠 3. Persist Context Across Sessions

Since every Claude Code session starts fresh, without a way to persist context you end up re-explaining the project from scratch every time.

CLAUDE.md is the file that fixes this. It's a context document Claude reads at the start of every session. Write it once, keep it updated, and Claude follows your conventions without being told twice. Mine covers:

• 🎨 Design system — exact color values, typography scale, the one accent color (#1D9E75) and that nothing else is allowed
• 📝 Language rules — "TypeScript always, no plain JS," "App Router only, never Pages Router patterns"
• 🧩 Component rules — "server components by default, use client only when required"
• 🌿 Git workflow — branch naming (feature/<task>-<description>), commit format (feat(scope): imperative summary), allowed scopes
• ✅ Verification commands — npm run build && npm run lint must pass before any commit
• 📂 Reference to other docs — @docs/design.md, @docs/architecture.md so Claude pulls those into context automatically
• 🚫 Hard constraints — "never add dependencies without a clear reason," "never commit directly to main"

Here's how the files connect:

your-project/
├── CLAUDE.md           ← read every session
└── docs/
    ├── architecture.md ← decision history
    ├── design.md       ← design specs
    └── requirements.md ← acceptance criteria

🏗️ 4. Document Architectural Decisions

As you build, you make decisions. Why this component structure and not that one. Why a certain API is shaped the way it is. Why you chose one approach over something simpler.

Those decisions live in your head during the session, and once you close the terminal they're gone. 💨

architecture.md is where I capture that history. Not a formal document, just clear notes about what was decided and why. When a new requirement comes in weeks later, I reference it and Claude immediately has the context it needs. No re-explaining, no accidentally undoing something that was already thought through.

Coming back to the project after a break, that file is the fastest way back into the mental model.

✅ 5. Write Requirements Before Coding

This one surprised me the most. 😅

When I was vibe coding, I'd describe a feature and Claude would build something. Sometimes exactly right. Often close but off in small ways that required rework. I kept thinking Claude was missing details, and it was, but the real problem was I hadn't written them down clearly myself.

requirements.md forced me to be specific before building anything. Feature by feature, with acceptance criteria. Not because Claude needs a formal spec, but because writing it out forced me to think through edge cases I'd otherwise discover mid-build and have to explain on the fly.

A simple example looks like this:

## Blog reaction bar

**Goal:** Let readers react to a post with an emoji.

Acceptance criteria:
- [ ] Displays 3 reaction options (👍 🔥 💡)
- [ ] Count updates optimistically on click
- [ ] Persists to Supabase on interaction
- [ ] Works without being logged in
- [ ] Does not allow more than one reaction per user per post

Nothing fancy. 🎯 Just enough that both you and Claude know exactly when it's done.

Once I had them written down, Claude had real targets to work from. I could verify against actual criteria instead of gut feel, and when something was off the conversation got useful fast — "this doesn't meet criterion 3" is much cleaner than "this doesn't feel right."

If you're starting to build something real with AI tools, the magic isn't in the prompts — it's in the structure you build around them. Give the tool a clear vision, a plan, and the right context and it will move fast. Skip that setup and you'll spend more time correcting than building.

I'm genuinely impressed by what Claude can create. But what excites me more is realizing that the tool is only as good as the clarity we bring to it. The ideas, the vision, the decisions ✨ — those still come from us. Claude just helps us get there faster.

What a time to be building. 🚀 Go make something. Happy coding. 👨‍💻