AI Fundamentals· Lesson 8 of 10
- 1What Even Is AI? AI vs. ML vs. Deep Learning6 min
- 2How Models Learn: Training vs. Inference6 min
- 3What Is an LLM?8 min
- 4Tokens — the Currency of Everything7 min
- 5Why AI Output Is Probabilistic (and Why It Changes How You Build)7 min
- 6Hallucination — Why Models Make Things Up7 min
- 7What AI Is Genuinely Good and Bad At — a Capability Map7 min
- 8AI Systems vs. Traditional Software — the Mindset Shift7 min
- 9Where AI Fits in a Product (and Where It Shouldn't)7 min
- 10Responsible AI Basics for Builders7 min
AI Systems vs. Traditional Software — the Mindset Shift
In one line · Traditional software is deterministic; an AI system is probabilistic and needs ongoing evaluation instead of fixed tests.
Enter with a 'works or doesn't' mindset and you'll struggle. AI systems work 'by degree' — your job is to measure and improve that degree.
Ordinary code is a calculator: same input, same output. An AI system is a smart employee: usually good, never guaranteed 100%.
A sum function always returns the same result. A summarizer may summarize the same text two acceptable ways.
The practical difference is threefold: (1) Testing — instead of a unit test that passes or fails, you build an evaluation: a set of real examples you score a success rate against (e.g., 'classification correct in 94% of cases'). (2) Debugging — instead of tracing the faulty line, you improve the prompt, data, or model and re-measure. (3) Maintenance — ordinary code stays fixed until you change it; an AI system's performance can shift when the model updates or user inputs drift, so measurement must keep running.
🧪 Try it: write a unit test for a sum function (a simple assert), then try writing a 'test' for a summarizer the same way — you'll find it impossible. Instead: collect 5 texts, define acceptance criteria for each (mentions point X, under N words), and compute a success rate. That's the test-vs-evaluation difference, hands-on.
Common mistakes: (1) asserting on exact output text — it breaks on the first innocent rephrasing; (2) judging the system by one example instead of a success rate over a sample; (3) assuming what worked last month still works — without ongoing measurement, degradation happens silently.
Use the 'measure by degree' mindset for any model-powered part: design an evaluation from day one, and gate every prompt or model change on it.
Don't extend this mindset to the ordinary code around the model: your API layer, database, and parsing still get normal pass/fail unit tests. The probabilistic mindset is for the model part only.