Three separate pieces of scaffolding, one outcome: nothing has to be re-explained or relearned.
Why this exists
Every one of my public projects — this site, and a couple of independent AI-research builds — gets touched by an AI coding agent regularly, often across sessions weeks apart. Left alone, that produces a specific, boring failure mode: each project drifts its own way, voice and quality bar diverge, and every new session re-litigates decisions a previous one already made. None of what follows fixes that with a clever prompt. It's three plain pieces of scaffolding — a persistent instructions file per project, one shared style guide across all of them, and a memory system that survives between sessions — doing for an AI collaborator roughly what onboarding docs and a style guide do for a human one.
1. A persistent instructions file per project, checked into the repo
Each project carries its own instructions file that an agent reads automatically at the start of every session: what the project is, its conventions, its guardrails, what's still outstanding. It's not a one-off prompt — it's versioned alongside the code, so it accumulates the same way documentation should: corrected when it's wrong, extended when something new is learned, never re-explained from scratch. The value isn't the file's existence, it's that it's the first thing read, every time, so a correction made once stays made.
2. One shared style guide across every public touchpoint
Several small AI-research projects, built independently and quickly, ended up with inconsistent voice — one drifted into fabricated-sounding jargon and invented precision it hadn't earned. Rather than fix each project's copy separately, I wrote one shared style doc — plain rules about tone, real citations, no fabricated verification claims, no decorative jargon — and pointed every project's own instructions file at it. A prospective client or collaborator bouncing between my site and my side projects should see one coherent, credible person, not a polished CV next to unreviewed AI-generator output.
That review pass caught real problems, not just tone: two of those research projects originally shipped with wide-open database rules combined with writes going through the client SDK — meaning anyone who found the necessarily-public client config could write or delete data directly from a browser. Fixed by moving writes server-side and locking the rules down. The style guide is what made me look at those projects critically enough to find it, not a separate security audit.
3. A memory system that survives between sessions
The most repetitive failure with AI coding agents isn't a wrong answer — it's the same correction, given again, because the last session's lesson didn't persist anywhere. I keep a small, file-based memory system alongside each project: notes on decisions and their reasoning, corrections I've had to make more than once, and pointers to where the ground truth actually lives (an external tracker, a specific doc) rather than a stale copy of it. An index file keeps it skimmable. The discipline that matters isn't the format — it's treating a repeated correction as a signal to write something down, not just fix it again.
4. Draft in private, publish deliberately
Not everything an agent touches is ready for anyone else to see. I keep a strict separation: private working repos for drafts, research notes, and anything not yet reviewed, and public repos that only ever receive material copied over on purpose, one finished piece at a time — never built directly against the private source. It's a slower publishing process than "just push it," on purpose. Several real fixes (the database-rules issue above, a couple of factual corrections to claims that had drifted from what actually happened) got caught specifically because that review step existed before anything crossed from private to public.
What this actually buys
None of this makes an agent smarter. What it does is stop the same categories of mistake from recurring: a security pattern gets checked on every new project because it's written down once, not rediscovered by luck each time; a factual claim gets challenged the same rigorous way every time because the process is documented, not remembered ad hoc; and a public project reads as part of one coherent body of work instead of a pile of disconnected demos with wildly different quality bars. It's the same underlying idea as any other agentic-engineering discipline: don't trust an agent's output by default, and don't trust your own memory of "we fixed that already" either — write the correction down somewhere it will actually get read next time.