The Robots Stopped and Nobody Told Me

Six days a week, at four in the afternoon, a small automation writes a journal entry about what I worked on. On Sundays a second one reads the week back to me.

Neither of them is finished. That is the point. I am building the small systems I use to run my own work one piece at a time — and I would rather run each piece for a few weeks and find out what it actually does than wire six of them together and trust the diagram.

Those two caught something in their first week that I was not looking for, and that part belongs to you more than it belongs to me.

Three robots quit and filed no notice

On a Monday, two scheduled tasks fired on time and then stopped in the middle of the job. Neither crashed. Neither logged an error. Both were still flagged, hours later, as running.

On the Thursday it happened again with a different pair, one of them a repeat offender.

Nothing told me. There was no alert, because nothing had failed in a way anything was watching for.

Sit with that if you have anything at all running on a schedule: a backup, a report that lands in your inbox, a sync between two apps, an assistant that summarizes your week. You are not going to get an error. A task that stops halfway looks identical, from the outside, to a task that is taking its time. The only difference is on your disk, and nothing is going to walk over and show it to you.

The check has to open the output

Not the status flag. The status flag was the thing doing the lying.

The daily journal doesn't ask a task whether it finished. It opens the file that task was supposed to write, and it reads the date on the last line. On the Monday it found two routines marked as running and a file whose newest entry was three days old. On the Thursday, same method, same answer.

That is the whole trick, and it is not a clever one. If you want to know whether your backup ran, you look at the backup. If you want to know whether the report went out, you open your sent folder. Whatever you have that reports on itself, your check should point at the thing it makes, not at the thing it says about itself.

A fresh timestamp is not proof

One of them had cover.

A document in my notes showed a recent date and a new note about exactly the kind of work that routine does. It looked like proof. If I had stopped there, I would have marked it working and moved on.

I had done that piece by hand, in a different session, for one specific thing. The automation's real job — sweeping everything else — never woke up. So the honest status of that routine isn't "working." It's unknown, which is a far more useful thing to write down than a guess in either direction.

This is the same failure I wrote about when I found my own site telling visitors two things that weren't true. Software that is confidently wrong is worse than software that is visibly broken. A green tick is not evidence. Neither is a recent date, if you never checked who put it there.

A status is not a result. "Running" is not "done."

And the question you actually want to ask is not whether your automation ran. It's whether you would know if it hadn't.

Write down what happened and the rule writes itself

There was a second thing in those journals that I didn't go looking for.

Five days in, I noticed I had never written a rule about which AI model to use for what, and a rule had shown up anyway. Writing and interview work had drifted onto one model. Deep, multi-file technical audits onto another. Long, patient, structured planning onto a third. A one-line note appended to one document went to the smallest and cheapest thing available, and the journal logged that as the right-sized match rather than as a shortcut.

Nobody enforced that. It came out of writing down what happened each day, and after about a week the answer was sitting there.

If you're trying to work out which of these tools to reach for and when, that is the cheapest method I know. You don't have to decide in advance and then find out you were wrong. You need about a week of honest notes about your own work, which nobody else can write for you and which cost you two minutes a day.

The habit comes first and the automation comes later

This is the part I keep having to relearn. It is tempting to skip ahead: to automate the thing before you have done it by hand enough times to know what it should produce, and what it looks like when it goes wrong.

I did it by hand first. That is the only reason I could tell that a routine had stalled, because I already knew what a good day's entry looked like. If I had started with the automation, three days of silence would have looked like three quiet days.

So the order I'd suggest, and the order I'm following myself, is unglamorous. Do the thing manually until it is boring. Write down what it produces. Then automate the boring version, and keep a way to check its output that isn't the thing itself. Add the next piece only once you trust the last one.

That is slower than the version people sell. It is also the version where you can still tell what is true.

You don't need any of this to be automated

That is the honest version. Mine runs on a schedule because I enjoy building things like this on my days off, not because the schedule is what makes it work.

Yours can be three lines:

• At the end of the day, write down what you actually did and what went sideways. Two sentences is enough.
• Once a week, read your week back in one sitting. A week says things a day can't.
• When something tells you it worked, whether that's a tool, a form, an automation or an assistant, open the thing it was supposed to make.

I've written before about a routine that caught its own bug, and about testing something before you trust it. This is the same idea one step further out — eventually you need something checking the checkers, and it should not be one of them.

Mine, so far, is a text file that gets a paragraph added to it six afternoons a week. It has been more useful than that sentence makes it sound.

And since this post is about testing things before trusting them: the cover image is itself a test. It was made with a new method, one reference image for the room and a separate one for the little terminal on its wheel, instead of a single prompt describing both in words. A few more covers will tell me whether the method holds. Same loop as everything above: run the small version, look at what it made, keep what survives.

I teach people to use Claude, Google AI, and ChatGPT on their own device, with their own messy files. If you want a hand with something like this, the free 30-minute call is the place to start. No pitch.

#ernestGoesToAI