A software engineer's question posted to Reddit's r/flying community cuts directly to one of the most consequential ongoing debates in professional aviation: whether decades of increasingly capable automation have systematically eroded the manual flying proficiency that remains essential when systems fail or behave unexpectedly. The post draws an explicit parallel between AI-assisted software development creating passive, skill-atrophied engineers and Flight Management Systems producing pilots who struggle to intervene effectively during automation anomalies. The analogy, while imperfect in its specifics, identifies a phenomenon that aviation safety researchers, regulatory bodies, and operators have been grappling with in earnest since at least the 1990s — and which has accelerated in urgency as glass-cockpit, fly-by-wire aircraft have become the dominant platform across commercial, regional, and business aviation.
The aviation industry's institutional response to automation-induced skill degradation is multifaceted and regulatory in nature. The FAA mandates recurrent training and proficiency checks for Part 121, 135, and many Part 91K operations, with Airline Transport Pilot certificate holders required to demonstrate manual flight competency including raw-data instrument approaches, unusual attitude recoveries, and engine-out procedures in full-motion simulators. More specifically, FAA AC 120-111, issued in 2016, directly addresses Automation Management and urges operators to establish policies requiring pilots to hand-fly portions of routine flights — particularly during climb and descent — as a deliberate counter to over-reliance on FMS and autopilot systems. Many major carriers and flight departments have since codified minimum hand-flying requirements into their Standard Operating Procedures, with some operators specifying that autopilot engagement below a certain altitude threshold requires specific conditions or captain authorization.
The human factors research underlying these policies is extensive and sobering. The accidents most frequently cited in automation complacency discussions — Air France 447 in 2009, Asiana 214 in 2013, and Colgan Air 3407 in 2009 — each involved flight crews who demonstrated degraded manual flying skills at critical moments following automation mode changes or unexpected system behavior. AF447 in particular became a defining case study: when the autopilot disconnected due to pitot tube icing, the crew's response revealed a fundamental misunderstanding of the aircraft's energy state and control laws, resulting in a sustained aerodynamic stall that went unrecognized until impact. The concept of "automation surprise" that the Reddit poster describes from software engineering maps almost precisely onto what accident investigators termed "mode confusion" — a state in which pilots are uncertain what the automation is currently doing, why it is doing it, and what it will do next. Staying "ahead of the aircraft," as the poster phrases it, is addressed in Crew Resource Management training through mental model building, explicit mode awareness callouts, and practiced decision-making under time pressure.
For Part 91 and 135 business aviation operators specifically, the automation management challenge carries particular weight because crews are often two-pilot or even single-pilot operations without the institutional training infrastructure of a major airline. A corporate pilot flying a Gulfstream G650 or Bombardier Global 7500 operates systems of comparable sophistication to those found on wide-body airliners, yet may fly significantly fewer hours annually, spend more time in cruise with automation fully engaged, and conduct fewer approaches in challenging conditions than a line carrier pilot. The practical mitigation strategies used by experienced business aviation professionals include deliberately hand-flying approaches in VMC when traffic and ATC workload permit, periodically flying raw-data ILS approaches without flight director guidance, briefing automation mode selections explicitly before execution, and using simulator recurrency sessions not merely to meet the letter of regulatory requirements but to practice scenario-based automation failures in high-workload environments.
The broader trend connecting the software engineer's observation to aviation's long experience is that as automation becomes more capable and reliable, the psychological and institutional pressure to rely on it exclusively intensifies — while the marginal cost of each individual deviation from manual practice compounds invisibly over time. Aviation's partial solution has been to treat manual flying proficiency as a perishable skill requiring deliberate, structured maintenance rather than a baseline competency that persists passively. Regulatory requirements create a minimum floor, but operators and individual pilots who treat that floor as the ceiling routinely produce crews less prepared than the checkride paperwork implies. The software engineering community's emerging conversation about AI-induced skill atrophy suggests the same lesson may need to be institutionalized across any domain where capable automation is introduced: monitoring a system and operating it are not equivalent competencies, and proficiency at the latter requires consistent, intentional practice that the presence of the former tends to discourage.