Just because we can automate easily doesn't mean we should. I think you nail that point well in this article. Yes, building is cheap. But we forget about the maintenance of that job and don't properly account for it.
Thank you for this. Separating trigger, scheduler and executor is the clearest framing I have seen. Treating the run receipt as part of the job is what most maps skip.
Juan's right that the receipt is the part most maps skip. Worth pushing on one layer further: the receipt only tells you a check ran, not that the check itself catches anything real.
If 'useful vs failed' comes from a check that's never been tested against a genuinely bad output, a passing mark in the history just means the check didn't error that time. Running it against a known-bad case first is one of the more reliable ways to find out if that mark actually means something.
So useful! Your framework handles execution failure extremely well, Jenny. The only thing I'd add is successful but obsolete automation as a separate failure mode. Ask me how I know 🤣
Karo's pointing at a real gap: success and whether it's still needed get measured in completely different ways, and most setups only check the first one.
One fix that's simple and different from a usage log: give every scheduled job an expiry date, say every quarter, so a real person has to re-justify it before it renews. That catches an obsolete job the moment nobody bothers to renew it, instead of waiting for someone to notice the output pile up unread.
Building on John's point: keeping the receipt is only half of it. What actually breaks is what happens after the receipt exists. A check that passes or fails quietly in a run history is easy to stop reading after a week or two.
So job proof only stays job proof if a failed check has to be dismissed, not just logged somewhere you could check if you remembered to.
Brilliant article Jenny. I will share it with my subscribers tomorrow.
Among all the useful information you shared I take one conclusion I got from the article: at this point in time, AI is a skill we must develop at any cost.
Even if building our systems require time to fix errors, and discover inefficiencies, what happens is that we learn to deal with LLMs and that is what brings us closer to build better AI systems, which is a different skill than developing software the traditional way.
Maybe that is why this feels like a different skill from traditional software development. We are learning how to work with LLMs, but we are also rediscovering what our own roles are made of.
Thank you for sparking this thought. I will probably be thinking about it for a while :)
Wow, Jose. Thank you. I really appreciate both the share and how deeply you read this. Your interpretation takes the idea one step deeper.
I think building AI systems forces us to look at our own work again. Repetitive work can keep us so occupied that we stop noticing where our judgment and taste sit. But when we try to hand part of that work to AI, we have to name the steps and what a good result looks like.
@stacksave
Just because we can automate easily doesn't mean we should. I think you nail that point well in this article. Yes, building is cheap. But we forget about the maintenance of that job and don't properly account for it.
Very well said, Raj. Thanks for reading and responding to this :)
Thank you for this. Separating trigger, scheduler and executor is the clearest framing I have seen. Treating the run receipt as part of the job is what most maps skip.
Juan's right that the receipt is the part most maps skip. Worth pushing on one layer further: the receipt only tells you a check ran, not that the check itself catches anything real.
If 'useful vs failed' comes from a check that's never been tested against a genuinely bad output, a passing mark in the history just means the check didn't error that time. Running it against a known-bad case first is one of the more reliable ways to find out if that mark actually means something.
Thank you for reading Juan! Glad it landed :)
So useful! Your framework handles execution failure extremely well, Jenny. The only thing I'd add is successful but obsolete automation as a separate failure mode. Ask me how I know 🤣
Karo's pointing at a real gap: success and whether it's still needed get measured in completely different ways, and most setups only check the first one.
One fix that's simple and different from a usage log: give every scheduled job an expiry date, say every quarter, so a real person has to re-justify it before it renews. That catches an obsolete job the moment nobody bothers to renew it, instead of waiting for someone to notice the output pile up unread.
Okay, I have to ask: how do you know? 🤣
And yes, successful but obsolete deserves its own failure mode. If nobody needs it, why create the work.
Scheduled tasks are underrated. Saving this to work through properly later.
They really are, whether AI is involved or not :)
Thanks for reading and saving this, Aniket!
Scheduler proof and job proof being two different things is the distinction most people miss.
Exactly. Thanks for reading, John :)
Building on John's point: keeping the receipt is only half of it. What actually breaks is what happens after the receipt exists. A check that passes or fails quietly in a run history is easy to stop reading after a week or two.
So job proof only stays job proof if a failed check has to be dismissed, not just logged somewhere you could check if you remembered to.
Brilliant article Jenny. I will share it with my subscribers tomorrow.
Among all the useful information you shared I take one conclusion I got from the article: at this point in time, AI is a skill we must develop at any cost.
Even if building our systems require time to fix errors, and discover inefficiencies, what happens is that we learn to deal with LLMs and that is what brings us closer to build better AI systems, which is a different skill than developing software the traditional way.
Maybe that is why this feels like a different skill from traditional software development. We are learning how to work with LLMs, but we are also rediscovering what our own roles are made of.
Thank you for sparking this thought. I will probably be thinking about it for a while :)
Wow, Jose. Thank you. I really appreciate both the share and how deeply you read this. Your interpretation takes the idea one step deeper.
I think building AI systems forces us to look at our own work again. Repetitive work can keep us so occupied that we stop noticing where our judgment and taste sit. But when we try to hand part of that work to AI, we have to name the steps and what a good result looks like.