For most of my career, the bottleneck was typing. You knew roughly what you wanted, and you spent your hours getting it into the editor. That world is ending. AI will write the code. What it cannot do is decide whether the code was the right thing to build.
That single shift moves the scarce skill from knowledge to judgment. And it changes who the hard problem belongs to.
Judgment, not knowledge, is the job now
The quality of what AI gives you is capped by the quality of what you ask of it. A precise plan, the right decomposition, knowing which tradeoff actually matters here and which one does not: that is judgment, and it is what turns a model from a fast typist into a useful collaborator. Hand the same model and the same docs to two engineers and you get wildly different results. The difference is judgment, not syntax recall or typing speed.
This is hardest on junior engineers, and it is also where the opportunity is. We have always said judgment comes from years of experience. But if judgment is the entire job on day one, "wait a few years" is a luxury nobody has anymore. We need a way to get people to useful judgment faster.
The lever: reduce the problem space to a finite set of components
Here is the move. If you can boil a messy problem space down to a small, finite set of components that combine to solve any problem in that space, you have created something powerful. You have made the space legible, to you and to the AI at the same time.
Why does this work so well with AI specifically? Because composition is the native idea. These models are trained to find reusable structure and recombine it; they generalize by composing learned concepts rather than memorizing every case. When you hand a model an explicit, named, finite vocabulary, you are not fighting it. You are meeting it where it already operates.
I want to be careful and honest here: that is a claim about behavior, not a theory of transformer internals. You do not need to understand attention heads to use it. The empirical version is enough: give a model a clear, consistent, composable vocabulary and its output gets markedly better and more consistent. Anyone who has tried it has felt this.
The compounding part
Now put the two together: judgment as the goal, a finite set of components as the lever. What you get is a shared language that both you and the AI actually speak.
That shared language is not a nicety. It compounds, on both ends:
- Describe a product in that vocabulary, and the AI can hand you back a robust design.
- Point the AI at an existing codebase, and it can surface the same components and patterns back to you.
- Keep conversing in that vocabulary, and your understanding of a system grows over time instead of decaying.
In every case the vocabulary is doing the work. The AI's context gets richer because you are speaking in terms it can reason over cleanly. Your mental model gets sharper because the AI keeps reflecting the same structure back at you. Understanding compounds on the machine side and the human side at once.
That two-sided compounding is the part I rarely see named, and it is the whole point. The shared vocabulary is not a teaching aid bolted onto the work. It is the interface between human judgment and the machine.
And a finite set is teachable
There is one more payoff, and as a teacher it is the one I care about most. A finite set of components is teachable explicitly. It behaves like a set of formulas: once you have them, you can hand them to someone and they can start using them immediately.
You no longer have to wait for years of accumulated experience to slowly deposit the same intuitions one production incident at a time. You can teach the vocabulary on day one and let judgment build on top of it from there. The thing that used to take years, an intuition for how systems are shaped, can be taught objectively, because it has been reduced to a finite vocabulary instead of a fog of "you will get it eventually."
That is the real unlock for junior engineers in the AI era.
The vocabulary I use
For software systems, the finite set is seven building blocks and three external entities. The trick to keeping it useful is to read each one not as a component but as a recurring decision you have to make:
Compute (the work)
- Service: what has to answer in real time, synchronously.
- Worker: what can happen later, off the request path.
Storage (the state)
- Key-Value Store: what you read constantly, by a known key.
- Relational Database: what has to stay consistent and be queried by its relationships.
- File Store: the large blobs that do not belong in a database.
- Queue: where producers and consumers should be allowed to move at different speeds.
- Vector Database: what you retrieve by meaning rather than exact match.
External entities (the edges you do not control)
- User: who acts, and what they expect to happen.
- External Service: what you depend on but cannot govern.
- Time: what happens on a clock instead of in response to a request.
Notice that none of those is really about syntax or a specific technology. Each is a judgment call. "Should this be a Service or a Worker?" is a question about what your users can tolerate waiting for, and that is exactly the kind of decision AI cannot make for you but can execute brilliantly once you have made it. The set is finite; the judgments are where all the value lives.
Every system I have taught, from a weekend to-do app to Instagram, is some arrangement of these ten.
The framework is open, and so are three small tools I built to test the idea end to end: one that turns a plain-English product description into a design, one that reviews an existing architecture against the vocabulary, and one that mentors you through real work in the same terms. They are the design / review / mentor arc of a single shared language.
I would honestly rather argue about whether seven is the right number, or whether these are the right seven, than sell you anything. The claim I am making is the interesting part: in the AI era, a finite shared vocabulary is the thing that lets human judgment and machine capability compound on each other. Tell me where it breaks.