Which AI for which job — I decide by the shape of the work, not the brand
I stopped comparing models and started classifying tasks. Four categories, one decision table, and the three jobs I do not hand to an AI.
Bu yazının Türkçesi: Türkçe sürüm.
Somebody publishes an answer to "which model is best" every month, and that answer is stale three weeks later. For a while now I have been working from a different question, and it does not go stale: what shape of work is this?
Because choosing a model is no longer choosing a brand. All three providers abandoned the single-flagship idea and shipped tiered families instead. Anthropic has Fable, Opus, Sonnet, Haiku; OpenAI has GPT-5.6 in Sol, Terra and Luna; Google splits Pro and Flash. So the real decision is not "Claude or GPT" but "which tier does this job deserve".
I settle that with four categories.
1. Work that has a referee
If a machine can tell you whether the output is correct, you are in this category. Does the code compile, do the tests pass, does the JSON match the schema, did the script run clean.
Here I give the model a lot of room, because when it is wrong the referee tells me. A wrong answer does not slip through quietly.
And precisely for that reason, I start at the cheapest tier here. With a referee in place, the only advantage of an expensive model is its first-try hit rate. If a cheap model gets there in three attempts, it is still cheap. I move up only when the cheap tier keeps stumbling. Doing the reverse — starting at the most expensive and discovering you didn't need it — is much more common and much more expensive.
2. Work that is expensive to verify
Numbers, dates, prices, "company X announced Y" claims. The output is fluent and confident, and finding out whether it is true means going and reading the source.
This is the dangerous category for me, and it has recently got more dangerous. I ran into why this week.
I was researching model prices for this blog. Search turned up five "AI pricing guide" sites. All five gave a different price for the same model. One quoted the old list price, one the promotional price, one had the promotion right but the date wrong. None of them linked to a source.
Those sites were themselves, in all likelihood, produced with model output. So the loop runs like this: a model produces a number, a site publishes it, a search engine indexes it, the next model treats it as a source. The model reading its own derivative as evidence.
The practical consequence: "summarise what's on the internet" is losing value fast. Instead of asking a model for a fact, I ask it to find the source and then I read the source myself. Every figure in this blog was gathered that way — from Anthropic's, OpenAI's and Google's own pricing pages. I trusted no third-party site, and I recommend that habit strongly.
3. Work that is a matter of taste
Whether a headline sounds good, whether a piece of interface copy is too formal, which of ten name suggestions lands.
There is no referee here, but there is also no damage. Worst case you don't like it and you throw it away. So in this category I use the fastest, cheapest tier without a second thought. Calling a flagship model for a list of name ideas is taking a taxi to buy bread.
One caveat: if you have the model write your own text, your voice disappears. I write this blog myself, and here is what I have noticed — the sentences a model offers "to help" always arrive in the same rhythm. Readers can tell. Taking ideas from it is one thing; letting it form the sentence is another.
4. Work that cannot be undone
Deleting files, deploying to production, moving money, emailing a user, publishing a release to a store.
One rule here: I don't let the model decide, I let it prepare. Let it write the deploy command, not run it. Let it produce the list of files to delete, not delete them. Let it draft the reply, not send it.
This is not distrust, it is asymmetry. When it is right I save a few minutes; when it is wrong the loss is irreversible. No accuracy rate makes that trade work.
The decision table
Reduced to one table, this is how my daily work actually runs:
| Task | Category | Tier | Check |
|---|---|---|---|
| Debugging, writing tests | Refereed | Start cheap, move up if it stumbles | Tests |
| Large refactor across a codebase | Refereed but long-horizon | Upper tier | Tests plus review |
| Finding sources for a blog post | Expensive to verify | Doesn't matter | I read the source |
| Prices, dates, figures | Expensive to verify | Doesn't matter | Primary source required |
| Headline and copy ideas | Taste | Cheapest | My own taste |
| Translation draft | Taste plus verification | Middle tier | I read it myself |
| Deploying, deleting, sending | Irreversible | Preparation only | I run it |
There is not a single model name in that table. Deliberately. A model name would be wrong in three months; the categories don't go wrong.
The three jobs I don't hand to an AI
Shorter list, sharper.
Replying directly to support email. I read and answer MCALAB's support messages myself. The volume is small, so I have that luxury, granted. But the real reason is this: when a user describes a problem, they are usually describing the wrong problem. Someone who writes "there's no sound" rarely has a sound problem. Working that out requires knowing what they wrote before, which device they use, and which build I shipped that week. The model does not have that context, and even with it, the cost of a wrong first reply is a lost user.
Producing numbers. Covered above. A model may well remember a figure, but the figure it remembers might be last year's price. If a number does not come with a date and a link, I don't publish it.
Text of uncertain provenance. Asking a model to "summarise this article" and publishing the summary is publishing an abridged copy. I read it, close it, and write in my own words. I don't use images on this blog either, for the same reason.
How I actually pick between tiers
If you want a concrete rule: start cheap when there is a referee, start in the middle when there isn't.
On refereed work, a wrong answer from the cheap tier costs me one round trip. The price gaps are serious — cheap tiers go down to a tenth of the flagships — so three attempts still comes out cheap.
On unrefereed work the cheapest tier is a bad choice, because the only mechanism that will catch the error is my attention, and my attention does not scale. A middle tier sits at a reasonable point between speed and reliability.
I reserve the flagship tier for work that is long-horizon and many-stepped. On a single-question task I cannot feel the difference; across thirty steps the small per-step differences accumulate and the outcome visibly changes. Also, on long tasks the dominant cost is context, not the model tier.
In short
I have not stopped reading model comparison posts, but I no longer read them to make decisions — only to see what changed. The shape of the work makes the decision.
And one piece of advice: sort your own tasks into these four categories once. It takes half an hour. The thing that will probably surprise you is this — most of your work is in category one, meaning you already have a referee, and you are not using it.
Advertise on this blog, or work with us
MCALAB is an independent studio. For sponsorship, cross-promotion or a partnership:
ads@mcalab.com.trDetails: Advertise & partner. For user support, see the support page.