Comment by monkeydust
15 hours ago
Agree. How would you solve this in general, what would be the ingredients? People use things like zapier, n8n, node-red to achieve this today but in many cases are overkill.
15 hours ago
Agree. How would you solve this in general, what would be the ingredients? People use things like zapier, n8n, node-red to achieve this today but in many cases are overkill.
Honestly, you just need cron (and Ruby/Python/bash/whatever) on an EC2. It's not very fashionable, but it works, will continue to work forever, and costs hardly anything.
To use an example in the article, what does
> Analyzing CI failures overnight and surfacing summaries
Look like on ec2 with python? Because with Claude, it’s that prompt, and with your solution it’s infra + security groups + multiple APIs + whatever code you actually write
I would suggest the prompt is an example of garbage in that's going to produce garbage out. Sitting down to confront the problem you're solving will show this, while Claude is going to happily spit out what looks like a plausibly functional system.
So for example the only "analysis" of CI failures are which systems failed and who/what committed the changes to those things. The only way AI would help me here is if the system was so jank that the sole primitive i can use is textual analysis of log files. Which granted is probably real for a lot of software firms, but I really hope I have better build and test infrastructure than that.
1 reply →
I'd start with solving the UX issues, specifically expectations and UI around scheduling jobs.
Expectations - the functionality of "do X on a timer" needs to be offered to users as a proper end-user feature[0], not treated as a sysadmin feature (Windows, Linux) or not provided at all (Android). People start seeing it on their own devices, they'll start using it, then expecting it, and the web will adjust too[1].
UI - somehow this escapes every existing solution, from `cron` through Windows timers to any web "on timer" event trigger in any platform ever. There already exists a very powerful UI paradigm for managing recurring tasks, that most normies know how to use, because they're already using it daily at work and privately: a calendar. Yes, that thing where we can set and manage recurring events, and see them at a glance, in context of everything else that's going on in our lives.
--
<rant>
I know those are hard problems, but are hard mostly because everybody wants to be the fucking one platform owning users and the universe. This self-inflicted sickness in computing is precisely why people will jump at AI solutions for this. Why I too will jump on this: because it's easier than dealing with all the systems and platforms that don't want to cooperate.
After all, at this point, the easiest solution to the problems I listed above, and several others in this space, would be to get an AI agent that I can:
1) Run on a cron every 30 minutes or so (events are too complicated);
2) Give it read (at minimum) access to my calendar and todo lists (the ones I use, but I'm willing to compromise here);
3) Give it access to other useful tools
Which I guess brings us to the actual root problem here. "Run tasks on a cron" and "run tasks on trigger" are basically just another way of saying unattended/non-interactive usage. That is what is constantly being denied end users.
This is also the key to enabling most value of AI tools, too, and people understand it very well (see the popularity of that Open Claw thing as the most recent example), but the industry also lives in denial, believing that "lethal trifecta" is a thing that can be solved.
</rant>
--
[0] - This extends to event triggers ("if X happens, then") automation, and end-user automation in all of every-day life. I mean, it's beyond ridiculous that the only things normal people are allowed to run automatically are dishwasher, and a laundry machine (and in the previous era, VCRs).
[1] - As a side effect, it would quickly debullshitify "smart home" / "internet of things" spaces a lot. The whole consumer side of the market revolves around selling people basic automation capabilities - except vendor-locked, and without the most useful parts.