Building the Playbook for How I Write With AI
How I turned “make it sound like me” into a practical playbook for writing with AI.
I thought I was making a style guide.
What we actually built was a playbook.
That matters, because “make this sound like me” is a terrible instruction for AI. It feels clear when you say it. It is not clear to the machine.
The machine does not know what “me” means.
It needs examples. Boundaries. Rules. Preferences. Corrections. A scoreboard.
That was the real work.
The problem I was trying to solve
I’ve been learning to build with AI in public. Part of that means writing about the process.
Build logs. Reflections. Notes on what worked. Notes on what broke. The occasional reminder that AI can make a messy workflow faster, which is not always a compliment.
But there was a problem.
Every time I used AI to help draft something, I could feel when it drifted.
Sometimes it sounded too polished.
Sometimes it sounded like a LinkedIn post that had been through three committees and one motivational speaker.
Sometimes it added hype I would never say out loud.
Sometimes it made me sound like I was pitching something, even when the whole point was that I’m not.
So the job became pretty clear:
Build a guide that helps AI write with me, not instead of me.
That sounds simple.
It was not simple.
Naturally, humans were involved.
We started with the obvious stuff
The first pass was basic.
Tone. Voice. Topics. Things I say. Things I do not say.
Plain English.
Short sentences.
No guru energy.
No “AI is coming for your job” doom bait.
No “this will change everything forever” hype parade.
Useful before clever.
Operator-to-operator.
That got us started, but it was still too vague.
Because “plain English” can mean a lot of things.
So can “optimistic but grounded.”
So can “don’t sound like a brand bot,” which is accurate, but not exactly a repeatable instruction.
The guide needed to get more specific.
The second pass was about tension
This was the part that made the guide useful.
My voice lives in the middle of a few tensions:
Confident, but not guru.
Optimistic, but not naive.
Technical, but plain-English.
Personal, but not oversharing.
Structured, but not sterile.
Business-minded, but not salesy.
Learning in public, but not pretending to be clueless.
That middle lane is important.
A lot of AI writing fails because it runs to the extreme. It tries to sound impressive. Or inspirational. Or authoritative. Or warm in that weird fake way where every sentence sounds like it wants to put a hand on your shoulder.
That is not the goal.
The goal is simple:
Sound like a real person who has done the work, is still learning, and is willing to show the process.
Then we built the guardrails
This is where the guide turned from “voice notes” into an actual operating system.
We added rules for what wins when instructions conflict.
Accuracy beats style.
Privacy beats color.
Usefulness beats jokes.
Specific task beats generic branding.
That matters because AI will happily optimize for the wrong thing if you let it.
Tell it to sound more like you, and it may start forcing jokes into places they do not belong.
Tell it to be inspiring, and it may invent confidence the work has not earned yet.
Tell it to write a build log, and it may quietly turn a half-tested idea into a case study.
No thanks.
Receipts over rhetoric.
If I built it, tested it, measured it, paid for it, broke it, or learned something real from it, we can write from that.
If not, the piece has to be framed honestly.
A hypothesis.
A plan.
A reflection.
A question.
Not fake proof.
The “AI tells” section became the film room
This was one of the most useful parts.
We made a list of phrases and patterns that make writing feel like generic AI output.
Things like:
“It’s not just X, it’s Y”
“Let’s dive in”
Overusing em dashes
The same tidy three-part rhythm everywhere
Corporate filler words
A closing paragraph that just repeats the article in nicer shoes
That section is basically film review.
Watch the tape. Find the bad habits. Fix the mechanics.
The point is not to make the writing less useful.
The point is to make it sound less manufactured.
AI has a house style. Once you see it, you cannot unsee it.
And once you can name it, you can remove it.
We also had to decide what not to say
This part matters more than people think.
A style guide is not only about what belongs in the writing.
It is also about what stays out.
For me, that means a few clear boundaries.
No public pitch.
No private business mechanics unless I explicitly ask for them.
No family details beyond broad, normal references.
No pretending audience metrics are the scoreboard.
No turning every post into “look at me building a personal brand.”
The scoreboard is learning.
That line became one of the anchors.
Because if the writing is supposed to document the education, then the content should serve the learning. Not the other way around.
The guide had to become usable by machines
A normal style guide is helpful.
A style guide that an AI agent can actually use is better.
So we turned the guide into drop-in prompts.
One markdown version.
One XML-ready version.
A stable system prompt for agents.
A user prompt template for each specific job.
That was the operator part of the process.
Do not make the instruction live only in your head.
Do not rely on memory.
Do not keep correcting the same mistakes forever.
Turn the judgment into a checklist.
Turn the checklist into a prompt.
Turn the prompt into a repeatable workflow.
That is where AI starts to become practical.
Not magic.
Just practical.
The weird part: the guide is not finished
This was another important decision.
The guide has stable parts and temporary parts.
The stable parts are voice, boundaries, tone, privacy, and principles.
The temporary parts are channel strategy, cadence, and where the work is currently showing up.
That feels right.
Because the work is going to change.
The tools are going to change.
The platforms are going to change.
The format will probably change six times before I pretend I planned it that way.
But the voice should not reset every time the workflow changes.
That is the point of the guide.
It gives the work a home base.
What I learned
The useful lesson here is not “everyone needs a style guide.”
Maybe you do. Maybe you do not.
The real lesson is this:
If you want better output from AI, you need to get better at explaining your judgment.
Not your preferences in some vague way.
Your actual judgment.
What good sounds like.
What bad sounds like.
What lines you will not cross.
What tradeoffs matter.
What examples count.
What proof is required.
What gets cut even if it sounds nice.
That is the work.
The prompt is the easy part.
The judgment behind the prompt is the hard part.
My takeaway
This guide started as a writing tool.
It became something bigger than that.
It became a way to make my own thinking more visible.
To me.
To the machine.
And eventually to anyone reading the work.
That is the part I did not expect.
Building with AI is not only about getting the machine to do more.
Sometimes it is about forcing yourself to define the work clearly enough that the machine has a chance.
That is a useful exercise.
Even if the first version is ugly.
Especially then.
AI involvement
This post is AI-assisted.
The style guide was built through an iterative process: draft, review, correct, tighten, test against examples, and turn the useful parts into repeatable instructions.
The machine helped organize the thinking.
I made the calls.
Next play: use the guide on real posts, see where it breaks, and update it from the work.