“Automation can lower the workload in some cases. But in other situations, using automation when it is not appropriate can increase one’s workload. A pilot has to know how to use a level of automation that is appropriate... Whether you’re flying by hand or using technology to help, you’re ultimately flying the airplane with your mind by developing and maintaining an accurate real-time mental model of your reality—the airplane, the environment, and the situation. The question is: How many different levels of technology do you want to place between your brain and the control surfaces?“[0]
—Sully Sullenberger
[0] Sully: My Search for What Really Matters. p. 188
I‘d say the same holds true for other use cases and should not only target vibe coders. Eg self driving cars. Level 2 is fine and level 5 is good, it‘s in between these two where I‘m afraid of as people are distracted enough and not able enough to gather what‘s happening around them to react in every situation.
We already have advanced autopilots that can fly commercial airliners. We just don't trust them enough to not have human pilots. I would trust the autopilot more than freaking Claude. We already do, every day.
yeah, I think GP misunderstood the nature of a thing like this. It's what hackers do, we play with things. Nobody is suggesting we replace the pilots in real planes with claude, certainly not OP
I think we can trust them to not have human pilots. It is just that having human in loop is very useful in not that rare scenarios. Say airfield has too much wind or fog or another plane has crashed on all runways... Someone needs to make decision what to do next. Or when there is some system failure not thought about.
And well if they are there they might as well fly for practise.
And no. I would not allow LLM in to the loop of making any decision involving actual flying part.
There's also the issue that when something goes wrong, many people will never trust an autopilot again. Just look at how people have reacted to a Waymo running over a cat in a scenario where most humans would have made the same error. There's now many people calling for self-driving cars to never be allowed on roads and citing that one incident.
> We just don't trust them enough to not have human pilots.
Much of the value of a human crew is as an implicit dogfooding warranty for the passengers. If it wasn't safe to fly, the pilots wouldn't risk it day after day.
To think of it, it'd be nice if they posted anonymized third-party psych evaluations of the cockpit crew on the wall by the restrooms. The cabin crew would probably appreciate that too.
There are soooo many pilot decisions that AI is nowhere near making. Managing a flight is more than flying. It is about making safety decisions during crisis, from deciding when to abort an approach to deciding when to eject a passenger. Sure, someone on the ground could make many of those decisions, but i prefer such things be decided by someone with literal skin in the game, not a beancounter or lawyer in an office
> It is about making safety decisions during crisis, from deciding when to abort an approach to deciding when to eject a passenger.
Everyone likes to hand wring about this sort of stuff but I think it's the exception. Nailing the "macro level" decisions like "we'll go around this storm but we'll go over that one" or "we must divert to A or B and we will chose B because it's better for our passengers/company/crew even if it's 10min more flying to get there" are what keep the industry humming along mostly in the black rather than in the red. And it's these sorts of things that AI just tends to yolo and get mostly right when they're obvious but also get immensely wrong when any sort of gotcha materializes.
I sincerely doubt that pilots decide "when to eject a passenger". Mostly it would be the cabin crew: the flight attendants are 100% in charge of flight safety, and they would be managing relationships with passengers, and they would be the ones to make the call. It would ultimately be them calling some kind of law enforcement. If an Air Marshal is onboard already, obviously they would be on the front line as well.
Furthermore, the concept of "ejecting a passenger" from a flight would mostly not be something you do while in the air, unless you're nuts. Ejecting a passenger is either done before takeoff, or your crew decides to divert the flight, or continue to the destination and have law enforcement waiting on the tarmac.
Naturally, pilots get involved when it's a question of where to fly the plane and when to divert, but ultimately the cabin crew is also involved in those decisions about problem passengers.
The Pilot in Command has ultimate legal responsibility over the operation of the flight, ICAO conventions explicitly state this. Whilst in practice the cabin crew will be the ones dealing with the passenger(s) and supplying information to the PIC , it won’t be them making the final decision.
Pretty sure ejection here is meant as shorthand for "Transfer the passenger to an entity on the ground to proceed from there" whether that entity is emergency medical services or law enforcement is secondary.
It absolutely can; it's called autoland[1]. In really bad visibility, pilots simply can't see the runway until too late, and most aerodromes which expect these conditions have some sort of autoland system installed. The most advanced ones will control every aspect of the plane from top-of-descent (TOD), flaps and throttle configuration, long and short final, gear down, flare, reverse thrust, and roll-out, all the way to a full stop on the runway. Zero pilot input needed.
And most of this was already available in the late 1970s. We have absolutely no need for LLM-based AI in aviation; traditional automation techniques have proven extremely powerful given how restricted the human domain of aviation already is.
Autopilots can. Both on airliners and small planes, although only landing on the latter as far as I know and it's only meant for emergencies. Airbus ATTOL is probably the most interesting of these in that it's visual rather than ILS (note that no commercial airliners are using this).
>never mind that most crashes are caused by humans, very rarely by technical issues going amok
Because humans are the fallback for all the scenarios that the tech cannot reliably cover. And my intuition says that the tech around planes is so heavily audited that only things that work with 99.999...% accuracy work will be left to tech.
Still those technological issues do happen, and in those situations it's good to have a human pilot in control. See for example Qantas Flight 72 - the autopilot thought aircraft was stalling, and sent the plane into a dive. It could have ended up very badly without human supervision.
That's so incredibly reductive, that I'd go ahead and call it plain wrong.
"Caused by a human" is the lowest tier, first base human instinct analysis of any accident, and as such, unless proven otherwise, can be discarded out of hand.
It comes down to: if a human mistake is capable of causing an accident, your system is badly designed because it assumes a part of the system known to be unreliable (a human) is always reliable.
The whole trick is designing systems that are safe despite humans being in the loop. Then you get to benefit from the advantages humans bring over machines without suffering the downsides.
The question of 'can it fly' is clearly a 'yes, given a little bit of effort'. Flying isn't hard, autopilots have been around a long time. It is recognizing and dealing with things you didn't anticipate that is hard. I think it is more interesting to have 99% of flying done with automated systems but have an LLM focus on recognizing unanticipated situations and recovering or mitigating them.
>I think it is more interesting to have 99% of flying done with automated systems but have an LLM focus on recognizing unanticipated situations and recovering or mitigating them.
Seeing how Claude (or any current LLM) perform in even the most low-stake coding scenario I dont think I would ever set foot on a plane where the 1% of most risky scenarios are decided by one.
General LLMs I would say are uniquely bad at this sort of thing.
I mean if you have a stable plane, then it'll do alright, as it'll mostly fly straight and level (assuming correct trim) reacting to turbulence however, the sampling rate would probably too slow, so you'd end up with oscillations.
For recognising that you're in a shit situation, yeah, it'll probably do that fine, but won't be able to give the correct control inputs at the right time.
>For recognising that you're in a shit situation, yeah, it'll probably do that fine, but won't be able to give the correct control inputs at the right time.
Even that im not sure of, I know relatively little about aviation safety but I can imagine that there are all kinds of 0.0000000001% percent corner cases that no plane has ever encountered that still need some sort of reaction, who knows how easy an llm can distinguish those from the 0.000000001% corner cases that no plane has ever encountered that are completely fine and can be ignored.
I agree with your intuition, There are lots of corner cases, but there are also a fucktonne of checklists: https://www.aviationhunt.com/boeing-737-normal-checklists/ (this is just a small "normal" one) but for loads of situations there are check lists, thats something the LLM can probably do very well.
However its as far as I know the check list volume scales with how "airline-y" the plane is. so for a one seater, the checklist is small and only handles a few things. For a 777 its a binder.
That sounds like a solution looking for a problem though, i see plenty of arguments against throwing critical safety information that are in charge of peoples lives into an LLM "just in case the result is better than the result that the current battle-hardened systems already provide"
To properly test an LLM based emergency system against the current as-is system there needs to be a way of verifying whether the LLM detected emergency is classed as an emergency as-is. If this information was available publicaly it could enable bad actors things like stress-testing the EMP-tolerance of the current systems or what level of malware infiltration is detected.
The bit in the middle where it decides to make its control loop be pure P(roportional), presumably dropping the I and D parts, is interesting to me. Seems like a poor choice.
I try to fly about once a week, I’ve never really tried to self analyze what my inputs are for what I do. My hunch is that there’s quite a bit of I(ntegral) damping I do to avoid over correcting, but also quite a bit of D(erivative) adjustments I do, especially on approach, in order to “skate to the puck”. Density going to have to take it up with some flight buddies. OR maybe those with drone software control loop experience can weigh in?
In some circumstances, yes (usually when the system itself acts as an integrator somehow). Aircraft controls do not strike me as a system where this is sensible (trimming an aircraft is basically an integral control process).
(d'oh, should have read the specific context: in the case mentioned, it is where the system acts as an integrator (pitch -> altitude), and so pure P control is pretty reasonable)
> CRASHED #2, different cause. Plane was stable in a slow descent but between fly.py invocations (~20 sec gap while I logged and computed the next maneuver) there was no active controller. Plane kept descending under its last commanded controls until it hit terrain at 26 ft MSL, 1.7 nm short of the runway. Lesson: never leave the controller idle in flight
"Can I Get Claude to Fly A Plane" isn't the same thing. Interesting though, would be a good test for different models but it relies on the test harness being good enough that a human could also use the same info to achieve the required outcome. e.g. if latency of input/output is too slow then nobody could do it.
Claude uses the wrong modality to be a piloting model. Latency is critical, and outputting tokens in the hope they take the action at the right time is kinda bonkers.
You'd want all the data from the plane to be input neurons, and all the actions to be output neurons.
AI being able to quickly react to real time video input is the next thing. Computer use right now is painfully slow working off a slow screenshot/command loop.
Surely at least part of the issue here is that even an LLM operates in two digit tokens per second, not to mention extra tokens for "thinking/reasoning" mode, while a real autopilot probably has response times in tens of milliseconds. Plus the network latency vs a local LLM.
> main issue seemed to be delay from what it saw with screenshots and api data and changing course.
This is where I think Taalas-style hardware AI may dominate in the future, especially for vehicle/plane autopilot, even it can't update weights. But determinism is actually a good thing.
This is a limitation of LLM i/o which historically is a bit slow due to these sequential user vs assistant chat prompt formats they still train on. But in principle nothing stops you from feeding/retrieving realtime full duplex input/output from a transformer architecture. It will just get slower as you scale to billions or even trillions of parameters, to the point where running it in the cloud might offer faster end-to-end actions than running it locally. What I could imagine is a small local model running everyday tasks and a big remote model tuning in for messy situations where a remote human might have to take over otherwise.
As most others have pointed out, the goal from here wouldn't be to craft a custom harness so that Claude could technically fly a plane 100x worse than specialist autopilots. Instead, what would be more interesting is if Claude's executive control, response latency, and visual processing capabilities were improved in a task-agnostic way so that as an emergent property Claude became able to fly a plane.
It would still be better just to let autopilots do the work, because the point of the exercise isn't improved avionics. But it would be an honestly posed challenge for LLMs.
Besides the article, I think a big issue for this would be the speed of the input-decision-act loop as it should be pretty fast and Claude would introduce a lot of latency in it.
Give the whole scheme some sort of mile multiplier and you will get high-freq fliers salivating over taking a llm flight with a 12 hour layover in Iceland to get to Portland from New York for those sweet miles.
Lots of people commenting seem to have not read the article. The author didn't hook Claude up directly with the controls, asking it to one-shot a successful flight.
The author tried getting Claude to develop an autopilot script while being able to observe the flight for nearly live feedback. It got three attempts, and did not manage autolanding. (There's a reason real autopilots do that assisted with ground-based aids.)
I suppose part of the problem with autolanding a small plane is that they have much less intertia and are much more susceptible to conditions.
Large planes are autolanded in normal conditions with oversight of qualified, capable and backed up operator, in harsh conditions they are not used, as far as I understand.
Autoland systems in small planes are emergency systems to land plane with disabled operator in any conditions generally acceptable for flying in that plane.
Friend participating in some sort of simulated glider tournament trained a neural network to fly one some way (don't ask details). I recall rules were changed to ban such, not because of him.
Using Claude sounds overkill and unfit the same time.
try using codex-5.3-spark, it has much faster inference, might be able to keep up. and maybe a specialized different openrouter model for visual parsing.
—Sully Sullenberger
[0] Sully: My Search for What Really Matters. p. 188
And well if they are there they might as well fly for practise.
And no. I would not allow LLM in to the loop of making any decision involving actual flying part.
Much of the value of a human crew is as an implicit dogfooding warranty for the passengers. If it wasn't safe to fly, the pilots wouldn't risk it day after day.
To think of it, it'd be nice if they posted anonymized third-party psych evaluations of the cockpit crew on the wall by the restrooms. The cabin crew would probably appreciate that too.
Everyone likes to hand wring about this sort of stuff but I think it's the exception. Nailing the "macro level" decisions like "we'll go around this storm but we'll go over that one" or "we must divert to A or B and we will chose B because it's better for our passengers/company/crew even if it's 10min more flying to get there" are what keep the industry humming along mostly in the black rather than in the red. And it's these sorts of things that AI just tends to yolo and get mostly right when they're obvious but also get immensely wrong when any sort of gotcha materializes.
Furthermore, the concept of "ejecting a passenger" from a flight would mostly not be something you do while in the air, unless you're nuts. Ejecting a passenger is either done before takeoff, or your crew decides to divert the flight, or continue to the destination and have law enforcement waiting on the tarmac.
Naturally, pilots get involved when it's a question of where to fly the plane and when to divert, but ultimately the cabin crew is also involved in those decisions about problem passengers.
It absolutely can; it's called autoland[1]. In really bad visibility, pilots simply can't see the runway until too late, and most aerodromes which expect these conditions have some sort of autoland system installed. The most advanced ones will control every aspect of the plane from top-of-descent (TOD), flaps and throttle configuration, long and short final, gear down, flare, reverse thrust, and roll-out, all the way to a full stop on the runway. Zero pilot input needed.
And most of this was already available in the late 1970s. We have absolutely no need for LLM-based AI in aviation; traditional automation techniques have proven extremely powerful given how restricted the human domain of aviation already is.
[1]: https://en.wikipedia.org/wiki/Autoland
never mind that most crashes are caused by humans, very rarely by technical issues going amok
Because humans are the fallback for all the scenarios that the tech cannot reliably cover. And my intuition says that the tech around planes is so heavily audited that only things that work with 99.999...% accuracy work will be left to tech.
"Caused by a human" is the lowest tier, first base human instinct analysis of any accident, and as such, unless proven otherwise, can be discarded out of hand.
It comes down to: if a human mistake is capable of causing an accident, your system is badly designed because it assumes a part of the system known to be unreliable (a human) is always reliable.
The whole trick is designing systems that are safe despite humans being in the loop. Then you get to benefit from the advantages humans bring over machines without suffering the downsides.
Seeing how Claude (or any current LLM) perform in even the most low-stake coding scenario I dont think I would ever set foot on a plane where the 1% of most risky scenarios are decided by one.
I mean if you have a stable plane, then it'll do alright, as it'll mostly fly straight and level (assuming correct trim) reacting to turbulence however, the sampling rate would probably too slow, so you'd end up with oscillations.
For recognising that you're in a shit situation, yeah, it'll probably do that fine, but won't be able to give the correct control inputs at the right time.
Even that im not sure of, I know relatively little about aviation safety but I can imagine that there are all kinds of 0.0000000001% percent corner cases that no plane has ever encountered that still need some sort of reaction, who knows how easy an llm can distinguish those from the 0.000000001% corner cases that no plane has ever encountered that are completely fine and can be ignored.
However its as far as I know the check list volume scales with how "airline-y" the plane is. so for a one seater, the checklist is small and only handles a few things. For a 777 its a binder.
Most of the time. Sometimes you get a double bird strike when you've barely cleared the Hudson river, or similar.
I try to fly about once a week, I’ve never really tried to self analyze what my inputs are for what I do. My hunch is that there’s quite a bit of I(ntegral) damping I do to avoid over correcting, but also quite a bit of D(erivative) adjustments I do, especially on approach, in order to “skate to the puck”. Density going to have to take it up with some flight buddies. OR maybe those with drone software control loop experience can weigh in?
(d'oh, should have read the specific context: in the case mentioned, it is where the system acts as an integrator (pitch -> altitude), and so pure P control is pretty reasonable)
Gold
"spawning 5 subagents"
You'd want all the data from the plane to be input neurons, and all the actions to be output neurons.
"500 Our Servers Are Experiencing High Load"
"500 Our Servers Are Experiencing High Load"
"500 Our Servers Are Experiencing High Load"
This is where I think Taalas-style hardware AI may dominate in the future, especially for vehicle/plane autopilot, even it can't update weights. But determinism is actually a good thing.
I wouldn't trust Claude to ride my bike, so I certainly wouldn't board its flight.
It would still be better just to let autopilots do the work, because the point of the exercise isn't improved avionics. But it would be an honestly posed challenge for LLMs.
http://extremelysmart.com/humor/howtofly.php
The author tried getting Claude to develop an autopilot script while being able to observe the flight for nearly live feedback. It got three attempts, and did not manage autolanding. (There's a reason real autopilots do that assisted with ground-based aids.)
Related from December 2025: Garmin Emergency Autoland deployed for the first time
https://www.flightradar24.com/blog/aviation-news/aviation-sa...
Large planes are autolanded in normal conditions with oversight of qualified, capable and backed up operator, in harsh conditions they are not used, as far as I understand.
Autoland systems in small planes are emergency systems to land plane with disabled operator in any conditions generally acceptable for flying in that plane.
Using Claude sounds overkill and unfit the same time.