The Demo Gods are Gods of Mischiefs
A new product rollout, a room full of people waiting to be impressed, and a demo that didn’t go according to plan — who to blame if not the demo gods?
It was a Thursday evening in April. I was standing in a room full of developers on the sixth floor of an office building overlooking the iconic London Eye. I’m not a developer myself, let alone an AI one, which was the target audience for the gathering. But I could tell from the people who took an interest in recording the presentation that this was a particularly interesting one.
On the podium was Louis Jordan, an engineer at ElevenLabs, a software company that provides AI voice tools that allows you to turn text into speech, and vice versa, among other services. The company secured $180 million for its Series C funding earlier this year, which brought its valuation to over $3 billion. That evening, Jordan was doing a demo of ElevenLabs’ latest product.
“This is the most stressful live demo I’ve had to do,” Jordan said.
The task? Ordering a pizza.
Just three days ago, ElevenLabs announced its model context protocol (MCP) server. The server allows users to integrate ElevenLabs’ voice tools into their AI chatbot platform. Say you’re building an AI agent on Claude. With ElevenLabs’ MCP server, you can now have an agent with voice functionalities that could, in the context of this live demo, order you a pizza.
“This is the first ever exploration into giving agents tools,” Jordan said, adding that now, more companies are looking to explore this critical paradigm.
Most people in the audience have built an AI agent, but building with MCP is still considered quite new, even among developers. Before the demo, a speaker had asked the audience: “Who here has built an AI agent?” I saw many hands raised in the room. But when asked about having experience with MCP, notably fewer hands were raised.
Let’s go back to the demo. In theory, Jordan could make an agent tasked with making a call to a local pizza restaurant and ordering a margherita pizza on his behalf. Because the agent now has access to Jordan’s voice he had stored on ElevenLabs, it could use his voice to have a conversation with the shopkeeper. And with access to Jordan’s Stripe account, the agent could also carry out the payment for the order. All Jordan has to do is wait for the pizza to arrive at his designated address.
But as with anyone who has done a live demo before, there’s always that chance of the technology glitching at the last minute, even when it had tested out fine in previous attempts, as Jordan had done during a recorded demo uploaded on X.
“Let’s see what happens. I’m not sure this is going to work, but we’ll find out very quickly,” Jordan said when he started running his code.
There was a brief silence as we waited for the machine to do its thing. “I’m going to give it two seconds, and then I’ll restart the service.”
“Come on the internet!”
“Okay, let’s just run it again. Second time’s the charm.”
“I’ll try it one more time. If not, I’ll just go to the backup demo.”
“Okay, I think it’s kind of working. It’s creating the agent. It’s giving it a personality. It’s telling it to order a pizza on behalf of the user. Now, it’s listing my phone number, which is a good start.”
But for some reason, the agent wouldn’t make the outbound call.
Then, Jordan said something I thought was interesting: “The demo gods are definitely not [cooperating].”
The demo gods?
I didn’t know there was such a thing called “the demo gods”. That was the first time I have ever heard of the term, but it wasn’t the last. In a different demo session I attended, there was another mention of the demo god, also in the context of a demo not working out the way the developer had hoped for.
I became increasingly curious about this entity. Does it exist in singular or plural? Is it the demo god or demo gods? What is the reason for its existence? Why do we call upon it, or them, in times of need? What does it say about the developer to mention the demo gods in certain contexts?
This edition is about that: me exploring this curious creature called the demo gods. This is my take in four points:
That technical glitches are not the technical person’s fault.
Isn’t it fascinating that at the preview of technical failures, we create an invisible, untouchable entity responsible for technical glitches in the systems that we’ve built? It’s as if we’re saying, this is definitely not my fault! But if it’s not my fault, the person who built this machine, then whose fault is it? The only natural answer must be that the gods are playing with me.
I thought it was interesting how there was an unspoken consensus about the technical person not being the one to blame for technical failures or glitches, and how natural it felt to call upon the demo gods in these contexts. What this reveals is an underlying assumption that the technical person is effective, is exhaustive; that they get the job done to the best of their capacity.
We imagine the technical person to be highly committed, highly engrossed in the machines that they build, so much so that we are quick to believe that they surely would have done everything they can to make sure the systems run smoothly. Hence, when things glitch, it is that. A glitch. An irregularity. It must be for something that is outside of the technical person’s control. To make myself clear, this is not a sarcastic remark. I’m making a case as to why the placing of blame onto the demo gods felt natural. And that is because we have certain assumptions about the character of a developer that put them at odds with complacency. Which brings me to my next point.
That the world of codes does not submit to the coder’s wishes.
At least not always.
I found this to be an interesting juxtaposition. We think of coders as the makers of the code universe. But the mention of an imagined higher entity — the demo gods — indicates that developers do not see themselves as occupying the most powerful position in the room. This reminds me of anthropologist Nick Seaver’s study on a music recommendation company.
“Again and again, I heard people working on music recommender systems take up similarly pastoral metaphors to describe their work. Despite the supposed rationality of machine learning, the makers of music recommendation rarely described their work as orderly calculation. Instead, they were bushwhackers or park rangers, gardeners or farmers; they were explorers or guides, cartographers or surveyors,” writes Seaver in his book “Computing Taste: Algorithms and the Makers of Music Recommendation”.
Seaver explains that these pastoral metaphors reveal the way power and responsibility are thought of by music engineers. I thought it was a helpful reference to understand the demo gods. “The demo gods”, when seen as a metaphor, showcases how developers relate to the products they build. That there is a limit to the control coders have over their codes. That they, as developers, are not omnipotent and omniscient. An imagery of an entity who are — the demo gods — solidifies the lack of power developers have over their creation, especially when the creation is acting out.
That mischief is always just around the corner.
What does this say about the demo gods? That they are mischievous creatures. They are desperate to be recognised. Nobody acknowledges the demo gods when things work well. Developers wouldn’t chant, “Praise the demo gods!” when things run smoothly. Which is probably why the demo gods are irksome.
I thought this notion of gods that wreak havoc was particularly fascinating. It becomes a reminder of a world that does not run on determinate terms. That there will always be circumstances unforeseen, circumstances that can’t be prepped for. It is a reminder that the world is a game of chance, of luck. That the world does not run entirely based on skills and merit. This brings me to my last point.
That there is a need for a framework to deal with the indeterminate.
“The demo gods” is an attitude towards the indeterminate in the sense that even the people we imagine to be entirely technical and binary also have to deal with uncertainties and need frameworks to navigate them. We run towards comforting narratives when we are pressed by the limits of our own agency.
An uncertain world births myth-making tendencies to tame the existential dread that comes from operating in a world where the floor is quicksand. The more you try to wiggle your way out of it, the more you get stuck. The best you can do is stay still and try to find comfort in that stillness. The existence of the demo gods is a reflection of that — a form of coping mechanism when things don’t go our way.
What does all this say about technology as a cultural product?
It’s that technology is not something that can be entirely figured out. Perhaps like a garden, developers do the work of planting the seeds, creating fences, tweaking things around, in the hopes that things will grow according to the garden that the developers have in mind. But they will never have 100% oversight as to what’s going on all the time. There still lies the magic of waiting for the plants to grow, the flowers to bloom, much like the wait during the running of codes, and the letting of machines to do their thing.
All this is to say that the world does not cease to be a mythical place even when it’s made up of 1s and 0s.
Additional note (added May 6, 2025):
When editing this newsletter, I took out a paragraph explaining my train of thought as to why I wrote an analysis of something seemingly so trivial. The reason was that I didn’t want to feel like I needed to justify why I write what I write in every single newsletter I put out. One, I worried about becoming repetitive. Second, it felt like an overcompensation for a lack of belief in the case I was making. I didn’t want that impression.
But after a conversation with a friend, I decided to add it back via this “additional note.” I am now of the view that in taking up a project where I experiment with my writing formats, an explanation of why I choose to explore the things I explore the way I explore them would only add to the reading experience rather than subtract from it.
On that note, the paragraph goes as follows:
You might think to yourself while reading this edition, “Dita, you’re reading waaay too much into this. It was merely a joke! A passing comment! It doesn’t warrant this kind of analysis.” To that, I would reply: But that’s the whole point! This newsletter, in its current form, is about exploring worldviews (read more about it here). The point I want to make is that worldviews often appear in these taken-for-granted utterances. They might seem trivial, which makes them easy to dismiss, but upon further inspection, they reveal a way of thinking, a system of values, that can manifest in other “more important” instances — vision statements, business decisions, product strategies, etc. I hope to explore more of that in future editions.