How Elon Musk Thinks, and Why It Is Killing Us
The software worldview applied to a domain that is not software.
People have been trying, for years, to reconcile two observations about Elon Musk that seem difficult to hold simultaneously. The first is that he is one of the most consequential industrial operators of the twenty-first century, responsible for two companies — Tesla and SpaceX — that have genuinely changed the trajectory of their respective industries in ways that were not obviously going to happen without him. The second is that his public political and cultural commentary is, on nearly any subject outside his areas of technical expertise, somewhere between embarrassingly shallow and actively dangerous. How does the same mind produce reusable orbital rockets and the posts he writes on X at three in the morning? The standard explanations have been psychological. He is a damaged narcissist. He is isolated by wealth. He is on ketamine. He is on too much Twitter. He has always been like this and we just see it now because the platform is his. These explanations are not wrong, exactly, but they all treat the contradiction as a puzzle to be dissolved by adding biographical facts until the two Musks become compatible. They miss the structural point, which is that there is only one Musk, and the specific mind that built Tesla and SpaceX is the same specific mind that is at this moment helping to dismantle the American administrative state. The engineering genius and the political pathology are not two separate features of the person. They are the same cognitive apparatus applied to two different domains, and the apparatus is excellent for one domain and catastrophic for the other.
I want to describe, as precisely as I can, how Musk thinks. I want to do it at length, because the description does work that shorter critiques cannot do. It explains what his actual contribution to manufacturing has been, which is significant and worth naming. It explains why that same contribution, generalized into politics, produces authoritarianism rather than good governance. And it places him in a specific American tradition — the tradition of industrial-fascist figures whose manufacturing genius and political depravity are linked by exactly this pattern — that makes the current moment legible as a recurrence rather than a novelty.
Musk thinks about the world as if it is software. This is not a metaphor. This is the operating grammar of his cognition. He takes the conceptual tools that work in software engineering — version control, continuous integration, rapid iteration, refactoring, debugging, A/B testing, optimization against objective functions, hardening against adversarial inputs — and applies them to everything he encounters. Factories are software. Rockets are software. Cars are software. Cities are software. Governments are software. Human beings are software. Political institutions are software. Cultures are software. The software-as-worldview is so total that it is not, to him, a worldview at all. It is what thinking looks like. The possibility that some domains might not be software-shaped is not available to him as a thought, because the tool he thinks with cannot perceive the shapes it cannot handle.
This sounds like a criticism but I want to start with the place where it is a genuine strength, because the essay does not work if you do not understand that the engineering achievement is real.
⁂
The standard way to think about Musk’s industrial accomplishments is to treat them as matters of scale and capital. He had a lot of money, he hired smart engineers, he pushed them hard, he shipped products. This is true but it does not explain what the actual innovation was, because Ford had money, Boeing had money, General Motors had money, Lockheed had money, and none of them produced what Tesla and SpaceX produced. The specific thing Musk did that the legacy industrial firms did not do is treat the factory itself as a version-controlled system under continuous integration, and this is a genuine contribution to manufacturing theory that belongs in the same intellectual tradition as Toyota’s lean production and Ford’s assembly line.
The traditional paradigm, which dominated twentieth-century mass manufacturing and still dominates most of contemporary industry, treats a factory as a system that is designed, optimized, and then maintained at equilibrium. You spend years engineering a product. You spend more years engineering the tooling to produce it. You turn on the line. The line produces the product. Continuous improvement in the Toyota sense means refining the line to produce the same product better — fewer defects, lower costs, faster throughput. The product itself does not substantially change until the next model cycle, which happens on a timescale of three to seven years depending on the industry. The design-manufacturing boundary is rigid. Engineering designs the car. Manufacturing builds the car. The handoff between them is formal and infrequent.
Musk’s insight, which he did not articulate in these terms but which is legible in the structure of his operations, is that this rigidity is a legacy constraint from a prior era of industrial technology, and that modern manufacturing can be run like a software project. A software codebase is not something you design once and then maintain. It is something you ship in a state of continuous improvement. Every day, every hour, developers are committing changes. Each change passes tests. If it passes, it goes into the next deployment. If it fails, it is reverted. The product users receive is materially different from the product users received a week ago, even though it carries the same name. This is possible because software is infinitely malleable and because the infrastructure for managing continuous change — version control, automated testing, deployment pipelines — has been developed to industrial-grade reliability over the last thirty years.
Musk’s Tesla and SpaceX operations apply this logic to physical manufacturing. A Tesla Model S in 2026 shares a nameplate with a Tesla Model S from 2013, but the internals have been iterated through hundreds of silent revisions. The battery chemistry has changed multiple times. The wiring harnesses have been simplified. The drive units have been replaced with entirely different designs. The assembly processes have been automated and then partially un-automated and then re-automated differently. Individual components are swapped out mid-production when a better supplier becomes available or when an internally-designed replacement passes testing. The line is, effectively, a deployment pipeline for a physical artifact. Each car coming off the line is a build of the Model S — a specific version, distinguishable from the version that came off the line last week, embodying whatever improvements have cleared the gate since.
SpaceX runs the same logic with even more visible results. The Falcon 9 rocket that flew in 2015 is a different rocket from the Falcon 9 that flies today, despite carrying the same name. The Merlin engine has been through many versions. The booster structure has been reinforced, lightened, re-reinforced, and optimized for reuse in ways that bear the fingerprints of hundreds of specific engineering decisions made in production rather than during a design cycle. The Starship program goes even further. Each test flight is explicitly a deployment. The rocket blows up, the engineers look at what happened, they revise the code, they build the next version, they fly again. The iterations are measured in months rather than years. This is how software projects work. It is not how aerospace projects have traditionally worked. The legacy aerospace industry designs a rocket, builds it with decades-long tolerances, flies it, and treats any failure as a catastrophe demanding exhaustive investigation before another flight is attempted. SpaceX treats failure as a test signal, uses it as input to the next revision, and ships the next revision quickly. The iteration speed is the advantage. The iteration speed is possible because the factory is organized as a continuous deployment pipeline rather than as a batch-production facility.
This is a real contribution. It is not hype. It is a manufacturing-theory innovation that deserves to be named as such, and the innovation is genuinely the result of applying software-industry organizational patterns to physical production. Toyota optimized the line to produce the same car better. Ford invented the line as an organizational form. Musk invented the continuously-integrated line — the factory as a rolling deployment of an improving artifact — and the innovation explains both Tesla’s cost curve on batteries and SpaceX’s cost curve on orbital launch. Neither curve would have been achieved by the legacy industries operating in their traditional manner. The innovation is his.
This is what his Henry Ford contribution actually is. It is not the electric car. Other companies would have built electric cars eventually. It is not the reusable rocket. The engineering for reusability was worked out incrementally by many people. It is the organizational form — the factory as continuous-deployment system — that scales. This is the thing historians of technology will credit him with a century from now, assuming there are historians of technology a century from now.
So far so good. If Musk had stayed in the domain where his cognitive apparatus is an asset, he would be a genuinely historically significant industrialist and nothing more. He would be remembered alongside Ford and Edison and Jobs as one of the Americans who invented something that changed how the species produces things. The complication is that he did not stay in that domain. He generalized the software worldview outward, first into business strategy more broadly, then into media and communication with the acquisition of X, then into politics with his alliance with Donald Trump and his role in the current administration’s demolition of the American administrative state. At each step of the generalization, the cognitive apparatus that had served him brilliantly in manufacturing met a domain whose fundamental ontology was not software-shaped, and at each step the mismatch produced pathologies that the legacy understanding of Musk — engineering genius, political amateur — cannot explain. The pathologies are predictable from the cognitive apparatus. They are what happens when you take the software worldview seriously as a theory of everything and apply it in domains where its implicit ontology does not hold.
Let me enumerate the specific features of the software worldview that produce specific pathologies when generalized, because the argument is strongest when stated at the level of mechanism.
One. Software treats all problems as optimization problems with specifiable objective functions. If you can define the metric, you can optimize it. This is correct in software engineering. It is, in fact, the central discipline of software engineering — reducing vague human needs to specifiable requirements so that the implementation can optimize against them. Politics is not that. The whole point of liberal democratic politics is that citizens legitimately disagree about which objective function to optimize, and the political system is the procedure through which that disagreement is adjudicated rather than resolved. A software mind looking at politics sees it as engineering with unacceptably vague requirements, and the software mind’s instinct is to clarify the requirements. Which in politics means imposing a single objective function on a citizenry that has not consented to being optimized around it. Musk has been explicit about this. His account of what government should do, when he speaks about it directly, is that government should minimize wasteful spending, maximize efficiency, and free the productive class to do its work. These are engineering objectives. They are presented as obviously correct, the way minimize memory allocation is obviously correct in a well-written program. The possibility that citizens might legitimately disagree about whether efficiency is the right objective function — that some of them might prioritize equality, or solidarity, or the protection of the vulnerable, or the preservation of traditions the market does not value — is not available to him as a serious consideration. Disagreement with his objective function is not, in his cognitive model, a sign of legitimate political pluralism. It is a sign that the disagreeing party has not understood the requirements. The requirements being obvious, the disagreement must be explained by stupidity or malice. Hence the famous contempt.
Two. Software treats users as endpoints of a designed system rather than as agents whose consent constitutes the system’s legitimacy. A good software designer thinks carefully about user experience, user intentions, user needs. But the user is never the source of the system’s authority. The designer is. The user gets to use the system or not, but the system itself is not accountable to the user in any deeper sense than market feedback. A software mind looking at citizenship sees citizens as users of the state, and asks how the state can be optimized for their experience. What it does not see is that citizens are the source of the state’s legitimacy, which makes them ontologically different from users of an app. This is the specific place where the software worldview diverges from democratic theory. Democratic theory says the citizens are not the users of the state; they are the state, and the administrative apparatus derives its authority from them. The software worldview inverts this. It treats the apparatus as primary and the citizens as consumers. The consequence is a specific flavor of technocratic contempt for ordinary political participation — the sense that voters are noisy inputs to a system that would work better if the noise were filtered out, the sense that representative democracy is inefficient because it aggregates the preferences of people who do not understand the objective function. This is Musk’s actual attitude toward democratic processes, visible every time he talks about them. He does not hate democracy out of explicit commitment to autocracy. He fails to see why democracy is necessary at all, because his ontology does not contain the category of things democracy protects.
Three. Software treats legacy systems as technical debt to be refactored or retired. If a component is inefficient, the move is to rewrite it. If a process is slow, the move is to automate it. This is correct engineering discipline. It is catastrophic political philosophy. Constitutional procedures, the separation of powers, the adversarial press, the independent judiciary, tenured civil service, due process, judicial review, administrative rulemaking, the whole elaborate inheritance of constitutional republican government — these all look like technical debt from inside the software worldview. They are slow. They are inefficient. They have redundancies that could be optimized out. A software mind looking at the administrative state sees a badly-written codebase that needs to be refactored. Move fast and break things, which is the motto of the software industry, is fine when you are iterating on a photo-sharing app. The cost of a mistake is that a feature breaks and you roll it back. Move fast and break things applied to government means that when you break something, you have broken a constitutional function whose restoration requires years of political work, if it can be restored at all. The Department of Government Efficiency operation that Musk has been running for the current administration is the software-refactor mentality applied directly to the American state. Functions are being deleted because the person doing the deleting cannot see why they were there. The engineering instinct is to treat any function whose purpose is not immediately obvious as dead code to be removed. In software, dead code is a maintenance liability. In government, the function you cannot see the purpose of is very often a safeguard against a failure mode that has not occurred recently because the safeguard is working. Removing it produces the failure mode the safeguard existed to prevent. By the time the failure mode becomes visible, the damage is irreversible.
Four. Software treats intelligence as computation and assumes that more compute reliably produces better outputs. This generalizes, in the Musk register, to the assumption that concentrated intellectual and economic power in the hands of technically brilliant people will produce better civilizational outcomes than distributed decision-making. If you have a hard problem, you assign the smartest person to it. If the problem is harder, you assign a team of smart people. If it is civilizational in scope, you assign a tech billionaire. The engineer’s meritocracy scales up into the technocrat’s contempt for democratic procedure. If the smart people are smart enough, why are we letting the dumb people vote on things they do not understand? This is the specific place where the software-as-worldview tips into the explicitly anti-democratic posture that characterizes the current tech right, not just Musk but Thiel and Andreessen and the Yarvin-adjacent factions that have become politically consequential over the last decade. The move from intelligence is computation to concentrated intelligence should govern is almost automatic inside the software worldview, because the worldview has no ontological category for legitimacy as distinct from competence. Competence is observable. Legitimacy, in the republican tradition, is a property of consent, of procedure, of the authorization relation between citizens and their government. It is not observable as a metric. From inside the software worldview, it is therefore not real. The only real thing is who is better at producing outcomes, and the people who are better at producing outcomes should have authority, and the ones who complain about this are either incompetent themselves or engaging in what the tech right calls rent-seeking — trying to extract value from the system without contributing to it.
Five. Software is optimized against adversarial inputs. Every well-designed software system assumes that some fraction of its users will be bad actors, and is hardened accordingly. Rate limiting, captchas, authentication, input sanitization, fraud detection — the whole apparatus of modern software engineering includes a substantial subsystem dedicated to identifying and neutralizing inputs that are trying to exploit the system. The software mind, scanning any population, asks: who are the bad actors? Who are the spam bots? Who are the exploiters? Who are the freeloaders using up resources without contributing? In engineering, this is good discipline. In politics, it is the cognitive structure that produces scapegoating, and it is the specific place where the software worldview generalizes into something that is not merely anti-democratic but actively fascist in the historical sense of the word.
The software mind trained to identify system exploiters will, when given political power, identify populations as system exploiters and optimize the system to exclude them. Immigrants become spam — inputs to be filtered out at the border. Welfare recipients become resource drains — consumers of the system who are not producers in it. Political opponents become adversarial inputs to the information system — sources of misinformation to be hardened against. The homeless become uncaptured externalities of a system that should be refactored to not produce them. Each of these populations, in the software-as-worldview, is a problem to be engineered away. The categories the software mind applies to them are not categories of citizenship or human dignity. They are categories of system performance. And the engineering solution to a performance problem is elimination or isolation of the input source.
This is not a rhetorical flourish. This is a specific cognitive pattern that produces specific political consequences. Musk’s public statements on immigration, on welfare, on political opponents, on the press, on the administrative state, on any population or institution he perceives as extracting value from the system without contributing to it, follow this pattern exactly. He does not hate these populations in the way a traditional racist hates them. He processes them as system exploiters, and his political instinct is to engineer them out of the system. The effect on the populations is indistinguishable from traditional fascism. The cognitive route is different. The traditional fascist has a racial or national or religious theory that designates certain populations as enemies. The software-fascist has a system-performance theory that designates certain populations as adversarial inputs. The outputs converge. The populations being designated are, in the current case, nearly identical — immigrants, the poor, the political left, dissenting journalists, marginalized ethnic and sexual minorities — because the coincidence between traditional-fascist enemy categories and software-fascist adversarial-input categories is not coincidence at all. The traditional fascism was itself a kind of prototype of the cognitive pattern the software mind now instantiates in a more technically sophisticated form.
⁂
This is where the Henry Ford parallel becomes exact and not merely illustrative.
Ford was the industrial genius of his era. His contribution to manufacturing was real and foundational. The assembly line as he organized it at Highland Park in 1913 was a genuine revolution in how mass production works, and the cost curve it produced on automobiles — from a luxury good for the rich to a product available to the working class — remade American society and then the world. Ford was also a virulent antisemite whose Dearborn Independent ran a series of articles in the early 1920s collected as The International Jew, which was enthusiastically received in Germany and read approvingly by Adolf Hitler. Hitler kept a portrait of Ford on his wall and cited Ford’s writings as influences. When the Germans awarded Ford the Grand Cross of the German Eagle in 1938, he accepted. His political instincts throughout his life included opposition to unions, sympathy for authoritarian government as an efficient alternative to messy democratic process, and a specific conviction that certain populations — Jews, unionists, Bolsheviks — were parasites on the productive industrial class he represented.
For decades, historians treated Ford’s antisemitism as an embarrassing character flaw that had nothing to do with his manufacturing achievements. This is wrong. The cognitive apparatus that optimized the assembly line — ruthless efficiency, system-level thinking, contempt for anything that obstructed the production process, the treatment of workers as inputs to be managed rather than agents with their own political standing — generalized into a politics that saw certain populations as obstructions to the productive system and designated them for removal. Ford’s antisemitism was not a separate character flaw. It was the same cognitive apparatus that built the Model T, applied to a domain where the apparatus is catastrophic. The apparatus has no ontological category for citizen that is not reducible to productive contributor. Populations that did not fit the productive-contributor category were, in Ford’s cognition, obstructing the system. His antisemitism was the specific cultural form this cognitive pattern took in the American industrial context of the 1920s. Different populations in a different era would have been designated by the same pattern.
Musk is the same structural figure in a different technological era. The cognitive apparatus has been updated for the software age — the specific tools are version control rather than assembly-line optimization, the specific metaphors are about code rather than about production — but the underlying pattern is the same. An industrial genius whose genuine contribution to manufacturing is linked, structurally rather than accidentally, to a politics that identifies populations as obstructions to the productive system and designates them for elimination. The specific populations Musk identifies as adversarial inputs are different from Ford’s in some details — the antisemitism is less central, though it surfaces in his engagements with X‘s algorithmic promotion of antisemitic content and in his recent public sympathy for specific antisemitic tropes about replacement and demography — but the pattern is recognizably the same pattern. The American industrial-fascist tradition runs from Ford through the Liberty League of the 1930s, through the anti-union industrialists of the 1940s and 50s, through the Koch operation of the late twentieth century, and now through the tech-billionaire class of the 2020s. Each generation produces its own version of the figure whose manufacturing competence and political depravity are linked by the same underlying cognitive apparatus applied to both domains.
⁂
This analysis has two consequences worth naming, one explanatory and one practical.
The explanatory consequence is that the Musk puzzle dissolves. There is no mystery about how the same person built Tesla and SpaceX while also helping dismantle the American state. He is doing both things with the same tool. The tool is excellent in one domain and catastrophic in the other, and he cannot see the difference between the domains because the tool he thinks with cannot perceive the difference. He is not stupid about politics in the way a person with low general intelligence is stupid. He is operating at high cognitive capacity with a specific tool that is misapplied to the subject matter. The mismatch is not a character flaw. It is a mismatch between a cognitive apparatus and an ontological domain. The apparatus is software-shaped. The domain is not software-shaped. The outputs are what they are.
The practical consequence is that this pattern is not going away when Musk does. He is not the only figure exhibiting it. He is the most visible and currently the most politically consequential, but the entire tech-right coalition that has aligned itself with the reactionary project is made up of people running versions of the same cognitive apparatus. Thiel runs a darker variant that is explicitly aware of its anti-democratic implications. Andreessen runs a more libertarian-cornucopian variant that tries to paper over the authoritarian implications with techno-optimist rhetoric. The younger generation of tech founders and VCs coming up through Y Combinator and the adjacent institutions are being trained in the same apparatus, and they will be politically active for the next forty years. The specific personalities will come and go. The apparatus will persist. The response to it cannot be personal. It has to be structural.
The structural response, I have been trying to say across this essay series, is a public philosophy that is explicitly not software-shaped. A philosophy that holds consciousness and meaning as features of reality rather than as outputs of computation. A philosophy that treats citizens as the source of political legitimacy rather than as users of a system. A philosophy that recognizes the legacy institutions of constitutional republicanism as accumulated wisdom about how free people govern themselves rather than as technical debt to be refactored. A philosophy that grounds its defense of pluralism in a metaphysics that makes pluralism a feature of reality rather than a procedural compromise. This is what my framework calls SIDAM — structurally irreducible dual-aspect monism — and what I have been articulating in The Positive Case for Liberalism and in the Crisis Papers across the last year. The philosophy is a response to exactly the kind of cognitive apparatus Musk represents, because the philosophy insists on the existence of things the apparatus cannot see.
The reason these things matter — the reason the argument is not merely academic — is that the software-as-worldview does not remain abstract. It is currently, at this moment, the operating theory of the dismantling of the United States federal government. The people who ran the DOGE operation, the people advising on the administration’s approach to regulation, to the civil service, to the press, to the immigration system, to the welfare state, are people whose cognitive apparatus is the one I have been describing. They are not acting maliciously in the sense of consciously seeking to destroy the republic. They are acting in accordance with their genuine theory of what governance is. Their theory is that governance is software engineering applied to national administration, and that applying software engineering discipline to this domain will produce better outcomes. Their theory is wrong. The outcomes it is producing are the predictable consequences of applying a tool to a domain the tool cannot handle. The damage is real, and the damage is being done by people who believe they are fixing something.
⁂
I want to close by naming something that should not need saying but that I think does.
None of this is an argument against software, or against engineering, or against the specific competences Musk and his class have genuinely developed. Software is an extraordinary achievement of human civilization. The cognitive apparatus that produces it is one of the most powerful tools our species has ever developed. The problem is not the tool. The problem is the failure to recognize that the tool has a domain of application, and that domains outside that application require different tools, and that the failure to notice this is producing an industrial-fascist politics that has historical precedents whose outcomes were catastrophic.
The appropriate relationship between software and politics is that software is one of the things the republic contains, not the other way around. The republic is the container. It is older than software. It was built by people who did not think about the world as software, and who understood things about collective self-governance that the software worldview cannot see. A software mind operating inside a republic should have humility about the republic, should treat its institutions as load-bearing until proven otherwise, should respect the accumulated wisdom encoded in the constitutional structure, should understand that efficiency is not the only legitimate objective function a polity can pursue, and should recognize that the citizens who disagree with the software mind’s preferred outcomes are not adversarial inputs but co-sovereigns whose consent is the source of any legitimate authority the software mind exercises.
None of this is how Musk operates. None of this is how the tech-right coalition he leads operates. They are running their cognitive apparatus at full capacity in a domain the apparatus is catastrophically mismatched to, and they are doing it with a degree of concentrated economic and political power that no previous generation of industrial-fascist figures ever wielded.
This is how Elon Musk thinks. It is why he built Tesla and SpaceX. It is why he is, right now, helping to destroy the American republic. The engineering genius and the political pathology are the same cognitive apparatus. The apparatus is excellent in its domain. It is killing us outside of it.
The psychological assessment covers the bases. Let's not confuse rationalizing with embracing the naked truth. The man has skills but no moral base -- a pathology.
I appreciate the thoughtfulness of this essay. Musk's ontological error is at least as old politics itself. Socrates complained about the arrogance of the craftsmen who really did have technical knowledge but who thought their technical knowledge was the same as sound political judgment.