No Code I Can’t Understand at 2 AM

Why responsibility still begins with understanding, even with AI

No code I can’t understand at 2 AM.

This was a rule I used to live by.

Early in my career, I carried a pager. We had an on‑call rotation, and if something bad happened, we had to fix it. The 2 AM calls were the worst.

My team was the first to get called. We made whatever changes were needed to get things working again, then handed it back to the data partner team when necessary. I loved this role. It was all about immediacy. Either we could fix it, or we had to reach out to the data providers to get them to fix it. Either way, we triaged, debugged, and kept things moving.

We built tools to support the platform. We attended code reviews for anyone wanting to add to it, checking that their changes met production standards and that we understood what was going live, and when.

That job is where the rule came from.

Never create code I can’t understand at 2 AM.

Sometimes it came with an addendum.

After having been at a bar until 2 AM.

Because sometimes the call didn’t come from the pager. It came from someone else on the team, already on call, who needed help. For one particularly bad incident, most of the team was pulled in, working for most of a week to untangle a real nightmare.

All of that made something very clear, very early in my career.

Understanding your code matters.
Building code that others can understand matters even more.

There was one engineer who liked to show us how smart he was. And he was very smart. But his code wasn’t maintainable by mere mortals. One of his impressive changes took down a system we didn’t think could fail.

At the time, we had PR‑blocking privileges. During one code review, done in a conference room with paper copies, he wasn’t taking feedback. So I stood up, said, “You’re wasting my time,” and walked out.

He was one of the most senior engineers in that space. I definitely was not.

But I took supportability seriously. Someone was going to get the call when this broke. I wanted to make sure it wouldn’t be me, staring at code no one could explain.

Why does any of this matter now?

Because I hold the same bar for AI‑generated code.

I need to understand it. I need to be able to write comments explaining what it’s doing. I can’t just throw it over the fence. I can do that for experimentation, sure. But not for production.

I’ll admit that over the years I’ve gotten more relaxed about perfect clarity. I move faster. I assume I’ll come back and clean things up later.

But pivoting to using AI has brought my first principles back into focus.

It’s great that Quinn can produce code for me. But I want to make sure I truly understand it. Because if I don’t understand it, how will I fix it? How will I work with someone else on it? How will I stand behind it when it breaks?

I hear people talk about being buried in PRs, and I get that. But good design up front matters. Being clear about what you want built matters. If I do that work, I should be able to understand the resulting code.

If I just say, “Build me a FluffyBunny,” then the extra work to understand it is on me.

I’m more forgiving now than I was back then. I move faster. I leave more TODOs than I should.

But the rule is still there.

Don’t ship what you can’t understand.
Don’t ask others to maintain what you can’t explain.
And don’t confuse speed with ownership.

Especially at 2 AM.