Writing

Domain Vocabulary

One of the major problems that people run into when they are starting a new project is that they have vague notions of where it wants to go, but haven't yet concretised even the rough details of their project.

Funnily enough, this is actually one of the main ways that engineers and product managers work together. The product manager will add a general guideline or direction, and may even include some more specific features, but then when it comes time to implement, the engineer needs to go back to the product manager and ask them, "did you mean this or did you mean the other thing?" Much of the genius of senior software engineers is understanding the best ways to go about implementing the product manager's vision, with "best" meaning whatever fits the context of that software.

The problem with this in everyday life is that even with a direction or a vague notion of a project or something you want to create, the actual process of going about creating that thing is painful and disordered because the implementation steps are not clear. The shape of the project is not clear. The various milestones and sub milestones are not clear.

Essentially the plan is not high definition enough to be executable in an easy fashion. People are vibe-coding their way through life.

In my research around AI and trying to understand what differentiates the standard AI slop from AI output which is indicative of real craft, one of the things I hit upon is that the limiting factor, or the limiting skill with AI is not capability of the model, but vocabulary of the user. And what I mean by that is the AI is perfectly capable of executing complex web designs (or most anything else) to a high standard. The problem is that it doesn't know that it needs to do that when a user says, "make me a landing page." But when a user understands what the different areas of that landing page are, when they understand things like spacing and typographic hierarchy, and when they understand the various elements that go into web design and can give the model a richer vocabulary of what it needs to output, then the quality of the output goes up and the slop-ness goes down.

This is exactly the same thing with all projects that any human does, even when they're prompting another human. The more precise you are able to be with your speech, the more precisely you're able to communicate what it is that you want, the better output you're going to get from your employees, from your spouse, from your children. And then essentially what it boils down to is the prompt. What makes a good prompt, what makes a good set of instructions for human beings and AI is the domain knowledge of the prompter, the level of specificity that the person is using to describe what it is that they want.

This is exactly why the higher up the hierarchy you go, the more general of a manager or an executive you're talking to, the less they are able to get quality output from any given individual worker; they are not the domain experts in any of those individual domains! They are the generalists, they see the vision of the entire company, they see how the components fit into one another, but they don't necessarily have the domain fine grain level vocabulary needed to prompt good execution out of all of those different layers.

If you want better output, get more domain knowledge, understand the level of abstraction you're operating within, and prompt with fine-grain detail for that level.