Back to blogYouTube Video

Published August 22, 2026

Log everything, alert immediately - Automation Tip #5

Can't play the video or having issues? Here's the direct link.

AI Summary

The video argues that the modern reliance on LLMs for debugging has eroded programmers' ability to diagnose issues independently, making robust application logging and alerting more critical than ever—especially for AI-driven automations and agentic workflows. Because automations inherently remove human oversight from repetitive tasks, they inevitably fail silently due to LLM hallucinations, invalid outputs, IP blocks, HTML structure changes, or GUI fragility. Without detailed logs capturing every input, decision, and action, retracing the failure path is impossible. Furthermore, without proactive alerts, broken automations can remain down for weeks unnoticed. The core prescription is to implement granular, step-by-step logging combined with immediate alerting to decision-makers to ensure rapid detection and resolution of inevitable failures.

Key Takeaways

  • Log every discrete step, input, and decision within an automation to create a complete audit trail for post-mortem debugging.
  • Treat logs as the primary debugging tool rather than defaulting to pasting errors into LLMs; logs provide deterministic context that LLMs cannot infer.
  • Implement immediate alerting (e.g., Slack, email, PagerDuty) on critical failures so the responsible human is notified the moment an automation breaks, preventing weeks of silent downtime.
  • Anticipate specific failure modes for AI agents: hallucinated outputs, schema violations, and unexpected token usage that crash downstream logic.
  • Anticipate infrastructure failure modes for traditional automation: IP bans/rate limits during scraping, DOM/HTML selector drift, and GUI resolution/state changes.
  • Design automations with the assumption that they *will* fail; the engineering goal is minimizing Mean Time to Detection (MTTD) and Mean Time to Resolution (MTTR) via observability.
  • If you are the sole operator, you are the 'decision maker'—configure alerts to reach you directly wherever you are most responsive.

Description

Book a call: https://calendly.com/itshassanaziz/discuss-a-project ==== ==== ==== The most important thing for your AI workflows and agents to have is proper detailed logs and precise alerts set up to ensure that you never operate in the dark. When something goes wrong, you are alerted immediately. You don't waste weeks not knowing that your AI agent has crashed. When you need to debug an issue, you have detailed logs that show you what happens at every step of the automation pipeline. You're not operating in the dark. ---- ---- ---- If you like this kind of content, consider subscribing. It helps out more than you know. And if you got ideas for more videos, drop them in the comments below. I'd love to see it. ==== ==== ==== LINKS Website: https://www.hassandev.me Portfolio: https://www.hassandev.me/work YouTube: https://www.youtube.com/@itshassanaziz?sub_confirmation=1 My Book: https://www.hassandev.me/designing-websites X / Twitter: https://x.com/intent/user?screen_name=nothassanaziz

Transcript

Auto-generated transcript
So one of the biggest issues I see with programmers today is that they don't know how to debug programs without LLMs. Back in the day before LLMs you would expect the programmer to either read the docs, google the issue, search for stack overflows, etc etc right and you would expect them to find out more about what went wrong and have or at least develop a really good understanding of the problem right. We don't do that anymore. Now we just paste the entire message in cloud and expect it to give us a perfect solution, which, you know, that comes with its own set of problems, and I'm not going to get into that in this video. But before we had Claude, we had something I would say even more useful, and that is the application logs. And logs are just that. They're just logs, right? They're just a bunch of statements, right? You log everything that your application is doing, every single action it takes, every single thing that's happening inside your application. And this way, if something goes wrong, which it inevitably will sooner or later, then you can just review the logs, see what went wrong, see what kind of input your application received, what it did with it, etc, etc, and just fix the issue from that, right? And this makes debugging an application a thousand times easier. And especially when you're building AI automations and agentic workflows and all that, especially when you're involved LLMs and their hallucinatory nature in your automations, you need logs, right? Because here's the reason, right? When you're automating a task, you're expecting that a human will no longer be doing it, right? Because you're automating it, no actual human being is going to do it, right? A machine is going to do it for you. That means that the automation has to record its steps very accurately so that when it inevitably fails, a human can retrace its steps and, you know, just see what went wrong, right? And something can always go wrong. If you're using LLMs, if you building AI agents you could have the agent hallucinate bad output right You could have some invalid output produced that completely breaks your program because it didn expect this output right If you doing I don know web scraping like I do a lot of web scraping right? Or just simple browser automation tasks, right? There's numerous issues in this as well. Your IP address could get blocked because you're scraping websites or, you know, building bots for websites or their html structure would change and your entire automation would just break because of that like there's issues in every single kind of automation you build even if it's gui automation especially if it's gui automation because screen sizes can change it's a whole like different mess of an automation style it's very finicky very fragile and very easy to break but the point is automations do break right they work most of the time but they do break eventually and when they do you want to make it as easy as possible for you to actually fix the issue right so when failures like these inevitably happen you need to make sure you're logging every step and alerting the decision makers in your company or if you're building this for yourself then you're the decision maker i guess but you need to have logs you need to have alerts so that you actually figure out what went wrong right because believe it or not i've seen companies where automations such as these were broken, the program crashed and stopped working and nobody noticed for weeks, as in literally weeks. And you know, I can't even blame them because like you've got your own work to do, right? You've got your own shit to deal with. You're not going to notice these things going down unless something truly catastrophic happens, right? And that is exactly why you need alerts and you need logs. So that's the big tip for today, right? Set up alerts so that you can always notify the decision makers, probably yourself, that something went wrong and you should go fix it and set up logs, proper detailed application logs, so that you can retrace the automation's steps anytime some issue pops up.

Share this article

All great things started with a conversation

If you've got a cool project or opportunity and you want me to be a part of it, set up a free meeting with me here, and let's talk. 😊