Essay — 2026-09-07 — 4 min
Models as Senior Designers
Treat the model like a fast senior who drafts the work — you still own taste, review, and the ship.
The most useful mental model for working with AI is not "intern" and not "oracle." It is "senior designer who drafts fast and still expects critique." That framing changes how you brief, what you accept, and what you still have to know.
Options, not answers
A senior designer can take a rough brief and produce four plausible directions in an hour. The value is not that one of them is final. The value is that the options are coherent enough to disagree with. The model is the same: it generates quickly, confidently, and in bulk. Your job is not to be impressed by the first one. Your job is to decide which direction is worth taking, then push it further.
Good seniors frame the problem before they draft. They know the user, the constraint, the risk. They expect their work to be reviewed and challenged. They do not treat silence as approval. A bad handoff is the opposite: a vague prompt, a dazzling output, and an unread diff shipped to production. The model does not care whether you read it. You have to care.
Taste is the scarce skill
When generation is cheap, the bottleneck stops being "can we make something" and becomes "which of these somethings should exist." Taste is knowing which implementation is the one you want to maintain in six months. Taste is killing the scope the model confidently suggests because it does not serve the user. Taste is naming the difference between "works" and "right."
This is why "senior collaborator" is the better metaphor than "intern." An intern needs step-by-step supervision. An oracle demands belief. A senior designer gives you a starting point you can argue with, then expects you to bring judgment. The model is the fast senior; you are the editor-in-chief.
You still own the loop
The human in the loop still owns the parts that cannot be delegated. Intent: translating a messy stakeholder request into a brief the model can execute without laundering ambiguity into confident nonsense. Review: reading the diff, checking assumptions, catching the subtle wrong. Security and stakeholder judgment: deciding what is safe to expose, what to promise, what to push back on. Proof of ship: the test, the eval, the screenshot, the user who actually used it.
This is the Vibe SWE loop. Build: state the outcome and constraints, then let the model draft. Ship: small, reversible, visible, with evidence. Learn: read what actually happened and change your defaults. The model accelerates each stage, but ownership does not transfer. You are still the name on the ship.
A seat under vibe engineering
Vibe SWE sits under vibe engineering, not beside it. The vibe engineering framing describes the senior, accountable practice: tests, evals, reviews, production discipline, an engineer who could have written the code by hand and chose not to. Vibe SWE is the working seat most of us occupy today, learning to hand off to a senior collaborator without abdicating the outcome.
The collaboration is real. The model is faster at syntax, broader at patterns, cheaper at iteration than any human teammate. But it has no context on your business, no stake in your reputation, and no memory of the last time it confidently shipped something wrong. Treat it like a senior who just joined yesterday and can produce ten versions before lunch. You would brief them. You would review their work. You would not let them rename your product.
The craft that survives
The builders who get good at this are not the ones who type the fastest. They are the ones who ask clearer questions, reject more first drafts, and keep the final decision human. That is the craft that survives every machine. Build. Ship. Learn.