The system went down. One leader opened Slack. The other opened the logs. Same title. Same years of experience. Same team size. The difference was proximity to the system they were responsible for.
I try to avoid writing code from scratch now.
I need to sit with that sentence for a moment because it still doesn't feel true, even though I've been living inside it for months. There was a time when I would stay up endless nights losing myself in the thinking of writing code. Not shipping. Not hitting deadlines. Just the pure absorption of building something from nothing, watching it take shape, debugging until the logic finally yielded. It was something I loved.
That's not where my attention goes anymore. All of it has shifted to optimizing AI or reviewing AI or shipping AI. I've trained a completely new muscle. And when I go back to the old one ... when I actually sit down to write code from scratch without tooling assistance ... I feel it immediately. The retrieval cost has gone up. Syntax I used to have at my fingertips. Patterns I implemented dozens of times. The knowledge is still there, but the fluency is gone. Like a language you used to dream in that now requires translation.
I try to avoid writing code from scratch now. I need to sit with that sentence for a moment because it still doesn't feel true, even though I've been living inside it for months.
The Question I Don't Have an Answer For
The question I keep circling back to is whether this is okay. Maybe it is. Maybe we're evolving. Maybe the world is changing at a pace that demands our worldviews change with it, and all the cultural scaffolding we've built around what engineering is ... and what it was ... is simply updating to match the new reality. The skills that got you riding a horse aren't the skills you need to fly a plane. That metaphor feels close but not quite right. Planes still require understanding aerodynamics. You can't fly on vibes alone.
The Retreat Doesn't Announce Itself
There was a period a few years ago where I realized my one-on-ones had turned into status reports. I was nodding through technical explanations without fully following the thread. Not because my team was poor communicators. Because I had drifted. The retreat from technical work doesn't announce itself. It happens in the margins of a calendar that keeps filling with meetings you believe are essential. You tell yourself you're staying close to the work because you're reviewing architecture documents and attending sprint planning. But architecture documents are not systems. Planning is not debugging. You can be present in every technical conversation and absent from the craft that makes the conversation meaningful.
The Bug That Wasn't the Point
A bug came in last month. Production issue affecting customer checkouts. The kind of ticket that normally routes to production support, enters a queue, gets triaged by someone three time zones away, and eventually resolves in a few days with a patch that addresses the symptom without anyone understanding the cause. I've seen that movie. I've written that script.
This time I dove in. Checked the logs. Found a data issue in how we were handling inventory holds during high-traffic events. Fixed the customer experience in thirty minutes.
The fix wasn't the point. I mean, the fix mattered to the customers who could complete their purchases, but the thirty minutes wasn't the win. The win was that I now understand a failure mode in our system I wouldn't have known about otherwise. A race condition between two services I thought were properly decoupled. A timing assumption that held up under normal load but collapsed when traffic spiked. Next time my team proposes an architecture change that touches that area, I'll ask the right question. Not because I read about it in a status report. Because I saw it break.
The Instinct That Was Gone
A senior engineer I know spent years building real production systems. The kind of systems that handle actual money and actual users and actual consequences when they fail. He was good. Deeply technical, respected by his peers, the person you wanted in the room when something was on fire. Then he switched to mostly directing AI agents. Reviewing, approving, orchestrating. The workflow looked productive. PRs were moving. Features were shipping. The metrics looked fine.
A few months later a production memory issue surfaced and he reached for the debug instinct that used to be automatic. It was gone. Not rusty. Not needing a moment to warm up. Gone. He described it like watching someone try to speak a language they'd been fluent in as a child, knowing the shape of the words but unable to summon the actual sounds.
Skills decay when you stop exercising them. Judgment decays faster.
Skills decay when you stop exercising them. Judgment decays faster.
What the Dashboard Won't Capture
The question I'm actually wrestling with isn't whether AI is making engineers worse. It's whether the role is changing in a way that makes certain skills optional until suddenly they're not. You can drive velocity and ship features and hit milestones while the foundation erodes underneath. You can look productive for a surprisingly long time before the gap becomes visible.
Your dashboard won't capture it. You can track AI credit usage and PR throughput and deployment frequency and watch all those numbers climb while the thing that actually matters hollows out. The engineers who spend their days prompting and reviewing without ever sitting with a hard problem until it yields. The leaders who can discuss system architecture in a conference room but flinch when asked to actually trace a failure through the logs. The drift is survivable in a normal engineering environment. It's survivable for a long time. Until the moment you need the instinct and it's not there.
The Signals I Watch For
I watch for specific signals now. When my one-on-ones start feeling like status reports instead of conversations. When I catch myself nodding along to a technical explanation I don't actually understand. When I realize it's been weeks since something in the codebase surprised me. When I try to avoid writing code from scratch because I know how it will feel. Those aren't neutral observations. They're warnings.
When I try to avoid writing code from scratch because I know how it will feel. Those aren't neutral observations. They're warnings.
The leader who opened Slack when the system went down wasn't wrong to coordinate the response. Someone has to. But coordination is different from comprehension. You can manage an incident without understanding the system that's failing. You can lead a team of engineers without remembering what it feels like to ship code that breaks in production and fix it before anyone notices. You can hold the title and occupy the chair and collect the salary without maintaining the proximity that makes the title meaningful.
I still read pull requests. Not to approve syntax ... my team doesn't need me checking their semicolons ... but to understand how they solve problems. To see whether their decisions connect across teams and regions. To stay close enough to the system that I can feel it when it surprises me. That's not micromanagement. That's maintaining the thread.
Rebuilding What You Once Had
The engineer who lost his debug instinct after months of AI orchestration is trying to rebuild it now. He's blocking time to work through hard problems without tooling assistance. Sitting with errors until he understands them instead of prompting his way around them. It's uncomfortable work. Rebuilding something you once had is harder than maintaining it would have been. The body remembers the shape of the skill but not the feel of it. Muscle memory without muscles.
Staying technical as a leader isn't about proving you can still code. It's about maintaining the judgment that comes from having been in the system when it broke. From knowing what a failure mode looks like before it becomes an incident. From asking the right question in an architecture review not because you read a case study about it but because you saw it fail last month and traced it through the logs yourself.
The system will go down again. It always does. The question is whether you'll understand what you're looking at when you open the logs, or whether you'll be coordinating a response to a failure you can no longer comprehend.
Maybe we're evolving. Maybe the airplane doesn't need the same skills as the horse. But someone in the cockpit still needs to understand why the plane stays in the air. Someone still needs to know what to do when it doesn't.
One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.