the canon#

RFC 1149 — "A Standard for the Transmission of IP Datagrams on Avian Carriers." IP over carrier pigeon. Specifies encapsulation, MTU, and the failure characteristics. Notably: it was actually implemented and tested in Bergen in 2001, achieving a 55% packet loss rate and ping times measured in hours.

RFC 2324 — the Hyper Text Coffee Pot Control Protocol, which gave the world HTTP 418 "I'm a teapot." Still returned by a nonzero number of production servers and still occasionally proposed for removal, which reliably generates more discussion than any real feature.

RFC 1925 — "The Twelve Networking Truths." Not a joke, exactly. A list of things that are simultaneously funny and among the most useful engineering aphorisms ever written:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.

(6a) It is always possible to add another level of indirection.

(11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

Number 11 is the most predictive sentence in computing.

RFC 748 — TELNET RANDOMLY-LOSE Option, the first April Fools RFC, which parodied the specification format so precisely that it reads as a real document until you notice what it specifies.

why they are well written#

Here is the thing: a joke specification only works if the reader can follow the technical content exactly. The humor lives in the gap between rigorous form and absurd content, and the gap only exists if the form is genuinely rigorous.

So the author cannot hide behind jargon. Cannot be vague. Cannot leave the failure modes unspecified, because the failure modes are the joke.

RFC 1149 specifies the MTU, the encapsulation, the retransmission behavior, and the security considerations. It is a more complete specification of a transport protocol than a lot of real protocol documents, in one page.

what to steal#

Specify the failure modes. The joke RFCs always do, because failure is funny. Real specifications frequently do not, because failure is embarrassing. Failure is also the part your implementer most needs.

Be short. Every one of these fits on a page or two. Length is not thoroughness.

Use concrete examples. The absurd ones are memorable; ordinary concrete ones are just as clear and less funny, which is fine.

Write the security considerations section honestly. RFC 1149's is a single sentence about the possibility of the carrier being intercepted by a predator. It is more informative than a great many real ones, which say "security considerations are out of scope for this document" — a sentence that should be banned.

the serious point#

Technical writing quality is not about vocabulary or formality. It is about whether the reader can reconstruct what you meant.

The joke RFCs are readable because their authors were writing for an audience they wanted to make laugh, which requires being understood. Most specification authors are writing for an audience they want to satisfy, which does not.

If you want to test whether your specification is clear, hand it to someone and ask them to implement it without asking you a question. Every question they need to ask is a defect.

The pigeon RFC would pass that test. Most of what I have written would not.

the tradition#

It continues, annually, and it is one of the better things about a standards organization that could easily have become entirely humorless.

An institution that can laugh at its own form is one that understands the form is a tool rather than a ritual. That is worth more than it sounds.

Here is what the rest of us should be stealing.

the frame budget#

A game running at 60 frames per second has 16.6 milliseconds to do everything: input, simulation, physics, animation, culling, draw call submission, audio, and whatever the game is actually about.

Not on average. Every frame. A frame that takes 20 ms is a visible stutter, and players notice a single dropped frame.

That constraint produces a discipline the rest of software largely lacks:

Budgets are allocated per subsystem, in advance. Physics gets 3 ms. AI gets 2 ms. If a system exceeds its budget, that is a bug with an owner, not a "performance improvement opportunity for next quarter."

Compare to how most web services handle latency: an aspirational p99 target, no per-component budget, and no mechanism that fails when a component regresses.

Steal this. Give each layer of your request path a latency budget. Assert on it in tests. A change that pushes the database layer from 20 ms to 40 ms should fail CI, not show up on a dashboard a month later.

Worst case matters more than average. Nobody in games optimizes mean frame time. They optimize the 99.9th percentile, because that is what the player experiences as jank.

The web equivalent is obvious and widely ignored.

determinism as a feature#

Multiplayer games with lockstep networking require that the same inputs produce bit-identical outputs on every machine. That is a much stronger constraint than "correct," and achieving it teaches you where nondeterminism actually hides:

• Floating point differences across compilers and architectures.
• Iteration order over hash containers.
• Time-based logic.
• Uninitialized memory.
• Anything threaded without a strict ordering.

Every one of those is a source of flaky tests and unreproducible bugs in ordinary software, and most engineers have never had to hunt them systematically.

If your test suite is flaky, the game industry solved that problem decades ago and the answer is: make the system deterministic, then the flakiness is a bug you can find.

data-oriented design#

The insight: modern CPUs are enormously fast and memory is enormously slow, so performance is dominated by cache behavior rather than instruction count.

Which means the layout of your data matters more than the cleverness of your algorithm, at least until the constant factors stop dominating.

Arrays of structs versus structs of arrays. Contiguous memory over pointer chasing. Processing in batches over per-object virtual dispatch.

This applies directly to any data-processing code and most developers have never been taught to think about it. If you have a hot loop over a collection of objects and it is slower than it should be, the layout is usually why.

shipping to a fixed target#

Console games ship to hardware that does not change for seven years. You cannot tell the player to buy more RAM. You cannot autoscale.

That produces genuine engineering rather than procurement: measure, budget, optimize, cut scope, ship.

There is a lesson here for cloud-native development, where "we will scale it" has become a substitute for making things efficient. The teams that treat their resource envelope as fixed produce dramatically more efficient systems, and the constraint is a gift.

the thing games do worse#

To be fair: game codebases are frequently a mess, crunch culture is a genuine industry problem, testing practices are often weaker than in other software, and "ship it and patch it" has become normalized in a way that undermines a lot of the above.

Take the engineering discipline. Do not take the working conditions.

the talks to look for#

The technical postmortems are the good ones — a team explaining what went wrong in a shipped product, in detail, publicly. The industry has a stronger culture of this than almost any other software domain, and the material is excellent regardless of whether you care about games.

The argument is settled in practice: models solve most early puzzles in seconds, the global leaderboard is not a meaningful competition anymore, and Eric Wastl has asked people not to use AI for leaderboard attempts. Some people ignore that.

I think the argument is also beside the point, and I want to make the case for what these puzzles are actually good for.

what the leaderboard was ever worth#

The global top 100 was always a competition between a small number of extremely fast competitive programmers, most of whom had done thousands of hours of practice specifically for this. For everyone else it was scenery.

If your enjoyment depended on that leaderboard, it was already not for you before any model existed.

what the puzzles are good for#

Practicing a language you do not know. This is the best use and it is what I do every year. Twenty-five bounded problems with clear specifications and verifiable answers is an excellent scaffold for learning a language's idioms. You are not fighting the problem, so you can concentrate on the tool.

Do it in something uncomfortable. Rust if you write Python. A Lisp if you write Java. Uiua or J if you want to genuinely reconsider what a loop is.

Finding the gap between working and good. Almost every puzzle has a naive solution that works for part one and does not terminate for part two. That gap — where you have to actually think about the algorithm rather than just express the problem — is where the learning is.

That is also the part models are least reliably good at, incidentally. They will write the naive version confidently.

Reading other people's solutions. The subreddit's solution megathreads are one of the better learning resources in programming. Twenty implementations of the same problem in different languages by people of different skill levels, all solving something you just spent an hour on, so you have full context.

You will learn more from reading five solutions after solving it than from solving three more puzzles.

A shared thing. For a few weeks in December a lot of programmers are all thinking about the same problem on the same day. That is a rarer thing than it used to be and it is worth something.

on using a model#

I do not think there is a moral question here for anything except the leaderboard, where the request is explicit and honoring it is basic decency.

For everything else: it is your time and your learning. If you use a model to solve everything instantly, you will finish faster and learn nothing, which is a trade you are allowed to make and which defeats the entire point of doing a programming puzzle for fun.

The interesting middle ground, which I recommend: solve it yourself, then ask a model to critique your solution. "What is the time complexity? What would break at larger inputs? Is there a standard algorithm for this I should know?"

That is a genuinely good use. You get the learning from solving it and you get the thing you did not know from the critique. It is closer to having a knowledgeable colleague than to having someone do your homework.

the thing that actually bothers me#

Not the puzzles. The people who have decided that because a model can do the easy version of something, learning to do it is pointless.

That reasoning has been available for every tool ever built and it has been wrong every time. Calculators did not make arithmetic understanding useless. Compilers did not make understanding what the machine does useless. IDEs did not make knowing the language useless.

The understanding is what lets you tell when the tool is wrong. That has never been more valuable than it is now, when the tool is wrong fluently.

Go do the puzzles. In a language you do not know. Slowly.

The proximate cause is obvious. The consequence is not, and it is worse than the obvious version.

the obvious part#

If you have a question about a TypeError, you ask a model. It answers in three seconds, in context, without telling you the question is a duplicate, without closing it as opinion-based, and without a comment from someone explaining that you should not want to do the thing you are doing.

That is a better product for the asker. It is not close.

The cultural failures are real and much-discussed — the moderation tone, the duplicate-hammer, the hostility to beginners — and they made the site fragile. But a site with perfect culture would still have lost this. The interaction model is simply better.

the part that should worry you#

Stack Overflow's answers are a large fraction of the training data that makes models good at answering programming questions.

Follow that through. The models learned from a corpus that humans produced under a set of incentives — reputation, peer review, the specific dopamine of being right in public — and those incentives have now been substantially removed. New questions are not being asked. New answers are not being written. The corpus is frozen at roughly 2023 plus a thin tail.

Which means: for any technology released after that point, the model's knowledge comes from documentation, release notes, GitHub issues, and blog posts, rather than from thousands of people working through real problems in public and having their answers corrected by peers.

You can already feel this. Ask a model about a library that came out last year and the answer has a different texture — more confident, less battle-tested, more likely to be a plausible synthesis of the README than a real solution to a real problem someone actually hit.

where the knowledge goes now#

It does not disappear. It moves to places that are worse for everyone:

• Discord servers, which are unindexed, unsearchable from outside, and effectively write-only. A brilliant debugging session in a Discord thread helps four people and then is gone.
• GitHub issues, which are better — indexed, searchable, versioned — but scoped to a single project and rarely capture the cross-cutting "how do these two things interact" knowledge that Stack Overflow was uniquely good at.
• Private model conversations, which help exactly one person and produce no artifact at all.

That last one is the real loss. Every debugging session that used to end in a public answer now ends in a chat log that nobody else will ever see.

is there a fix#

I do not think there is a clean one, but a few things help.

Write it down publicly. If you spent four hours on something, the blog post takes twenty minutes and it is the highest-leverage twenty minutes available to you. It helps the next person and it goes into the corpus.

Answer in issues, not chat. When someone asks in Discord, answer in Discord and then put it in a GitHub discussion. Same effort, permanent artifact.

Maintainers: write the failure modes into your docs. The reason Stack Overflow existed is that documentation describes the happy path. A "common errors" page in your docs absorbs an enormous amount of what used to be questions.

the honest conclusion#

We are consuming a commons that was built by a specific social arrangement, and that arrangement has stopped producing. The models are good because a decade of people answered each other's questions for internet points, and we have replaced the mechanism that generated that with one that generates nothing.

That is not a reason to go back. It is a reason to be deliberate about what replaces it, and right now nobody is being deliberate about it at all.

The technical achievement is real and got buried under the meme, which is a shame, because the technical achievement is the interesting part.

what is actually different#

Previous image generation from a chat interface was a handoff: the model wrote a prompt, a separate diffusion model rendered it, and the chat model never saw the result in any meaningful sense. You could not say "same picture but move the cat" because there was no shared representation.

Native generation means the same model produces the image tokens. That gives you:

• Real editing. "Make the sign say something else" works, because the model understands the scene it produced.
• Text that renders correctly. This has been the single most obvious tell of AI images for three years, and it is largely fixed. Infographics, diagrams, menus, and UI mockups now come out legible.
• Instruction following at a level diffusion models never had. Ten objects with specified positions and colors. Diffusion models fall apart around four.

For developers specifically, the practical unlock is diagrams and mockups. "Draw me an architecture diagram with these six services and these arrows, in a clean technical style" now produces something you can actually put in a document.

the part everyone is arguing about#

Studio Ghibli did not consent to this and Hayao Miyazaki has been publicly, memorably contemptuous of AI-generated animation for years.

The legal position is genuinely unsettled. Copyright does not protect style — you cannot own "watercolor backgrounds and round faces" — which is why the outputs are probably not infringing on their face. Whether training on the works to acquire the style is infringement is the actual contested question, and it is being litigated in several jurisdictions simultaneously with no consistent answer yet.

The ethical position is less unsettled and more uncomfortable. A studio spent four decades developing a visual language through enormous manual labor — Miyazaki's teams famously hand-drew crowd scenes frame by frame — and that language is now a free preset. Whatever the courts decide, something was taken that was not offered.

I do not think "it is legal" resolves that, and I do not think "it is theft" resolves it either. It is a genuinely new situation and the reflex to force it into an existing category is making the conversation worse.

the practical guidance#

If you are shipping a product that generates images:

• Do not name living artists or active studios in prompts you send on behalf of users, and filter for it. The legal risk is unquantified and the reputational risk is not.
• Understand your provider's indemnification terms. They vary a lot and most people have not read them.
• Provenance metadata (C2PA) costs you nothing to include and will matter more every year.

the thing that will actually change#

Stock photography as a business is finished, and has been finishing for a while. So is a large chunk of low-end commercial illustration — the spot art, the blog headers, the marketing filler.

What is not finished is illustration where the point is that a specific person made it. Miyazaki's films are not valuable because they look like that. They look like that because of what they are.

The model can produce the surface. It has nothing to say.