Writing with a blocklist
I use AI write first drafts, and I've made my peace with that. What I haven't made my peace with is when it's dead obvious :D
I built a small set of skills to help me write LinkedIn posts, and a list of anti-patterns those skills lean on to keep the writing from reading as machine-made. This is a piece about both.
If you're short on time, here's the TLDR:
- I turned my posting process into three skills plus one stubbornly manual step: one skill mines my git history for ideas, one drafts a post from an idea, then I redraft it by hand, and the last skill learns from the difference between the draft and my redraft.
- The skills share a styleguide. Most of that styleguide is a numbered blocklist of AI writing tells.
- The redraft is the important step. Everything the machine writes is a first pass; my hand-edit is what actually goes out, and the gap between the two is where the system gets better.
- The blocklist grows every time I catch a new tell. It started from the Wikipedia article "Signs of AI writing" and it hasn't stopped growing since.
Why bother
I used to chronically overthink posting. I would spend far too long on stuff that might not be read at all, and I abandoned plenty of posts for not being up to scratch. So like any engineer worth his salt, faced with a manual task that hurts, I automated it 🤖
The catch is that the automatable parts are the easy half. A model will happily produce a semi-competent post from a one-line prompt. The trouble is that semi-competent is not good enough, especially when the reader might be seeing dozens of AI sounding posts on their timeline. Asking the model to "sound like a human and make no mistakes" does very little; I've tried, and if a prompt like that ever does work I'll update this post. So instead of trusting the model to avoid AI-sounding pitfalls, I wrote the tells down and made the skills check against them.
The four steps
The whole thing lives in one folder, social-posts, which is its own little git repo. It has an ideas/ directory, a drafts/ directory, a redrafts/ directory, and one big STYLE.md file. The skills move work between those directories.
1. /post-idea - mining commits for ideas
The first skill reads git history across my workspace repos over some range ("last two weeks", "since v1.4", "between date_x and date_y"), and clusters the commits into narrative themes rather than a changelog. A theme is a story arc: a debugging saga that crossed two repos, a capability that shipped, some local developer-experience thing I've built. For each theme it picks one of five post types, writes a one-sentence takeaway, and drops an idea file into ideas/. If a range only yields two good themes it proposes two; I told it not to pad.
One theme the skill kept picking up was decision-reversals: "first I did it like this, then I did it like that". When a theme's tension rests on inferred intent - a reversal, a changed mind - it usually isn't that compelling. Git shows what changed, never why, so the takeaway would often come out odd or useless.
It once proposed a lovely "built fourteen watchers, deleted thirteen the same day" reversal story - which turned out to be no reversal at all. I'd spun up a batch of watchers while prototyping the workspace monitor, realised most were redundant, and cleared them out the same afternoon. The commits read like a dramatic change of heart; really it was just me tidying up scaffolding. The skill had invented the tension.
I did upgrade /post-idea with this in mind: now, when it's guessing at intent, it has to mark the guess explicitly so I can check it.
2. /draft-post - idea to draft
The second skill takes one idea and writes a finished post into drafts/. It reads STYLE.md in full first, honours the post type, writes a hook that pulls the reader in, and ends with exactly three hashtags. Then it runs an anti-AI lint pass over its own output - grep for the banned vocabulary, count the em dashes, hunt for negative parallelism, and so on - and rewrites the violations before it shows me anything.
The blocklist it checks against started from the Wikipedia "Signs of AI writing" article and I've been adding to it ever since. I iterate on this list often, because each tell I catch is one I stop from happening again, which makes every future draft sounds nicer.
3. The redraft, by hand
The only tool involved in this step is my own brain. I copy the draft into redrafts/ and rewrite it. This is the step that ensures I produce something I'd actually want to post. Automating the brief and the first draft just gets me past the blank page; the final product has to be mine. Perhaps once I've built up a large enough corpus of my own text, I could write a skill that writes like I do, warts and all. I
don't think I'll try to write that one :)
4. /check-post - learning from the edit
The last skill is the one I'm most fond of. It does two jobs:
First it spell-checks the redrafts, and only the spelling; it's forbidden from touching phrasing, because the whole point of the redraft is the voice. It does still flag structural problems, repetition, and mechanical errors.
Then it diffs each redraft against the draft it came from and treats every difference as a signal. If I deleted a phrase, why? If I rephrased a sentence, what was wrong with the original? Those differences get converted into new rules in STYLE.md, or into
stronger checks in the draft skill, so the next draft needs less editing than the last. If a signal isn't yet strong enough to become a rule, the skill records it for later.
That last skill is what makes this a loop rather than a pipeline. My hand-edits are the ground truth for my own voice, and the machine mines them to learn how I write. A pattern seen once goes on a watchlist; seen a second time, it graduates to a numbered rule with a wrong/right example pulled from the actual diff. Reading the output of /check-post also turns out to be an interesting way to reflect on my own style.
For example, I asked Claude to look at the outputs of /check-post and cite some of the changes I'd made and the signal each one pointed to. It came back with these:
- "you distrust writerly cleverness that the model generates" - true; models have a habit of coining epigrams and taglines that are usually rubbish (sorry Claude). This became a rule: "flourishes are author-only".
- "you name the concrete thing; the model abstracts." - Claude tends to abstract when describing something concrete that actually happened. It once generated "the physics is cheap" to describe some mock data I was using; I'm still not sure what it meant. The rule: "if a concrete example is available, never describe it in the abstract".
- "you narrate the experience before the lesson" - e.g "Demobilisation made the cable share obvious." became "The main task I did during demobilisation was unplugging and rolling up cables." Announcing the lesson before the reader has seen it puts the cart before the horse. The rule: "never announce a takeaway before the reader has seen the thing it came from".
The workflow in practice
A normal session looks like this:
- I run
/post-ideaand get three or four proposals sitting inideas/. I skim them, pick the one with the sharpest takeaway, and run/draft-poston it. - I read the draft, scoff at a couple of sentences, copy it into
redrafts/, and spend ten minutes making it mine: cutting a metaphor the model coined, adding a parenthetical it would never have thought of, working in some of my own flavour. - I run
/check-post, which fixes my typos and folds what it learned back into the styleguide.
The first pieces were only okay. But by iterating the styleguide and redrafting often, I pulled out more and more of my style preferences and voice fingerprints. The skills now produce a fairly good first draft; I know this because there's less and less I have to change.
The next skill I'd like to add is about feedback: looking at how posts perform after a while and marking some as more or less successful. I doubt I'll be able to work out why any given post landed, but it might yield something anyway.
The blocklist
The heart of all of this is the anti-pattern list inside STYLE.md. This is the part I hope you steal and iterate on, if you generate written content with AI.
1. Negative parallelism. The "not X, but Y" contrast, used to manufacture drama. This is the most well-known AI tell, and despite that I still see it everywhere. It fails because it assumes the reader first believed the subject was the not-something, which is almost never true. If the reader doesn't hold the first framing, you've lost them the moment you correct it.
Wrong: "This is not a limitation - it is an engineering reality."
Right: "This is an engineering reality."
2. Present-participle significance tags. A trailing "-ing" clause bolted onto the end of a sentence to claim importance. It asserts a conclusion instead of building to one - showing beats telling - and the tacked-on clause is usually a non sequitur:
Wrong: "The project ran from June to February, demonstrating the method's real-world applicability."
Right: "The project ran from June to February, on in-service highway structures."
The project running from June to February doesn't, on its own, demonstrate real-world applicability; there's a missing inferential step.
3. Editorialising openers. "It is worth noting", "it is important to note", "no discussion of X would be complete without". Like the one before it, this tells the reader what to think instead of showing them the facts.
4. Inflated significance and puffery. "A pivotal moment", "plays a significant role", "underscores the importance of", "stands as a testament to", "solidifies its position". More telling, not showing; writing that borrows significance instead of earning it. This one reminds me a lot of my undergraduate essays :)
5. Overused conjunctive transitions. Opening sentences with "moreover", "furthermore", or "in addition". "Also" does the job, or just start the sentence. Like puffery, it reads as trying too hard.
6. AI vocabulary. A set of words banned purely because their frequency in generated text makes them a tell: delve, intricate, tapestry, pivotal, underscore, landscape (as a metaphor), foster, testament, enhance, crucial, robust, comprehensive, nuanced, multifaceted, realm, and "leverage" used as a verb meaning "use". This list is hard to keep current, and it spills over into rule #13 with words like real, genuine and actual. Any time I start seeing a word too often on LinkedIn, it goes on the list.
7. False spectrum constructions. "From X to Y" used to imply a full range when X and Y are two loosely related examples. A range from one point to another only makes sense if the two points sit on a single ordered dimension; "from freezing to boiling" works because it's on the axis of temperature. In the example below, can you name the single axis? (hint: there isn't one)
Wrong: "From surface surveys to deep structural assessment, the method covers a wide range."
Right: "The method covers structural assessment from the cover zone to ten metres depth."
The construction borrows the implication of completeness from a spectrum, without there being a spectrum for the two clauses to be complete across.
8. Compulsive summarising. Closing with a recap the reader didn't need, announced by "In summary", "In conclusion" or "Overall". The tell is a final paragraph that restates rather than concludes, and has to label itself as an ending because it doesn't earn the feeling of one.
9. Em-dash overuse. The em dash dropped in everywhere a comma, a full stop or a set of parentheses would do; everyone knows this tell by now. I keep mine to genuine asides, and you'll notice I prefer to smuggle those in behind a semicolon.
10. Rule of threes. Defaulting to exactly three adjectives, three benefits, three examples, every time. If two make the point, use two. Consistent triplets set off my AI alarm bells.
11. Vague attribution. "Industry observers", "experts", "studies", "reports", with nobody named. State the claim plainly, or name the source.
12. "Statement. That's X." constructions. A short statement followed by a sentence of the form "That's ___". I dislike this one because it apes the rhythm of a persuasive speaker while carrying none of the weight. A speaker can deliver a pause and emphasis; on the page that posture is only implied. It's also another significance assertion, labelling a fact as worthwhile without showing that it is.
Wrong: "Copies drift. That's the real cost."
Right: "Every copy drifts a little further from the original, until eventually you're maintaining many sources of truth."
13. "Real" as importance shorthand. Using "real", "actual" or "genuine" to signal that something matters. A thing being real is self-evident, so the word just claims candour or significance without cause. The same ban covers "quietly" and "silently" as significance adverbs, and "honest" as a label claiming candour.
Wrong: "real bugs", "migrating to it quietly fixed a counter that had stopped ticking", "the honest caveat is that…"
Right: just state the thing without the flag.
14. Framing labels followed by a colon. "The haul:", "Then execution:", "The result:", "The part I'm still chewing on:". A person narrates their own work in first person instead: "The result was that…", "To execute, I used…". Plain list intros like "A few examples:" are fine by me.
15. Visible-part / deeper-part escalation. State a claim, name its obvious aspect, then unveil a second "more important" aspect. This is a manufactured depth: it pre-announces a revelation and then delivers something ordinary dressed as profound. I find it particularly annoying, because it sets up a mic-drop and the payoff is usually feeble.
Wrong: "Every duplicated piece of logic is a place where the truth can fork. The maintenance cost is the visible part. The drift is the part that bites."
Right: "Every duplicated piece of logic is a place where the truth can fork. Fix the rule in one copy, miss the other, and the bug that follows has no single file to blame."
16. "wasn't X. It was Y." The sentence-split variant of negative parallelism. Banned everywhere; my eyes glaze over every time I read it. The example reads especially poorly because it assumes the reader first thought the findings were the useful part, which we're now graciously correcting. Realistically the reader hasn't drawn any conclusion about which thing was more useful by the time they reach the full stop.
Wrong: "The most useful artefact of the review wasn't the findings. It was the dependency graph."
Right: "The review turned up plenty of findings, but the most useful thing it left behind was the dependency graph we drew to get there."
17. Dramatic echo and staccato fragments. Single-word echo sentences, and chains of clipped fragments strung together for punch. This one is closer to a personal preference; I can imagine cases where staccato fragments read as genuinely punchy.
Wrong: "Seven components each had their own dismiss logic. Seven."
Right: "Seven components each had their own dismiss logic, which is about six too many."
18. Manufactured flourishes. Cute metaphors, coined taglines and invented jargon the model produces on the author's behalf. These get cut in every redraft, while my own imagery tends to survive.
Wrong: "the same pattern in different costumes", "where the fidelity budget should go", "the physics is cheap"
Right: plain description of the thing.
Sharpening your own imagery is one of the more rewarding parts of writing, so handing that work to an LLM just robs you of the chance to get better at it.
19. Lesson-first openers. Opening a paragraph by announcing what an experience proved, before the reader has seen the experience, often with an abstract subject doing the learning.
Wrong: "Demobilisation made the cable share obvious."
Right: "The main task during demobilisation was unplugging and rolling up cables." (then the observation about working with cables)
Another cart before the horse. Someone writing about doing a thing usually starts with the doing, not with the insight that arrived afterwards.
The watchlist
The blocklist doesn't stop at nineteen. Beneath it sits a watchlist for patterns I've seen only once; the second time one shows up, it's promoted to a numbered rule. Most times I redraft, something new lands there. That watchlist-to-blocklist promotion is how the skills iterate and improve without me having to design the rules up front.
In closing
Having a system for moving ideas into drafts has increased my output more than anything else I've tried. I can point it at work I've done, get something passable to start from, and refine it into a post that reads like I wrote it - largely because I do rewrite a lot of the original output. And I like that it gets a little better every time I use it.
If you generate written content with AI, I'd genuinely encourage you to build your own blocklist and start fingerprinting your own voice. When you take the time to write about your work, the hope is usually that someone reads it and finds your perspective useful, or interesting. For that to happen, the perspective has to be yours to begin with.