The moment when everything falls apart is not in the explosion, it’s in the quiet right after.- Lily (How to Trap a Tiger)
I entered the tech workforce right as the dot-com bubble was inflating to its limits. My very first job out of the gate was providing 24x7 support for one of the largest e-commerce sites of the era. To say it was a trial by fire would be a massive understatement. The systems crashed. They crashed constantly. They crashed all the time. I would go to sleep at night clutching a pager in my hand so the vibration would wake me up without waking up my roommates (NOT A JOKE!).
It was my job to keep the digital lights on, keep the servers upright, and somehow spin gold out of straw by writing actionable bug reports so the engineering team could actually fix the underlying infrastructure. You know what engineers love to do? Close bugs as “not reproducible.”
The catch? “Back in my day,” there were no IDEs hooked up to production. There were no real-time debuggers or slick APM dashboards watching the stack. When things went sideways at 3:00 AM, my only tools were a terminal, core dumps, and raw, sprawling log files. I had to reconstruct the crashed process line by line, figuring out exactly where the code failed and why. Because of that, 99% of the code I actually wrote and committed during my first year as a developer wasn't new features. It was painstakingly adding log statements to other people's code so we wouldn't be flying blind the next time their system broke (I mean, our system. #oneteam).
I carry that philosophy with me today. When I learn a new language, my Hello World program has ample log lines in it. Write your log statements like you are an engineer who needs to troubleshoot a 50-year-old computer running on a decaying nuclear battery from a full light-day away. You’ll thank yourself later. Or, your production support team will thank you. No, really, they will, or they should.
Now? We are living in an era where an incredible amount of code is being spun up by LLMs. But if you look closely at most AI-generated code snippets, you'll notice a glaring, quiet omission: they almost never include proper logging. Actually, you probably won’t notice. Sigh. That’s my point. AI is trained on code across the Internet, which does not log well. It’s functional and completely silent.
This is my request of you. When you are prompting an AI to build a function, a script, or an entire service, explicitly make logging part of the acceptance criteria. Force your prompts to demand robust, structured, and highly configurable logging. Don't let the AI skimp on the instrumentation just because the code works on the first run.
Now, this might naturally change on its own. We’ve reached the point where AI agents aren't just writing the code; they are monitoring the production logs. We are deploying systems where an AI can watch a log stream in real time, catch an edge-case exception, understand the context of the failure, and automatically draft or deploy a code update to fix it before a human engineer even finishes pouring their first cup of coffee.
So, uh, here’s my point. Logging is the foundational data stream that powers support engineers (we love you!) and will power autonomous software engineering. Logging is amazing. Make sure your prompts reflect it.