How to give your AI tasteHow examples and feedback turn personal judgment into guidance an AI can use.

Taste is not a moat by itself. When a model can reproduce much of what makes a design good from a screenshot, those decisions become available to someone who could never have made the original.

Good taste still helps you choose the example and judge the result. But even that choice can begin with a collection someone else has curated. You can borrow more of their judgment than the phrase “taste is the moat” suggests.

The practical question is how to give AI enough of that judgment to produce work you like, without personally correcting every decision.

Examples carry more than rules

We've been trying to explain good writing for a long time. The Elements of Style offers useful guidance, but giving everyone the same style guide doesn't make everyone an equally good writer.

“Omit needless words” leaves you with the difficult part: deciding which words are needless. A sentence can repeat a point, or supply the missing reason that finally makes it clear. Both make the paragraph longer.

Taste doesn't need to be mystical for this to be hard to describe. A preference can depend on several choices working together, and we often recognize the result before we can explain those choices.

A good example preserves that interaction. An article shows how much context the author gives before making a claim, where an example helps, and when the explanation has gone far enough. “Write clearly” contains none of that detail.

A site can use dithering to turn photographs into patterns of dots while keeping the type crisp. Applying that texture everywhere would make the text harder to read.

Both versions could fit “make it retro.” A reference shows how the image treatment, type and empty space work together.

When people say taste is the moat, I think they're pointing at the ability to produce better work when everyone has access to similar models. Quality is the advantage. Taste matters because it steers the model toward that quality, and examples let some of that steering happen outside your head.

The best examples are annotated

A reference still leaves an ambiguity: which part do you want?

When I give AI an article whose prose I like, I want its diction and pacing. I don't want its subject matter appearing in my essay. A model can imitate the wrong property while following “write like this” quite faithfully.

In a transition, a thumbnail can expand into a larger view while the same image stays visible throughout. An annotation can point out that continuity and the way the background recedes, instead of asking for a “smooth animation.”

A sequence of frames records what changes and what stays recognizable. The original clip is still needed to judge the timing.

While working on Thinking in rhythms, I kept asking for simpler writing. Some revisions cut the explanation until they barely said anything. Others added so much explanation that a useful intuition became a textbook.

The preference wasn't just for fewer words. I wanted enough reasoning to understand the idea, with no repeated explanation after it had landed. A reference paragraph and a note about where it stops convey that much better than “be concise.”

For example, “Clear briefs improve AI writing” states a conclusion. A more useful explanation would be:

A brief tells the writer who will read the piece and what they need to understand, so it can judge whether a paragraph belongs.

The annotation can name the difference: “This explains how the brief changes a writing decision. Its extra words supply the mechanism. Shortening it to the first sentence would remove the explanation.”

My prose rules include rejected passages beside better versions, with notes on what changed. The comparison makes a rule such as “avoid artificial punchiness” less ambiguous. The writer can see the sentence that failed and how a complete, ordinary sentence does the same job.

A whole article is useful for structure and pacing. A short comparison isolates one decision. Keeping both gives the model a target at each level.

Selection is easier than specification

It's often easier to choose between two openings than to describe the opening you want from a blank page. The alternatives give your judgment something to react to.

That changes how you can develop the instructions. The first version doesn't need a complete theory of your taste. It needs enough direction to produce attempts worth comparing.

After a correction, the useful thing to save is the choice and its reason. “I prefer B” helps with this draft. “B names the reader's problem before introducing the framework” gives the next draft a decision it can reuse.

Some preferences won't have a clear explanation yet. The comparison is still worth keeping. Asking AI to propose reasons can help you articulate the difference, but its first plausible explanation shouldn't automatically become a rule.

Repeated examples reveal the scope. You might prefer a short opening in several practical articles and a longer opening in a personal story. Recording what each piece was trying to do keeps those preferences from turning into contradictory instructions.

This is how a taste guide can grow through selection. You collect decisions made on actual work, then revise the instructions around patterns that keep recurring. You don't have to invent a comprehensive guide before making anything.

Taste has to meet other people

A collection of things you like can also become a way to repeat yourself. More agreement between you and the model doesn't establish that the work has improved.

Taste is, in part, what has worked condensed into judgment. That judgment needs contact with the people the work is for. If an explanation feels elegant to you but readers can't use it, something in your idea of a good explanation needs updating.

For an article like this, a useful response is a reader explaining how they would apply the idea to their own work. If they repeat the heading but can't describe what they would do differently, the article may have named the idea without teaching it.

Other work needs other evidence. A product page has to help visitors understand the product. A story might succeed because someone finds it moving or funny. “Effective” depends on what you meant to make, not one universal metric.

Getting more people involved expands the feedback available to you. A writer can catch a structural problem, while a reader unfamiliar with the subject exposes the context you assumed everyone had. Their disagreements are useful because they test different parts of the work.

I want those observations beside the examples too. A passage I liked but readers misunderstood teaches me something a folder of favorites cannot.

A reviewer needs something to test

Rules and references give the writer direction. A rubric gives the reviewer specific reasons to reject a result.

“Is this a good article?” leaves too much room for agreeable commentary. For an explanatory essay, the questions can be more concrete:

• Does the opening identify a problem the intended reader recognizes?
• Does each main conclusion have an explanation or example that supports it?
• Could a reader apply the idea to a different case?
• Does any paragraph repeat a point without adding useful information?

An adversarial review looks for where the draft fails those tests. It should quote the passage and describe the missing step. That gives the writer something to repair; a high score alone doesn't.

The context of the review matters. After a long conversation, the model has seen your explanations of what the draft means. It may understand the argument because you explained it in chat, even when the article never does.

A fresh reviewer receives the rubric, the draft and a description of the intended reader. It cites the passages that support its judgments and flags explanations it had to supply itself. It can still overlook a gap, but it no longer has the original conversation filling gaps for it.

The rubric needs checking too. A test for short paragraphs is easy to satisfy by deleting reasoning. A reviewer should be able to reject a draft that obeys the style rules but fails to explain its subject.

A small system is enough to start

The material can live in Notion, a reference collection in Are.na, or a folder of Markdown files. The model needs access to the actual examples and annotations, not just their titles.

For a writing task, a small folder could contain:

taste/
  brief.md
  references/
  corrections.md
  review.md

The brief says who the piece is for and what they should get from it. The references show the intended quality. Corrections preserve the choices made during earlier work, and the review file holds the questions used to judge a draft.

The next writing session reads the relevant material before drafting. A separate reviewer checks the result, and feedback from readers can change the examples or questions you keep. My writing process also separates the argument from the final voice pass, so a style repair doesn't hide an unresolved idea.

A useful first test is whether a new session can handle a related task without you repeating the old correction. If the mistake returns, checking whether it read the reference comes before rewriting the reference. The annotation may be unclear, or the model may need help applying a decision you've already explained.