The glossary — the real bottleneck in building with AI isn't the AI
I direct AI to build software without writing the code myself. So what is actually the limiting factor? I assumed it was the model's ability. It isn't — it's my ability to say precisely what I want in the vocabulary the work happens in.
Not knowing a word costs more than not knowing a concept. I understood caching and deployment as ideas long before I could use the terms confidently enough to ask for the right thing. Writing down every non-trivial term the first time it appeared turned a recurring friction into a compounding asset — and made me notice the terms I'd been nodding along to.
Not stopped. Nineteen terms in, it grows whenever a new one shows up in real work. The rule is that it only holds words I actually hit, never a curriculum.
The thing nobody says about directing AI
The interesting constraint in building software this way isn't the model. It's translation.
I know what I want. I can see the behaviour, the layout, the failure I'm trying to avoid. What I couldn't do — for a long time — was name it in the vocabulary the work happens in. And when you can't name a thing, you can't ask for it precisely, which means you get something adjacent to what you meant and spend the next hour explaining why it's wrong.
That's the bottleneck. Not intelligence on either side. Shared language.
The vault
So I keep one. Every non-trivial term gets written down the first time it comes up in real work, in a file of its own, in plain language, with the context where I met it.
Two levels, and a term earns promotion by use:
- Level 1 — a short definition. Enough to recognise it and use it correctly.
- Level 2 — the extended version, written only when a term keeps showing up and the short definition stops being enough.
Most terms stay at level 1 forever. That's fine — that's them doing their job.
What's actually in it
Nineteen terms, and the range is the point:
The plumbing of building things — fetch, endpoint, design token, placeholder,
smoke test, SDD, cascade, safe zone.
Algorithms I met by needing them, not by studying them — Knuth-Plass (how you break a
paragraph into lines so it looks right), Liang (how hyphenation actually gets decided),
KMP (finding a string inside another fast), Monte Carlo (answering a question by
simulating it many times), and rivers — the accidental channels of white space that open up
through justified text, which is a typography problem I'd seen for fifteen years without
knowing had a name.
Terms from whatever I was building that month — reverse-design, roster, 2D rigging,
deformer, face tracking.
That last cluster is a fingerprint of a project: you can tell what I was learning by which words appeared.
Why one file per term
It looks like overkill for a definition. It isn't. One term per file means each one can be linked from anywhere, revised on its own, and found without scrolling — and it makes the index a real map of what I know instead of a wall of text I'd never reopen.
The rule that keeps it useful: only words I actually hit. No curriculum, no "terms every designer should know". A glossary built from a syllabus is a thing you feel guilty about. One built from your own confusion is a thing you use.
The part I didn't expect
Writing the definitions exposed the terms I'd been nodding along to.
There's a specific and common failure where a word gets used at you often enough that you stop asking, and you build a vague shape around it that's almost right. It survives conversation fine. It falls apart the moment you have to write one sentence defining it.
Doing that nineteen times found several of those. That, more than the reference value, is what the vault is for.