How to Build an AI Writing System That Actually Sounds Like You

After years of AI promising to handle your writing, it may actually be possible without the output sounding like slop.

In one long Claude Code session, starting from an empty repo, I built an AI writing pipeline that turns my rambling recordings into drafts in my voice.

And after working through a few rounds of feedback, my edit rate fell to 3% on content that this pipeline produced.

Whereas before, AI attempts to write for me always had dead giveaways, these are getting quite good, and for someone less picky about their writing you could hand off 100% of your written output to a process like this and 99% of readers would not notice.

So if you're a writer, creator, or founder who is tired of AI drafts that sound like an AI wrote them, this is the exact system we built, including the rules that backfired on us.

Here is everything we're going to cover, in case you want to skip around:

1. The Architecture: Writer vs. Judge

2. Organizing by Content Type

3. Building and Cleaning the Corpus

4. Separating Eras of Your Voice

5. Writing the Voice Guide from Real Data

6. The Draft, Judge, and Revise Loop

7. The Live Rounds: Editing Real Drafts

8. Finer Points

And of course you can also send this straight into Claude Code as a guide.

The Architecture: Writer vs. Judge

Before writing any code, we had to pick the division of labor.

Earlier, I had compared Gemini 4 Argon's writing against Claude's in a blind test and picked Argon's by a wide margin. So the rule was simple: Argon writes every word of the piece, and Claude (inside Claude Code) is the evaluator and runs the loop.

My first instinct for the workflow was what most people do: Argon writes a draft, I review it, we feed my feedback back into the prompt, and repeat.

The problem with that is I stay the bottleneck longer than I have to. Worse, there is no way to know when the system is good enough to trust without me.

Here's how the loop works:

1. An inner automatic loop runs first. Argon drafts the piece from my source notes, Claude judges it and gives Argon the top 3 fixes, and Argon revises for a few rounds.

2. Before I ever see a draft, the Claude judge writes down the edits it predicts I will make.

3. In the outer loop, I review in batches. Instead of writing notes about the drafts, I edit them until they're publishable. My actual edits carry more signal than a description, and "how much did Nat change" is the best quality score.

4. We compare what I actually changed against the judge's sealed predictions, and classify every edit into one of four buckets: voice rule, structure/format, fidelity (made-up facts), or banned phrase.

The percentage of my edits that the judge predicted is the number that tells us when I can step out of the loop.

Organizing by Content Type

My voice is the same across everything I write, but the structure differs depending on the format. An X post is not a thought piece, and a thought piece is not a how-to guide.

So we split the repository into three content types (X posts, how-to posts, and thought pieces) across four main folders:

• corpus/ holds my published writing, used as the style source and examples for Argon.

• holdout/ holds real pieces I wrote that Argon never sees, used only for testing.

• inputs/ holds the voice notes and raw material for each piece.

• evals/ holds every draft, score, and edit per version.

Building and Cleaning the Corpus

To teach Argon how I write, we needed a clean dataset of my actual writing. I pasted in 12 X posts, and gave links to 11 thought pieces and 7 how-to posts.

We wrote three importers to pull everything down:

• Substack posts through Substack's API

• Old nateliason.com posts scraped from the page

• X Articles through the public fxtwitter API (which needs no X login)

Next, we stripped out everything that isn't me writing: subscribe buttons, "if you enjoyed this, subscribe" lines, Husk and Crypto Confidential book plugs, and SEO for Solopreneurs course footers. Every image became an [image] placeholder.

Why bother? If you leave your footers and plugs in the training set, Argon learns to end every piece with a book plug.

When the cleanup finished, we had roughly 44,000 words of training material.

Separating Eras of Your Voice

Once we looked at the how-to posts, we hit another issue.

The how-to posts spanned 2016 to 2026, and the 2016 one sounds noticeably younger.

I wanted Argon to use my modern voice from 2022 onward, not the younger one from 2016.

The problem was that I stopped writing how-to posts for a while. Only two current-voice how-tos exist in the set (the TikTok guide and the Felix post). Meanwhile, the three pre-2022 how-tos have the structure and level of detail that make my how-to posts do so well.

The fix was one shared voice guide across all formats, plus a separate format guide for structure.

Voice comes from my thought pieces and X posts from 2022 onward. For how-to structure, we tagged the three pre-2022 posts as structure-only and showed them to Argon labeled "older voice, structure and detail only".

Writing the Voice Guide from Real Data

Before opening the holdout pieces (so nothing from the test set could leak in), Claude read the training pieces closely and wrote a voice guide.

Instead of vague descriptions, the guide breaks down ten core moves:

1. Lead with something concrete or a blunt claim, with no warm-up.

2. Use my own life and real numbers as the evidence.

3. Build around one clear idea, often given a name.

4. Write short paragraphs with one-line turns, plus the occasional long loose run-on.

5. Use spoken connectors (And, But, So, "Alright,", "Honestly,").

6. Get humor from absurd specific exaggeration and self-deprecation.

7. State blunt opinions alongside honest uncertainty.

8. Talk directly to "you".

9. Use emphasis sparingly.

10. End quickly, often landing in one line.

It also lists my rhythm devices, mechanics, and a list of "not-Nat" tells, along with format guides for each content type. For how-tos, that means opening with results in numbers, adding a table of contents for long ones, giving one section per step in order, naming exact tools, schedules, and numbers, walking through a worked example, showing what went wrong, adding a "Finer Points" FAQ, and ending with a short forward-looking close.

We also wrote a stats script to measure paragraph length, sentence length, bold and italics per 1,000 words, and questions. In my thought pieces, my median paragraph is ~45 words, my median sentence is ~16 words, and I use ~3 bolded lines per 1,000 words.

Finally, we checked every candidate "AI word" against my actual writing before banning it.

Words with zero uses in my writing went on the ban list: delve, crucial, moreover, furthermore, additionally, testament, seamless, robust.

But some words people call AI tells actually show up in my writing: foster, elevate, navigate, and "Imagine" (which I've used 18 times). So the ban list only has words I never use.

The Draft, Judge, and Revise Loop

With the guides done, we built an Argon draft script to run the inner loop.

The script builds Argon's system prompt from the voice guide, the format guide, and full real example pieces (about 16,000 words of my writing for thought pieces), followed by the source material. It enforces a hard rule: every fact comes from the source, and Argon can never borrow stories from the examples.

Once Argon writes a draft, the judge skill (using Opus 5.5) runs a full check:

• Mechanical checks comparing the draft's stats against my targets, counting em dashes, and checking for phrases copied from the examples.

• A fidelity check of every factual claim against the source material.

• 11 voice dimensions scored 1-5 with quoted evidence from the draft.

• The worst lines in the piece.

• The sealed list of predicted edits I'll make.

• A 1-10 overall verdict.

Then the judge sends its feedback back to Argon for revision.

Two rules keep the revisions from going off the rails. First, feedback to Argon is capped at the top 3 fixes, because Argon just fixes the easy items when handed a long list. Second, revisions run for up to 3 rounds, since doing more tends to sand the voice flat.

The Live Rounds: Editing Real Drafts

Once Claude had done its best to build the writer through synthetic tests, we switched over to real drafts I'd actually publish, with me editing each one.

The Local Web Editor

Editing raw Markdown is a pain, so Claude built a small local web editor using Tiptap, running on localhost inside the repo.

The sidebar lists the drafts, and I edit in rich text and hit save. Saving a draft writes my version to a new file, nat-final.md, right next to the draft and leaves the original draft untouched. There's also a "Notes for Claude" box that saves to nat-notes.md, for when the reason for an edit isn't obvious.

The judge's reports are hidden from the sidebar, so its sealed predictions of my edits stay sealed until I'm done.

The First Live Piece

The first live piece we ran was this post.

I changed about 5% of the words (95 added and 153 cut, out of about 3,000), and it was shockingly good.

My biggest edit was replacing the draft's cautious framing, which treated the results as if the system wasn't there yet, with my own verdict that it's close to ghostwriter level. Because the source notes didn't have my take, Argon had guessed the framing.

So that gave us a new rule: when the source doesn't say how I feel about an outcome, Argon leaves a [NAT: your take] placeholder instead of guessing.

Real Video Input and Edit Rates

Next, we tested real voice input. I sent over six short videos I'd recorded for Founders School.

We ran the posts in batches on purpose: one post first, then three, then three more drafted only after the skill was updated from my edits on the previous batch. Comparing edit rates between batches shows whether the updates actually helped.

Here's how many words I changed in the drafts I saw:

• First two live pieces: about 7%

• First video batch: 10% on average (ranging from 0% to 25%)

• Second video batch: 3% on average (ranging from 0% to 10%)

In the second batch, two of the three posts went through with zero words changed. A five-book reading list post from the first batch also went through untouched.

The judge loop pays off measurably here. A script counts how many words differ between each draft and my final version, and every judge revision landed closer to my final edit: one post went from 58 words off to 32 to 11 across two revisions, and the reading list went from 48 words off to 0.

When the Judge Overshoots (And What Held Up)

The judge also overshot twice, and I undid both fixes.

After a single edit taught the judge that I add "But" and "So" at turns, it pushed an extra "But" into a draft (which I cut, since it put two "But"s within four lines) and added a closing "So" line that just restated the opener (which I cut too). Both came from rules learned from a single edit.

The fix: rules learned from one or two edits are now treated as hypotheses. The judge can mention them, but it only pushes them as fixes once they've held up across multiple pieces.

After several batches, here are the patterns that held up across my edits:

• I add "But" or "So" where the argument turns, one per turn.

• I cut a last line that just restates the opening.

• I cut inside-baseball detail, like lists of my own file names or old post titles.

• I contract about 89% of the time, whereas the drafts started at about 50%.

• I keep putting back the small words that Argon's tightening removes: subjects ("I hope", not "Hope"), repeated verbs ("getting really good… and getting deeply immersed"), and qualifiers like "especially as a teen". That last one became a firm rule after the third time I put them back.

Meanwhile, the judge's sealed predictions are getting better, though it still guesses more edits than I actually make: it predicted about 20% of my edits on the first live pieces, 29% on the first video batch, and 38% on the second.

Every real source and my final edited version is now saved as a pair. After any future skill change, the system can redraft from those sources and measure how close it lands to what I actually published, without me having to read anything.

Finer Points

What Still Gives the AI Away?

Three things:

1. My odd, invented word choices and images get smoothed into plainer ones.

2. My asides and qualifiers get trimmed.

3. The structure gets tidier than mine.

What's Next

The routine is pretty simple now: I drop videos or voice notes into the folder, Claude transcribes them, Argon drafts, the judge loops, I edit in the browser, and the skill updates from my edits. My only jobs are editing and confirming names Whisper can't know.

But the best part is that every piece I write this way makes the system better. And every new model release will make it stronger, too.

This is the worst it'll ever be.

(And yes, I only wrote ~5% of this post after telling Claude to draft this based on our working session together.)