Injecting first-hand experience into an AI draft

Chapter 5 of 7. Prerequisite: Chapter 4. You should already treat the model's output as raw material rather than a draft. This chapter is the pass that turns it into one: the structural edit that swaps generic claims for things that happened to you, with the dates and version numbers still attached.

Every tool guide covers prompting. Most now cover counters and thresholds too. Almost none cover the move that separates a publishable piece from fluent filler: embedding experience the model cannot have. Google names the gap directly. The helpful-content documentation defines "experience, expertise, authoritativeness, and trustworthiness, or what we call E-E-A-T" and then ranks the four: "Of these aspects, trust is most important. The others contribute to trust, but content doesn't necessarily have to demonstrate all of them. For example, some content might be helpful based on the experience it demonstrates, while other content might be helpful because of the expertise it shares."

Experience is the one item on that list a language model cannot supply. It has none. Supplying it is your job, and the job is structural. You do it on the page, in the edit, against a record you kept. You do not do it in the prompt.

The tell that no counter catches

The deterministic audit this course closes on counts surface patterns such as em-dash density, hedge phrases, and throat-clearing transitions. It refuses, by design, to judge semantics. Fabricated specifics and empty assertion pass straight through it, because a shell script cannot know what you did or did not do.

That leaves a whole class of tell untouched. A generic claim is grammatically clean. Its em-dash density reads zero. No hedge word appears. Every counter shows green. The paragraph still reads as AI, because it asserts things anyone could assert.

Here is the shape, labelled as an example so it stays out of this chapter's own tell counts:

We iterated on our AI's voice several times, testing different approaches
to tone and register. Through careful experimentation and reader feedback,
we refined the output until it matched our brand — a process that taught
us valuable lessons about balancing precision with warmth.

Nothing in that paragraph happened. No test id, no version number, no date, no result that could have gone the other way. A reader cannot falsify a single sentence of it, and a sentence nobody could prove wrong is a sentence nobody needed.

Google's spam policies give the same diagnosis from the ranking side. The scaled-content-abuse section lists, verbatim, "Using generative AI tools or other similar tools to generate many pages without adding value for users" as an example of abuse. The dedicated generative-AI guidance page repeats the test in its own words: "using generative AI tools or other similar tools to generate many pages without adding value for users may violate Google's spam policy". The operative phrase in both is "without adding value". The value a model cannot add on its own is precisely the thing this chapter injects.

How to inject personal experience into an AI draft

Start with what does not work: asking the model to sound experienced. A 2026 preprint from UC Berkeley's D-Lab (van Nuenen, arXiv:2604.22142) tracked 300 personal narratives rewritten by three frontier LLMs under three prompt conditions and found "a consistent pattern of stylistic normalization" across every model and condition tested. Voice-preserving instructions cut the drift by about a third but did not change its direction. Prompting mitigates. It does not reverse. Chapter 6 takes that result apart in full; the consequence for this chapter is that experience gets injected by hand, after the model has finished, from material the model never saw.

The intervention is four moves, in order.

1. Build the inventory before you touch the draft

   Go to your own records. Devlog entries, commit messages, tickets, test runs, support threads. Pull out dates, ids, version numbers, exact figures, file paths, error output, decisions with the reason attached, and any result that surprised you. This site's source material is an engineering devlog, and every chapter in this course traces back to dated entries in it. No log means no inventory, so if you do not keep one, the honest first step of this whole method is starting it today.

2. Mark every claim anyone could make

   Read the AI draft and highlight each sentence that could appear unchanged on a competitor's site. Those are the swap targets. The fastest filter is falsifiability: could a reader, in principle, check this sentence and find it wrong? If not, mark it.

3. Swap or cut

   Each marked sentence either takes an inventory entry or leaves the piece. Do not let a generic claim stay as connective tissue between two specific ones. The reader's trust decays on contact with the first sentence that sounds like everyone else.

4. Keep the failures

   When the inventory offers a success and a failure on the same topic, the failure carries more signal. The next two sections show why.

The swap, on a real article

The article this chapter leans on is Both voice iterations failed the Cash ISA test. I shipped the original. It documents a voice experiment on a UK personal-finance calculator site, and its credibility is carried entirely by inventory entries of the kind step one collects.

The specifics in that piece: a content monitor watching 14 curated UK personal-finance sources on a 3-hour cron heartbeat, polling each source by its declared fetch type and deduplicating by URL plus SHA-256 hash. A committed source allowlist where every entry carries a fetch_type and an advice_language_risk flag. A cron disabled pending backlog item B-012. Voice versions numbered v1.0.0, v2.0.0, v2.1.0. A blind test with an id, SC-010: three Cash ISA drafts built from the same calculator and the same data, version labels stripped before reading. Selection came back v1.0.0. The original. Second failure in two attempts.

Put the generic and the lived version of one of those beats side by side:

Generic:  We ran a blind test comparing the different voice versions and
          found that the original approach performed best.

Lived:    Three Cash ISA drafts, labels stripped before reading. Selection
          came back: v1.0.0. The original. Second failure in two attempts
          (test id SC-010).

The two versions report the same event. Only one could have been written by someone who was there. Note what the difference cost: nothing in writing skill, everything in record-keeping. The test id existed because the experiment was logged. The version numbers existed because the voice config was versioned. Injection is cheap at edit time and impossible at edit time if the record was never kept.

The failure is the signal

"Both voice iterations failed. I shipped the original." Only someone who ran the experiment writes that sentence. Ask a model for a story about voice iteration and you get a refinement arc that ends somewhere better than it began. The lived version produced a reset. v2.0.0 aimed for analytical precision and came out, in the article's words, as "a rate sheet. Accurate, complete, cold." v2.1.0 over-corrected into named empathy and landed as "a fintech chatbot". The version that shipped, v1.1.0, contains zero new voice prompting. Its entire diff is a documented rule: if the blind test fails twice on the same voice change, reset to the last passing version. The article is precise about the label: "Not a revert… A reset, labelled as one."

A negative result is the strongest inventory entry you own, for one structural reason: it is the entry a model would never volunteer. Generation optimises for plausibility, and the plausible arc of an improvement story bends toward improvement. Publishing the reset, with its test id and version numbers intact, is a signal no volume of generated success stories can imitate.

The same article carries a second first-hand beat that shows another marker of lived writing. On the ship day, a helper script turned out to be calling an LLM API directly over urllib.request with an API-key environment variable, against the project's convention of going through the vendor CLI. The owner flagged it immediately; the fix swapped the call for a subprocess invocation of the CLI. The article then connects the two incidents: "Both the voice regression and the auth drift are the same shape of problem: an implementation choice drifted from an established convention… Different gates. Same function: surface drift before it propagates."

That cross-domain link, from voice regression to auth drift, is a pattern only experience produces. Generic prose stays inside its topic because there is no memory underneath it to connect one domain to another. When your draft draws a line between two incidents from different parts of your own work, no counter needs to certify the prose as human. The structure certifies it.

Disclosure comes free

The helpful-content page makes a recommendation most AI-writing guides treat as a separate chore: "Sharing details about the processes involved can help readers and visitors better understand any unique and useful role automation may have served." The same page states the line you must stay on the right side of: "If you use automation, including AI-generation, to produce content for the primary purpose of manipulating search rankings, that's a violation of our spam policies."

A piece assembled by this chapter's method discloses itself. The cron schedules, the backlog ids, the failed blind test and the reset rule are the process, visible on the page. A reader can see where the automation sat and where the human decisions were made, because both are named with their artefacts. You never have to append a sterile "this article was written with AI assistance" footer to a piece whose body already shows the machinery and the judgement in the same paragraph.

Where does that leave the draft you started with? Thinner and heavier at once. Thinner because the unfalsifiable padding is gone. Heavier because what remains can be checked. That trade is the entire E-E-A-T argument in miniature: the experience signal is not a tone you adopt but a set of records you surface.

One open question remains, and it is the obvious one. If experience must be injected by hand, could a better prompt at least get the voice right, so the edit pass only has to add facts? The Berkeley result above says no, and this site ran the experiment twice and shipped the reset. Chapter 6 is that story: why you cannot prompt your way to voice, and what the blind test caught that iterative review never would.