AI Is Flying the Plane. When Did You Last Take the Controls?

The While Loop Moment

I was doing a code review recently. A few hundred lines, just another PR, nothing out of the ordinary.

Then I hit a while loop with a continue statement inside it.

I paused. I had to trace the logic in my head before I felt confident enough to move forward. The kind of code I wrote on autopilot in university, in gamedev, in any project that wasn’t modern frontend.

It took me a moment longer than it should have. (In my defense, frontend code hasn’t needed much of a while loop since IE6.)

I’ve been writing code for over 10 years. I have a computer science degree. That loop still made me pause.

That’s a problem worth thinking about.

Autopilot Is Great. Until It Isn’t

I use GitHub Copilot every day. As a team lead, I rarely get uninterrupted hours to sit and code and Copilot genuinely changes what’s possible in the gaps. I pick up a Jira task, iterate to get a working version, then go through it manually and make it mine. Without that tool, I’d be far less technical than I am today. I’m not here to tell you to stop using it.

But there’s a tax we pay without noticing. Call it coding skill atrophy: the cognitive muscles we’re not using stop responding as quickly as they used to. Copilot writes the loop; we read it, nod, move on. Over months and years of doing that, the gap between “reading code” and “writing code from scratch” grows wider than you’d expect.

The output still looks fine. Our velocity is up. Our PRs ship. The erosion is invisible, right up until you’re in a code review, staring at a while loop, and realizing you need a second to think.

This isn’t a criticism of AI tools. It’s just how skills work. Use a muscle and it stays sharp. Park it for two years and it gets stiff. That’s not a moral failing; it’s biology. A 2025 analysis in Communications of the ACM calls it the deskilling paradox: short-term efficiency gains may hollow out deeper expertise without anyone noticing.

The Pilot Analogy

Commercial pilots fly on autopilot for the vast majority of every flight. Nobody in aviation considers this a problem. Autopilot is more precise than a human on a long cruise, less fatigued, and statistically safer on routine segments.

But airlines and regulators still require pilots to maintain manual flying proficiency through recurrent training and periodic checks. The reasoning is straightforward: when something goes wrong (unexpected weather, a system failure, an unusual approach) the pilot needs to take the controls and handle it. Immediately and correctly. There’s no time to recall how it works in theory.

The parallel to software development is almost too clean to be useful, but here it is anyway.

Copilot is the autopilot. We’re the pilots. It handles the repetitive, predictable work well. But production bugs don’t wait while we dust off our memory of basic control flow. A tricky Safari rendering issue, a subtle race condition, a performance regression nobody can explain: all of those require someone who can actually read and reason about the code, not just prompt their way toward a fix.

Nobody in aviation asks “is autopilot making pilots worse?” They just make sure pilots stay sharp regardless. That’s the conversation I think we should be having about AI coding tools. Macnamara et al.’s 2024 study on AI-induced skill decay takes the aviation comparison further: AI assistants likely cause more cognitive skill decay than traditional automation, because they offload the cognitively demanding work, not just the mechanical parts.

Debugging Code That Isn’t Yours

A while back I was building a feature for a side project. Nothing serious, just something cool I wanted for my own use, so I wasn’t being particularly rigorous. I let Copilot drive, accepted suggestions without reading too carefully, and hit a mobile Safari bug somewhere in the generated code.

Since I was already in “just make it work” mode, I kept that approach: describe the bug to Copilot, apply the fix, test, find it still broken, repeat. I spent a surprising amount of time in that loop.

The irony is that diving into the code manually would have been faster. But because I hadn’t written it, I had no mental model to start from. I didn’t know which part was doing what, or why. I was searching in the dark.

That’s the hidden cost of vibe coding. You can skip the understanding phase when things work. When they don’t, you pay it back with interest.

Schedule Your Manual Hours

The wrong response to all of this is to feel guilty every time you accept a Copilot suggestion. That’s not sustainable and it misses the point. Use the tool on real work.

The right response is to treat manual coding practice as something you schedule separately, away from shipping pressure. Pilots don’t practice emergency landings on a flight full of passengers. They do it in a simulator, on a schedule, when the stakes are low. That assumes you have protected time to schedule in the first place — keeping focus blocks clear is the prerequisite.

In practice, that means setting aside 30 minutes to an hour once or twice a week for exercises that work the actual thinking muscles: algorithm problems, tree traversal, boolean logic, complexity analysis. Not writing boilerplate by hand (that’s just tedious). The goal is to keep the reasoning sharp, not to prove you can type without autocomplete.

A few resources worth knowing:

• Advent of Code — annual challenge, great variety of problems
• Codewars — ranked kata-style exercises you can dip into anytime
• CSSBattle — if you’re frontend-focused, this is a good way to keep CSS fundamentals honest
• awesome-katas — a curated list of practice collections if you want more variety

This post is a reminder for myself to actually treat those exercises seriously. Crosswords don’t make you a better writer, but they keep the brain from going soft. Same idea.

The Minimum Bar: Understand What You Push

Deliberate practice is the long game. But there’s a shorter-term standard that applies right now, on every PR: understand the code you’re pushing.

As long as teams review each other’s work (and most still do), every line in a git commit should make sense to the person committing it. Not “Copilot generated it and it looks plausible” but actually understood. What it does, why it’s structured that way, what would break if you changed it.

There’s a simple professional argument here too. If you expect your teammates to review your code, the least you can do is read it yourself first. Sending a PR full of code you haven’t looked at is asking others to do work you skipped. Code reviewers can tell, and it slows everyone down.

Beyond reviews, there’s a practical angle too. Code you understand well enough to explain is easier to debug, easier to hand off, and easier to revisit when requirements change. That’s true whether you wrote it yourself or guided an AI to write it. The inverse is also true: code nobody fully understands becomes a knowledge silo problem, one PR at a time.

Stay a Software Engineer

None of this is an argument against AI tools. Use them. They’re genuinely effective and only getting better.

The engineers who still invest in their fundamentals on purpose have an advantage. When something breaks in a way the AI can’t explain (a bug in generated code nobody fully understands, a postmortem asking “who owns this logic?”), you want to be the person with an answer.

Scheduling some manual practice and understanding the code you ship doesn’t conflict with using Copilot on everything else. It’s skill maintenance.

Would you board a plane flown by a pilot who hasn’t touched the controls in two years because the autopilot handles it?

If you want more systems for staying sharp as an engineering lead, the newsletter is where I share them.