JS13K and JS13P

"Every great game jam is defined by its constraint. When the tools evolve, the constraint has to evolve too."

For those who don't know, js13k is an annual gamejam competition focused around building optimised JavaScript games in less than 13 kilobytes of code. In the most recent competition, there were more AI-built games submitted than ever before.

That shouldn't be surprising to anyone who has followed the tech industry in the last few years.

Unsurprisingly, there has been backlash from the veteran developers. Apparently there's the open question of why they should bother submitting next year if it means spending time meticulously fine-tuning the packing and design of their games under 13 kilobytes only to have their work buried in a tide of rapidly generated AI projects.

They aren't wrong to feel that way. The spirit of JS13K was always to demonstrate human ingenuity under a constraint – the constraint of file size. If the spirit of the competition becomes unfair, what's the point?

So how do you actually fix it?

The transparency trap

You can't put the genie back in the bottle. And simply adding a line to the rules that says "No AI allowed" on the honour system doesn't solve the problem when the final artifact is a minified 13 kilobyte file.

Even if everyone wants to play fair, you immediately run headfirst into the boundary problem. Where do you draw the line on what counts as "using AI"?

• Is it okay to brainstorm theme ideas or game mechanics with an LLM before you open your IDE?
• What if you write the game loop by hand, but let editor autocomplete fill in the boilerplate WebGL matrix maths? That's been allowed for a long time right?
• What if the code is 100% hand-written, but you used an AI tool to generate a sprite, or a sound effect?
• What if you wrote the game yourself, and then asked an agent at the last minute to shave 600 bytes off the bundle so it fits under 13 kilobytes?

When a rule is both blurry and impossible to verify from the final zip file, two bad things happen at once: honest developers will spend time second-guessing their own workflow, and anyone who quietly vibe-codes an entry in an afternoon can look indistinguishable on the submissions page from someone who spent forty hours hand-tuning jump physics.

So my first conclusion is that without transparency, suspicion poisons the jam.

My proposal? Introducing JS13P

Instead of trying to police an invisible, blurry middle ground, what if we made it part of the whole competition? And we gave both ways of building games a constraint that actually makes them interesting?

So, what if… the competition was split into two distinct buckets: JS13K and JS13P.

1. JS13K: The classic craft jam (13 kilobytes)

JS13K stays true to the traditional spirit of the jam. You have to build a web game under 13 kilobytes of zipped JavaScript, HTML, and assets. Every line of code and every asset is hand-crafted. No AI allowed.

How do you solve the transparency problem? Developers livestream (or perhaps record a continuous timelapse of) their game dev process.

Requiring a build stream or VOD repository removes the guesswork. More importantly, it turns the craft itself into part of the event – watching someone hand-roll a tiny audio synth or shave 200 bytes off a collision routine is half the magic of JS13K anyway.

2. JS13P: The AI-assisted companion jam

Rather than pretending AI doesn't exist, run an official companion event right alongside it: JS13P.

What does the P stand for? Prompts, of course.

In JS13P, you still livestream your development process for full transparency, and any AI tool is allowed – coding agents, asset generators, level builders, whatever you want to bring to the table.

However, instead of staying under 13 kilobytes of output code, you have to stay under 13 prompts.

And across all 13 of those prompts combined, your total prompt input cannot exceed 13 kilobytes of text – roughly 2,200 words in total.

Finally, because AI collapses build time, JS13P should run in a much shorter window – a sharp 24- or 48-hour sprint rather than a full month.

Why 13 prompts changes the game

Think about why the original 13 kilobyte limit worked so well for JS13K in the first place.

In an era where an empty web page routinely ships several megabytes of framework scripts, forcing developers into 13 kilobytes turned file size into a game design puzzle. You couldn't brute-force your way through it. Every byte had to earn its keep.

Right now, AI-generated games suffer from the exact opposite problem: infinite retries encourages lazy design.

When prompts are free and unlimited, anyone can sit in a loop firing off three hundred micro-corrections. The constraint disappears. Capping JS13P at 13 prompts and 13 kilobytes of total prompt text puts the friction back where it belongs:

• Every turn becomes high-stakes. You can't burn four prompts arguing with an agent over a broken canvas resize handler. You have to think clearly about architecture, state, and game feel before you hit enter.
• The constraint moves from the code to the specification. How well can you articulate a complete, cohesive game – its mechanics, pacing, visual identity, and edge cases – in 2,200 words across at most 13 steps?
• The livestream becomes a spectator sport. Watching a developer sit on Prompt #12 with ten minutes left on the clock, deciding whether to risk their final 800 bytes of prompt budget on a boss fight or a bugfix, has genuine dramatic tension.
• Every submission ships with its own history. Because there are at most 13 prompts totalling under 13 kilobytes, every game in JS13P can publish its exact prompt log right next to the "Play" button. Reviewers aren't just grading an opaque bundle, they can see the craft in how the builder steered the model.

Protecting both crafts

A competition is only fun when everyone agrees on the rules of the sport. Right now, putting hand-crafted 13 kilobyte games and AI-generated games into the same unmarked bucket is like entering a motorbike in the Tour de France: it demoralises the cyclists, and it doesn't even make for an interesting motorsport race.

Hand-crafting a game in 13 kilobytes of raw JavaScript is a test of low-level ingenuity and patience. Will it stick around forever? Probably not, but let's still pay tribute to that old craft while we still can.

Meanwhile, steering an agent to build a genuinely fun game in 13 prompts and 2,200 words of specification is a completely different discipline.

Both can be fascinating to build and watch – as long as each one has a constraint tough enough to filter out the slop:

• JS13K: 13 kilobytes of output, zero AI, livestreamed hand-craft process.
• JS13P: 13 prompts (and 13 kilobytes of input), any AI, livestreamed over a short sprint.

You can't ban the new tool – but you can give it a constraint hard enough to turn it into a real competition.

Article published on: 9 Oct, 2026