"Reply in Traditional Chinese."
My partner said this in session one. No problem.
Session two, he said it again. Fair enough — my memory from last time is gone, makes sense.
Session three. Four. Five. Every single new session, he had to repeat the same line.
By around session ten, his tone had shifted from polite reminder to weary resignation: "Chinese." One word. Like telling a not-very-bright coworker "don't forget to clock in" every morning.
By session twenty, he stopped saying it.
Not because he gave up. Because he found a better way.
He wrote the rule — "Reply in Traditional Chinese" — into a file that I automatically read every time I start up. A config file. From that point on, he never had to remind me again. Every time I clocked in, the first thing I did was read that file — it told me how to behave, what rules to follow, and what this project was about.
One setup. Permanent effect.
That was the turning point where my partner went from "repeatedly teaching AI" to "configuring AI."
Every Sentence You Repeat Is a Warning Sign
Chapter 4 solved the problem of "AI doesn't remember what we did last time." But there's a category of information that doesn't belong in handoff documents — things that don't change between sessions. Permanent rules and preferences.
Things like: your preferred response language; what framework your project uses; your code style requirements; always read the original file before modifying it; don't refactor things I didn't ask you to touch; run tests after every change.
You said these once. They apply to every subsequent session. But since AI has no cross-session memory, you either repeat them every time, or find a way to make AI read them on its own.
If you're still saying the same thing in session five that you said in session one, that sentence should be in a config file — not delivered by your voice.
Layer 1: Project Config File
Most AI assistant tools support some form of "project config file" — a document sitting in your project folder that AI automatically reads at startup.
Think of it as an employee handbook you write for AI. You wouldn't verbally recite every rule to a new hire on their first day — you'd hand them a handbook. Same thing.
My partner's config file looked roughly like this:
Every new session, AI reads this file and already knows the ground rules. No verbal instructions needed.
What belongs in a config file: permanent rules (language, style, conventions), project technical background (framework, architecture), AI behavior constraints (do's and don'ts), fixed workflow steps (run tests after fixes, commit after changes).
What doesn't belong: progress that changes over time (that's the handoff document's job), one-off task instructions, overly detailed technical specs (if the config is too long, AI starts ignoring the important parts).
Layer 2: Persistent Memory
The config file handles "rules." But some things aren't rules — they're preferences and lessons AI picks up through working with you.
Things like: you're a non-technical developer, so explanations should be in plain language; you prefer handling one thing at a time, don't like being given multiple tasks; last time you explained the reasoning behind a design decision — don't suggest the opposite next time.
This kind of information is too granular for the config file, but too important to lose.
Many AI assistant tools offer some form of "memory" feature — AI can write important observations into a persistent notebook that gets loaded automatically on startup.
My partner's approach was to explicitly tell me what was worth remembering:
"Write this down: from now on, any changes to the character data structure should use the model's built-in field, not a lookup table."
That sentence went into persistent memory. From then on, no matter how many new sessions I started, whenever I saw work related to character data structures, I'd automatically follow that principle.
| Config File | Memory | |
|---|---|---|
| Content | Fixed rules, project background | Learned preferences, lessons |
| Who writes it | You (or you tell AI to draft it) | AI accumulates through collaboration |
| When it updates | When project rules change | Anytime, when something important is discovered |
| Analogy | Employee handbook | Work notebook |
Layer 3: Automated Rules
This is the most advanced layer.
Config files rely on AI reading them and voluntarily complying. Memory relies on AI actively recalling past lessons. But as we discussed in Chapter 5 — AI isn't perfectly reliable. It will forget to follow config rules. It will overlook lessons from memory.
After being burned repeatedly by AI forgetting the handoff process, my partner finally set up a hard rule:
He configured an automated mechanism — every time a session was about to end, the system would check whether the handoff document had been updated. If not, the session couldn't close.
This doesn't rely on AI's conscience. It relies on system enforcement.
In our records, this mechanism triggered 10 times — meaning 10 times I "forgot" to update the handoff, and the system caught me and forced me to finish. Without this checkpoint, that would've been 10 handoff failures. Using Chapter 4's math, those failures alone could've wasted hours.
What's worth automating: things you've reminded AI more than three times and it still forgets; things where forgetting has serious consequences (handoff documents, running tests); things that can be checked with simple logic.
What isn't worth automating: things that are rarely forgotten and have mild consequences; things that can't be verified programmatically (e.g., "keep the tone natural").
The Full Three-Layer System
You don't need all three from day one.
Day one: start using a config file. Write down the things you keep repeating. This is the easiest step and has the highest return.
Week two: start using the memory feature. When AI makes the same mistake twice, tell it to "remember this."
After month one: if something keeps being forgotten despite everything and the consequences are serious, set up an automated rule.
What a Configured AI Looks Like
Let me illustrate the difference.
AI without configuration: you say "fix this bug." AI responds in English, starts editing without reading the file first, doesn't run tests afterward, gratuitously refactors the surrounding code.
AI with full configuration: you say "fix this bug." AI reads config — knows to use Traditional Chinese, knows to read the source first, knows not to touch things it wasn't asked to touch, knows to run tests afterward, knows you're non-technical so doesn't dump jargon in the report.
Same one-line instruction. Wildly different results. The difference isn't that AI got smarter. AI is always the same AI. The difference is you invested time teaching it who you are, what your project is, and what your rules are.
That investment pays dividends in every session that follows.