How I cut my CLAUDE.md from 1,090 lines to 83

A marketer with no programming background builds production software. On the working method that makes this possible, and what a failed configuration file taught me about it.

My most valuable AI partner is the same one that delayed my project for weeks with a single piece of bad advice. That is not a criticism of Claude. It is a criticism of any workflow where one AI source is the only truth. Including the source you use every day.

Context first. I am a marketer, 15 years in B2B, ex-AWS EMEA. During the day I lead global marketing at Nordcloud, an IBM company. In evening hours and weekends I build CoNudge, a B2B2C SaaS for personal trainers. Two to three hours per weekday evening. On weekends I get up at 5:30 for four to six hours in the morning, plus the evening. On this project: no team, no budget. I am not a programmer and have no plans to become one.

Yet there is a working app. The pilot starts in August 2026 with ten personal trainers.

The bug that was not a bug

For three weeks my app kept forgetting its user's profile. After four weeks of training, everything was gone: goal, sport, experience level, training days, equipment. The technical cause was found quickly. The API trimmed every chat to the last ten messages to control costs. Precisely the first messages, containing the profile and progress, fell out.

The real diagnosis sat deeper. It sat in CLAUDE.md.

CLAUDE.md is the file Claude Code automatically reads at the start of every session. Think of it as a briefing for a new colleague who loses his memory every morning. What is in the file, he knows. What falls outside it, he forgets or invents.

My CLAUDE.md counted exactly 1,090 lines on April 3, 2026. Vision, protocols, history, decisions, open tasks, everything in one file. Claude Code missed things in it. Resolved bugs kept returning. Claude later summarized it himself: "our CLAUDE.md is 1,090 lines. That is 18x too long. Claude Code ignores rules that sit far from the top."

On April 3 at 06:44 I sent Claude this message. I quote directly from my work notes, including the typos of an early morning, in the original Dutch:

"ik wil geoon 100% dat we netje zoals hoort deployen volgend process ik begrijp niet wat je doet dus er moeten dubbel check in zitten een source of trourht en een duidelijk protocol."

Translation: I want 100% certainty that we deploy properly, by process. I do not understand what you do, so there have to be double checks, a source of truth and a clear protocol.

Claude's original advice, weeks earlier on March 31, read: "The real problem: CLAUDE.md is your only source of truth. If it is wrong, Claude Code writes next session's code against a wrong schema."

That advice was half right. Source of truth: yes. One large file: no. But I could not judge that at the time, because I do not read code.

The pipeline: no single source is the truth

For major architecture decisions I have since used a fixed method. Not for every commit, but for every decision that touches the foundation. Six steps.

Step 1. I describe the problem to Claude in plain language. Example: "How do I build an AI coding workflow as a non-technical person."

Step 2. I have Claude write a deep-research prompt. Claude writes better research prompts than I do. I review two to three times and request rewrites. Sometimes with a persona role, in the style of prompt researcher Sander Schulhoff. Not always.

Step 3. The same prompt goes into three LLMs in parallel: Claude, ChatGPT and Gemini. Three deep researches run simultaneously.

Step 4. The three outputs go into NotebookLM. In my experience the best tool for synthesizing large volumes of text. I collect the findings there per theme.

Step 5. Based on the synthesis I write a PRD for Claude Code.

Step 6. I have that PRD reviewed in a brainstorm session inside Claude Code, which can see my full codebase. Then the Compound Engineering plugin by Kieran Klaassen takes over execution.

No link in this chain is a single point of trust. Including myself. Especially myself.

What the pipeline delivered

I ran the CLAUDE.md question through these six steps. The outcome was not what Claude had advised earlier.

Not one large file. A router.

CLAUDE.md became 83 lines pointing to thirteen modular files in .claude/rules/: protocols, security, database, API routes, onboarding, coach system, gotchas. Separate folders for skills and session handoffs. From that day's log: "1090 → 83 lines router + 1254 lines across 13 modular files. Nothing lost."

The intermediate step was 857 lines. That did not work either. The guideline that came out of the research, drawing on the Compound Engineering documentation and analyses on Every.to, was 60 to 200 lines.

The insight was counterintuitive. For humans, one document containing everything is often convenient. For LLM context it backfires: more context means more noise. Claude summarized the new approach himself as "CLAUDE.md as a router, not an encyclopedia."

For completeness: six weeks later, on May 21, the file stood at 138 lines again. Within the upper bound, but growing. Documentation creeps back when you stop paying attention.

The bar-raiser method on a team of one

At Amazon and AWS, no significant document passes without bar-raiser review. A bar-raiser sits outside the project, is trained in critical reading, and has one goal: keeping the bar high. Six-pagers, thirty minutes of silent reading, sixty minutes of critical discussion. A bar-raiser can reject a document regardless of the author's seniority.

I work for an employer during the day. On this side project, I work alone. No colleagues available for review, no engineering team to consult. But three LLMs and NotebookLM. Same discipline, different raisers.

At AWS a bar-raiser has ninety minutes per document, inside working hours. I have two hours per evening for everything combined. So the pipeline has to do more than hold up. It has to run in parallel.

A typical evening during the CLAUDE.md research looked like this: Claude Code was executing a PRD for a bug fix. In a second tab, I was brainstorming the restructure with Claude. Cowork was meanwhile synthesizing the three deep-research reports from Claude, ChatGPT and Gemini into one comparison. Three tools, three tabs, three processes I did not have to watch simultaneously. I switched between them when something was delivered.

Bar-raisers sit in one meeting at a time. AI bar-raisers wait for no one.

When four out of six sources agree, I treat it as true. Three LLMs, two podcasts, one market report. When they differ, marketing instinct decides as tiebreaker. Fifteen years of B2B is the one input no LLM can replicate.

What I cannot do, and what the system does instead

I am not a programmer. I do not read code, and I cannot judge whether code is good or bad. With a human engineer I could not judge that either, so this is not an AI problem.

That is why guardrails exist. ESLint checks syntax. Mirdan flags AI slop in my codebase; its exact logic is a black box to me, but the pre-commit hook stops bad commits before they reach the repo, and that is what I need. Husky enforces those hooks. The Compound Engineering plugin reviews PRDs. Twenty self-written protocols catch patterns I learned to recognize over four months. A lens review, with perspectives from CTO, CFO, security, legal and marketing, forces me to examine every major decision from six angles.

The system is deliberately designed to be self-improving. Fewer bugs over time. The repo gets better. Not me.

Whether this scales beyond one person, I do not know yet. The CoNudge pilot starts in August 2026, with ten personal trainers. That will be the first real test.

CoNudge is the B2B2C SaaS for personal trainers I am building. Pilot starts August 2026. conudge.com