Passing taste to AI models

If you meet someone and they have a slightly annoying way of talking, you barely notice. Talk to them every hour, every day, for a month… that tiny tic starts to feel like a cut. When you use AI models that often, their tics become super grating too. Each model has a certain smell in the way they communicate.

My theory is that this comes from training models to succeed. There is no established evidence for it yet. Post-training, fine-tuning, and reinforcement learning reward successful-looking outputs and push the model away from failed ones. That leaves the shipped model very practiced at sounding right.

Humans fuck up all the time. We carry those failures into the next attempt, and that is how we get good at things. A shipped model’s weights are frozen, so it cannot fail for you today and become a better model tomorrow. It ends up sounding like an overly confident human being who has never failed in life: headstrong, charging into every problem, bluffing when it is not certain.

Imparting taste to models is hard. I have not solved it, and I am suspicious of anyone who says they have. I use several techniques, and parts still fail.

Where the smell comes from

Think about how a human writes. You make notes, write a draft, and polish the shit out of it. You cut what does not belong, add what is missing, and keep going until it reads properly. A transformer emits one token, feeds the chain back through itself, and emits the next until the text ends. Thinking modes give it room to revise before answering, which helps. I still don’t think that simulation is the same as carrying your own failed drafts into the next one.

Wikipedia’s editors maintain a page called Signs of AI writing, built from cleaning up thousands of AI-written edits. It lists words such as delve and tapestry, “not X, but Y” constructions, em-dashes everywhere, and inflated claims. A specific fact such as “inventor of the first train-coupling device” becomes “a revolutionary titan of industry.”¹

Their explanation is regression to the mean. The model picks language that could apply to the widest range of cases, so the writing becomes generic while the claims get bigger. I think that explains the generic smell, while training for successful-looking answers explains the confidence. One paper investigates why models say “delve” so much; a follow-up traces some word overuse to learning from human feedback.²

Ordinary readers detect AI text at roughly coin-flip accuracy in controlled studies. Heavy LLM users reach around ninety percent.³ After seeing the same constructions every day, you start spotting them everywhere.

The mental model I use

I picture an AI model as a headstrong person who does not learn. Once a model ships, the learning I can influence happens through its context window, which people call in-context learning. It struggles with that too. Dump a massive rant on somebody and say “follow all of this,” and they will forget parts of it. Models do the same thing.

Writing taste

I start with a global instructions file. I use Claude Code, but other agent CLIs have their own version of this. Mine explains who I am and how I work. One of its most important instructions came from a repeated failure.

I dictate almost everything because my typing never kept up with my thinking. Speech-to-text sometimes gets words wrong. The model used to take those words literally and run with them. I added an instruction that says this user dictates, work out the intended meaning from context, and ask when you still don’t understand.

I also give the maker and checker an 80/20 rule. Eighty percent of the finished post has to come from my words, usually from these dictated rants. The remaining twenty percent is organization: fixing typos and mistakes, formatting and laying out the post, bridging gaps, and finding references. The result sounds like me because most of it is me, while the AI does the time-consuming production work around it.

Sparse instructions pull the model back towards its trained average. If you give it nothing, you get its usual style. Examples carry more taste than instructions, so I show it writing I like, writing I rejected, and the difference between them. Its next draft sounds more like me. I still have to correct it because the taste has to keep coming from me.

I also name the tics. My writing skill has a growing list of banned patterns. Whenever the model produces one, I flag it and add the example to the rule. Then I ask the model to correct itself, update its instructions, and try again from a fresh context. No correction is guaranteed to stick. Its chance depends on the model and how I wrote the instruction.

Some weeks after I banned the “not X, but Y” template, I found it on Wikipedia’s list as one of the strongest tells. Hundreds of editors cleaning up AI text and one annoyed person dictating blog posts had found the same tic.

I can also package a correction as a command. Dillon Mulroy has a three-line skill called bro: restate your last message, stop using jargon, and say it simply, like one human talking to another.⁴ When an agent asks a dense engineering question, he invokes bro and gets the same question in plain speech. The larger stop-slop skill removes predictable filler across a whole response.⁵ bro steers the model towards Dillon’s voice, while stop-slop removes common filler and leaves the voice to you.

Maker-checker is the most involved technique I use. One model writes with my style guide in its context. It does a reasonable job and still fucks up. A second model starts with fresh context and checks the work. Tell a model that its job is to find problems and it will find them, because finding them is how it succeeds.

The best version would use models from different companies, with different training and biases, like bringing a different person into a review. Most single-vendor CLIs make that difficult. Pi allows each subagent to use a different provider.⁶

In practice, I usually use the same provider for both. The fresh checker still catches things the maker missed. I have not measured how much a different provider would improve it.

The checker also nitpicks things that don’t matter. I ask it to rank findings by severity, and the maker only applies the high and critical ones. If the maker is unsure, it asks me. I cap the loop at about three rounds so the agents cannot keep correcting each other forever. I sit outside the loop and watch it… when it goes haywire, I step in.

Coding taste

Taste in code is the architectural choices you make while solving a problem. You can smash your head through a brick wall or hire a wrecking ball; both will give you an opening. Models will solve the same problem five different ways, so one of my first instructions is: don’t reinvent patterns. Before introducing something new, grep the codebase because it probably already has a way to do this.

Most coding conventions are implicit. Teams rarely write down the order of functions, constants, types, and exports in a file. A human reads the code and thinks, okay… this is how we do things here. A model does not reliably make that jump. I run a separate session that scans the codebase, finds those conventions, and adds them to the project’s agent instructions.

I also turn some preferences into code. I ask the model to write static checks, then run them after file changes or in CI. The preference still applies when nobody remembered to put it in the context. When the shape of a solution matters, I give it that shape upfront. I describe the classes and methods I expect, then add high-level pseudocode. The model does a better job because it has an outline and does not have to make up shit.

When I use all of these, the model fucks up less. I still have to supply the taste and catch what gets through.

Design, where I still lose

Writing and code are easier for me to steer because I can give the model the instructions, examples, conventions, and checks as text. Design is where I still lose. Front-end skills, screenshots, and design systems have not fixed it completely.

I was building an app and had a good design in my head. I described it through speech-to-text, the model built a UI from my words, and the result looked nothing like the picture. I did a bad job there. The picture in my head became a paragraph of dictated text, and that paragraph was all the model got.

I found similar designs online, took screenshots, and gave them to the model as references. The result captured the essence of those designs, but it could not merge their intent with the thoughts and feelings I had in my head. The part that was mine never made it through.

There are now tools aimed directly at this problem. The open-source Taste Skill reads the brief, sets controls for layout variation, motion, and density, then applies rules against common model defaults: purple gradients, centered heroes, repeated feature cards, and cards that serve no hierarchy.⁷ This is the design version of my banned writing patterns. Somebody notices the same failures, names them, and gives the model better instructions.

Alex Kehr’s Taste gets closer to personal taste. You save screenshots you like, and it extracts the colors, type, spacing, shapes, and composition into a profile. It also records designs you reject, and your ratings of generated screens feed into the next version of the profile. The profile can then travel into Codex or Claude as a skill or through MCP.⁸ This matches what I have found with writing: examples and rejected examples carry more than a paragraph of instructions.

It also leaves my question open. A profile can record that I like rounded corners. Can it transfer why this corner feels cozy in this interface? That is the part I still don’t know how to pass.

Without references, GPT and Codex models keep giving me boxes inside boxes inside boxes. They show buttons that should only appear on hover and expose complexity that should stay hidden until somebody needs it. They choke on minimalism and progressive exposure.

The tightest constraint is a design system where the model can only compose existing components. It sits at the far end of the constraint spectrum I wrote about before. It can give me a correct UI that still lacks taste. Constraints alone have never given me a pleasant interface. Once I let the model get creative, I am back to hoping.

I think the failure comes from how humans design. A human can close their eyes and picture an interface that does not exist. Then they look at the screen and feel whether it matches. Your eyes move across the layout, you notice whether the lines align, and a rounded corner can feel cozy while a sharp one feels alert.

The bouba/kiki experiment makes this visible. In the original study, 95% of participants called the rounded shape “bouba” and the spiky one “kiki.” Later studies found the same bias across languages and in infants.⁹ Human senses mix together, and design taste uses that mixture.

People with aphantasia cannot voluntarily picture an image in their mind.¹⁰ Ask them to imagine an apple and they see nothing. The models we use for design feel similar to me. I cannot know what happens inside them that corresponds to cozy or alert. I give them words and images, and they predict an output. The surprising part is that they produce reasonable designs at all.

The banned-pattern skill I described above checked this draft. A separate checker then found places where the writing had turned “the model fucks up less” into “problem solved.”

A mistake becomes an instruction, and the instruction raises the chance that the model gets it right next time. It never removes the need for me to supply the taste. Design is where that gap is easiest to see.

Addendum after a second human review

A human read this again after the maker-checker loop finished and found more problems. Some sentences went further than what I knew. I had said model producers try to prevent a house style, and that similar interfaces prove a shared reinforcement-learning history. I cannot know either from the outside, so those claims came out. The checker did not always invent problems; more often it found real things that did not matter, so I changed that to nitpicking. I had also repeated conclusions and separated ideas that belonged together.

I made those fixes by hand. I removed claims I could not support, narrowed claims based on my own experience, joined related sentences, and cut explanations that added nothing. The agents caught patterns because I told them which patterns to catch. I still had to read every sentence and decide whether it meant what I meant.

---

Footnotes

1. Wikipedia, Signs of AI writing. Worth reading in full, including its own caveats: the list is descriptive, humans are individually bad at this, and merely patching the surface signs makes detection harder without making the writing better. ↩

2. Juzek & Ward, Why Does ChatGPT “Delve” So Much? (COLING 2025), and their follow-up, Word Overuse and Alignment in Large Language Models: The Influence of Learning from Human Feedback. ↩

3. Russell, Karpinska & Iyyer, People who frequently use ChatGPT for writing tasks are accurate and robust detectors of AI-generated text (ACL 2025). Casual readers perform near chance; heavy users reach roughly 90% accuracy. ↩

4. Dillon Mulroy’s bro skill. The entire skill: “Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another.” ↩

5. stop-slop, a widely used skill that strips predictable AI writing patterns: filler, throat-clearing, emphasis crutches. ↩

6. Pi, an open agent harness supporting 15+ model providers; its subagents extension allows a per-agent model override, so a checker can run on a different provider than the maker. ↩

7. Leonxlnx, Taste Skill. The current default skill reads the brief, adjusts design variance, motion, and visual density, and contains explicit rules against common AI interface patterns. ↩

8. Alex Kehr, Taste. It turns saved screenshots, rejected designs, and ratings into a versioned profile that exports to Claude and Codex skills or MCP. ↩

9. The bouba/kiki effect: Ramachandran & Hubbard (2001), building on Köhler’s takete/maluma experiments from 1929. ↩

10. Aphantasia: described by Francis Galton in 1880, named by Adam Zeman’s team in 2015 after their study of patients unable to form voluntary mental images. ↩