Bill Gurley’s All-In Summit description of MCAS is accurate on its core claim โ and the record beneath it contains a structural distinction that matters far beyond aviation.
The Record โ MCAS & The 737 MAX
12
Days between Lion Air accident and Boeing’s public naming of MCAS
1
Sensor at a time used to trigger MCAS โ a single point of failure
~4 mo
Between Boeing naming MCAS publicly and the Ethiopian Airlines accident
Speaking at the All-In Summit in a talk titled “Searching for Feynman,” investor Bill Gurley described the flight-control software at the center of the Boeing 737 MAX accidents in a single sentence: “So they wrote a piece of software, secret software called MCAS, and they put it in there without telling anybody.” That characterisation holds on its central claim. MCAS was omitted from the 737 MAX crew manual and from training materials before the Lion Air Flight 610 accident of 29 October 2018. Boeing elected not to describe it in the flight manual or in training materials in that period.
The sequence that followed is worth stating in full rather than in shorthand. Boeing issued an Operations Manual Bulletin on 6 November 2018 and publicly named MCAS on 10 November 2018 โ twelve days after the Lion Air accident. The Ethiopian Airlines Flight 302 accident followed on 10 March 2019, roughly four months after that public naming. Across both accidents, 346 people died.
Two angle-of-attack sensors are fitted to the aircraft, but only one at a time was used to trigger MCAS. The flight control system had no mechanism for treating that single sensor’s input as possibly faulty. Subsequent analysis reports that these emergencies did not present as a classic runaway stabiliser situation but initially as ambiguous unreliable-airspeed and altitude conditions. What the Flight 302 crew knew about MCAS, and which procedures they attempted, is not established in the material relied on here.
The key insight: Gurley’s one-sentence description is accurate on the disclosure failure. But the record contains a second, structurally distinct failure โ one that disclosure alone cannot fix. Collapsing the two into one loses the part that generalises.
The Structural Read
There are two separable failures in this story, and they operate at different levels. The first is a disclosure failure. A system was acting on the operators’ behalf, and the operators’ working model of the aircraft did not contain it. You cannot diagnose a behaviour you have no name for. You cannot search a manual for a term you have never encountered. Disclosure addresses this failure completely.
The second failure is different in kind, and it is the durable one. MCAS took its cue from a single sensor and had no basis for treating that sensor’s reading as possibly false. This is not a tuning problem. It is not fixed by making the system more accurate on average. It is a missing faculty: the system had no internal representation of its own reliability โ nothing to consult before acting. Accuracy and self-knowledge are different properties. A system can have a great deal of the first while having none of the second.
The complication in the record is the interesting part. MCAS was publicly named twelve days after the first accident. The second accident occurred roughly four months after that naming. This does not embarrass anyone’s account โ Gurley’s core claim about the pre-October-2018 period stands. What the full sequence supports is a precise distinction: disclosure and safety are not the same variable. Knowing that a system exists is a different thing from being able to act on that knowledge under time pressure, with ambiguous indications, in the seconds available.
Structural Property
The Indistinguishability Problem
A system that cannot represent the possibility that its own input is wrong will act on a false reading with exactly the confidence it brings to a true one โ because from inside the system, the two are indistinguishable. This is a general property of automation acting on sensed input, stated here as a property and not as an account of any particular flight or crew.
What transfers to software that acts on a user’s behalf is the shape of the design question, and only that. As systems increasingly take actions rather than produce suggestions for review, both failure modes become available again in a new setting: a user may not know an automated step occurred, and the automated step may have proceeded on an input it had no way of doubting. The analogy concerns the structure of the problem and nothing else โ no AI system is named here as calibrated or uncalibrated, and no claim is made that any AI product is unsafe or comparable to an aircraft accident.
Three Implications
IMPLICATION 1 โ Disclosure Is the Floor, Not the Ceiling
Telling an operator that an automated system exists is the minimum viable condition for informed use. It addresses the first failure mode completely. But it is not a safety guarantee โ it is the starting point. The gap between knowing a system is present and being able to act on that knowledge under operational pressure is its own design problem, separate from the disclosure question.
IMPLICATION 2 โ Self-Knowledge Is a Design Requirement, Not a Feature
A system that cannot represent uncertainty about its own inputs will act with uniform confidence regardless of input quality. Building in the capacity to flag or refuse to act on potentially unreliable data is a different engineering task from improving average accuracy. The two are often conflated; the MCAS record is a clean illustration of why they should not be.
IMPLICATION 3 โ Effective Override Is the Third Condition
What determines whether a failure is recoverable is not only whether an operator knows a system exists, and not only whether the system can doubt its own inputs โ it is whether the operator retains a timely and effective way to intervene once something has begun. As agentic systems move from producing suggestions to taking chained actions, this third condition deserves its own engineering budget, not a footnote.
Business Engineer Framework
The Map of AI โ Where Automation Acts on Your Behalf
The Map of AI tracks 200+ companies across 9 layers of the AI stack. The MCAS structural read maps directly onto a question the framework surfaces for every agentic layer: at which point does a system act rather than suggest, what input does it act on, and what does the operator retain? Those three questions determine the risk surface of any automated system โ not the marketing copy around it.
Gurley’s one-sentence framing of MCAS is accurate where it counts โ the system was absent from the manual and from training before the first accident โ and the full sequence beneath that sentence contains a distinction worth keeping precise: disclosure and safety are not the same variable, and a system that cannot represent doubt about its own inputs will act on a false reading with the same confidence it brings to a true one. That is not a Boeing problem or an aviation problem. It is a property of any automation that acts on sensed data without a faculty for self-doubt, and it is worth naming clearly before the design question arrives in a new domain rather than after.
Sources: Bill Gurley, “Searching for Feynman,” All-In Summit (YouTube). Factual sequence on MCAS disclosure and accident dates drawn from publicly available accident investigation records and contemporaneous reporting; no certification detail, regulatory finding, lawsuit, settlement, fine, executive name or internal document is cited or relied on here.
This is businessanalysis. It is not a safety assessment, not engineering advice, and not a finding about any accident investigation. The quoted sentence is Bill Gurley’s own characterisation, from his All-In Summit talk. On its central point the record supports it: MCAS was omitted from the 737 MAX crew manual and from training materials before the Lion Air accident of 29 October 2018. Boeing issued an Operations Manual Bulletin on 6 November 2018 and publicly named MCAS on 10 November 2018; the Ethiopian Airlines Flight 302 accident followed on 10 March 2019. That sequence is set out above for completeness and not as a correction of anyone’s account. What the Flight 302 crew knew about MCAS, and which procedures they attempted, is not established in the material relied on here, and nothing above claims anything either way. Nothing above makes any claim about any party’s legal liability, guilt, negligence, intent or commercial motive, and no certification detail, regulatory finding or internal document is described. The comparison drawn to software that acts on a user’s behalf concerns the shape of the design question only. Nothing above claims that any AI product is unsafe, compares any AI system to an aircraft accident, or suggests that any AI system will harm anyone, and no model is named as calibrated or uncalibrated. Nothing is predicted.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur, HackerNoon and Search Engine People. Find him on LinkedIn and Substack. See how we source.
Scroll to Top
Discover more from FourWeekMBA
Subscribe now to keep reading and get access to the full archive.
