Fly-by-Wire

In 1988, Airbus put a flight control computer between the pilot and the wing with the A320.

Before that, flying a plane was physical. A pilot’s yoke was connected to the control surfaces through a web of steel cables and hydraulics. You moved the stick, you felt the resistance of the wind against the wings in your hands. Airbus turned the stick into a digital input device. You pulled back, the computer read your intention, checked it against flight parameters, and decided how much to move the elevators.

They built Flight Control Laws into the software to make this safe. Under Normal Law, you have full envelope protection. You can pull the stick back as hard as you want, and the flight computer calculates the maximum safe angle of attack. It gives you maximum lift without letting the wings stall. The computer shields you from your own worst mistakes.

Writing code used to feel like pulling those steel cables. You felt the friction of the system through syntax, compilation errors, memory allocations, and hand-traced call stacks.

Cursor, Copilot, and Claude Code have placed software engineering into Normal Law.

The AI generates the boilerplate, wires up the endpoints, writes the unit tests, and patches syntax bugs before you even notice them. You pull back on the stick, and the feature flies out the door. We move faster because we believe the system won't let us stall.

But aviation has a catch. If onboard sensors freeze or conflict—like when ice crystals block pitot tubes—the flight computers realize they can no longer trust their data. The system drops down to Alternate Law. The safety envelope vanishes. The stick controls the wing surfaces directly, and the plane can be stalled and crashed like a conventional aircraft.

In software, Alternate Law hits during incidents. A microservice falls over in a complex distributed system. An edge-case memory leak or a database lock contention under load breaks the mental models generated by LLMs. What do you do when the AI hallucinated the state transition? How do you debug a race condition when the LLM keeps suggesting slightly different variations of the same broken patch? Who owns the outage when no living person on the team actually wrote the diff?

In June 2009, Air France Flight 447¹ hit high-altitude Atlantic turbulence. Ice crystals froze its pitot tubes for less than a minute. The autopilot disconnected in pitch-black darkness at 38,000 feet. The crew did what Normal Law had conditioned them to do: the flying pilot pulled back on the stick. In Alternate Law, that pitched the nose up and held the wings in a deep aerodynamic stall all the way into the ocean.

When generated code fails in production, developers raised entirely in Normal Law rarely drop down to first principles. They keep prompting. They ask the AI to "fix the bug," feeding bad outputs back into the model and compounding the outage in real time. It is the engineering equivalent of pulling back on the stick during a stall warning. Reading code is inherently harder than writing it. Diagnosing an execution path generated by an agent requires a far deeper mental model of the underlying system than writing it manually ever did.

Seven months before Air France 447, US Airways Flight 1549² lost both engines to bird strikes over Manhattan. Captain Sullenberger landed the Airbus A320 on the Hudson River with zero fatalities. During the glide down, the fly-by-wire system remained in Normal Law. Sully didn't fight the abstraction layer; he understood its exact boundaries. On final water entry, he held the sidestick all the way back, letting the flight computer manage the exact edge of aerodynamic lift while he focused entirely on trajectory and water impact.

The aviation industry didn't respond to Air France 447 by ripping out fly-by-wire computers and returning to steel cables. Flight envelope protection makes flying safer and more efficient. Instead, they realized that spending thousands of hours supervising an autopilot under Normal Law does not train a pilot for the moment sensors freeze. They introduced mandatory simulator training specifically for Alternate Law degradation.

If writing syntax is automated, typing out boilerplate can no longer be how engineers build their core system intuition. We have to replace those lost reps intentionally. We need mandatory chaos engineering days, zero-AI debugging sessions on legacy codebases, and in-depth post-mortems. Defining explicit service and ownership boundaries are the guardrails that keep the AI operating safely.

Managing AI agents forces you into a weird, middle-management role almost immediately. You end up spending less time writing syntax and far more time reviewing diffs written by agents who work at infinite speed but have minimal context on your business. You are doing task decomposition, spec writing, continuous review, and quality control. Management skills require judgment, and judgment historically came from years of manual execution. Learning to manage agents effectively requires developing "taste" before you've spent the years writing boilerplate that used to build it.

Sully didn't survive the Hudson because he hated Airbus's software, nor because he trusted it blindly. He knew exactly where the computer stopped and where he had to take over.