Time to read: 10 minutes Time to apply: 15 minutes Prerequisites: Phase 0 (The Stage)
I've seen it in my own work and in every team I've observed: the moment someone discovers AI agents, they try to use them for everything.
A simple file rename becomes a prompting session. A grep-as-a-service script becomes "let's add an LLM to parse the output." A static lookup table becomes "we should give it to an agent so it can reason about the results."
This is premature agentification — the new premature optimisation. And it burns money, time, and trust.
The Waste Principle is a simple decision framework: if the task doesn't need unpredictable output, don't use an agent. Every pattern in this course builds on this principle. Learn it first, and the rest of the course will make more sense.
Before you reach for an agent, run the task through this gate:
| Gate | Question | Pass | Fail |
|---|---|---|---|
| Domain | Does the task genuinely need an LLM's reasoning or generation? | Use agent | Use deterministic code |
| Stability | Would a deterministic script produce acceptable output every time? | Use deterministic code | Consider agent |
| Cost | At full production volume, does the inference cost justify the output value? | Use agent | Use deterministic code |
| Review | Can you verify the output faster than writing the deterministic version? | Use agent | Write the script |
If the task fails any gate, stop. Write the bash script. Write the Python function. Use grep. Use jq. Use whatever tool gives you deterministic, predictable, instantly verifiable output.
This isn't anti-AI. It's pro-efficiency. The agent is for the tasks that actually need it.
Flexibility through LLMs is a feature until it produces a wrong answer with total confidence. Deterministic code that fails loudly is safer than an agent that fails quietly.
I once replaced a 3-line jq filter with an agent "just in case the JSON structure changed in the future." The jq filter never failed. The agent hallucinated a field name twice before I gave up and went back to jq. The flexibility I was protecting against never materialised. I'd burned an hour and a dollar on a problem that didn't exist.
You probably don't. Premature agentification is the new premature optimisation. Start with the simplest deterministic solution. If the requirements genuinely evolve past what static code can handle, add the agent then.
The pattern I've seen repeat across projects: someone builds an agent wrapper around a straightforward text transformation because "we might need fuzzy matching later." Six months later, the fuzzy matching hasn't been needed, and they've paid inference costs on every single call in the meantime.
At 100 calls per hour, 8 hours per day, even cheap models add up. A $0.15/M input model at 2K tokens per call generates $24/day in inference costs — $500+/month for one pipeline. Then add the cost of the time spent reviewing unreliable output, debugging hallucinations, and rebuilding trust in the results.
The penny-per-call framing hides the volume problem. And it hides the attention tax.
Verification: You should have at least one script that replaces an agent workflow, and a number in minutes that represents time you're getting back.
I had an agent pipeline that parsed error logs, categorised them by severity, and suggested fixes. It cost about $12/day in inference and hallucinated a fix category once every three days. The deterministic version? A 45-line Python script with regex patterns and an enum. It runs in 200ms, costs nothing, and never hallucinates. The agent was useful when I was figuring out what patterns existed in the logs. Once I knew the structure, the agent became unnecessary.
The Waste Principle doesn't say never use agents. It says be honest about when you're using an agent for exploration vs. production. Exploration needs ambiguity. Production needs determinism.
Module 3: Boot — The first session that makes every other session work. Once you know when to use an agent, learn how to start one properly so every session compounds.