People have spent years now trying to figure out how to get AI to do their software engineering work. It's been fascinating to watch, mostly because I'm fairly sure the answer has been sitting in plain sight for decades. The aviation industry has been dealing with automation of some of their jobs for over a century. So instead of solving the problem all over again, consider this: software engineers should be like airline pilots.

On a typical multi-hour route human pilots hand-fly the aircraft for maybe a few minutes. Takeoff, a bit of the climb, and perhaps the last stretch of the landing. Everything in between is flown by automation, while two highly trained professionals watch it work, refilling their coffee, and, from time to time, press a button that amounts to "yes, carry on". 

No one boards a plane demanding the captain disconnect the flight computer. Automation flies more precisely than any human, and it doesn't need to nap over the Pacific. And yet, regularly, those same pilots get buckled into a very expensive box on hydraulics: the flight simulator. In this fake plane they fly for real, automation off. Engine fire, hydraulic failure, unreliable airspeed, power loss at night in a lightning storm. Intense stuff.

That's what aviation understood and software engineering still hasn't: skills you don't use decay, and they decay quietly. Meanwhile, on software teams everywhere, engineers have just been handed an autopilot and are arguing about it like we asked them to choose tabs or spaces.

In 1914, when most American homes had neither electricity nor indoor plumbing, Lawrence Sperry took his father's invention, the gyrocompass, and developed the gyroscopic stabilizer. In a demonstration in Paris, his automation kept the aircraft level and on course while he stood up in the cockpit with his hands in the air. Automated flight is nearly as old as flight itself.

From there, automation only got better. A US military C-54 crossed the Atlantic under automatic control in 1947 and made the news. Automatic landing entered passenger service in the 1960s, and in the late 1980s the Airbus A320 brought digital fly-by-wire to airliners. Simulators took over pilot training, but for decades US airline training asked for little hand flying beyond the check-ride basics. The automation was good, so manual flying quietly faded from daily life.

Then came 2009, and two crashes that changed the conversation. In February, Colgan Air Flight 3407 went down after the crew responded to a stall warning by doing the opposite of what it called for. In June, Air France 447 was lost over the Atlantic after ice blocked its airspeed sensors, the autopilot disconnected, and the crew, suddenly hand-flying at cruise altitude, could not make sense of what the aircraft was doing. Both investigations pointed at a serious issue: pilots lacking training and so reliant on automation that their manual skills and instincts had eroded.

The response went from advice to law, which is how you know regulators were serious. Nobody writes a federal rule for things that are going fine. In early 2013 the FAA issued a safety alert urging airlines to promote manual flight operations. Later that year, following a congressional mandate, a new training rule required airline pilots to practice stall recovery, upset recovery and more. Today every US airline pilot on every aircraft type trains regularly, on slow flight, loss of reliable airspeed, and more.

Software is now replaying this history, minus the regulators. On one side are people who still refuse AI tools entirely. Real engineers write every character by hand, they say. These are the folks who would fly the Atlantic by sextant. They're right that skills matter. They’re wrong that refusing the tool is how you keep them.

On the other side, a growing crowd hasn't typed an if statement in months. They describe what they want, something appears, the tests go green, they ship it. The tests were also written by AI. It's a very supportive environment. Now ask them how it works and you get the look a passenger gives when you ask how the plane stays up: confident, warm, and completely empty.

Their favorite defense: nobody hand-writes assembly anymore either. True, but nobody maintains assembly either. Compiler output is a layer you never have to look at. You don't review it, you don't extend it, and you don't get paged for it. When something breaks, you fix your source code, and the compiler faithfully translates the fix. AI output is different: it is your source code. It's the layer you'll read during the outage, refactor next quarter, and explain to the new hire. A compiler is an abstraction you can safely forget. Generated code is the thing you live in.

Both camps are wrong in the same way. They're treating the question as "autopilot: yes or no?" Aviation figured out that this was never the question. The question is "autopilot: yes, obviously, and what are you doing to stay a pilot?”

AI-assisted coding is good. It is good the way autopilot is good. It removes an enormous amount of tedium, it holds altitude better than you do, and it frees your attention for the parts of the job that actually need a human: What should we build? Is the code structured right? Will my future self be able to understand and change this? What happens when it breaks? Who gets paged at 2 a.m., and will they be able to do something about it?

Here is where the analogy gets uncomfortable. When an autopilot gives up, it usually does so loudly: alarms sound, the screens turn amber, and the pilot knows it's their airplane now. But the accidents that taught aviation the most were the quiet ones. In 2013, Asiana 214 hit the seawall at San Francisco on a clear day. The autothrottle had slipped into a mode that wasn’t holding speed, and the crew didn’t catch it until it was too late to save by hand. The alarm came, but only after the moment to save it by hand had passed. For most of the approach, the automation was quietly doing something other than what the crew assumed.

AI-generated code fails like Asiana. It fails silently, confidently, and with excellent variable names. Your AF447 moment is the 2 a.m. production incident where the generated code is doing something subtly wrong and you have to actually read it, understand it, and fix it under pressure. Or it's the moment the tool confidently refactors half a module and only your own judgment can tell you whether the result is still correct.

There's no alarm for that. The only warning system is a human who still knows what correct looks like.

Aviation has a useful division of labor. On every flight, one pilot is the pilot flying: responsible for the aircraft's path, even when the autopilot is doing the work. The other is the pilot monitoring: watching the instruments, cross-checking, and calling out anything that looks wrong.

In AI-assisted software, more often than not, the engineer is both. You are the pilot flying, accountable for what ships, the one who will be asked afterward why you let the computer do that. And far too often you are also the pilot monitoring, which in the software world mostly means code review: carefully reading what the machine produced, then typing "LGTM" on a 900-line diff four minutes later.

Aviation's answer is to put two people in the cockpit. Software can borrow that cheaply. The person who prompted the code shouldn't be its only reviewer, and the reviewer should be able to explain the change back without opening the chat log.

The trouble is that monitoring is exactly the skill that decays fastest. You can't judge code you can no longer read closely.

Anyone whose management strategy is to ban the tools has confused suffering with skill, and they’re going to lose their best people to the company down the street that didn't. But anyone who thinks "AI understands this, so I don't need to" has made the opposite mistake. They've confused the autopilot's competence with their own. A pilot who hasn't hand-flown an approach in a year doesn't feel rusty. They feel fine. They feel fine right up until the day the automation drops out and their hands don't remember what to do.

The industry has a name for this: automation complacency. That's why regulators stopped treating manual flying as optional. It became mandated, scheduled and checked. Nobody gets to decide they're too senior for the simulator.

Engineers should have simulator time. Regular, deliberate, slightly uncomfortable practice with the autopilot off. Not as punishment, not as a purity test. As the practice that keeps you qualified to supervise the machine.

There's an important bonus here, too. Aviation doesn't only use the simulator to keep veterans sharp; it's where new pilots learn. Airline pilots often earn their rating on a new aircraft type without ever flying the real one until their first revenue flight, with a training captain in the other seat. The same exercises could be a sustainable way to grow new engineers, who otherwise risk learning to supervise an autopilot before they ever learned to fly.

What that looks like is up for grabs, and it should be. There's no universal syllabus: a startup racing to ship won't look like a bank, and a team of seniors won't need what a team of new grads does. But to make it less abstract, let me throw out some numbers that you can start taking apart:

How often? For what types of tasks? Your mileage may vary. Which is exactly why this deserves a real debate: how, and how much, should we keep practicing?

Whatever the answer, it probably has to be structural, not personal. Pilots don't do simulator time because they're diligent. They do it because it's in the rules, on the calendar, and someone checks. Left to individual discipline, everyone means to practice and nobody does, because the autopilot is right there and it's so very good. Teams that want engineers who can still fly may need to put it on the schedule and defend it against the sprint.

That's a hard sell without a regulator, so sell it on what managers already pay for: the on-call engineer who can actually fix the 2 a.m. outage, the reviewer who catches the bad migration, the junior who grows into a senior rather than a prompt operator. A no-assist day costs real capacity. So does an outage nobody can debug. And if you work in finance, healthcare, or infrastructure, you may have a regulator after all.

Someone is always the pilot flying, and they're the one who will be asked, afterward, why they let the computer do that. That is the job now. Being the one in the left seat, using every bit of automation available, and still being the one who can take the airplane back, by hand, when it matters. You get there by letting the autopilot fly most of the time, and by flying yourself some of the time, on purpose, when nothing is on fire.

Use the autopilot. Book the simulator. Keep your hands on the stick.