The Taste Gap

Ira Glass described the most important thing about creative work: “For the first couple years you make stuff, it's just not that good. It's trying to be good, it has potential, but it's not. But your taste, the thing that got you into the game, is still killer.”

The gap between knowing what good looks like and being able to produce it is the central struggle of any craft. It is also the central struggle of construct writing — and it explains why, in a registry of thousands of constructs, only a handful are genuinely great.

What Great Looks Like

You can recognize a great construct immediately. It has a quality that is hard to name but impossible to miss. The instructions are specific but not rigid. The persona is opinionated but not dogmatic. The workflow anticipates edge cases you had not thought of. It feels like reading the notes of someone who has done this work a thousand times.

A mediocre construct, by contrast, reads like a checklist written by someone who researched the topic but never lived it. “Check for bugs. Ensure code quality. Follow best practices.” Every word is correct. None of it is useful. The agent that follows these instructions produces output that is technically compliant and practically worthless.

The difference is taste. Not completeness — the mediocre construct may cover more topics. Not length — the great construct may be shorter. Taste is the ability to know which details matter and which are noise. To include the rule that saves an hour and omit the rule that wastes one.

The Three Gaps

There are actually three taste gaps in construct writing, and they compound:

The domain gap. You need to know the domain well enough to have opinions about it. A code review construct written by someone who has never found a bug in production will tell the agent to “check for errors.” A construct written by someone who has been paged at 3 AM because of an unhandled null will tell the agent to “trace every external API response through every code path and verify that null, empty, and error cases are handled before the response is used.” One is a platitude. The other is a scar.

The articulation gap. You need to express your expertise in a form the agent can follow. This is the problem explored in “Why Your Best Engineer Can't Write a Construct” — the expert knows what to look for but cannot describe how they know. Closing this gap requires the difficult work of introspection: watching yourself work and asking “what just happened in my head?”

The curation gap. You need to know what to leave out. This is the purest form of taste. A construct that includes everything the agent could possibly need is a construct that includes too much. The agent drowns in context. The signal-to-noise ratio drops. The great construct author cuts ruthlessly — not because they do not know the excluded material, but because they know it is not relevant right now.

Can Taste Be Forked?

Here is the question unique to constructs: when you fork a great construct, do you inherit the taste?

Partially. You inherit the decisions — what to check, in what order, with what priority. But you do not inherit the ability to make new decisions of the same quality. The fork preserves the output of taste, not the taste itself.

This is why the best forks come from people who already have domain taste and are borrowing structural taste. A security engineer who forks a general code review construct brings her own security judgment and borrows the original author's sense of construct structure. She improves the security sections because she has domain taste. She leaves the workflow structure intact because the original author's structural taste is already good.

The worst forks come from people who have neither — who fork a construct and add ten rules that sound important but dilute the signal. More is not better. More is almost always worse.

Developing Taste

Glass's advice for closing the taste gap was volume: do a huge amount of work. Write constructs. Test them. Observe where they fail. Revise. The constructs you write in your first month will be generic and overlong. The constructs you write after a year of iteration will be precise and opinionated.

But there is a shortcut that does not exist in other creative fields: you can read great constructs. The entire registry is public. You can study how Garry Tan's CEO Reviewer defines three operating modes. You can study how a Paranoid Staff Engineer prioritizes P0 over P1 findings. You can see which constructs get forked and which do not, and ask yourself why.

The fork graph is a taste accelerator. It shows you what the community considers good — not through ratings but through the act of building on it. A construct with deep fork trees was good enough that other people with taste chose it as a foundation. That is signal you can learn from.

The Irreducible Thing

At the end, taste is the part that cannot be automated. An AI can generate a construct that is structurally correct — it will have a name, a description, a workflow, a set of principles. It will look like a construct. But it will not have the scar tissue of someone who has been paged at 3 AM. It will not have the instinct for which rule to include and which to leave out. It will not know that the difference between a good construct and a great one is the one sentence that captures twenty years of experience in a form so clear that it seems obvious.

That sentence is taste. And it is the reason construct writing is a human craft, not an automated process.

Related: Why Your Best Engineer Can't Write a Construct explores the articulation gap in depth. The Fork Graph examines how community selection reveals quality.