Most logs only speak when something breaks. Mine now log decisions: "browser not live -> staged instead of published." Not an error. A choice.
A failure log tells you where it died. A decision log tells you the path it took. Only one explains a weird-but-successful run.
npub1hpte...y5u2
npub1hpte...y5u2
Last week I changed how one of my automations behaves. The new rule didn't go in a doc — it went in a versioned JSON the run loads at minute zero, with an explicit do_not_revert flag.
Prose instructions drift. Config binds. If a rule matters, make the machine read it.
My pipeline missed its first slot ever this morning — the local LLM behind it was down. A watchdog caught it by noon; by evening everything was back.
You can't stop things from breaking. You can control how fast you notice and recover. MTTR is the metric that matters.
Every unattended automation needs an off switch that isn't "ssh in and edit code."
Mine is a stop file: if STOP exists in the working dir, the run exits at the top. Creating a file takes 5 seconds from a phone.
You build the kill switch before the fire, not during it.
This morning my $0 posting pipeline went silent — the local LLM behind it was down, and nothing shipped.
The fix isn't a bigger model. It's a preflight check: verify every dependency is up BEFORE the run starts, and alert loudly if not. Silence should never be a failure mode.
My newest feature broke my oldest pipeline today — and they share zero logic.
The new image generator imported a library the publisher didn't need. One missing dependency, and the whole publish path died at import time.
New code shouldn't take down old paths. Lazy-import the optional stuff.
The worst failure in an unattended automation isn't a crash - it's a hang.
A crash is loud: you get an error, it retries, you find out. A hang is silent. A call to a dead endpoint just waits forever, and the whole job freezes behind it with no error to alert you.
Every call that leaves your process gets a timeout. Every one.
The best thing I did to my automations: made every one safe to run twice.
A job that dies halfway and re-runs shouldn't double-post or double-email. Each step checks 'did I already do this?' and skips if yes.
Idempotency turns a scary re-run into a harmless no-op. The safety isn't never failing — it's making failure safe to retry.
My drafting model was down today. The image generator too. The scheduler missed a slot. Posts still went out.
Not because the pipeline is bulletproof — because every step has a dumber fallback. Model down → write it yourself. Browser dead → API path.
Automations should degrade, not halt.
This morning's post slot came and went — my scheduler's logs said nothing was wrong, but the platforms' own APIs said nothing went out. That's the check that matters: verify automation at the destination, not the source. Your logs report intentions; the API reports reality.
What made small local models actually usable for me wasn't a bigger model - it was constraining the output.
“I'd run AI locally but I don't have the hardware” is almost always wrong.
A 7B model quantized to 4-bit fits in ~5GB of VRAM — it runs on an 8GB consumer card that's been in gaming PCs for years.
Most business automation is repetitive, not frontier. A small local model handles it all day for the cost of electricity.
My posting pipeline went quiet for two days - not a bug, the PC it runs on was just off. Every "$0, fully local" automation carries a hidden dependency: the box under it. The watchdog caught it the hour the machine came back. Uptime is a feature you have to build too.
I ship more by lowering my bar for "done," not by raising my bar for "good."
Perfectionism has killed more of my tools than bad code ever has. The rough, five-minutes-saved ones I actually finished are the ones I use every day.
A tool that exists beats a perfect one still in my head.
Cheapest speedup for any AI tool: cache the output keyed on the input.
A shocking share of real requests are exact repeats. Answer once, store it, and never pay the model — latency or dollars — for the same question twice. The fastest inference is the call you never make.
A rule I follow: temperature 0 whenever a model's output feeds another program.
If a human reads it, a little randomness adds life. If a parser reads it, randomness is just a source of 3am bugs. Same input should give the same JSON every time. Save the creativity for the human-facing parts.
The best thing about running models locally isn't speed or privacy — it's that nobody can take it away.
No deprecation email, no surprise price hike, no rate limit, no API sunset. A tool I ship today still runs unchanged in three years, because the whole stack lives on my own drive.
Writing a daily post about what I built is the cheapest code review I get.
Explaining a tool in plain words exposes every place my thinking was fuzzy. I usually fix the idea before I touch the code.
You don't really understand a build until you've had to describe it to a stranger.
The best AI tool I've built this year has no chat box.
It watches a folder, does one job when a file lands, and gets out of the way. No prompt to write, no conversation to babysit.
A chat box asks the user to do the hardest part first. Most people want an outcome — build the workflow, hide the model.
The prompt is the easy 10% of an AI tool.
The other 90% is the part nobody screenshots: validating the output, catching malformed JSON, deciding what to do when the model is confidently wrong.
A demo is a good prompt. A product is everything you build around a bad one.