The Autopilot Didn't Make Pilots Obsolete

As software engineers, we contributed an enormous amount of code to open source. Of course, LLMs got trained on it, and now that work is slowly creeping back into our workplaces. The days of handwriting every line are coming to an end.

Luckily, it isn’t foolproof. Good engineering practices still need someone watching over them, making sure the AI actually got it right.

What’s really happening is that the bar to enter this field is going up, not down. It’s the same shift aviation went through. Pilots are trained to fly planes, and then most of the flying is done by the autopilot. The training didn’t become pointless. It became the reason the pilot can tell when the autopilot is wrong, and take over when it is. Software engineering is heading to the same place.

Here’s what a pilot has to learn, and what each subject maps to in our world.

Open-source license compatibility (GPL contamination in generated code is a real hazard), data residency and GDPR/PDPA, export controls, industry regimes like PCI-DSS or HIPAA, and your org’s own policy on what may be sent to a model. An AI will happily emit code whose provenance you can’t account for. You’re the one who signs off.

Metrics, traces, logs, dashboards. Recognizing the signatures of trouble the way a pilot recognizes a squall line: latency creeping into the p99 while the median stays flat, saturation approaching a cliff, retry storms building. Forecasting load, seasonality, capacity. AI writes code that works on a clear day. You’re the one who sees the front coming.

Where you are in the system, where the request goes, what the boundaries are. Service topology, data flow, dependency graphs, consistency models. An agent can fly any single leg of the journey. Deciding the route, and noticing when you’ve drifted off it, stays with you.

How the database actually executes your query. What the garbage collector does under pressure. How TCP and TLS behave. What your orchestrator does when a node dies. How the language’s concurrency model really works. This is the deepest well and the least substitutable, because it’s what lets you predict behaviour instead of discovering it in production.

Complexity, data structures, concurrency hazards (races, deadlocks, ordering), distributed systems theory (CAP, consensus, idempotency, exactly-once being a lie). This is the equivalent of stall behaviour: knowing the regimes where systems stop behaving linearly and start falling out of the sky.

Latency budgets, throughput ceilings, memory footprint, cloud spend per request, token cost if the system itself calls models. Knowing what the aircraft can carry and where the margins are. Generated code is famously indifferent to what it costs to run at scale.

Turning requirements into a plan, with contingencies: rollout strategy, feature flags, migration paths, rollback triggers, and knowing what the alternate aerodrome is when the deploy goes wrong. The reserve-fuel discipline of always leaving room to abort has no automated substitute.

Specifications, API contracts, ADRs, incident comms, review language, and increasingly, prompting and task specification as a formal skill. Aviation phraseology exists because ambiguity kills. The same pressure applies to how you brief an agent and how you write down what a system is supposed to do. And: knowing when to declare an emergency out loud instead of quietly hoping.

This is the one that gets more important, and aviation learned it the hard way. Automation complacency. Mode confusion, meaning not knowing what the system is currently doing. Skill fade from never hand-flying. Over-trust in a plausible-looking output. Then add testing and verification as the core craft, security threat modelling, on-call fatigue, and the crew-resource-management equivalent of working with a partner who is confident, fast, and occasionally wrong in ways that look exactly like being right.

Training pilots is expensive.

I became a software engineer without any formal training. I learned everything on the way, by writing bad code and then writing better code. That path is narrowing. If the entry bar is now “can you supervise a system you didn’t write,” the cost of getting in, in time, in mentorship, in money, goes up. And it goes up most for the people who had the least to begin with.

Maybe the answer is the same one aviation reached: you don’t learn to fly alone. You learn in the right-hand seat, next to someone who already knows. Perhaps the way in is co-piloting real projects, with real supervision, long before you’re trusted to command one.

I don’t think we’ve built that seat yet. I’d like to hear from anyone who’s trying.