I audited my own AI usage a while back and found something embarrassing. I'd been running a frontier model on a task that is, functionally, grep with opinions: watching a dev-server log for lines that mean something broke.
That's not a hard problem. It needs no reasoning, no architecture, no taste. It needs a thing that never blinks. And the model I want for "never blinks" is the cheapest, fastest one available — not the one I'd trust with a schema migration.
The split: the expensive model does the thinking, the cheap model does the staring. Once I framed it that way, a whole class of always-on tooling became basically free to leave running.
The problem it solves: you find out too late
Here's the failure this fixes, and it's the one that costs the most trust.
An agent makes an edit. The edit breaks the build. The agent doesn't notice, keeps working, makes three more edits on top, then reports success. You open the browser and find a white screen. Now you're debugging four changes at once instead of one, and the agent's status report has become actively misleading.
Or worse — the version I actually lived. The console errors and the wrong-page problem were both discovered by me, after handover. Which means every "done" now requires my independent check, which is exactly the work I was trying to delegate.
Continuous log monitoring is the standard fix in ops: watch for error patterns in real time so an issue gets caught before it compounds. It's just that almost nobody applies it to their own dev loop.
The money pattern: a filtered tail on a cheap model
The core of it is unglamorous, which is why it works:
tail -f dev.log | grep -Ei 'error|failed|cannot|undefined|expected corresponding'Five words, chosen from real experience rather than theory:
error/failed— the obvious ones.cannot— catches "Cannot find module", the single most common break after a dependency change or a bad import path.undefined— catches the runtime class that builds cleanly and dies on hydration.expected corresponding— catches unclosed JSX/Astro tags, which is the most common way a sloppy edit breaks a template.
Then a small model reads the matches and answers one question: did anything actually explode, and if so, what's the one line that matters? That's a classification task. A Haiku-class model does it perfectly and costs a rounding error to leave on all day.
Wire it as a notification, not a report you have to go and read. The value is entirely in the interrupt — a break that surfaces in three seconds costs a one-line fix, and the same break found forty minutes later costs an investigation.
The rule that makes it worth having: triage before you report
The watcher alone isn't the win. The win is the standing rule attached to it: triage breaks before relaying status.
If the watcher fires while an agent is mid-task, the agent's job is to fix it — or at minimum name it — before telling me anything went well. Never leave the human to discover the break. That single rule converts the monitor from a dashboard nobody looks at into an actual quality gate.
The wider pattern: route by task, not by habit
Watching is one instance of a general rule. Most calls in a real AI system are not hard, and matching model to difficulty is the single easiest cost win available:
const ROUTES = {
watch: 'small', // did anything break? tag this. classify that.
work: 'default', // drafting, refactoring, multi-step agent turns
careful: 'frontier' // migrations, money, irreversible, customer-facing
};Everything that's genuinely a yes/no or a which-bucket question belongs on watch: log triage, console-error checks, "does this diff touch auth?", tagging, extraction, classification, first-pass filtering of search results. None of it needs frontier reasoning and all of it is the kind of thing you want running constantly.
The 60-second browser heartbeat is my favourite of these. A small model reads the console every minute while I work on something else. It has caught hydration errors that never appear in the build output at all — the class of bug where the server-rendered page looks perfect and the interactive layer is dead.
The catch: watchers that spam get ignored, and watchers can eat your machine
Two failure modes, both of which I caused.
Alert fatigue. A watcher that fires on warnings, deprecation notices and expected dev-server noise gets muted within a day, and a muted watcher is worse than none — you now believe you have coverage you don't. Tune the filter to breakage only. If it fires on something that turns out to be fine, that's a filter bug to fix immediately, not noise to tolerate.
Waiter sprawl. This one's mine and it's stupid. I once spawned a fresh background poller for every wait — four separate "wait until condition" loops plus a process-watching chain-starter — and never killed the previous ones. They stacked on top of the actual work and I got asked why five shells were running. The rule now: one reusable watcher, killed before another is spawned. Never let watcher processes accumulate.
Related: don't build brittle watchers around things you're about to kill. I wrapped a set of download-monitors around processes I then terminated out from under them, and they spent the next while false-firing and erroring — pure noise the human had to sit through. If the thing you're monitoring is transient, poll its state inline instead.
The verdict
You do not need your best model to notice that something is on fire. Put a small, fast, cheap model on watch duty, filter for the five strings that mean real breakage, wire it to a notification, and attach the rule that breaks get triaged before status gets reported.
The result is that build breaks arrive as interrupts instead of discoveries — and the person you're working for stops being your error-detection system.
Keep one watcher, kill it before you start another, and never pay frontier rates to stare at a file.
Want always-on monitoring wired into your build loop? Book a call or see the work.