Rabbit Holes 2026

Published October 23, 2026

We are temporary beings who insist on making things beautiful. And then, fascinated by our own creations, we invent entire disciplines to understand them — computer science is one such wonder.

We are running an experiment. We want you to pick a question that makes you curious enough to spend an unreasonable amount of time investigating it. You're welcome to modify it, challenge its assumptions, or pursue something entirely different. Most importantly, you don't need to produce something useful. We’d much rather see a careful investigation of something small than an impressive looking project you cannot explain.

Investigate any problem and submit a blog post or write-up documenting what worked, what didn't, and what you learned.

The contest runs for 84 days starting from November 1, 2026. The last date of submission is January 23, 2027. Submit before the deadline here.

We have three tracks: Seed, Sprout and Sapling.

Seed: Explore mathematics, physics, and natural phenomena through code.
Sprout: Question the functions and systems you take for granted.
Sapling: Investigate how programs actually perform, and tweak as needs arise.

You are free to explore anything beyond these as well. After all, we're looking for the curious, not necessarily the knowledgeable.

Seed

The need to understand completely unrelated fields through structures and rules can be a good entry point. Vera Molnár studied art history and aesthetics, and later went on to pioneer the whole field of computational art. Look into geometric paintings, music and natural phenomena and investigate if you can create them from a few lines of code.

What can you do?

Recreate geometric artworks using rules, patterns and randomness or generate trees, coastlines, clouds, and fractals using mathematical models.
Turn mathematical sequences and algorithms into sound, or create visuals that respond to sound or movement of input devices.
Experiment with generating textures and landscapes from a random seed, and mess around with particles, fluid simulations, reaction diffusion systems. That is, blend in physics, biology or anything else.

Many of these phenomena are surprisingly easy to model. If you use p5.js then the rendering part will be handled by the library itself, so that you can focus on the mathematical aspect.

p5.js code beside a generative artwork of green flowing lines — Generative flow lines and the code that draws them

Start exploring randomness, noise, various mathematical functions, fractals and so on. Move on to explore recursive patterns, different visualization techniques and eventually more and more tricks to render geometric patterns in an optimized way.

We’d greatly appreciate if you can show us a gallery of your generative art, and tell us how you infused your creativity into them. The basics are fairly easy to learn in an afternoon, but there are uncountable possibilities of what you can do with even the most simple primitives.

Repeatedly running the same program gives us variations of similar looking trees.

Try to decompose things, and then bring in variety. Once you understand how a certain phenomenon can be abstracted in the form of states, behaviors and relationships along with the constraints — then it’d be dead easy to experiment. What happens when I vary the thickness of a line, increase the size of the ellipses, or maybe apply some new constraints using if-else statements?

Inspiration can come from anything: be it water, leaves, lightning, cauliflower and what not. Even the simplest of shapes can be used to create new possibilities.

The world isn’t static and neither should the code be! Look at birds flocking, and you may stumble upon simulating boids from there. We see things due to light rays bouncing off everywhere, how can we simulate light rays then?

Sound can be generated from simple rules too. How do harmonics affect a bird call? What makes a piano and a flute sound different even when playing the same note? How can we recreate these sounds by adding waves together? Look at how making a synthesizer requires fitting harmonics, or how random noise can turn into the sound of a plucked string.

The trick is to imagine a phenomenon, then discover the smallest set of rules needed to reproduce it. Over time, it’d be possible for you to express yourself by writing code. We can work backwards too. Given a sound, a pattern or a movement, how do we discover the rules behind it? Could different rules produce the same result?

Search for various recreational programming communities on the internet, look into the demos and references provided by various creative-coding libraries (p5.js, Processing etc). And simply, do something.

Things can get really complex when you start going deeper!

Ray marching, ray tracing and the likes <3

How much of this fits into a few kilobytes? Look into the demoscene and sizecoding. .kkrieger fits a 3D shooter into 96 kB by generating its textures and models. Or look at Crow Sign, whose graphics, sound effects and music are made from sine waves. How much can we create from a few simple rules?

Not everything we simulate needs to be an artwork! Computers can be treated like little laboratories to explore physical and biological phenomenon as well. For inspiration, look at Bartosz Ciechanowski's interactive essays.

Why does a pendulum swing? How do waves travel through water? Why does the Moon change its appearance throughout the month? How do birds flock together, or how do spots and stripes emerge on animal skins?

Many of these phenomena can be explored by expressing a few physical rules mathematically and letting a computer evolve the system over time.

Even after choosing the rules, how we simulate them matters. A pendulum loses energy to friction, but what if your simulated pendulum keeps swinging higher? Where did that energy come from? Changing how we advance time can change the behaviour of the entire system.

Some good reading and watching materials to get started:

Document your adventure. Show us what you tried, what surprised you, what failed, and what you discovered along the way. Focus on how you got the idea, what mathematical concepts you borrowed, and what the code snippets do. Then pick a portion, and try to tweak to make it slightly different. Explain if it improved something or caused any catastrophe. We’d love to read your entire rambling chain of thought.

You can submit a Google Doc, Notion file or a live webpage.

Sprout

In this track, you are supposed to question or look for what is hidden. In Seed, you explore how to bring the world of mathematics and physics behind the screens through code. But in Sprout, you are to rip apart the primitives themselves. What have you taken for granted? Even representations are choices. Why do we store an image as pixels, or write a program as text? What becomes easier when we choose differently?

Your input() function or the print() which you had taken for granted contains much complexity underneath. You have to go inside the rabbit holes to figure out how they work.

A line is infinitely thin. A pixel isn't. So how do we draw one?

Pick anything which you had taken for granted, rebuild it from first principles. Explore documentation, and state the different implementation techniques which can be used. Then show how they differ based on their use-cases.

What can you do?

Pick any concept — printing something, allocating memory for array, calling line() in p5.js etc and re-implement it.
Show alternative implementation techniques, and understand the judgement behind each.

To keep things achievable, start with seemingly common things. Feeling ambitious? Pick anything which requires the knowledge of multiple fields. Examples:

How does the terminal work?
How does a video game render a 3D world onto a 2D screen?
How does a computer handle numbers which exceed the native size of integers?
How does a compressed image turn back into pixels? What information was kept, and what was thrown away?
How does a computer calculate sin(x)? How much accuracy do we need, and where does the calculation stop?
How does a music player change playback speed without changing the pitch?

Find an interesting boundary, cross it, and understand what lies underneath. The goal is to understand the decisions that made an abstraction possible. If you have nothing in your mind, go explore random().

You can submit a Google Doc, Notion file or a live webpage. We expect some flowcharts and photos of your rough notes.

Take nothing for granted.

Sapling

In Sprout we encouraged you to tear apart the abstractions that make programming convenient. Now in Sapling, we want you to understand an uncomfortable reality. Your intuition about how computers perform is often wrong. Sometimes an algorithm with fewer operations need not execute faster.

In this track, investigate how a program uses time, memory or space. What can we change, and what do we gain or lose? How can we make better use of available resources?

What can you do?

Pick something you built in Seed or Sprout, or any existing program. Then measure execution time, throughput, memory consumption, executable size or compressed artifact size or whichever metrics are relevant. Essentially come up with metrics to communicate a program’s measurable performance.
Use profilers, flamegraphs, memory analyzers or other diagnostic tools to investigate the bottlenecks.
Form a hypothesis, change the implementation, and measure again. Repeat until you have something interesting to report.
Run your experiments multiple times, control the conditions, and make sure the improvements aren't just measurement noise (tip: turn off Turbo Boost!).

Your investigation might lead you into CPU caches, memory allocation, branch prediction, vectorization or even the behavior of your programming language's runtime.

Sometimes doing extra work helps. Compressing data takes computation, but leaves fewer bytes to read or transfer. Keeping a result avoids calculating it again, but occupies memory. Where does one choice become better than the other, and how does that point move as the input grows?

We want to see your measurements, profiles, failed experiments, and explanations. Show us what changed and why. If your attempted optimization made things worse, that's an interesting result too. Remember the word “ablation”. And what must the result preserve? An exact answer, a recognisable image, or a sound we cannot distinguish from the original? Decide what counts as correct before measuring the trade-offs.

Running short on ideas? Read Unvibecodable. Some example problems:

Find a byte sequence inside a 10 GB file as quickly as possible.
Can a specialized implementation outperform a general purpose built-in function in Python?
How do abstractions affect generated code? Daniel Cristofani’s comments on a Brainfuck ray tracer show how they introduce needless copying and clearing. How would instructions designed around Brainfuck’s tape produce smaller code?
How small can an executable become? Read The Smallest Hello World Program, then try another architecture. Which tricks still work on other architecture?

Portability introduces another constraint. Why do we usually build different executables for different operating systems? Look at Justine Tunney’s Actually Portable Executable and Cosmopolitan. How does one executable work across operating systems, and what assumptions does that require?

If you accomplish something in this track, your next step would be to calibrate yourself against engineering work happening at a much larger scale. Read technical blogs from Netflix, PlanetScale, Cloudflare, and others. Observe the problems they solve, the evidence they collect, and how they present their findings. Pay attention to their method of investigation.

You can submit a Google Doc, Notion file or a live webpage. We expect performance benchmarks (tables), flamegraphs, flowcharts and photos of your rough notes.

Why are we doing this?

Programming has never been more accessible. You can describe an idea to an AI agent and have a working implementation in minutes. You can now build things without ever understanding how they work, wonderful! No, this is a recipe for disaster.

In his recent lecture Math 2.0 , Terence Tao makes a similar observation about mathematics. When machines become capable of solving problems that once demanded enormous human effort, we need to reconsider what we value. A solution is not the only valuable outcome of an investigation. The understanding developed along the way can matter just as much.

We think something similar applies to computer science education.

We don't want to discourage you from using AI. Instead we want you to use it to explore unfamiliar territory and try experiments you wouldn't otherwise have attempted. But don't let it do all the thinking for you. There is a difference between using a machine to explore something and using it to avoid exploring altogether.

Rabbit Holes is our small attempt to reward the former. We want you to become comfortable with uncertainty and discover that understanding something deeply can be far more satisfying than merely getting it to work.

What do we expect?

Oozing curiosity.

And a good write-up that screams it was written by a human who went through frustration and occasional euphoria of figuring something out.

We want to see how you think, what you tried, what surprised you, and how your understanding changed along the way. That’s it.

Footnotes

Why are we telling you to explore and build things which most people never attempt to do? Post-2026 will be different from anything we could have imagined 6-7 years ago, the only remaining bet is to mold oneself like a researcher, capable of dealing with ambiguity. Read the following blogs in this order to understand what we mean:

One of the finest ways to explore more rabbit holes is to browse Hacker News, Lobsters and pouët.net :: your online demoscene resource.