Six months of evolving how I use AI agents like Claude Code in my daily dev work

Since the beginning of 2026, I have been developing every day with Claude Code.

Like many devs, I started by trying it out on several personal projects. In my case:

• a DPE (energy performance) calculation engine
• a property management SaaS
• a personal wealth application

Each project got its own instruction file for the AI agent (CLAUDE.md, then AGENTS.md). Then, over time, going back to these files, I realised they tell a story!

The story of how I work with an AI, which has changed quite a bit since 🙂.

This post walks through those four stages, and what I take away from them.

Stage 1 · The “golden rules” (April 2026)

The first file, on the DPE calculation engine, looked like this:

## Golden Rules

- Always propose a short plan before implementing
- Keep things SIMPLE
- Avoid over-engineering
- Prefer fewer files, fewer abstractions
- Business logic MUST stay outside UI
- Tests are mandatory for meaningful logic

## Forbidden unless explicitly asked

- Microservices
- CQRS heavy setups
- Event sourcing by default
- Massive refactoring

A list of preferences, basically, and it worked rather well: “propose a plan before implementing” saved me many times from going way too fast.

But the real value came from a single line:

For each new feature, check the calculation reference at `doc_methode_calcul_dpe/docs`

I had transcribed into Markdown the annex of the French regulation that defines the 3CL calculation method (25 sections, four consolidated decrees). So Claude had a readable business source of truth, and not just style guidelines.

👉 First lesson: an agent codes well what it can check. Giving it the business reference is worth more than ten style rules.

The limit of this file: it said how to code, but never when to stop or what to do when you don’t know.

Stage 2 · “Never guess”

On the property management SaaS, I added the rule that changed my daily work the most:

Never guess. If you don’t know (business rule, product intent, expected format, default value, open design choice…), ask me explicitly before coding. A short question beats a patch built on a wrong assumption.

Then a second one, right above it: documentation before code. Every new feature starts with a SPEC (context, persona, vocabulary, expected behaviour, open questions), and no implementation plan is proposed until the open questions are resolved with MY help.

The file also held the tricky domain vocabulary. For example, Copropriete (the units one owner holds in a building) is not Syndicat (the whole building, with all its co-owners). Without that clarification, the AI agent naturally extended the existing concept, which was exactly the wrong choice.

The trap: two files drifting apart

This is the project where I made the most instructive mistake. There was a CLAUDE.md and an AGENTS.md (for the other agents), written with the same content at first.

Later, an ADR decided we would move away from event sourcing for most aggregates (I’ll come back to that in another post). I updated CLAUDE.md. Not AGENTS.md, which still states:

- Event sourcing strict (agrégats + events)

An agent reading that file will confidently defend an architecture I abandoned.

👉 Second lesson: a single source of truth.

Since then, my CLAUDE.md holds only one line, @AGENTS.md, and every agent reads the same file.

Stage 3 · Philosophy before rules (July 2026)

On the personal wealth application, I changed approach. Instead of a list of rules, I first wrote a PROJECT_PHILOSOPHY.md: the product’s intent, why I wanted to build it.

A short excerpt below:

AI is a design and execution assistant, never the business decision-maker.

When a choice is ambiguous or has significant business consequences, the AI asks for clarification. When a choice is mechanical, reversible and consistent with the documents, it may act and briefly state its assumption.

That distinction between ambiguous and mechanical choices solved a problem I had in stage 2: because of “never guess”, Claude sometimes asked questions about details, which “lost” me a bit and took me way too far at times.

Three other ideas came up at that point.

Separate facts, assumptions and decisions. The AI agent must say what is written somewhere, what it infers from it, and what remains unknown. And never turn an assumption into a default rule.

Not just writing tests, but running them too. At first, I mostly asked Claude to write tests. Then, as the months went by, I started to trust it more, and I asked it to run integration tests itself, against a real PostgreSQL database (and not an ORM mock!).

Indeed, without that, a broken mapping (for example an EF Core column silently missing) goes unnoticed.

Demand proof, layer by layer. This is the section I am most pleased with:

- UI: actually run the application and play the scenario in a real
  browser (Playwright or equivalent). A `curl` on the page only proves
  the initial HTML render, not interactivity (Blazor Server runs on SignalR).
- Never report a check as done without actually running it.
  "It should work" is not a check.
- A test that cannot fail does not count as coverage.

Each line of that section matches a time Claude told me “it’s fixed” when it was not.

👉 Third lesson: explaining the why lets the AI agent settle on its own the cases the rules did not anticipate.

Stage 4 · A reusable kit (October 2026)

After several projects, I got tired of copying and adapting by hand. So I restructured my resources repository into a kit of templates to copy into a new repository.

The heart of the kit is an eight-step procedure. Steps marked STOP end the AI agent’s turn until a human answers:

#	Step	What the AI agent does
1	Read	AGENTS.md, the SPEC, the applicable ADRs, the code involved
2	Sort	Separates facts, assumptions and unknowns
3	Specify	Drafts or updates the SPEC if business behaviour changes
4	Ask · STOP	Asks the questions whose answer changes the result
5	Plan · STOP	Approach, files touched, impacts. Waits for explicit approval
6	Implement	The smallest change that satisfies the SPEC
7	Verify	Runs the checks and reads their output
8	Report · STOP	Changes, assumptions, checks actually run, commit message

A trivial request (typo, explicitly requested rename) may go straight to step 6, as long as the assumption made is stated.

A few choices that were put in place:

• RFC 2119 keywords (MUST, SHOULD, MAY). It looks pedantic, but an agent clearly tells a recommendation from a prohibition.
• The AI agent never commits. It prepares the diff and proposes the message, I am the one who commits. Approving a plan approves the implementation, not the commit.
• Always ask about security, personal data, deleting or migrating data, and production, even when the answer seems obvious.
• A source priority: ADR > architecture docs > SPEC > code. On a contradiction, the AI agent reports it before implementing anything.
• Layers: a base for any stack, then a .NET layer, a GitHub layer, a Blazor layer. Convention files are copied unchanged, project-specific rules only go in AGENTS.md. That way I can update a project’s conventions without losing anything.

Bonus: stopping the AI agent from reading images

On a project where the images were not produced by AI, the graphic design team wanted us to put restrictions in place to stop AI from reading their work. Indeed, in the Git repository, we had image assets, logos, etc. made by graphic designers.

So we set up instructions to forbid AI agents from reading image files. Besides, on top of being expensive in context, it is rarely useful for a coding task.

In Claude Code, these are permissions.deny rules on Read(./**/*.png) and the like. But you have to be clear-eyed:

• it blocks the built-in read tools and the shell commands it recognises (cat, head…);
• it does not block a script that opens files without naming them;
• a .claudeignore file has no effect in Claude Code.

Hence a rule in AGENTS.md that explicitly forbids working around the block. A written rule is not a technical guarantee, but the two complement each other.

What I take away

1. Provide the business reference. An agent with a checkable source of truth writes better code than an agent with style rules.
2. Write down the why. Rules cover the expected cases, philosophy covers the rest.
3. A single source of truth. A duplicated instruction file always ends up lying.
4. Explicit stop points. “Propose a plan” is not enough. It has to be “propose a plan, then wait”.
5. Demand proof. “It should work” is not a check, for an agent or for a human. And as trust grows, I also ask it to run the integration tests.
6. The file lives with the project. When an ADR changes the architecture, the instruction file belongs in the same commit.

In the end, reading it back, none of this is specific to AI!

Indeed, it is what I would expect from a rigorous developer joining the team: read before acting, ask the right questions, stay within scope, and never announce a result they have not checked.

The difference is that with an agent, you have to write it down in black and white. And that forced me to clarify my own way of working.

It is also the natural follow-up to setting up ADRs in my team: documenting decisions serves humans as much as agents.