For most of the work we do with digital tools, the work is hidden from us. This is partly a benefit. We do not need to understand routing tables, server architecture, or network protocols every time we open a website or send an email. A good interface simplifies complicated systems so we can get work done.
The problem is that this simplification can make the Internet largely unintelligible. You click a couple of buttons and your picture is shared online, or a car arrives at the curb, or your phone decides you are you. Each of those outcomes is reliable, and none of them is explained. We get the result without any model of what produced it, which is fine right up until something goes wrong, or someone asks us to make a decision about it.
We have been moving quickly and slowly at the same time. The technologies change quickly, while our understanding of the systems underneath them develops much more slowly. We learn to use Google Search without knowing how an index is built. We stream a movie without thinking about where the file lives or how it reaches the television. Now we type into an AI chat box and receive an answer without seeing much of what happened between those two events.
That matters when we start arguing about privacy, energy use, data centers, intellectual property, or the environmental effects of artificial intelligence (AI). It is difficult to make judgments about a system when our mental model of that system consists mainly of a text box and a blinking cursor.
Build it, test it, break it
One of the ways I have tried to deal with this problem in my teaching and outreach is to give people opportunities to get their hands on the machinery. I believe that people learn by building, testing, and (occasionally) breaking things. To a certain extent, this means taking time to play.
In earlier work, that meant asking people to build spaces on the open web, experiment in MOOCs, or play with tools from projects like Mozilla Webmaker. The goal was rarely to turn everyone into a programmer. It was to slow the technology down long enough that people could develop a working mental model of it. When I was experimenting with digital badges, we built and awarded them in the wild to find out what would break, and offered a FAIL badge for anyone’s “first attempt in learning.”
You may not know every technical detail, but you understand enough of the system to reason about what it is doing, where it might fail, and what questions you should ask.
AI presents the same challenge at a larger scale. Most people encounter generative AI through a polished interface. They type a prompt, wait a moment, and receive text, an image, or some other output. The machinery disappears.
I think that to better understand AI, we need to push back against what the systems and interfaces want us to do, and make the infrastructure visible.
What’s in the box?
The best way to get started is to stay unplugged. Pull out the pencil and paper, the picture books, whatever is at hand. When I’m explaining AI, I try to stay as low tech as possible. I have my slides open on one projector and a whiteboard next to it. If I could teach it all with just the whiteboard, I would. :)
I start by drawing a big box on the whiteboard. Outside the box, I write some examples of cloud AI services (Claude, ChatGPT, Gemini). On the other side of the box I sketch a person, and I show that person typing a query and entering it into the box. I mark that with an arrow going from the user into the box.
I then ask some basic questions. What goes into the box from the user? What happens inside with that query? What comes out of the box to the cloud AI services? What happens on that side of the box? What comes back from the cloud AI services to the box and the user? What is the box?
The questions are simple, but the answers are not. I provide some guidance on what is in the AI models, but a lot of the pieces remain unexplained. We also take time to think through what is actually happening in those arrows we draw coming in and out of the box. What data and information is coming and going? What cost, in electricity and in money, is being covered up by these arrows? What else is unseen here, like Internet connectivity, your laptop, and access?
Then I draw another box.
This box I label Local AI. The local AI might be created using LM Studio or Ollama. On the left of the box I once again draw a person and an arrow showing the query coming in from the user. Outside the box, to the right, I draw a couple of smaller boxes, each one a downloaded local model (Qwen, Llama, DeepSeek, Gemma). When the user adds a query, they can also “load a model,” and I show an arrow bringing one of those downloaded models into the main box.
In the box labeled Local AI, the prompt does not need to travel to a provider’s servers for inference. Instead of connecting immediately to a remote model, the local model goes to work on the query. The model is sitting on the machine. We can look at what comes with it: model weights, configuration files, tokenizer files, parameters. The processor and graphics card in your computer do the work. The computer draws electricity. It gets warmer. The response appears.
Figure 1. The same question can be answered in two places. Only one of them keeps the work, the cost, and the hardware inside the room.
I started doing this on participants’ laptops and desktops. More recently, I have been using Raspberry Pis because they make the exercise even more tangible. The little board sits on the table. You can see the power cable. You can feel it warm as the model works.
My next goal is to make the setup smaller and simpler still, perhaps something that can live on a thumb drive or another inexpensive offline device. I will have more to say about those experiments in future posts.
Then I ask everyone to turn off the wifi.
People disconnect, type another query, and wait for the error message. It does not come. The model keeps answering, at the same speed, in the same voice, as if nothing had happened. That pause is the moment the exercise is built around. Someone always looks up from the screen to ask where the answer is coming from, because the honest answer is that it was never coming from anywhere else. It was on the table the whole time. The box they had been drawing around the Internet was drawn in the wrong place.
Figure 2. The answer still arrives, because nothing was crossing the link that was cut. The cut falls inside the boundary people assume and outside the one that actually answers. So what is the box?
What follows is usually a much better conversation than the one we would have had otherwise. Arguments about whether the machine is lying to you land differently once you have watched it produce fluent text with the network unplugged. The question stops being whether to trust the output and starts being what the thing in front of you actually is.
The point is not that everyone should run AI locally. The point is that local AI gives us a way to open the box. It is more about building and breaking AI to learn what is happening behind the scenes.
The box is always bigger
Once we open one box, we begin to see the other structures around it. I have participants build and play with AI on their local systems. In the most recent work this summer, a Raspberry Pi made some of the computation visible, but it did not make the entire system visible. Electricity still has to come from somewhere. The processor and memory had to be manufactured. The board was assembled, packaged, transported, sold, and will someday be discarded.
This also hammers home the questions about the cloud AI services we use and pay for. When I go to ChatGPT.com and log in, the prompt leaves my computer, passes through my router and Internet provider, crosses network infrastructure, and eventually reaches a data center. Inside are host computers, storage systems, accelerators, networking equipment, and cooling systems. Those machines connect in turn to electrical grids, power plants, water systems, factories, mines, and global supply chains.
Figure 3. Every box we open sits inside another one. The interface shows the innermost box and leaves the rest out of frame.
The data center is not the end of the system. As we have started to explore, that information does not completely explain how much energy my query used. That depends on where the computation occurred, how the facility was cooled, what electricity supplied it, and how we decide to account for those systems.
The clean chat interface has not removed any of this. It has simply placed most of it outside our field of view. That is why the box matters.
Learning to see the system
This is why I think infrastructure belongs in conversations about AI and digital literacy.
AI literacy cannot only mean knowing how to write a good prompt, recognize a hallucination, or evaluate an answer. Those skills matter, but they still leave much of the system hidden.
We also need better mental models to ask better questions.
What goes in, and what comes back out? Where does the work actually happen? What does the system consume in order to do it? And who gets to decide any of that?
None of us needs to understand every transistor, network protocol, or cooling system before using AI. That would simply replace one impossible standard with another. But we should be able to draw the box.