The compound effect of AI has a dark side nobody talks about.
Build good habits with it and they compound into something real.
Build lazy habits and those compound too, into a dependence you don’t notice, until it’s too late.
I’ve had a version of this conversation with multiple founders this year, and it always splits the same way.
Same Claude Code, same MCP servers, same starting capability.
Six months apart, they’re describing two completely different relationships with the stack.
✅ The founder who compounds
Reviews every AI-drafted email before it goes out
Tests messaging manually before automating anything
When something fails, updates the no-go list so the system never repeats it
When something works, asks why and writes the pattern into CLAUDE.md
Each campaign lands a little sharper than the last, because the system remembers what he learned instead of him having to.
❌ The founder who gets dependent
Automates everything from day one
Hardly reviews the output, checks the dashboard instead of the emails
Runs the same generic campaign month after month, because nothing feeds learning back into the system
Ask this founder six months in to describe his own ICP without opening a prompt, and watch him struggle.
AI didn’t make him better. It replaced a muscle he stopped using, slowly enough that he never noticed the trade.
Same stack. Opposite outcomes.
The gap isn’t which AI you use, since both founders above are usually running the exact same stack.
It’s where you’re treating it as a training partner or a shortcut.
The founders who review, refine, and feed their learning back into the system are building something that compounds every week.
The founders who automate and forget are building a dependency that gets harder to unwind the longer they wait.
Run this before automating anything else
The habit that separates the two doesn’t need to be complicated.
It’s writing down why something worked, every time, so the system inherits the lesson instead of losing it.
Here’s a Claude Code prompt that forces that habit instead of hoping you remember to do it:
You are my GTM system architect. I'm building the foundation
of my outbound system in Claude Code instead of renting a
managed AI tool: two files, CLAUDE.md and BATTLECARD.md, that
every future session will read before doing anything else.
Never smooth over a vague answer into something that sounds
specific. If my answer is soft, tell me it's soft and ask me
to sharpen it before moving on. A file built on vague answers
produces vague outreach, which is the exact failure I'm
building this system to avoid.
## STEP 1: INTERVIEW ME, ONE QUESTION AT A TIME
Wait for each answer before asking the next.
For CLAUDE.md:
- What I sell, in one sentence, and roughly what it costs
- My best customer of the last year: who, what was happening
in their business right before they bought, what it was
costing them
- The customer I regret taking: who, and the early warning
sign I ignored
- Two or three job titles I actually sell to, not job titles
I wish I sold to
- One phrase or tone I never want to sound like
For BATTLECARD.md:
- My single best proof point: a named customer (or
anonymised, my choice) and a specific number. If I don't
have one yet, say so rather than inventing one, and note
it as a gap to fill before this file is trustworthy
- The one thing that makes a prospect say yes, described the
way a customer would say it, not the way my website does
## STEP 2: DRAFT BOTH FILES
Write CLAUDE.md with these sections: ROLE, COMMUNICATION STYLE
(3 voice rules from my answers, not generic advice), IDEAL
CUSTOMER PROFILE (written as the condition my best customer
was in, not just firmographics), NO-GO LIST (built from my
regret customer).
Write BATTLECARD.md with: THE PROBLEM WE SOLVE, THE PROOF
POINT (exactly what I gave you, flagged clearly if it's
generic rather than a named result), OBJECTION HANDLING (ask
me for my single most common objection and draft one response
to it).
## STEP 3: STRESS-TEST BOTH FILES
Before finalising, tell me which answer I gave you was the
weakest, the one most likely to produce generic output if I
don't fix it now. Push back on that one specifically. Then
tell me what's still missing that a full system would need,
the proof point, the ICP, or the voice rules, so I know this
is a starting foundation, not the finished system.
Keep both files under a page each. Every future session
inherits them, so nothing generic gets in.This is the kind of habit that separates the two founders above.
One does this every week without thinking about it.
The other has never run anything like it, which is why nothing he learns ever makes it into the next campaign.
Takeaway
The stack was never the variable. It’s identical in both cases above.
What decides the outcome is whether someone keeps doing the thinking, or hands it over the day the automation starts working well enough to ignore.
Run the prompt above after your next batch, and you’ll already know which side of this you’re on.
PS: The prompt encodes one batch of lessons. The Context Engineering framework is the full system: the CLAUDE.md structure, the four components of an AI-ready GTM setup, and the method for making every session compound instead of repeat.
