Labels

The Demoscene Was Built to Push Computers. Why Stop at AI?

TL;DR: This Easter I released my first full PC demo at The Gathering 2026. body.mod placed third. I used AI to help write the code, generate 2D assets and turn some of them into 3D. The music was composed by a human musician in Crusaders. Some demoparties would disqualify the result because they treat the production method as proof of creativity. I think that confuses craftsmanship with creativity. Both matter, but they are not the same. Keep dedicated categories where a specific craft or constraint is what competitors are being asked to demonstrate. For general demo compos, disclose how each production was made, and then let the audience judge them together.

ai-demo-creativity

In 1993, at a demo party, I coded a sine scroller. A pretty bad sine scroller. In Turbo Pascal.

That was more or less the peak of my demo coding career.

By then, the demoscene had already travelled from the Commodore 64 to the Amiga, and the PC was becoming a serious demo platform. Each machine changed what we could create. The Commodore 64 invited people to exploit every cycle, sprite and quirk of its sound and graphics chips. The Amiga brought richer graphics, sampled sound and hardware that felt built for audiovisual experimentation. Then the PC arrived with faster processors, graphics cards and a moving target of possibilities.

The scene adapted every time.

I was never a great demo coder. I was not particularly good at 3D either. I understood what I was looking at, and I had opinions about what was good, but there was a large gap between the demo I could see in my head and the one I could build with my own hands.

Thirty-three years later, I entered a PC demo at The Gathering 2026. It was called body.mod, it placed third, and it was the first demo I had attempted to create end to end myself.

The title was a small demoscene-and-aging pun. A .mod is a tracker music module, but at my age the body may need a few modifications too. Add a touch of cyberpunk body modification, and body.mod felt about right.

It is by no means a great demo. It was my first serious run up the learning curve.

The difference was AI tooling.

That sentence alone will make some demosceners stop reading. I hope they keep going.

Because this is not only a story about how I made one demo. It is about whether a scene built around exploring computers can evolve when the computer becomes a collaborator.

A very short introduction to the demoscene

For anyone outside the scene: a demo is a real-time audiovisual production. It is an executable program, not simply a rendered video. Code generates the visuals while music, graphics and effects are pulled together into something that can be abstract, funny, beautiful, technically impossible-looking or occasionally all four.

The demoscene grew out of the crack intros of the early home-computer era. Groups competed to create increasingly impressive introductions, then started making stand-alone demos where the art and technical achievement were the entire point. The scene developed its own groups, handles, parties, archives, status and language. We call competitions compos. Coders, musicians and graphicians form groups and release productions under group names.

I am Wobba of Crusaders.

The scene has shaped me far beyond the code I did or did not write. I spent years as a compo organizer at The Gathering. I learned by watching other demos, talking to people, sharing ideas and seeing what the people around me could make a computer do. I am still learning that way.

In the early scene, pushing the hardware mattered enormously. How many objects could you put on screen? Could you make the machine do something everyone thought was impossible? Could you fit a complete audiovisual experience into 64 kilobytes, 4 kilobytes or less? Those constraints still produce some of the most impressive work in computing.

But when I stood in the audience, I rarely understood every trick behind the code.

I saw the result.

I saw the effects, the sync, the pace, the atmosphere and sometimes a story. A brilliant technical achievement could make me admire the coder. A brilliant demo could make me feel something.

Those are related, but they are not the same thing.

What changed for me

Today I work as a product manager, architect and programmer in enterprise software. Earlier in my career I worked as a computer game designer. I know programming, graphics and game fundamentals. I can reason about systems. I can debug. I can tell when a visual effect is wrong even when I cannot immediately write the mathematics that will make it right.

Before AI, making the demo I wanted would normally have required a team. A strong graphics programmer. Someone comfortable with geometry and 3D mathematics. A 2D artist. A 3D artist. A musician. Perhaps a dedicated designer or director to pull the parts together.

That team structure has produced decades of wonderful demos, and working with talented people still makes ideas better. Creativity feeds on other creativity.

But I do not have all those people sitting around me every evening.

What I do have is an RTX 5090, Nvidia's flagship consumer GPU, local image models, tools that can convert 2D assets into 3D, and coding agents that can turn a detailed description into C++ I can run, inspect, reject, debug and improve.

I am over 50 now. Unlike the version of me who coded that bad sine scroller in Turbo Pascal, I finally have the means to go slightly overboard on the hardware. Some people buy a sports car. I bought a GPU and started making demos again.

rtx5090-pc

For body.mod, I used those tools layer by layer. I started with an idea. I worked out the parts and effects. I generated and refined visual assets locally. I turned some 2D material into 3D. I explained the motion, timing and composition I wanted to coding agents, then ran what they produced and pushed it closer to what I had in mind.

That took many turns and more than a few late nights. Prompting in this kind of flow feels a lot like coding: describe, run, inspect, adjust, repeat. Rinse and repeat until the visuals are not merely plausible, but as close as I can get them to what I saw in my head.

The music was not AI-generated. It was made by a musician in Crusaders, the group I am part of. That contribution did what collaboration has always done in the scene: it added someone else's domain skill and creative perspective to mine.

The rest did not happen in one prompt.

Not even close.

Prompting is not pressing a button

There is a persistent fantasy about AI-assisted work where someone writes "make me an awesome demo," waits thirty seconds, and submits whatever comes out.

That is not how I work.

I have spent many hours on my current production. I develop one part, run it, find what is wrong, explain the problem, try a different approach and repeat. Sometimes the model misunderstands the visual. Sometimes it produces code that is technically plausible but aesthetically useless. Sometimes fixing one glitch creates two new ones. Sometimes I throw away an entire direction.

Conveying a visual idea to a language model is surprisingly hard. Yes, it can inspect an image and describe what it sees. That does not mean it understands the image in the same way I do, or knows which part of it matters to the experience I am trying to create.

I have had to learn how to describe movement, camera behavior, light, material, scale and timing. I have had to learn when words are not enough and a rough reference image communicates more. I have had to build a feedback loop where the agent proposes, I evaluate, and we move another step toward the target.

I am still learning and adapting as the tools change and as I discover where my own process is weak. body.mod taught me what to ask for, what not to accept and how much work still sits between a plausible first output and a demo I am willing to release.

Had I ever heard of Gaussian splatting before I started researching how to approach 3D in my next demo? No. Now I have. The tools did not merely produce an answer. They helped me discover a technique, understand what it could do and add it to the set of ideas I can draw on. The next time I face a 3D problem, I start from a wider base than I did before.

That is a skill.

It is not the same skill as writing a renderer from scratch. It does not deserve the same credit as squeezing an impossible effect into 4K. But "not the same craft" is different from "not a craft."

I am closer to the director than the camera operator

The best description I have found for my role is director.

A film director does not operate every camera, build every set, sew every costume, create every visual effect or perform every role. Christopher Nolan and Martin Scorsese work through people with deep specialist skills. We still consider them creative because creativity also lives in the idea, the selection, the direction, the pacing and the judgment about what belongs in the final cut.

I am not comparing my demo to a Scorsese film. I am comparing roles.

When I work with AI tools, I direct a strange little production crew. I explain what I want. I review what comes back. I keep the parts that move the production toward my idea and reject the ones that do not. I change my mind when an experiment reveals something better. I take responsibility for the final result.

Could I explain every line of the generated C++ code? Probably not.

Can every film director explain the wiring of every light on set?

The more useful question is whether I understand enough to direct the work, judge the result and fix the problems that stand between the current version and the demo I want. My background matters enormously here. Without programming knowledge, I would not know what to ask for when the frame rate drops. Without graphics fundamentals, I would struggle to explain why the camera, material or composition feels wrong. Without years of watching demos and working with computer games, I would have less instinct for pacing and effect.

Taste is not implementation skill. But implementation skill is not the only form of authorship.

Creativity is not the same as craftsmanship

I have written before about a developer colleague who loves the complete arc of programming: sitting down with a problem, thinking it through and writing the code himself. For him, the craft itself is the point. Handing part of that arc to an agent removes something he came to work for.

I respect that.

The same is true in the demoscene. In a 4K intro, the constraint and the code are inseparable from the work. In a graphics compo where entrants submit working stages, the manual process is deliberately part of what is being judged. In a tracked music compo, opening the module and studying how the musician constructed it is part of the culture.

Some compos should absolutely protect a particular craft.

The mistake is turning that into a claim that everything made with different tools is uncreative.

Was Edvard Munch great because of technique, creativity or both? What about Picasso? We can admire the brushwork, the experimentation, the composition, the emotional effect or the break with convention. Different viewers value different parts. Art has never had one clean unit of craftsmanship.

munch-picasso

Neither has the demoscene.

Think about ships.

We can admire a reconstructed Viking ship built with period tools, traditional materials and knowledge passed down through generations. The process is part of the achievement. We can also admire a modern hydrofoiling catamaran designed with computer simulations, scientific measurements, carbon fiber and detailed models of drag and friction. One demonstrates historical craftsmanship. The other combines design, science, engineering and modern tooling to move across water in a way the Viking shipbuilders could not have imagined.

One is not better than the other.

They are interesting for different reasons, and which one moves you more is partly taste. We do not claim the modern boat lacks creativity because its designers used simulations instead of shaping every component by eye.

The same distinction already exists in the demoscene. A 4K or 64K intro is explicitly about constraint. How much can you cram into an absurdly small executable? The size limit is not a side note. It is part of the work.

Graphics compos have already evolved this way. Pixel and old-school graphics still exist alongside digital graphics, 3D renders and combinations of techniques. We did not have to decide that one method was creative and the others were not. We made categories, wrote rules and kept creating.

If a compo wants to celebrate hand-written code or hand-drawn pixels, say so clearly. Call it handcrafted. List the allowed tools. Make the process an explicit constraint in the same way we make file size and hardware explicit constraints.

But do not shut people out simply because their way of creating does not fit the current rulebook. Rules can evolve, categories can be added, and a general demo compo should still be able to judge demos.

The scene already has a precedent for this: the Wild compo. It created room for productions that did not fit the normal platform or format rules. Use any tool, any hardware and any idea; make something creative that can be recorded and shown on the big screen. When creativity outgrew the existing boxes, the scene built a bigger box.

An AI-assisted demo could perhaps compete in Wild. If that were the only category open to me, I would submit it there. But that still feels wrong. A real-time PC demo does not stop being a demo because an agent helped write the code or generate some of its assets. Wild should be for work that is wild in form, not a waiting room for demos made with tools the main compo has not accepted yet.

The parties are already choosing different answers

The Gathering 2026, where I released body.mod, used a deliberately pragmatic rule:

"Entries with primarily AI-generated content are not allowed. AI may be used for assistance, but the majority of the entry must still be the competitors' own work."

Did I break that rule?

I do not believe I did. My interpretation is that AI was tooling inside a production I initiated, directed, iterated on and took responsibility for. The concept, selection, composition, feedback loops and countless decisions were mine. The music came from Nightshade in Crusaders. The tools helped me implement the production. They did not choose what to make, decide which results were good enough or take responsibility for the finished demo.

Could someone read "primarily AI-generated" differently, especially if they count lines of code rather than creative decisions? Certainly. That ambiguity is part of the wider debate. What I like about TG's rule is that it at least tries to distinguish assistance from substitution and leaves room for organizers to make a judgment about the whole work. It is pragmatic rather than ideological.

Assembly Summer 2026 has chosen a practical transitional model. Its traditional demo compos do not allow AI-generated code, graphics or music. It also has a separate AI Coding (Vibe Demo) competition where AI may write up to 100% of the code and assets may be human-made or AI-generated. The entry must still be an executable real-time production, not a single-shot prompt output, and entrants must submit a readme.txt describing the AI tools they used.

That is better than a ban.

But I am no longer convinced a separate vibe coding category is the right destination.

It protects the traditional production method while giving the new one a stage, but it also risks turning AI-assisted demos into a side show. The label starts judging the tool before the audience has seen the production. A weak AI-assisted demo is still a weak demo. A strong one should not need a separate definition of strong.

The 2026 results also make another point. Rasteriunelma by Doomsday won the AI Coding compo. Before Zero by Byterapers and friends won the regular Demo compo. To my eyes, Before Zero is in a completely different league. It is simply a much better demo. AI did not magically level the field or make traditional skill irrelevant. If anything, putting the productions side by side shows how far AI-assisted creators like me still have to go.

The Gathering and Assembly both held their first events in 1992. These are not newcomers chasing a trend. They are old-school institutions that have survived because they adapted as computers, creative tools and communities changed. Making room for AI does not require abandoning their history.

Other established parties have chosen blanket bans. A check of published 2026 rules finds several parties in Germany and Sweden prohibiting generative AI across their compos, sometimes with narrow exceptions for minor assistance. Organizers are allowed to draw those lines. They do a huge amount of unpaid work, and categories with clear rules are a healthy part of the scene.

My concern is not that every compo must allow every tool. It is what happens when the scene as a whole offers no place for people using the tools that increasingly define how computers are used.

Disclosure is not a problem for me. I am proud of the process. Tell the audience what tools were used. Let them decide what the process means when they vote.

AI did not have my idea

I do not believe an LLM is creative by itself in the way a person is creative. It knows patterns from its training. It can combine them in useful and surprising ways, but it does not sit at a demo party in 1993, remember a sine scroller, spend decades gathering experience, then decide it finally wants to make the demo it never had the technical range to build.

That part came from me.

Of course my ideas also come from things I have seen, heard and experienced. Human creativity is not created from a vacuum either. We build on references, culture, technique, accidents and other people. For this article I am deliberately leaving the training-data debate to one side. It matters, but it is a different argument. Think of training here as experience on steroids.

The question in front of me is simpler: when a human has the idea, directs the process, evaluates every iteration and owns the result, does using AI make the work non-creative?

I cannot see how.

The human is still the proponent

At Microsoft we have gone deep into AI-assisted work. Production code is written with AI, directed and reviewed by humans with domain knowledge. It works. It can be stable, maintainable and efficient.

The tool is not the proponent or opponent of quality. Humans are.

The same tool can produce generic filler in one person's hands and something thoughtful in another's. The difference is not that one model suddenly became creative. The difference is the idea, context, taste, direction, iteration and willingness to reject mediocre output.

AI closes capability gaps. It lets one person attempt a production that previously needed a larger team, in much the same way better cameras, editing software and visual-effects tools have lowered the budget needed to make a film. A low-budget film is not automatically worse than a high-budget one. It is made under different conditions.

Would I create a better demo together with excellent coders, graphicians, 3D artists and musicians? Very possibly. Their experience would broaden my ideas, challenge my taste and take the work somewhere I could not reach alone.

That is not an argument against AI. It is an argument for collaboration.

When those collaborators are not around, AI fills part of the gap. It lets me keep creating. I can then show the work to real people, get feedback and adapt. The circle still includes humans. It is simply shaped differently.

The community is the point

To me, the demoscene has always been inclusive. Not in the sense that every entry belongs in every category, or that rules do not matter. Inclusive in the more practical sense that you can show up, learn, make something, put it on the big screen and become part of a community that wants to see what computers and people can do together.

That community formed me.

I have carried the idea into my professional life. For more than fifteen years I have helped organize the Arctic Cloud Developer Challenge, a nonprofit community hackathon for developers, consultants and architects working with Microsoft 365, Power Platform, Azure, Fabric, pro-code and, increasingly, AI. We created it with inspiration from The Gathering: give people a place to learn, compete, socialize and show off what they can make.

The technology changed. The purpose did not.

AI has become a large part of the hackathon in the past few years because it has become a large part of the technology. Participants still need ideas, domain knowledge, judgment, persistence and teamwork. They simply have a new set of tools to explore.

That is what I want from the demoscene too. I want to compete and show my work. If it is good, perhaps I get some acclaim for the creativity, storytelling and ideas. If it is not, I watch the other demos, see what they did better and learn. I have been doing that for most of my life.

One compo, with the process visible

Is music made in a DAW more creative than music generated with ACE-Step or Suno and then directed, selected, arranged and refined by a person? I do not think there is one answer. Taste is subjective, and competitions are allowed to judge process as well as output.

What I object to is the shortcut where AI use itself becomes proof that no creativity or craftsmanship occurred.

My preferred model is straightforward:

  • Put demos in the demo compo, regardless of whether the code was typed by hand, written with an agent or built through a mixture of both.
  • Show a clear production card before each entry: code, graphics, 3D, music, AI tools, engines and other major parts of the process.
  • Keep craftsmanship-specific compos where the method is the point, and name the constraint clearly: handcrafted code, pixel graphics, tracked music, 4K, 64K or a specific hardware platform.
  • Require honest disclosure, with disqualification for hiding or misrepresenting the process.
  • Keep real-time execution as the defining line for demos.
  • Let the audience decide how much the production method matters when they vote.

That respects the heritage without freezing the scene in one era's toolchain.

Some voters will reward a hand-coded effect because they understand how difficult it was. Some will care mostly about the audiovisual experience. Some will discount AI-generated assets. Others will be impressed by how one person directed a complicated production into existence. That is fine. We have always voted with different ideas of what makes a demo good.

9 Fingers by Spaceballs is a good historical example. Released on the Amiga at The Party 1993, it used heavily processed footage of a dancer, driving music and tight synchronization to create something closer to a music video than the effect-by-effect demos many people expected. Some questioned whether preprocessed animation was proper demo craft. It still required clever compression and code to make the result run smoothly on an Amiga 500, but its lasting power comes from the complete audiovisual experience. It placed fourth in the compo and became one of the best-known Amiga demos of its era.

The argument was familiar even then: are we judging how an effect was made, or what happens on the big screen?

The process card gives craftsmanship the credit it deserves without turning one process into the admission ticket for creativity.

If the compo does not exist, build it

There is a fitting historical loop here.

Before the first The Gathering, we in Crusaders spent plenty of time complaining about what other demo parties got wrong. Eventually someone gave us the obvious answer: "So do it yourself, then."

And we did.

The Gathering grew from that impulse. Do not only complain about the room. Build a better room and invite people into it.

If the scene does not adapt, perhaps those of us making AI-assisted demos will eventually have to follow the same advice. Not because we want to split the community, but because we want to participate in it. I would much rather see existing parties create clear, welcoming rules than build a parallel scene from scratch.

The Crusaders slogan is "We break for nobody." It fits where I am now. I am still following ideas, still learning, still adapting and still trying to make the demos I want to see.

The demoscene has always explored what computers can do. We moved from chip tunes to four channels, eight channels, sixteen and effectively no meaningful channel limit. We moved from hand-plotted pixels to 3D packages, modern engines, shader languages and GPUs powerful enough to render 4K at 60 frames per second.

Every generation has had better tools than the one before it.

AI is a bigger jump, and it raises harder questions, but rejecting it as inherently non-creative feels strangely out of character for a culture built around making machines do new things.

I did not become a brilliant demo coder.

I found a different way to make a demo.

body.mod was neither better nor worse because AI helped me create it. It was a first production made with a different process. People watched it alongside the other demos, voted for it and, I hope, enjoyed it.

That was always the point for me.

I already have another one in the works. I cannot disclose much, because a demo should not be released before it enters a compo. But in my own completely biased opinion, it is at least 10x better than body.mod.

That improvement did not arrive in a prompt either. It came from doing the first demo, seeing where it fell short, learning the tools, changing my process and trying again.

Apparently, even with AI, there are no shortcuts around having to get better.

Stay creative :)

Sources and further reading

Labels: