The IOCCC 2025 page collects this year’s winning entries in the long-running International Obfuscated C Code Contest, where the goal is not just to make C unreadable but to cram surprising behavior into tiny programs with style. The standouts people kept pointing to were a Game Boy emulator whose source is literally shaped like a Game Boy, and a 366-byte virtual machine based on a one-instruction computer that can boot Linux and run Doom. That framing mattered, because several people came in assuming the contest was mainly about confusing syntax. It is not. The winning formula is closer to code golf, rule-bending, and conceptual cleverness that still delights a human judge.
That is also why most people did not buy the claim that LLMs make the contest obsolete. The consensus was that current models are decent at deobfuscating finished entries, and sometimes hilariously overreact to them as possible malware, but still weak at producing IOCCC-grade work on their own. The missing ingredient is not token-level weirdness. It is the taste to find a funny or beautiful angle, exploit constraints, and make the result feel like a stunt worth showing off. One winner even explained that the real work was writing a full emulator first, then spending roughly 100 hours stripping it down to the contest’s character limits, dropping hardware features Tetris did not need, and abusing edge cases in both C and the contest checker to make it fit. That pushed the conversation toward a sharper definition of the contest: impressive entries often become obfuscated as a side effect of compression and trickery, not because obscurity itself is the end goal.
The other strong theme was that the contest remains charmingly hostile to newcomers. People complained that the site makes it oddly hard to find the actual source files, understand the submission flow, or even figure out what the contest is without prior context. A few replies pointed out the direct links, but that mostly reinforced the point that a motivated insider can navigate it while everyone else has to hunt. The affection for IOCCC is still there. People were thrilled it is active again, swapped side references like the dormant Underhanded C Contest, and enjoyed the anime nods tucked into entries. But the practical read is simple: the magic is still in the work, while the presentation still assumes you already know the club rules.
If you write or judge programming contests, treat IOCCC as an art-and-engineering competition, not a benchmark for raw code obfuscation. Also expect newcomers to bounce off the site and rules unless you provide a much clearer path to the source, the demo, and what each entry is trying to prove.
Strongly positive and amused. People were impressed by the technical audacity of the winners and happy IOCCC is still alive, with the main frustration aimed at the contest website and submission process rather than the entries themselves.
Key insights
01
The Game Boy stunt was brutal compression
Fitting a usable Game Boy emulator into IOCCC limits took far more than cosmetic obfuscation. The author says the project started as a normal emulator around 6000 non-whitespace characters, then got cut down over about 100 hours by removing features Tetris did not need, leaning on ugly old C tricks, and even exploiting quirks in the contest's own checker and Makefile allowances. That makes the entry easier to understand as compression under adversarial rules, not random cleverness.
If you want to understand or replicate IOCCC-style work, study the reduction process, not just the final source. The interesting engineering is in choosing what can be deleted and what rules can be bent without breaking the stunt.
The useful framing here is that IOCCC is closer to code golf plus artistic judgment than to commercial code obfuscation or DRM. Entries win by doing something conceptually sharp in very little code and by pleasing human judges who reward novelty, elegance, and once-only rule abuse. That cuts through the lazy "LLMs can obfuscate too" reaction, because machine-generated mess is not the same thing as a compact trick that still lands as a joke, puzzle, and technical feat at once.
Do not evaluate this contest with metrics like unreadability or resistance to reverse engineering. Evaluate whether the program does something disproportionate to its size and whether the trick would still feel clever after the source is explained.
Several people with direct experience said current models are much better at explaining finished obfuscated programs than at inventing strong new ones. The concrete examples were telling. Models produced superficially clever rewrites of simple conditions, but many were wrong on edge cases, relied on undefined behavior, or were just algebraic reshufflings rather than the kind of size-aware, semantics-preserving transformation IOCCC rewards. The same pattern showed up outside C too, with K brought up as another place where models know the vocabulary but fail to exploit it well.
Use models as reverse-engineering assistants or idea generators, not as a substitute for the final stunt design. If you ask them for compact trick code, test edge cases hard and expect to do the real compression work yourself.
The one-instruction Linux VM hides a real design space
The tiny VM that can boot Linux is not just a party trick. People dug into the actual instruction model, a SUBLEQ-like one-instruction set computer with operand dereferencing, and noticed that the published descriptions and reference implementation leave important details murky. Questions around byte versus word addressing, relocation, timer behavior, and magic memory locations suggest the hard part is not merely shrinking a VM down to almost nothing. It is defining a minimal machine that toolchains and operating systems can still target coherently.
If minimalist VMs interest you, read the README and implementation together before taking the architecture at face value. Small spec choices around addressing and special memory semantics have outsized consequences for compilers, linkers, and portability.
The navigation complaints were not nitpicking. Even people excited by the winners said it was oddly hard to find the source, understand the inventory, or figure out how the contest works unless you already know the IOCCC layout. Replies with direct anchors and hidden-in-plain-sight links only underscored the issue. The information exists, but it is organized for insiders who already know where to click.
If you share IOCCC entries with a team or audience, link directly to the source and demo assets rather than to the front page. If you run a niche technical event, do not assume the charm of legacy presentation offsets the cost of making newcomers work this hard.
Not everyone saw the Game Boy-shaped source as fresh genius. The pushback was that making obfuscated code resemble an image is a well-worn IOCCC move, so the visual stunt alone should not be mistaken for the whole accomplishment. That is a useful correction because it separates the aesthetic gimmick from the underlying emulator work, which is the harder part.
When you show off an entry, focus on the behavior it achieves under the contest limits, not just the visual joke. The shape may get attention, but it is rarely the deepest technical contribution.
Even with the FAQ language allowing AI tools, some people were not convinced the rules are internally clean. The sticking point was ownership and permission. If rule 7 is read as banning code you do not own, then model output creates ambiguity unless the contest explicitly states how it treats generated code and attribution. The current posture looks intentionally vague, probably to keep discretion and avoid inviting low-effort submissions.
If contest integrity matters, write AI rules that cover authorship, ownership, and acceptable assistance separately. Leaving that implicit may preserve flexibility, but it also creates avoidable argument at the edges.