top of page
< Back

2

Reinforcement: my new colleague's first day

His first success was exactly ten calendar entries — then came three nights of zero.

Tuesday morning, May 19th. The overnight run is done. Result: zero. No error message, no crash — just nothing. Third night in a row. Two days earlier the world still looked different. That Sunday was my new colleague's first day on the job. 


The colleague is an AI — Claude, to be precise. I describe what I need, he builds workflows and scripts. First task: the monthly billing from episode 1. Pull appointments from the calendar, enter the hours. 

And then it appeared, the log line of the year: `outlookEvents: 10` — ten real appointments, pulled from the calendar all by itself. Ten — no more. But every one of them real. 

And now: zero. What had happened? Two things, both self-inflicted. First: I'd entered part of the settings only in the tool's click interface — in a moment of euphoria, saved… you guessed it: nowhere.

 Gone at the next restart. The tool has sticky notes, not a memory. Second: when the tool hung once, I killed it with a sledgehammer. What I didn't know — the sledgehammer also invalidated every access key, bending the keys, so to speak. Door shut, key stuck inside and useless to boot. And the repair script was locked out there with me. 

The fix was unspectacular: a check script that now, after every restart, inspects all critical settings and reports a dry `[OK]` or `[FIX]` — and calls the repair service right away. Since then the nights deliver numbers again instead of zero. The colleague's first day ended like many first days: one small, real success, two avoidable mishaps — and a rule for life.

For the nerds

The calendar query strictly needs a from-date and a to-date — obvious in hindsight. Both had only been typed into the interface by hand, so the nightly scheduled run started without them, the calendar service answered with an error, and the workflow quietly branched off into the error path. 


On top of that, the forced process-kill invalidated the instance's API keys, which locked out the deploy script too. Company rule No. 1 ever since: every setting you click goes straight into a script.

Once a ticket, today a sentence

In my old projects this would have been a ticket: prioritized across two meetings, resolved by change request, re-tested the following week. 

The discipline behind it — prioritize, change, re-test — was spot on; I kept that and only cut the waiting. Here: say a sentence, watch. In return I'm learning vocabulary again — Claude explained twice why `null` in a logfile is something other than the number zero. The second time I got it. Almost.

What I wish I'd known earlier

Whenever you click something important together somewhere: take a screenshot right away and drop it in a folder called "Settings". Inelegant, but after every restart you know how it should look. 

And: the elegant version of that is a script — which is exactly where automation begins. Although, really, the colleague could just handle all of that himself.

The first success is allowed to be small — it just has to be real.

the bouncer who let no one in — how a login machinery stonewalled us for weeks. Not even with a valid ID.

bottom of page