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. The senior who built it was gone. The documentation was sparse. The code made sense only if you'd been in the room when the decisions got 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 just 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 it. I had a deadline breathing down my neck and a fix I could've written before lunch. That three-day tax on understanding used to be everywhere in engineering. It still is, but it's getting scarcer, and we're very proud of that.
The logic is tempting, too. Why spend three days when AI could spend three minutes? Why force junior engineers through the pain of understanding when they could generate a fix instantly? Why not move faster?
What actually gets lost in that acceleration is the discipline of caring how your system works. Not conceptually. Not in a post-mortem six months later. Right now, while you're building it. When you have to look your code in the face and think about what it's asking of the next person who touches it, something shifts.
That engineer learned something in those three days that would've taken years of smaller mistakes to understand otherwise. They learned that systems have shapes, that those shapes have reasons, and that understanding the reason is the actual work. That's not a soft skill. That's the thing that separates someone who can patch code from someone who can steward it.
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 actually doing something to them.
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.
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.
Now? Now you can spin up a system in an afternoon that would've taken weeks, and it'll be held together with prompt engineering and middleware and a lot of hoping nothing breaks in production. Not because you're lazy, but 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. The point isn't whether the tool is available. It's what happens when you stop treating friction as something to overcome and start treating it as information. Sit with it instead of automating past it, and you learn something about the problem that no prompt could've given you.
The people who'll actually build things that last won't be the ones who move fastest. They'll be the ones who hear "I would have rewritten it" and need to understand why before they agree. Who still believe understanding is a prerequisite to building. Who stay in it until they know what they're looking at.
AI didn't create this moment. It just made the choice visible. You can move fast and hollow, or you can move with discipline. You just can't hide from which one you're choosing anymore.
Top comments (0)