How I make Claude Code Work For Me (Aug 2025)

My contribution to the Vibe Coding Discourse. I hope it helps you find your way.

It’s clear that successful Claude Code vibe coding requires a very different approach than traditional coding or even being a tech manager. If you follow the traditional meandering coder approach you will overwhelm the context window and end up in doom loop after doom loop. If you follow the top down manager approach you will under-specify and Claude Code will leave you with a bad implementations, lots of semi-working but buggy code.

What actually works is right down the middle, more like the indie hacker at a hackathon, extreme execution focus, highly specify everything you care about like the most control obsessed tech lead you’ve ever worked with, and then act like a dev manager overseeing someone with zero common sense. Ask Claude questions along the way to manage its focus, and ask them repeatedly. This runs against your normal instincts about employee autonomy but it makes sense here.

Here I’ll share what I’ve come to as a process that reliably produces good iterations of quality code with Claude Code. Both philosophy and overall structure. This is as-of August 2025, I will repost newer versions when my approach changes substantially.

Augmented Collective is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

The Core Philosophy

• Always be closing. You want to seal the deal on this current iteration as fast as possible. Your goal is to get the feature in, in a working state, and get Claude to fresh status as fast as you can. Once you’ve sealed the deal you can get back in there and tweak it as a new Claude iteration or by hand.

• You want to transform from working state to working state fast. Bad states tend to trigger the accumulation of additional bad states. After a small number of overlapping bad states Claude becomes unable to reason. This is what I call a doom loop.

• Don’t be overly picky. Never ever refactor working code mid-session. Mark it down and come back with a fresh Claude. Working is good enough, close the deal and come back.

• Don’t ever work on anything but the feature you are focused on in a Claude Code window. Asking it to do a single unrelated thing will substantially decrease your chances of success. Stay focused.

• Do you see a pattern? Leave that bug you just discovered until next time. Don’t tidy up that coworker’s code right now. Leave it and come back.

• You’ll do it anyway sometimes and regret it. This is how you learn, by suffering.

• If you absolutely must make an unrelated change, use another Claude instance to change it. Even then I would avoid it, you’re potentially invalidating some assumptions that Claude already has.

• You’re tempting the doom loop. Stay as far as you can from the doom loop in state space.

• If things are going off the rails restart from the last time things felt good. Sunk cost fallacy holds, once you’re in a doom loop it’s like a black hole, you will never escape.

This seems excessively stated but it’s very different than how I normally code and takes me substantial self discipline to follow, which is why I emphasize it so much here. It’s very easy to distract or overwhelm Claude. Eyes on the prize.

Process

I take a very structured approach to Claude Code. I’ve found this is necessary and when I get lazy I tend to end up losing a lot of time and regretting it. This is maybe the hardest won lesson, stick to the plan.

My process for a sizable end-to-end feature follows this structure:

1. Draft Spec and iterate with AI, specific implementation details (1-2 hours)

2. Break down into tasks and carefully review (15-30 min)

3. Execute keep an eye on it, make sure it's not off the rails (30min-2 hours)

4. Iterate, ask it to validate the implementation against the spec again and again, keep doing this until it tells you it's the same (30-60min)

5. Testing, have Claude run tests, lots of tests at every level. (30-60 min)

6. Manual testing and visual inspection, walk through it. (30-60 min)

7. Clean up, Claude will make tons of trash files, tests and markdown, clean it up. (10-20 min)

8. Create PR, Never let Claude commit directly to any important branch. (10 min)

9. Review, like it was a coworker’s PR you paired a bit on. (30-60 min)

I’ll go through each of these with some notes.

Draft Spec

Your goal in the draft spec phase is to specify everything you might care about. The best way to get better at this is to do it, notice what the AI does that you didn’t like and then specify it next time. I typically call it a PRD but go much deeper than I would in any of my before-times PRDs. I get as deep as specifying database table shapes, any important API endpoint names and shapes if not obvious, I make sure all of the entities are called out.

You can ask Claude to make you a PRD and then keep correcting and adding to it. This works great actually, it’s easier to move fast seeing what you don’t want and correcting it. I usually start with a solid two to three paragraphs describing what I want and any important properties, and then iterate from there. Make sure to ask the AI to look at the existing codebase and describe how the implementation will fit into the existing system. If you don’t like it than change it.

You might be wondering if your PRD is too long: the answer is no, it is never too long. The more time you invest in the spec the easier things will be in the later phases. This is the most important phase as far as your individual effort and focus goes. Do this well and you don’t have to pay much attention later.

Don’t forget security requirements and any specific packages you want it to use. It’s better to pick out any libraries dependencies before it gets going.

If things go off the rails you can always come back to the spec and give it another shot. Don’t be afraid of sunk costs, especially when you’re first learning. You can always make a branch and come back to it if you’re afraid of losing something.

Break Down

Now it’s time to take your spec and turn it into tasks. You must take this seriously as well: if you do a good job Claude will breeze through most implementations and testing, and it can also do things in parallel if you specify it correctly here too so you’ll gain speed by getting better at this phase.

This is similar to what you might have experienced helping a junior dev be productive. You break the tasks down and then do it again. You can often just ask Claude to make the steps smaller like some kind of agile coach for AI, it works. I’m dead serious, I usually say “not yet, break them down even more” a few times before I let Claude go at it. Questions like “Where do you plan to look at security?” work well too.

Sometimes you do have to tell Claude certain steps are missing and add steps manually, so some amount of focus is needed here too. Testing is especially important to call out and making sure the plan actually makes sense. It usually does but not always.

Execute

This is the phase where you let claude have at it. I don’t have a whole lot to say here except I like to keep the window open and keep glancing over at it, you can always hit the escape key if you catch it going off the rails. I will say if you do see it going way off the rails it’s often better to revert and fix up your PRD than try to guide it mid process, although that can work sometimes.

Iterate

Claude never gets it right the first try, it will miss obvious things in the spec. It will implement things wrong. It may even implement do-nothing tests or shove in placeholder code. This is the pressure testing phase where you sort all of that out. I do this by repeatedly asking Claude to compare it’s implementation to the spec until it says it matches exactly. This is often 2-3 tries, sometimes more. Then I ask about each subsection, to be sure.

You want to iterate in this way both horizontally and vertically: Horizontally meaning everything within one layer (i.e. backend, database, front-end, etc). And vertically (one specific facet or sub-feature). Call out anything you might consider tricky for a normal programer to do and ask it how it implemented it.

It’s not very hard to do though, you’re basically forcing Claude to check its work through different lenses. After some time you also begin to intuit where Claude will mess up, and will learn to ask about those.

I like to commit between every round of fixes in case it goes wrong and I want to give it another try. I’ll say it again: it’s ok to reset to a prior checkpoint and try it again if you feel like you’ve gotten stuck.

Testing

Sometimes this is mixed in with Iteration. It a good time to ask Claude to tell you about what is tested or not and in what way, horizontally and vertically, and to suggest better tests where needed.

You can ask Claude to evaluate itself here too, ask it to call out any particularly sophisticated logic or to rate itself on how well various areas are tested, and it usually does a good job. The trick is to do it repeatedly and to ask about specific sub-areas.

If Claude finds a problem in this mode it will typically fix it, which is rather nice. Don’t forget to checkpoint after each fix in case something goes badly.

Manual Testing

At this point you have something Claude thinks is working quite nicely, never fully trust it. Make a checkpoint! You’re almost there.

Run the build yourself. Run the tests yourself. Run the linter yourself. Always get in there and play with it yourself a bit. This is especially true on the front end where things can seem fine when you look at the code but cause weird performance issues.

Don’t get lazy you will regret it (I have regretted it).

Cleanup

Claude is an absolute code pig leaving garbage everywhere: markdown files, old broken tests, copies of code files, ancient database migrations, whatever else. It just piles the stuff up and never removes them. So you must tell it to get things ship shape for your PR, and it will do so without much issue. If you don’t clean up eventually the accumulated garbage in source control will begin to confuse Claude, this step is non-optional.

I recommend always committing a checkpoint to your feature branch before cleanup because occasionally it will trash actually important things while cleaning up.

Also take a quick look for any extra branches. Claude sometimes gets very branch-happy and you’ll find you have like 10 branches with code scattered between them. You can tell it to clean these up into whatever form you want. I typically like one clean PR with everything in it, but you can also have Claude break it up. It’s better than your typical dev at this kind of source control operation.

If you do have database migration files and a dev database right at the end of this is a good time to compare your database state to your migration. It has wrecked my migration while cleaning up migration iterations before.

Create PR

It’s foolish to let Claude have direct access to you main or dev branches. Claude will check in garbage to your most important branches and there’s currently no reliable way to avoid it at the Claude level. It will make you and your coworkers sad. It will do this even if you say explicitly not to in your CLAUDE.MD file. It will do this even if your CLAUDE.MD file has a very nice positively worded workflow for it to follow. Claude can really go off the rails once you enter a doom loop and get near the end of the context window.

The easiest way to prevent Claude trashing your repo is to implement a PR-only policy in your source control and then tell Claude to make PRs.

Claude is really good at the gh command line tool, you can ask it to make the PR and it will likely do a better job than any of your coworkers have ever done over your entire career.

This is also just a very clean way to commit, and gives coworkers and a chance to look (including other AI models) and leaves a nice record of the change with a detailed description.

Review PR

The second law of Claude vibe coding is don’t get lazy (The first law is always be closing). You are likely at least somewhat familiar with the code at this point and this can be a fairly quick review, as you might do on some code you partially paired on with a somewhat unreliable coworker. I have found major things in this phase, and putting the code into that familiar review context of a PR often triggers lines of thinking you might otherwise have missed.

Conclusion

And that is that. I hope you found my philosophy of vibe coding tutorial useful. This post was driven by a couple of friends who I’ve recently talked to about my process and I figured it would be best to share it broadly. If you have any questions or discussion points please reach out, I love talking about this stuff.