“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
In aviation there's a saying, "Aviate, Navigate, Communicate" which describes the hierarchy of things to pay attention to while piloting an aircraft.
Autopilot can be thought of better as "auto-aviate". That is to say, if there is already a navigation plan, the aircraft can follow that plan. Simple autopilots just keep the wings level, others can hold an altitude and change heading. More sophisticated ones can change altitude or even fully land the plane.
All of those things, however, require people to manage the "Navigate" part. "Aviate" is a deterministically solved problem, at least in normal flight operations. As you point out we trust autopilots today, including on (nearly) every single commercial flight.
LLMs are a poor alternative to "aviate", but they could be part of a better flight management automation package. The parent article tries to use the LLM to aviate, with predictable results.
If paired with a capable auto-pilot (not the relatively basic one on that C-172), the LLM could figure out how to operate the FMS and take you from post take-off to final approach and aid in situational awareness.
Currently, I don't think there is a commercial solution for GA aircraft that could say, "Ok, I'm 20NM from KVNY, but there are three people ahead of me in the pattern, so I have to do a right 360 before descending and joining downwind on 34L".
Having an LLM propose that course of action and tell the autopilot to execute on it definitely would be an improvement to GA safety.
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.
Yeah, I think it's been technically possible to automate jetliners for a while now, but when a metal tube with hundreds of people in it develops a technical fault while moving 500+ mph there's no substitute for a pilot.
> 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.
and then you have Air France Rio-Paris where the Pitot sensors got something wrong, leading to a disconnection of the autopilot, and the pilots did everything they could to crash the plane by themselves, while it was fully operational.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
“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 hope vibe coding enthsiasts are listening.
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.
I don't think anyone is suggesting we should do that...but it's still a fun project to play around with?
Agreed. I think thats a really fun way to test out Claude's ability to perform an abstract task it's probably not trained on, was nice to read
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
In aviation there's a saying, "Aviate, Navigate, Communicate" which describes the hierarchy of things to pay attention to while piloting an aircraft.
Autopilot can be thought of better as "auto-aviate". That is to say, if there is already a navigation plan, the aircraft can follow that plan. Simple autopilots just keep the wings level, others can hold an altitude and change heading. More sophisticated ones can change altitude or even fully land the plane.
All of those things, however, require people to manage the "Navigate" part. "Aviate" is a deterministically solved problem, at least in normal flight operations. As you point out we trust autopilots today, including on (nearly) every single commercial flight.
LLMs are a poor alternative to "aviate", but they could be part of a better flight management automation package. The parent article tries to use the LLM to aviate, with predictable results.
If paired with a capable auto-pilot (not the relatively basic one on that C-172), the LLM could figure out how to operate the FMS and take you from post take-off to final approach and aid in situational awareness.
Currently, I don't think there is a commercial solution for GA aircraft that could say, "Ok, I'm 20NM from KVNY, but there are three people ahead of me in the pattern, so I have to do a right 360 before descending and joining downwind on 34L".
Having an LLM propose that course of action and tell the autopilot to execute on it definitely would be an improvement to GA safety.
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.
Which makes sense: a robot can’t be responsible for anything, a human can be.
Yeah, I think it's been technically possible to automate jetliners for a while now, but when a metal tube with hundreds of people in it develops a technical fault while moving 500+ mph there's no substitute for a pilot.
> 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
I doesn't sound ethical to eject passengers while aborting an approach, regardless of precise timing.
> 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.
No. Cabin crew recommend. Pilots actually decide.
Do the pilots also decide whether to issue a parachute to the ejected passenger?
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 would be interesting to see if Claude can land and take off. Don't think the autopilot can do that yet.
> Don't think the autopilot can do that yet.
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
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).
> We just don't trust them enough to not have human pilots
never mind that most crashes are caused by humans, very rarely by technical issues going amok
>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.
and then you have Air France Rio-Paris where the Pitot sensors got something wrong, leading to a disconnection of the autopilot, and the pilots did everything they could to crash the plane by themselves, while it was fully operational.
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.
[dead]
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.
Using an LLM doesn't mean it has to take the final decision. You can also use it as a warning system.
Is there any indication that current warning systems are insufficient in any way that would be improved by LLM involvement?
Well they don't attract nearly as much investment in the current market, I think that might be the problem people really want to solve
We won't know that until someone has actually investigated how an LLM would do in those scenarios.
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"
Nobody can be against just collecting the data and letting people experiment with it.
Are all those security systems actually open right now? Because that sounds like an absolute security nightmare if so.
Can you give an example scenario?
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.
False negatives are a huge issue when designing safety systems. It is not the case that "more warnings = more better".
Of course, but an LLM can potentially help with that.
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.
> Flying isn't hard
Most of the time. Sometimes you get a double bird strike when you've barely cleared the Hudson river, or similar.
If planes can fly autopilot I assume claude can make a pretty good flight plan. Not sure if claude can react in time if shit hits the fan.
"spawning 5 subagents"
"Rate limited try again in 10 seconds"
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?
Dumping the I part instead of just tuning it properly is kind of an insane thing to do … speaking as an actual controls engineer
"Actual controls engineers" use PD loops (no I) all the time.
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)
[dead]
> 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
Gold
"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.
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.
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.
Prepare for landing "rate limit exceeded" (Error 429)" ;-)
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.
"Approaching for landing"
"500 Our Servers Are Experiencing High Load"
"500 Our Servers Are Experiencing High Load"
"500 Our Servers Are Experiencing High Load"
Mate, we don't trust it to write an email or the code it generates. Why should we trust it to fly a plane?
Somebody, somewhere, is using it to decide who lives and who dies by bombs. Why not hook it up to a flight sim?
Sad, but true.
> 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.
You could also use your forehead as a hammer, but it's likewise going to result in more pain than gain.
I wouldn't trust Claude to ride my bike, so I certainly wouldn't board its flight.
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 a stochastic text generator to physics. What can go wrong.
I see you are still in the stochastic parrot phase.
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.
I wonder if using a model with a higher TOK/s would yield improvements, as the model will have faster feedback loops
The real question is, can it keep the plane in one piece?
Keeping a plane on the ground seems easy enough. Keeping in the air in one place would be impossible. Keeping any place in the air is only temporary.
And which human will fly in an llm operated plane?!
I am sure some Ryanair customers would risk it for good price.
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.
Please welcome aboard of Airthropic Lines!
Let's hope you don't reach Claude's session limit during approach, while trying to correct a slightly too steep descent angle.
...or that the satellite network connection disconnects for some reason.
I think you gave someone an idea for a new RL environment :) Probably it will be able to fly it in the next iteration.
If there's a timeline where claude can actually fly a plane, then operating nuclear reactors can be possible as well.
So Claude crashed because it was busy figuring out how to fly the plane?
Does Claude know the plane isn't at the car wash?
Humans can also fly. Once.
Douglas Adams formulated how it would be possible for a human to fly continuously, though.
http://extremelysmart.com/humor/howtofly.php
I have the hitchhikers guide to the galaxy but I never got around to reading it. I might have to read it next
I'd imagine Claude is too slow to fly a plane above everything.
Sky King managed it, no reason claude shouldnt be able to.
haha, if can, would you dare to follow it? :D
they say already used in some missiles which hit school at current war by mistake
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 wouldn't really worry about flying, but more about taking off/landing.
Related from December 2025: Garmin Emergency Autoland deployed for the first time
https://www.flightradar24.com/blog/aviation-news/aviation-sa...
Autoland has been used for 60 years and on much more complicated aircraft than that Beechcraft B200.
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.
Yes, but for a limited time only.
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.
[dead]
[dead]