A spam filter and a chatbot are not the same kind of thing
In one line
The word "AI" covers two products with opposite shapes — one has a right answer and one has better and worse ones — and the shape decides everything downstream.
The situation
Two items sit next to each other on a roadmap: "AI spam detection for the community forum" and "AI assistant for the help centre". Both get the same estimate, the same review process and the same success metric — "accuracy" — because both are "AI features".
They will fail in completely different ways, be tested by completely different means, and one of them will be finished in a week while the other is never quite finished. Understanding why is the first useful distinction in this whole field, and it needs no maths at all.
Classify: the output is small and checkable#
The spam filter takes a post and produces one bit: spam or not. That single property — a tiny output with a right answer — makes everything about it tractable. You can collect a thousand posts a human has labelled, run the filter, and get a number: 97% agree. You can set a threshold. You can inspect every mistake, because each one is one bit against one label.
The model doing this can be small and fast, because it is not writing anything;
it is reading and deciding. And its output goes straight into code — an if
statement — without any parsing, because it is already a value.
Most of the AI problems that get quietly solved and forgotten about are this shape: routing, tagging, flagging, ranking, extracting one field. They are under-appreciated precisely because they work.
Generate: the output is open-ended and judged#
The help-centre assistant takes a question and produces a paragraph. There is no single right paragraph. Two good answers will use different words; the same question asked twice can produce two different good answers unless you switch that variation off with . "Accuracy" has no meaning until you define what you are measuring: is the fact correct, is it grounded in the docs, is the tone acceptable, is it concise?
Testing it means either a human reading outputs, or a second model grading them against a rubric — — and then checking that the grader agrees with the humans. The is a project in itself, and the number it produces is a distribution, not a score.
The model doing this is large, slow and priced per word. Its output has to be parsed if code needs anything from it. And it can be wrong in a way the spam filter cannot: fluently, confidently, with no signal that anything is off.
Questions to ask
- Is the output a value or a text? Values are checked; texts are judged.
- Can a human label a thousand examples in a day? If yes, this is the easy shape.
- If two runs give different outputs, is that a bug or expected?
- What would the test for this look like, and who writes the answer key?
Mindset
Before anything else, sort the request into classify or generate. The first is a well-understood engineering task with a clear finish line. The second is a product with a quality bar you will be defining for months. Giving them the same estimate is the mistake; noticing they are different kinds of thing is most of the fix.
Goes deeper in
Phase 1 · 6 min
Encoders vs decoders
One architecture reads in both directions to produce vectors, the other reads only backwards so it can write; a single mask is the difference.
Phase 3 · 6 min
Evals
Automated tests for a component whose output is not stable, where the assertion is a threshold on a score and the suite is the only thing making changes measurable.
Got the shape of it?
Examples do not count toward phase progress — that stays on the topics. This is just so the list remembers what you have seen.