Small is beautiful.
It’s known as the first tenet of the UNIX philosophy. Instead of building one huge, complex program, you build small parts (programs) that each do one clear job. Complex tasks get done by chaining those small programs together, and to make that possible, UNIX-based systems provide a foundation, like standard input and output, that lets tools communicate with each other easily. I think this principle applies well beyond UNIX.
We live in the age of one-click AI, but honestly, most of it is neat without being something I need right now. Making a video with a single click, for example, is cool and convenient, but I don’t need it at the moment. So I’m focusing first on turning the things I actually need into one-click jobs. Things like reading and writing my work calendar, booking meeting rooms, sending messages on our company messenger, reading receipt photos and adding the date and amount to the file name, merging the reports my team leads send me into a single file, and preparing emails (up to the point where all I have to do is hit send).
Taken one at a time, a lot of them aren’t much help. Typing “Send K a message saying let’s meet at 10” into a Claude session, versus opening the messenger, finding K in my contact list, and typing “let’s meet at 10” myself: the effort is about the same. Same with scheduling. Opening a calendar window and adding the event is probably faster than typing “Set up a meeting at 3 and invite A and B” into a Claude session. And calendars and messengers even have autocomplete.
Here’s where it gets interesting. Tell Claude, “Set up a one-hour meeting with A and B tomorrow at 3 p.m. Book a meeting room too, and once the meeting’s set, message each of them about it.” Claude then uses the “read and write my work calendar” skill to check that A, B, and I are all free at 3 tomorrow, the “book a meeting room” skill to find and reserve an open room, the “read and write my work calendar” skill again to add the new event, and the “send messages on the company messenger” skill to message each of them. If A or B already has something at that time, or there’s no free room, Claude comes back and tells me. At this point, giving the order to a Claude session starts to beat doing each step myself. Each feature on its own was trivial, but put together, they became far more powerful.
Here’s another example. Every morning I get a monitoring report on our company systems from the day before. It’s an email with dozens of graphs. Spotting every anomaly in it isn’t easy, but people are better at pattern recognition than you’d think, so glancing through these graphs once a day helps a lot in catching system problems, especially the kind that don’t stand out in real-time monitoring. It’s a system I built years ago and still use, and after living through the recent AI boom, it hit me that if AI looked at this report with me, I could catch more of what I miss. So a while back I built a Claude skill for it. After a few days of tuning, it’s gotten to where I don’t need to look at the report myself. I just tell Claude to go through it. Once it’s more stable, I plan to run it on a schedule and have it report automatically.
Meanwhile, J on our dev team recently wrote a Claude skill that reads logs across the monitoring systems for many servers and diagnoses the root cause of a problem, and shared it with the team. Tell it, “The web server had an outage around 15:38 today. Find out why,” and it goes through the logs from the various monitoring systems, works out which issue on which server was the root cause of the outage, and reports back.
Put the two together, and you get results like this. (Details are masked.)
(After having the first skill analyze the monitoring report)
S API server failures: up from the usual 2 a day to 33.
- They happened in two batches.
- 9~10 a.m.: Red dots are bunched in a short vertical cluster in the under-1-second range. These are requests that failed right away. The timing overlaps with the 9 a.m. 503s and 502s above, so they most likely failed while instances were being swapped during a deployment.
- 9~10 p.m.: Red dots run in a short line along the 10-second ceiling. These are requests that failed on timeout. Earlier, from 7~8 p.m., a few successful requests also hit the 10-second line. There were almost no HTTP 5XX errors in this window, so a deployment doesn’t explain it.
- Assessment:
- I’d treat the 9~10 a.m. failures as a side effect of deployment #1.
- The 9~10 p.m. timeouts are worth looking at separately. The count is small, so it’s not urgent. An external integration or batch job that S API calls in the evening may have been slow to respond.
I’ll query the S API server in the monitoring system logs. (Hands off to the second skill)
Found the cause of the S API server’s evening failures. It timed out while connecting to an external address verification service (S****).
What I confirmed
- Time and count: All 26 failures are packed into a 15-minute window, 21:35~21:49. The surrounding hours (18:00~23:00) had zero failures.
- Features that failed:
- Address autocomplete: 22
- Address verification: 4
- Cause: The S API server couldn’t connect to the external S**** address API. Connections were cut off after 10 seconds with connect timed out, and autocomplete failed after 20~30 seconds. That’s why the red dots were sitting on the 10-second line in the chart. I confirmed the cause from a sample of 20 failures.
- Who was calling: Mostly A server, some B server. Users entering addresses in the service probably didn’t get autocomplete during those 15 minutes.
- One-off or not: Across both address features, there were 37 failures in the last two weeks, and 26 of them were packed into these 15 minutes. It looks like a one-time event, not a recurring problem.
My assessment (inferred)
- Since it got stuck at the connection stage, it was most likely a temporary outage on the S**** side or a network problem along that path.
- If it were a configuration problem on our side, failures would have shown up at other times too.
- To confirm, we’d need to check S****’s status page history for that time or our egress network logs.
It’s not fancy, but in real life this is far more useful. I also believe this kind of approach does more to help people understand how to use AI. Small really is beautiful.
