Blog · Review Essay · Last reviewed June 25, 2026

Your Computer Is on Fire and the Material AI Stack

Your Computer Is on Fire, edited by Thomas S. Mullaney, Benjamin Peters, Mar Hicks, and Kavita Philip, is a useful antidote to clean-interface thinking. It shows why computing should be read as a material stack: chips, data centers, labor, standards, categories, contracts, institutions, and histories arranged so that a system can appear effortless on screen.

The stronger AI-age lesson is that "virtual" is a claim to be audited. A model answer may appear as text, but it rests on energy, water, minerals, fabrication, cloud regions, training data, annotation, moderation, procurement terms, privacy rules, and people who absorb the failures. If those layers are not documented, the system's smoothness becomes a way of hiding responsibility.

The Book

Your Computer Is on Fire was published by the MIT Press on March 9, 2021. MIT Press lists Thomas S. Mullaney, Benjamin Peters, Mar Hicks, and Kavita Philip as editors, gives the paperback ISBN as 9780262539739, the eBook ISBN as 9780262360784, and lists the book at 416 pages. Google Books lists ISBN-10 026253973X and ISBN-13 9780262539739; Amazon uses 026253973X as the product identifier for the paperback.

The collection belongs beside Programmed Inequality, Behind the Screen, Algorithms of Oppression, and Atlas of AI. Its shared argument is simple but hard to keep in view: computing systems are historical, embodied, political, and institutional long before they become products.

The book's title is not only a metaphor. It is a method. If a technology arrives wrapped in promises of abstraction, scale, and neutrality, the first task is to find the fuel, the workers, the categories, the legal permissions, and the public infrastructure that make the abstraction possible.

Current Context

As of June 25, 2026, the book's warning has become a live infrastructure question. The International Energy Agency's 2025 Energy and AI report estimated that data centers used about 415 terawatt-hours of electricity in 2024, around 1.5% of global electricity consumption, and projected roughly 945 terawatt-hours by 2030 in its base case. In the United States, the Department of Energy announced a Lawrence Berkeley National Laboratory report estimating 176 terawatt-hours of data-center electricity use in 2023, about 4.4% of U.S. electricity, with a modeled 2028 range of 325 to 580 terawatt-hours.

Those figures are for data centers broadly, not for AI alone. That boundary matters. Still, the growth of accelerated computing means AI deployment is now also grid planning, cooling design, chip-supply planning, land use, water stewardship, labor organization, and local political negotiation. A system that enters a classroom, workplace, hospital, public agency, search interface, or companion app also enters substations, server rooms, fabrication plants, logistics chains, and waste streams.

The waste side is no longer background. The UN's Global E-waste Monitor 2024 reported 62 million tonnes of e-waste generated in 2022, with 22.3% documented as formally collected and recycled, and projected 82 million tonnes by 2030 under current trends. AI hardware is not the whole e-waste problem, but rapid accelerator turnover, edge devices, networking gear, batteries, storage media, and data-center equipment make material lifecycle accounting part of responsible AI governance.

The legal record is also beginning to admit materiality. The EU AI Act's Annex XI requires technical documentation for general-purpose AI models to include computational resources used to train the model and known or estimated energy consumption, with estimation allowed from computational-resource information when direct energy data is unknown. That is not a complete environmental regime, but it is an important shift: the model is no longer allowed to appear only as a capability claim.

The Material Stack

The useful definition is this: the material AI stack is the full chain that lets an AI system appear virtual. It includes semiconductor fabrication, accelerator supply, data-center siting, electricity, cooling, water, fiber, cloud contracts, training data, labeling and moderation labor, model documentation, interface design, procurement rules, and the institutions that decide who bears cost when the system fails.

That definition matters because "AI" is often discussed as if the model were the whole object. The model is only one layer. A chatbot answer depends on industrial capacity, data histories, language norms, safety policy, routing infrastructure, account permissions, worker review, and the administrative decision to trust the output. The screen compresses that chain into a reply.

A material stack record has to be local enough to matter. Global electricity shares are useful context, but the public conflict often happens at the substation, watershed, tax district, labor market, fiber route, landfill, or utility docket. A model provider may report training energy; a city may experience the same system as grid queue pressure, water demand, noise, land competition, tax incentives, and a service contract that is hard to exit.

That is why the stack should be documented by layer: training versus inference, compute versus cooling, embodied hardware versus operating energy, data collection versus data cleaning, direct employees versus contractors, public-sector purpose versus vendor reuse, and launch plan versus retirement plan. Treating the system as software-only is a category error.

Nothing Is Only Virtual

The book's strongest correction is aimed at the word "virtual." Cloud services, AI assistants, feeds, dashboards, and automated workflows often appear as frictionless surfaces. The collection pulls the reader below that surface: data centers, labor markets, gendered work histories, colonial infrastructure, speech recognition, content moderation, network policy, and the cultural stories that let technical systems present themselves as neutral.

That matters for AI because model culture encourages abstraction. A user sees a generated answer. A firm sees a productivity tool. A policymaker sees an innovation sector. The book asks for a more material reading: where did the data come from, who cleaned it, which workers absorbed the risk, what infrastructure made the service feel instant, and whose history was converted into a default?

The word "cloud" performs political work. It makes facilities, contracts, substations, training sets, incident queues, and labor disputes feel atmospheric. A better vocabulary keeps the chain visible. A service may be remote, but it is not placeless. A model may be statistical, but it is not contextless. An interface may be smooth, but smoothness is often the result of displaced friction.

AI as Hidden Labor

The chapter title "Your AI Is Human" is the hinge for this page. It does not mean that an AI system is conscious or person-like. It means the opposite: apparent autonomy often hides people. Moderators, annotators, warehouse workers, call-center staff, contractors, educators, care workers, users, and affected publics all become part of the system that later gets described as automated.

This is one reason the collection remains useful in 2026. AI agents are being sold as systems that can plan, retrieve, draft, route, summarize, and act. But every agentic workflow still depends on boundaries, permissions, records, exceptions, review labor, and institutional cleanup. The more seamless the interface looks, the more important it becomes to ask what work has been moved out of sight.

The labor question is not separate from the infrastructure question. Hidden people and hidden facilities are the same design pattern at different scales: the front end presents a clean capability, while the back end absorbs mess, risk, repair, and judgment. The related review of Ghost Work follows the labor side of that pattern; the site's data-center governance essay follows the civic infrastructure side.

A material labor record should therefore name who labels, moderates, tests, red-teams, maintains, supervises, and repairs the system; what jurisdiction and contractor chain they work under; what harms they are exposed to; how their feedback changes the model or workflow; and whether they can contest unsafe conditions. Automation claims are weak when the omitted humans have no record, no leverage, and no path into governance.

Against Neutrality

The book is also a critique of technological belief. It does not treat techno-utopianism as mere optimism. It treats it as an operating ideology: a way of making power look like progress and making historical inequality look like implementation debt. That frame is useful because AI culture repeatedly turns product roadmaps into civilizational stories.

A chatbot, model API, content filter, ranking system, or workplace dashboard becomes socially dangerous when its categories are treated as common sense. The book's essays help name that process without turning the machine into a demon or an oracle. The harm is not that the computer has a will. The harm is that institutions use computational form to authorize decisions they already wanted, then call the result objective.

Neutrality is best read as a routing claim. It says that the system merely carries information, allocates attention, or optimizes a target. But targets are chosen, data is selected, labels are inherited, rules are written, and exceptions are escalated or ignored. A supposedly neutral system can therefore conserve power while appearing to remove human discretion.

The Governance Reading

Read after the first wave of generative AI deployment, Your Computer Is on Fire becomes a governance book. NIST's AI Risk Management Framework is designed to help organizations manage risks to individuals, organizations, and society, and NIST's generative-AI profile adds actions for risks specific to generative systems. The EU AI Act, Regulation (EU) 2024/1689, turns part of this documentation problem into law: Chapter V obligations for general-purpose AI models apply from August 2, 2025, and Annex XI includes technical documentation for training process, data, computational resources, and known or estimated energy consumption.

Those official frameworks speak in policy language, but the collection supplies the historical reason they are needed: the technical artifact is never the whole system. If governance stops at the model, it misses the workplace, the data supply, the data center, the energy contract, the interface, the procurement office, the people categorized by the system, and the person asked to repair the error.

The practical lesson is that governance cannot stop at model cards, benchmarks, or red-team exercises. Those can matter, but they do not answer the deeper questions: who benefits from automation, who is exposed to failure, who can refuse, who can appeal, and who has the authority to shut the system down?

A serious review should ask for an AI bill of materials: model provider, compute provider, data-center region, major hardware dependencies, training and tuning data sources, labor pipeline, moderation process, safety evaluations, known limitations, incident history, content-provenance support, environmental estimates, and appeal channels for affected people. The point is not to make every system impossible to build. It is to make the dependency chain visible enough to govern.

For high-impact deployments, that bill of materials should connect to a material safety case. The case should state the public purpose, affected communities, deployment geography, estimated training and inference footprint where available, data-retention and reuse rules, subcontractor duties, worker-safety controls, water and grid assumptions, hardware-retirement plan, incident thresholds, appeal route, vendor-exit terms, and office with authority to pause use. If those facts cannot be assembled, the institution is not ready to claim responsible deployment.

This is also where procurement becomes safety. A public agency, school, hospital, newsroom, or community organization should not buy an AI system only by comparing features. It should ask whether the contract preserves logs, forbids undisclosed data reuse, requires energy and lifecycle disclosures where available, supports export and deletion, provides audit access, protects workers and affected people, and allows the buyer to leave without losing records or institutional competence.

Where the Book Needs Care

As an edited collection, the book is uneven by design. Some chapters move through history, some through critique, some through case study, and some through manifesto. That variety is a strength for teaching and a limitation for readers looking for a single sustained argument. The book names many fires, but it does not always give an institutional fire plan.

It can also under-specify the difference between technical repair and political repair. Some failures need better engineering: accessibility, security, documentation, testing, reliability, and incident response. Others need law, labor power, procurement rules, public funding, democratic oversight, or refusal. The best reading does not reject technical work. It refuses to let technical work substitute for accountability.

The other limit is precision. Computing, platforms, datafication, automation, machine learning, and generative AI are related but not identical. A stronger material analysis should name the specific layer under review: data-center load, model training, inference routing, dataset provenance, classification harm, workplace surveillance, procurement dependency, or content moderation. Otherwise "the computer" becomes too large to inspect.

The book also predates the post-2022 public rollout of general-purpose chatbots, multimodal systems, and tool-using agents. That does not make it obsolete. It means its method should be extended from the visible screen to the whole service lifecycle: training, fine-tuning, inference, retrieval, evaluation, logging, support, incident response, retirement, and replacement.

What This Changes

Your Computer Is on Fire changes how this archive should read AI systems. Start with the interface, but do not end there. Follow the model into the data center, the workplace, the training set, the standard, the procurement contract, the moderation queue, the classroom, the benefits office, and the exhausted person asked to make the machine look smooth.

The collection's lasting value is its refusal of virtual excuses. AI does not float above society. It runs through bodies, institutions, histories, wires, water, energy, categories, contracts, and screens. If the computer is on fire, the answer is not to admire the glow. The answer is to trace the fuel, name the owners, protect the people breathing the smoke, and decide which systems should not be rebuilt in the same shape.

Source Discipline

Material AI claims need source hygiene. A data-center electricity forecast is not the same as a measurement of AI training energy. Facility power in megawatts is not annual energy in terawatt-hours. A corporate sustainability page is not the same kind of evidence as a regulator filing, public standard, audited report, utility docket, or government energy analysis. A model card can describe a model, but it cannot by itself describe the labor, infrastructure, or public costs behind the model.

The same discipline applies to safety claims. "Human in the loop" should name who the human is, what authority they have, what information they see, what time they have to act, and whether affected people can appeal. "Responsible AI" should name documentation, logging, monitoring, incident response, data rights, environmental accounting, labor conditions, and shutdown authority. Without those details, governance becomes branding.

Environmental claims should separate operating electricity, embodied hardware impacts, cooling and water use, grid emissions, local siting effects, and end-of-life disposal. Labor claims should separate employees, contractors, data vendors, content moderators, facilities workers, public servants, and affected users. The material stack is useful only when it turns abstraction into checkable records.

Sources

Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.

Buy on Amazon Browse Books

Return to Blog · Return to Books