The mercy of hard things

#learning #softwareengineering #ai #leadership

The other day I watched an engineer spend three days on a piece of the codebase nobody had touched in two years.

Should've been a four-hour fix, except...

The senior who built it was gone.
The documentation was sparse.
The code only made sense if you'd been in the room when the decisions were made.

They could've asked me to rewrite it. I would have.

Instead they sat with it.
Read through the git history.
Traced the logic forward and backward.
Built a mental model of why each piece was there.

By the end, they didn't just fix the bug. They understood the system.

I asked them why they didn't escalate it.

"I needed to know how this worked," they said. "If I'd just had you fix it, I wouldn't know."

I checked in twice that week. Both times they were still in the thick of it. I had a deadline breathing down my neck and a fix I could've written before lunch.

I'm not going to pretend it was easy to watch.

That three-day tax on understanding used to be everywhere in engineering. It still is, but it's getting rarer and we're very proud of that.

The logic is tempting. Why spend three days when AI could spend three minutes? Why put junior engineers through the pain of understanding when they could generate a fix instantly? Why not move faster?

Three minutes gets you a fix. Three days gets you something else.

Systems have shapes.
Those shapes have reasons.
Understanding the reason is the actual work.

That's the thing that separates someone who can patch code from someone who can steward it. I've been both, sometimes in the same week.

Those three days weren't a gift I was giving them by staying out of the way. They were the part of the job that was changing my developer.

There's an argument going around that if you have an idea and Claude can build it, you have no excuse for not shipping. That's true, as far as it goes.

But the grind isn't dead weight. It's a filter. The person with a vague idea about "an AI agent for our workflow" and the person who's traced where the data goes and what breaks when the API times out are not the same person.

It used to be obvious before anything shipped, because nothing shipped until you'd earned it. That felt like a feature at the time, but mostly it was called a blocker.

What AI is actually collapsing isn't a barrier to capability.
It's a barrier to mediocrity.

That's a different crisis than anyone's talking about.

When execution was hard, you had to believe in the thing before you built it.
You had to think through the architecture.
You had to anticipate problems because debugging would be expensive.
You had to write documentation because the code would outlive your memory.

These weren't best practices.
They were necessities.
Having no shortcut made them automatic.

I complained about this at the time. The week of planning before writing a line of code felt like overhead. It wasn't.

Now you can spin up a system in an afternoon that would've taken weeks, held together with prompt engineering and middleware and a lot of hoping nothing breaks in production.

Not because you're lazy. Because you can.
Because nothing forces the hard architectural thinking upfront.

I've done it. Shipped a workflow last month that I couldn't fully explain if someone asked me to trace a failure through it.

It worked.
The demo was clean.
The tests passed.
I moved on.

That's the part that should worry me more than whether the engineer took three days.

The engineer could've used AI on day one. For the fix itself, they probably should have. They didn't, at least not until they understood what they were looking at.

I told them as much after the fact. They nodded, then asked if they could walk me through what they'd found. They were excited about it.

We were on a call five minutes later.