Pick the Right Model for the Job: The Four-Seat Division of Labor in AI Coding

The same frontier model spent one afternoon doing four different jobs—walking through the UI, writing an architecture plan, executing a 40-file refactor, and running a security review. All four outputs were passable, but only one was actually a good fit. By dinnertime, what I had was a confident plan that missed the critical seam, a refactor that "compiles" but changed the wrong abstraction layer, a UI report that described the click sequence instead of reproducing the failure, and a review that sounded thorough while letting the blast radius slip through. One model, four jobs, and one person's afternoon diluted.

The Opposite of Common Advice

The usual advice is "pick a favorite model and stick with it," or "chase the latest leaderboard." But the author proposes a quieter, contrarian approach: models aren't personality objects you marry—they're instruments. The real skill is matching the instrument to the phase of work, and writing down what "done" means before you open a tab.

This is the fourth post in the "Ship With Agents" series. Previous installments covered running long tasks, treating your paid stack as a team roster with handoffs, and checking progress from your phone without pretending it's a full IDE. The core of this one: different seats, different evidence.

The Same Model Is Not the Same Job

If you treat every hard problem as "ask the smartest model," you're optimizing for eloquence, not for the artifact you actually need next.

• UI walkthroughs need a model (and its scaffolding) that can stay in the product path, deliberately fail a repro, and bring back evidence
• Planning needs to compress constraints without inventing architecture you didn't ask for
• Long refactors require patience across files, respect for existing seams, and a stop condition that isn't "looks cleaner"
• Review demands adversarial attention: finding holes, catching overclaims, pointing out the blast radius you ignored

These are different failure modes. A model great at long-form writing will happily produce a beautiful but wrong plan; a model great at code editing will "helpfully" widen scope because nobody told it the blast radius; a model great at critique will start rewriting the entire feature if you don't assign it a seat.

The logo on the tab matters less than the contract you put in front of it. Tools really are different—latency, context behavior, tool calling, stubbornness, taste for structure all vary. But the point is to upgrade that feeling from "gut instinct" to "role assignment."

The Four Seats I'd Actually Staff

Here's the roster I use in practice. Names shift as labs ship new releases, but the seats shouldn't change.

1. UI & Product Path Work

Responsibility: Enter the real path (or a staging copy), reproduce, observe, return evidence. Evidence is a failing-to-passing path, screenshots of unbroken screens, a trace id—not a sentence saying "it should work now."

I need a model that stays concrete under tool calling, and doesn't invent stories when the UI breaks. If the agent can't verify the old repro as failing after a fix, it's drafting, not finishing.

trace id is a unique string used in distributed systems to thread together the full-chain logs of a single request. When an operation spans multiple services and components, the same trace id appears in all related logs, letting an investigator stitch scattered records into a complete timeline. In a UI walkthrough context, its value is turning "I clicked here and it broke" into an objective anchor that others can reproduce and verify—a reviewer can take the trace id, locate that specific call, compare parameters, response, and latency, rather than relying on the reporter's memory and narration. Without a trace id, a UI report easily slides into "restating the steps," which actually obscures the request that really failed.

2. Planning & Compression

Responsibility: Compress a messy problem into a short contract the next layer can execute. Goals, constraints, blast radius, acceptance checks, open questions. Evidence is a brief you can paste directly into the implementation phase without reconstructing intent from chat tone.

I need a model that will cut. If the plan grows into a novel, either the process is wrong or the seat is wrong.

3. Long Refactors & Multi-File Changes

Responsibility: Move seams elsewhere in the codebase, not rewrite the product for fun. Evidence is a small, reversible diff against the branch, attached tests or script checks, and a clear rollback path.

I need a model that remembers the local architecture and refuses an epic rewrite when the ticket is just "rename + update call sites." Overnight loops only make sense where the trace survives a tab crash (see "Let It Run for Days").

Seam is a concept introduced by Michael Feathers in Working Effectively with Legacy Code: a place in the codebase where you can change behavior or swap a dependency without modifying a certain piece of logic itself. Typical seams include interface boundaries, dependency injection points, overridable factory methods, and so on. The core judgment in refactoring isn't "does the code look cleaner" but "did the change move responsibility along an existing seam." If a refactor barrels straight through a seam and rips out the abstraction layer, it goes from a safe move to high-risk surgery, and both rollback cost and conflict surface spike. Recognizing and respecting seams is the key to whether the long-refactor seat can produce a small, reversible diff.

4. Review & Adversarial Pass

Responsibility: Find holes before production does. Risk lists, falsifiable points, missing checks, overclaims. Evidence is a list that makes the implementer feel "usefully uncomfortable."

I need a model willing to be "rude." If it starts building features, I've pulled it out of its lane.

The author maps these seats to Claude Max, ChatGPT Pro, SuperGrok, Cursor, and Antigravity: persistence and long loops in one place, compression in another, adversarial review in a third, repo-local implementation where the diff lives, and product walkthroughs where the evidence lives. The mapping may change next quarter, but the seats don't.

Blast radius refers to how much is affected when a change fails—from a single test user, a staging environment, to all production traffic, downstream dependencies, or even irreversible data corruption. One of the review seat's important jobs is to proactively estimate and call out this scope, rather than only checking whether the code is correct. Common practices include: tracing the call chain the change touches, confirming whether shared state or global config was modified, and checking whether degradation and rollback paths cover the worst case. A review that sounds thorough but doesn't clarify the blast radius treats "impact is contained" as a default assumption—which is exactly the most common starting point for incidents.

A Real Morning: One Ticket, Four Instruments

Not a stage demo—a concrete shape.

Ticket: On staging, saving a setting and refreshing loses a field. Classic problem, easy to discuss, easy to "fix" at the wrong layer.

I wouldn't open the strongest model and paste in the whole story.

Step 1: Planning seat, five minutes. Just the brief: preserve field X on save and reload in staging. Blast radius: staging, test users, no prod writes. Stop condition: a scripted reload shows X still present, plus a note on the empty-field case. Open: client state vs API omission vs cache. This brief is the contract.

Step 2: Adversarial seat, with the brief and a first hypothesis. I want punches, not a rewrite. It returns three: check the PATCH payload, check empty string being treated as omission, check the second-tab race. Now the implementer has falsifiable points instead of vibes.

Step 3: Refactor or implementation seat, owning the change in the repo. Minimal reversible fix, appropriate test or script, a PR I can roll back.

Step 4: UI seat walks the same path the brief named and returns evidence. Before-and-after reload comparison. If the empty-field case still fails, call it out explicitly.

If all four phases use the same model, what I get is still just words. I don't get clean artifacts at the seams. This morning works because each seat produces the evidence that seat owes—and the handoffs are my job.

Matching Is a Written Decision

People skip the matching step because it feels slower than "just asking."

The first 30 seconds are slower; the whole afternoon is faster. Write three lines before opening a tab:

1. Seat: UI, planning, refactor, or review (pick one)
2. Artifact: what must exist at the end of this round (brief, diff, evidence pack, checklist)
3. Stop condition: what "done" means in the product or repo—not in the model's self-report

That sticky note is the whole skill. Without it, every model becomes a chat therapist with a compiler; with it, swapping models next month still preserves the operating system.

Bounded, reversible, checkable still applies. The seat card should spell out what the model can write, what it can only read, and how to undo a bad hour. Demo energy is one model sounding smart at every phase; production energy is four boring artifacts that survive a handoff.

Stop condition is not the model's self-reported "I think it's done," but a state verifiable independently by a third party at the product or repo level: a scripted reload shows the field still present, a test flips from red to green, a trace reproduces the old failure. Writing the stop condition into the contract converts "done" from subjective judgment to objective evidence ahead of time. It also constrains the model's scope creep—when the model wants to "optimize a bit while it's in there," the stop condition pulls it back to the ticket boundary. Without a stop condition, models tend to replace clearer convergence with longer output, rounds extend indefinitely, and handoffs never happen.

What Goes Wrong When You Skip Matching

• Planning model doing UI walkthroughs: You get a confident bug theory with zero path evidence. You "fix" the mental model and the screen still drops the field.
• UI walker doing multi-file refactors: You get click narration and opportunistic edits near visible symptoms. The abstraction layer is still wrong and the bug moved.
• Refactor model doing security or blast-radius review: You get a cleaner module and a quiet permission expansion. The PR looks tidy and the risk looks pretty.
• Review model doing greenfield planning: You get a brilliant critique of a plan that doesn't exist yet. Useful as seasoning, fatal when it's the only dish.

The quietest failures love mismatched seats. The output still sounds like work. The next person (usually you, two hours later) can't tell which claim came from which phase. That's how the same bug gets planted twice in one day.

Cut the Default to One Seat Per Round

If your default is "open the best model and dump in the whole problem," change that default.

One seat per round, one artifact, then hand off. Model hopping without a contract is still thrashing; model matching with a contract is how a stack becomes a team.

You don't need a perfect matrix of every model against every task type. You need fewer rounds that pretend to do everything at once. When a new model ships, promote it to one seat with a trial ticket and a written stop condition; if it just writes prettier paragraphs for the wrong artifact, demote it.

Tools are cheap; contracts are the work. Choosing a model is choosing which contract you're about to execute.

The Bottom Line

The best model for "anything" is usually the wrong model for the next artifact.

Match the seat to the work, write down the stop condition, demand the evidence that seat owes. Eloquence isn't the shipping gate—the brief, the diff, the evidence, and the checklist are.

One-line Summary

Having one model do four jobs dilutes output; match seats to work phases instead.

Paragraph Summary

The article argues that throwing every hard problem at "the smartest model" optimizes eloquence, not the next artifact you need. One frontier model doing UI walkthroughs, planning, refactoring, and review in a single afternoon produces a confident plan that misses the seam, a refactor that changed the wrong abstraction, a report describing clicks instead of reproducing failure, and a review that ignores blast radius. The author treats models as instruments rather than personalities, matching work to four fixed seats: UI walkthroughs need failing-to-passing path evidence, planning needs an executable brief, long refactors need small reversible diffs, and review needs a useful risk list. Matching is a written decision—write the contract of seat, artifact, and stop condition on three lines before opening a tab. Tools change; seats don't. Tools are cheap; contracts are the work.