Sixty-six percent of developers say their single biggest frustration with AI is code that is almost right, but not quite. That number comes from the 2025 Stack Overflow Developer Survey, and I believe it, because I spent most of a year on the wrong side of it.

What fixed it was not a smarter model. It was writing down the parts of my job that had only ever existed in my head. That is all Claude for freelancers really is, and this post is the structure I built to do it.

I run Sitez Incorporated alone. Thirty-plus WordPress clients, one person, no employees. There is no product to install here and nothing to buy. It is a handful of plain text files and one task board, and I will show you how each piece works and why it is there.

The Problem Is Not the Model. It Is Everything You Retype.

An assistant that forgets everything between sessions is not really an assistant. It is a very fast intern on their first day, every day, forever.

The cost of that is not the wrong answer. It is the twenty minutes of setup you type before you get to the question. Which client is this? Where does their site live? Who hosts it? What did we decide last time, and why did we decide it that way?

Anthropic's engineering team calls the discipline of fixing this context engineering, and they state the goal plainly: find the smallest set of high-signal tokens that gets you the outcome you want. Not the most information. The least information that still works.

There is a hard reason for that. Chroma's Context Rot study, published in July 2025, tested 18 frontier models and found that they do not use their context evenly. Accuracy drops as the input grows, and it starts dropping long before the window is full. A model with a 200,000 token window can already be losing ground at 50,000 tokens.

So pasting everything you know into every session is not the answer. The answer is a small core that always loads, and everything else sitting on disk where it gets looked up only when it is needed. That split is the whole design.

One Playbook File for Client Work

All of my client work lives under one folder. At the root of that folder sits one file named CLAUDE.md. It loads at the start of every session in that folder, and it is the only thing that always loads.

The playbook holds operating rules, not facts about clients. Where deliverables get saved. How a task moves from start to finish. When the assistant may act on its own and when it has to stop and ask me. Which connectors it may reach for by default.

That last one matters more than it sounds. Google Drive on my machine is a sync layer over local files, not a separate place to read and write. Treating it as a second location was a repeating mistake until the rule went into the playbook. Now it is one line in one file and it never comes up again.

Under the playbook, each client folder that needs one gets its own CLAUDE.md. Those carry only what is different about that client: a quirk in their hosting, a plugin that breaks on update, a deploy step nobody else has. The rule is that the client file wins where the two disagree. Specific beats general, and both are on disk where I can read them and correct them.

Three CSV files so nobody has to describe a client

Alongside the playbook sit three files, all keyed on the client's site URL. One holds contacts and billing status. One holds filesystem paths and the client's Todoist project ID. One holds the technical details of the site itself: theme, page builder, host.

Because all three share the same key, a client name resolves into everything else in a single lookup. That is the trick, and it is the reason the playbook can stay short. The assistant never needs to be told about a client. It looks the client up.

Memory Is the Part That Makes It Useful

If you only take one thing from this post, take this one. The playbook makes the assistant follow my rules. The log is what makes it remember my work.

Every client folder, every project folder, and every personal folder carries the same subfolder, with the same name and the same four things inside it. Same convention everywhere, so I never have to think about where something went.

The activity log is the important one. Newest entry at the top, one entry per completed job, written at the end of the work rather than during it. Each entry has the same five parts: the task, the steps completed, the results, the issues, and the next steps.

The issues section is the one I insisted on. It is where the assistant writes down its own mistakes from that session, in plain language, with no softening. One entry on my own site records that it recommended a cache server address that turned out to be a guess and did not exist. Another records that it told me to set a renewal date to a value the plugin silently refuses, because it had read the form and not the code that saves the form. Both cost me a wasted cycle. Both are now written down where the next session reads them.

That is the difference between a chatbot and something that works for you. When I open a client folder six weeks later, the first thing that gets read is that log. It knows the fix we shipped, the thing we tried that failed, and the question still sitting with the client. I do not brief it. It briefs me.

When the active log gets long, older entries move to an archive file next to it. The active file stays short enough to read cheaply at the start of every session, which is the whole point of keeping it.

Todoist Is Where the Work Actually Happens

Files hold the rules and the history. Todoist holds the job. Every client gets a project board, and the board is the shared surface between me, the assistant, and in most cases the client themselves.

Three sections do the work:

• To Do holds what is queued, in the order it should be picked up.
• In Progress holds the one card being worked right now.
• Awaiting client input holds anything that stalled because it needs a decision from the client.

The card description carries the goal, written the way the client would describe it rather than the way I would build it. That is deliberate. It keeps the work pointed at the outcome the client is paying for instead of at the mechanism I find interesting.

When work starts, the card moves to In Progress. When it finishes, a comment goes on the card saying what changed. When it stalls, the card moves to Awaiting Ernie with a comment saying exactly what it needs from me. So the board is never a guess about where things stand.

The comment rule that took the longest to get right

Todoist emails those comments to the client. So every comment is a client-facing piece of writing, and it has two rules.

First, it is written in my voice, in the first person, and addressed to the client in the second person. The tell that it is wrong is the word "he." I caught this on a comment that read like an internal note the client could see, and my note back was blunt: who is he? I would not write "he," I would say "you."

Second, the internal detail comes out. Function names, snippet IDs, file paths and option keys do not belong in a comment a business owner reads. "The rate that was in place before was limited to a single zip code and set to zero percent, so no tax was actually being collected anywhere" is the comment. The database table it lived in belongs in the activity log, where a future session can find it and the client never has to.

That rule pays me back twice. The client gets a readable update the day the work happens, and at the end of a job I can assemble the wrap-up email straight from the comments instead of reconstructing the month from memory.

What It Is Like Now

The trial and error phase is over. The structure has been stable for months, and the changes I make to it now are small ones, a line here and there as something new comes up.

What it feels like, once you get there, is having a senior developer sitting beside you in your office. Not a search box and not an autocomplete. Someone who already knows the client, already read what happened last time, can look at the card and see what the client is actually asking for, does the work, and then writes the client an update you would have been happy to write yourself.

On top of the files and the board I have written procedures for the jobs I repeat, and a set of them run on a schedule without me. Fifty-six procedures and about twenty scheduled runs, as of the end of August 2026. But that layer came last and it is the least important part. It only works because the playbook, the log and the board underneath it are right.

None of it removes the need to check the work. 84% of developers use or plan to use AI tools, while only 33% trust their accuracy and 46% actively distrust it. That gap is fair. My own writeups on chasing a reinfecting malware campaign and on tracking down a WooCommerce mystery both turn on the same thing. The tool found the pattern. I confirmed it was real before acting on it.

How To Start

Do not start where I ended up. Start with one file.

Put a CLAUDE.md at the root of the folder where you actually do client work, and write down the five things you retype most often. Where files go. What your stack is. How you want things named. What you never want done without being asked first. That alone kills most of the setup typing.

Add the log second. One markdown file per folder, newest entry on top, written at the end of a session. This is the piece people skip and it is the piece that pays.

Put your tasks on a board third, and make the assistant work against the card instead of against a chat message. Write a procedure fourth, and only for a job you have now done the same way three times. Schedule something fifth, and only after that procedure has run correctly with you watching, because unattended work amplifies whatever your procedure actually says, including the parts you got wrong. Anthropic's own Economic Index reporting tracks that same drift from working alongside the model toward handing work off to it.

The architecture is not the point and few of my files transfer to your business. What transfers is the habit. Every time you catch yourself explaining something for the second time, stop and put it in a file.

If you are a freelancer trying to get this working in your own shop and you want a hand setting it up, get in touch. I am happy to walk you through what I did. And if you want to see it on a single job rather than a whole business, here is a full site audit done through the Claude Chrome extension.

Sources

• Anthropic, Effective context engineering for AI agents, September 29, 2025
• Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance, July 14, 2025
• Stack Overflow, 2025 Developer Survey, AI section
• Stack Overflow, 2025 Developer Survey Reveals Trust in AI at an All Time Low
• Anthropic, Anthropic Economic Index report: Cadences, June 2026