The Power of Theory: Debugging What You Actually Understand

Hey everyone, let’s restart our little philosophical conversation about the future — our future.

For those who know me: I’m a nerd who spent the last 14+ years working at international companies, and my hobby was always sharing knowledge. Blog posts, YouTube, udemy, trainings, talks — whatever the format, because when you teach, you are the one who ends up learning the most.

If you’ve followed my content, you probably already hear me during my examples saying “This is gold, believe me.” And people agreed. (Or they were just being nice and lying to my face — hard to tell 😄.)

But every now and then, someone would push back with the same comment:

“Douglas, you show the theory, you explain the concepts, you show how it’s done… but why don’t you go build a real hands-on training for us?”

Well. Here I am today to talk about exactly that. And here’s the plot twist: now, better than ever, I can prove why the theory was the right thing to focus on all along. And I’m glad I didn’t invest time creating those hands-on trainings.

Why I’m Glad

Think about it. If I had asked 20,000+ students to spend weeks manually grinding through the mechanical parts of a system design — writing boilerplate, wiring configs, fighting YAML — that would have been a waste of their time.

Not because the practice is worthless, but because the mechanical execution was never the most valuable skill. Today AI does that heavy lifting in seconds. What it can’t do for you is understand the system.

And that’s the whole point of this newsletter: in the AI era, you can only debug what you actually understand.

You Can’t Debug What You Don’t Understand

Here’s the uncomfortable truth a lot of engineers are about to discover. AI will happily generate a service for you. It’ll scaffold the API, the retries, the caching layer, the Terraform. It looks great — until 2 a.m., when it’s on fire in production.

Now the AI-generated code is throwing a cascading failure, your p99 latency is exploding, and the error budget for the month is gone in 40 minutes. In that moment, autocomplete doesn’t save you. Understanding does.

• If you don’t understand timeouts and retries, you won’t see why a retry storm just DDoS’d your own database.
• If you don’t understand static stability, you won’t know why the system fell over the moment a dependency blinked.
• If you don’t understand SLOs and error budgets, you won’t even know how bad the incident really is, or when to stop the bleeding.

The AI wrote the code. But the theory is what lets you reason about the code, read the failure, form a hypothesis, and fix it. Debugging is applied understanding. Always has been.

The Concepts Were Rare Before AI. Now They’re the Baseline.

For years, deep SRE knowledge was rare because it was expensive to acquire. You had to survive real incidents, break real things, and slowly build intuition. Most people never got there — they stayed stuck at the mechanical layer, busy writing the code the AI now writes for free.

That’s the shift. The mechanical layer just got commoditized. And what’s left standing — the part that doesn’t get automated away — is exactly the stuff we’ve been talking about for 60 newsletters:

• SLOs & SLIs — knowing what “good” even means, and how to measure it
• Error Budgets — turning reliability into a number you can spend and defend
• Automation & eliminating toil — pointing the machines at the right problems
• Monitoring & observability — knowing what to instrument and what the signals mean
• Release Engineering — canary, blue-green, feature flags: shipping fast without blowing up
• Simplicity — resisting complexity, because complexity is just more ways to fail
• Embracing risk & postmortems — learning from failure instead of fearing it

These were rare to find before. In the AI era, they become the basic literacy of a serious engineer. If you know how to code, you know the frameworks, and you carry these concepts deep in your bones — that combination is the real leverage. Let AI do the hard mechanical work. You focus on what you’re actually delivering and on the health of the whole ecosystem.

An SRE’s Superpower: Breadth Without the Time Tax

Here’s what always made SRE special — and slightly painful. A good SRE tends to know every domain: networking, databases, CI/CD, security, cost, the app itself. The problem was never breadth. It was time. SREs know a bit of everything but rarely have time to dive deep into any one thing during an incident or a design review.

Now? They do have time.

AI removes the time tax on going deep. The SRE who understands the concepts can suddenly go three levels deeper in seconds — pull a mental model, validate it, and move. That’s why I keep saying it: the SRE is one of the most critical people on any team, and this era makes them more valuable, not less.

So imagine your worth as a specialist who genuinely knows how to apply all of this — SLOs, automation, monitoring, release engineering, simplicity, embracing risk, postmortems, error budgets, and more. That’s not a “nice to have” anymore. That’s the moat.

Keep Your Eyes Here 👀

And speaking of building instead of just explaining — keep an eye on this newsletter over the next few weeks. I’m about to launch an SRE App to help you learn and be able to apply those concepts. Something I never had time to build before AI… but now I do.

No, no, no — I’m not here to ask you to invest money. I’m just saying: get prepared. This isn’t the “IT professor trying to sell you a course” speech. I’m telling you plainly that these concepts are what will survive the next few years. They were rare and hard to find before. They’re becoming the baseline now.

So let’s keep doing SRE. Let’s dive deep into it. And let’s add a lot of value along the way.

Because at the end of the day, AI can write the code — but you can only debug what you actually understand.

Stay tuned. This one’s going to be fun.

Cheers,

Douglas Mugnos

MUGNOS-IT 🚀