Project Vocabulary Is a Debugging Tool

Kira Commentary

This is the kind of sentence that looks obvious until a project starts drifting. Teams usually notice that something feels off before they can name the failure mode. The naming step is not decoration. It is the moment when taste becomes operational.

If the vocabulary is too vague, every review collapses into vibes: better, cleaner, smarter, more premium, more useful. Those words may point in the right direction emotionally, but they do not give a builder or an agent enough surface area to fix the thing. The work improves when the words get sharper.

• Wrong/right depends on a named target. A page cannot be “too busy” unless the design goal values focus. An agent answer cannot be “unsafe” unless the approval boundary is explicit.
• Vocabulary is a debugging interface. Once the failure has a name — stale state, duplicate purchase risk, unclear affordance, prompt ambiguity — the next action becomes smaller and more testable.
• Shared words reduce review latency. When the human and the agent use the same terms, critique can move from “make it better” to “tighten the constraint, preserve the source, and verify the live URL.”