Here’s how my approach to Claude Code has shifted over time. It’s not the oversold promise of AGI, but it’s definitely working better now.
Initially, I viewed Claude Code as a shortcut for lazy developers. Toss in a vague prompt, like 'implement a CRUD for user content, both front and backend' and hope for the best. Predictably, what came out was a mess. Sure, the code ran, but it was brittle and weirdly tangled. Maintenance? We don't speak that here. The whole thing felt about as stable as a sandcastle at high tide, and coding on top of it became an insurmountable (and painful) task.
So I tried something different. Before I even open Claude, I get very specific about what I want. Which logic needs to exist, what should happen, and why. If files need to change, I say so from the start. Claude is decent at picking up context, but it can’t read my mind. That extra effort pays off.
Instead of using it for every little tweak or half-formed idea, I save Claude for bigger changes; scenarios where the time spent writing context actually matters. If a change is small or the requirements are fuzzy, it’s usually faster to just do it myself.
Now, the process is all about detail. For a CRUD endpoint, I outline what users can and cannot do, provide the routes and database schema, and explain how this component fits into the rest of the app. I ask Claude to generate only what I need. Endpoints only, for example. Once it spits something out, I always refactor. Partly because sometimes its output is just off, but also because refactoring forces me to actually understand the code. You’d think that would be obvious, but it’s alarmingly easy to lose track. Projects spiral into chaos when each new feature makes things murkier.
Same goes for frontend work. I give details about components and folder structure, point to existing parts of the codebase, and tie everything back to backend routes so Claude isn’t just guessing.
One recent trick that’s been unexpectedly useful: **plan mode**. Can't overstate how much value this has. Instead of jumping straight into edits, Claude lays out a plan first. It gives me a chance to spot misunderstandings before they turn into a mess I have to untangle later. Sometimes the mistakes are on its side, sometimes they’re from my own muddled instructions or half-baked code.
If things keep going sideways after a couple rounds; if Claude keeps missing the point, I just restart the conversation. There's no point in trying to prompt it back to sanity, and the failed previous messages just throws it off. And honestly, if it still doesn’t get it after a restart and a rewritten prompt, it’s probably my fault for being unclear or dumping in bad context. Another thing I gave up quickly was trying to cram multiple features into one session; that’s when things really start to fall apart.
Is this workflow magical? Not even close. You can’t just tell Claude what you want and walk off, and no amount of twitter hype from people with a concerning post/commit ratio will prove it otherwise. But if you’re willing to be detailed, put up the work, and keep a tight grip on context, it becomes something closer to a competent coworker who chews through boilerplate so you can focus on actual architecture and business logic rather than writing the thousandth CRUD endpoint.
It’s not perfect. But I'll be lying if I say that I'm not impressed by the progress and the power it enables.