How I code with AI: my real workflow with Claude Code

I code with AI every day. Not as occasional help: as part of the workflow.

Here's how I actually do it, with what works and what has gone wrong.

First thing: write the context once

The most expensive mistake I made early on was explaining the project again in every conversation.

Now every repository of mine has a CLAUDE.md file at the root. It's a document the model reads at the start, and it holds what a new developer would need on their first day:

• The commands. How to start it, how to build it, how to check it.
• The architecture. What's in each folder and why.
• The decisions that don't get touched. On my site, for example, there's a rule that says you always navigate with the Link that keeps the language, never with a plain link. That fixed an SEO bug I'd already made once.
• The traps. Things that look fine and break the build.

The file for my personal site runs to about two pages. Writing it properly takes half an hour. It pays for itself in the second session.

What matters isn't that it's long. It's that it holds what you can't work out by reading the code.

How I frame the job

A badly framed job gives you code that compiles and is useless. A well framed one is half the work done.

I do it in three parts.

What I want to get, as an outcome, not as steps. "I want the project page to show the gallery on mobile without loading the big images" beats "add a gallery component".

Where that lives, in specific files. If I tell it where to look, it doesn't invent a parallel structure.

What it can't break. This is where I gain most. "Don't change the h1 markup", "don't add new dependencies", "this still has to generate statically in all four languages".

That third part is the one almost nobody writes. It's the one that avoids 80% of the disasters.

What I hand over and what I don't

After a good year of doing this I have a fairly clear split.

I hand over completely:

• Translating a component into another language, or adapting copy to four locales.
• Repetitive changes across many files. Renaming, migrating an API, applying a new pattern in twenty places.
• Writing the first version of something I've built before: a form, a table with filters, a CRUD endpoint.
• Reading someone else's code and explaining it to me. This is where it saves me most time and carries least risk.
• Tests and checks I'd write half-heartedly.

I don't hand over:

• Deciding the data architecture. How one company's information is isolated from another's in Savia, I decided myself, on paper, before writing a line.
• Anything touching security or permissions without me reviewing it line by line.
• The part of design that takes judgement. A model gives you a correct interface. The gap between correct and good is still yours to close.

The rule I use: if I wouldn't know how to review the result, I don't delegate it. AI isn't a substitute for understanding what you're doing. It multiplies what you already understand.

The build is the judge

I consider this the most important part of the whole article.

My site has no tests. It has something that works just as well in practice: the build command statically generates every page in all four languages. If a translation is missing, if a JSON isn't closed properly, if a route doesn't exist, the build fails.

So the standing instruction is: don't tell me it's done until the build passes.

This changes the work completely. Without an automatic check, reviewing generated code costs you more than writing it yourself. With one, you look at the result and the machine handles the mechanical part.

Writing got cheap. Checking didn't. And now there's a lot more to check.

That's why, when I start a new project, the first thing I set up is the way to verify it. Before the first feature.

Go in stages

A big job gives bad results. I always split it up.

A real example, the blog section of this very site:

1. Read the content files and pull out their metadata. Check that all eight articles show up.
2. The listing page, without fine design. Check that it renders.
3. The article page with the markdown rendered.
4. Metadata, canonical and hreflang. Check it in the generated HTML.
5. Sitemap and structured data.
6. Design.

Each step gets reviewed before the next one. If step 3 came out crooked, I fix it there. Not after stacking six layers on top.

When something goes badly wrong, I'd rather start the conversation from scratch with corrected context than argue. Pushing on inside a long conversation that already went the wrong way almost never comes cheap.

What has gone wrong for me

In case it saves you the trouble.

Accepting code I didn't understand. It compiled, it did what I asked, and two weeks later I had no idea why it was written that way. Now, if I can't explain why it works, I rewrite it until I can.

Letting it reorganise folders on its own. A change I asked for in one component ended up touching eight files. All of them correct. None of those eight was the one I wanted touched. Since then I set the scope in writing.

Trusting suggested dependencies. A package that solves the problem may have gone unmaintained three years ago. I check that myself, always.

What has really changed

It isn't that I write more code. It's that I finish things I used to leave half done.

Boring work costs more than the time it takes: it's the reason projects get abandoned. When that part stops hurting, you finish more.

The other thing that has changed is what sets me apart. Writing the code isn't the scarce bit any more. Knowing what to build, for whom and why, is.

Before it replaces professions, AI is replacing tasks. It's worth knowing which ones are yours.