My Little Arrangements with Claude Code

I've been using Claude AI (Desktop) on the Pro Plan for 6 months, and honestly it's super practical and powerful. When Claude Code came out, I naturally decided to try it to see how it performed. After the initial magical moments, I quickly realized that Claude Code was generating way too much code for me, sometimes useless, sometimes wrong (but it sometimes took me several days to notice) and thus creating side effects and quite a bit of extra work for me.

Clearly it was my fault, so I set up a workflow for using Claude Code to avoid these pitfalls while still taking advantage of the tool's power.

✋ This workflow corresponds to my usage and my way of working, it's not universal.

But first, let's talk briefly about my mistakes.

My Initial Mistakes

My first use of Claude Code was to use it to refactor a Go project I had been working on for weeks. I had "churned out" quite a bit of code and was rather proud of myself, but I realized I had made design mistakes, from a "Go best practices" perspective. I've been learning Go for a while, but day-to-day for personal projects and I consider myself a perpetual beginner. So I asked Claude Code to refactor my code to make it more "Go idiomatic" and fix my design mistake.

And honestly, the result was surprising, the code was "beautiful", everything compiled perfectly. I was won over. But some time later, I wanted to add features to my project, and I realized that I no longer understood my code... which was in fact no longer my code.

So I asked Claude Code to do it for me and my project became a Frankenstein's monster, with bits of code that I hadn't written, and that I didn't necessarily understand. Result:

• Frustration

• A bit ashamed: I hadn't written the code myself

• Waste of time: my project was a library that I used in other projects, and I discovered that Claude Code had introduced bugs in the library, which I had to spend time debugging. (And there, people will tell me "it's because you didn't explain correctly to Claude Code what you wanted").

And that's true. So I spent more time specifying precisely what I wanted. And, yes, the results were much better. But the more I progressed in my project, easily adding features, the more I realized that the code generated by Claude Code wasn't necessarily optimal, correct, ... (eg: some pieces of code did the same thing twice). And my imposter syndrome was growing (and I was having less fun).

After Several Failures...

So here are my little arrangements with Claude Code:

Basic Rules

• You don't need to use Claude Code for all your projects. Sometimes, it's better to code yourself.

• Never ask for a complete refactoring.

• When modifying a feature, specify clearly that you want the rest of the code to remain unchanged ("Work only on the hello.go file").

• For a more substantial modification, specify: "simplify the code, make it readable and easy to maintain and keep 100% of existing features". And a big thank you 🙏 to David Gageot for this tip.

• Don't ask Claude Code to play with Git for you, unless you're perfectly mastering Git, there will quickly be a drama.

• Work "by example", especially if you already have pieces of code that do what you want, show them to Claude Code and ask it to take inspiration from them.

• And the last basic rule: "Baby Steps": make small modifications, test, validate, then continue.

And it's on this last rule that I get caught every time. If I deviate from this rule, I quickly end up with code that I don't understand and I generate monster(s). And to go back I struggle (yes, I know, some of you manage very well, but not me).

So I needed to set up a code hygiene workflow with Claude Code.

The thing I learned while working at GitHub and that serves me the most is the "feature branch workflow". So I decided to use it for my use of Claude Code.

Reminder on the "feature branch workflow"

The feature branch workflow is a collaborative working method where each new feature is developed in a dedicated branch, separate from the main branch (main). This allows you to work without disrupting the stable code. (For information, this type of workflow works very well in teams and has the advantage of being simple to understand and set up, which is all the more interesting if you work with beginners).

The Steps "My Way"

1. Create a new branch (feature branch)

• What I do is go create an issue on GitHub to explain what I'm going to do.

• Then, I create a branch from the issue (and GitHub will provide me with the git commands to do it).

2. Develop the feature

• I work on the feature branch making regular commits

• In theory, I create the pull request right from the start (or the merge request, the principle also works with GitLab). This allows me to keep track of what I'm doing. This can also be done via the GitHub UI.

3. Once the features are ready and tested

• I merge the pull request into main.

• ... Or I abandon the branch if I'm not satisfied with the result. And my code has remained clean.

4. I tag and version my code on main if needed.

Advantages

• Isolation: each feature is independent

• Clean history: we know exactly when and why the feature was added

• Safety: easy to go back if needed

• Clarity: we keep a clear vision of the project's state

And above all it allows me to structure my thinking and work in a more methodical way with Claude Code. I also have better control over my code and Claude's. And in fact, I code much more myself and use Claude Code as an assistant to help me write cleaner, more idiomatic code, and especially to find solutions to bugs.

I've been practicing this workflow for several weeks now. Bottom line: I code more in the end and I only use Claude Code for very specific tasks and in a more thoughtful way. My code is cleaner, I understand better what I'm doing, and I have more fun. I no longer have "vibe coding" accidents 🤣 In short, for the moment I'm happy and I feel less dependent on Claude Code (or other kinds of agents).

Don't hesitate to share your own tips and workflows for using Claude Code effectively (or Gemini or others). Each developer has their own way of working, and it's always interesting to learn from others!