There is a benchmark floating around AI circles called the pelican test: ask a model to draw an SVG of a pelican riding a bicycle. It is a joke, but a useful one — a fast way to see whether a model can compose spatial ideas or just pattern-match. Andrej Karpathy says we are leaving that territory. His latest experiment, which hit the top of Hacker News this week, makes the case with a bird of a different kind.
Instead of one SVG, he handed an LLM the opening paragraph of The Lord of the Rings, a budget of one million tokens (about $10), and a prompt: render this as a 3D scene. The model worked for roughly two hours and wrote 5,500 lines of code that procedurally generates the story's world — geometry placed in (x, y, z) coordinates, assets orchestrated, everything animated. Here is the raw output, jank and all:
Watch the video on blog.koardy.com
Video: Andrej Karpathy's original post. The world is procedurally generated by the model — no human placed a single polygon.
It is kind of janky. It is also kind of astonishing. Not because the output is polished — it is not — but because the task exists at all. A model held a spatial plan in its head for two hours, coordinated thousands of moving parts, and produced a coherent, explorable scene. A year ago the pelican barely stayed on the bicycle.
The economics that actually matter
Karpathy's sharpest observation is not about capability. It is about cost:
No one in their right mind would ever spend the time to write something this custom but LLMs have all the stamina and patience in the world, so it's an example where we go from "no one would ever do this" to "sure, why not, it's ~free".
Read that twice, because it describes a category change, not an improvement. Most coverage of AI progress focuses on the quality frontier: better code, better images, better benchmarks. But a second frontier gets less attention — the feasibility frontier. Whole categories of work never happen, not because they are impossible, but because no one can justify the hours. A bespoke visualization for one paragraph of a novel. A one-off internal tool. A throwaway prototype to settle an argument in a meeting.
When the marginal cost of custom work falls to $10 and two unattended hours, the backlog of "not worth it" projects becomes a frontier of "why not." Karpathy extends the thought to games: hyper-custom worlds, generated on demand, that you could drop players into — an ephemeral GTA of whatever you can describe. That is speculative. The spreadsheet version is not: any team sitting on a list of small, custom, never-prioritized builds should reprice that list.
The part that broke
The demo also exposes a weakness, and Karpathy names it plainly: the model could not audit its own work. It cannot natively watch video or play the game it built. To check itself, it had to take screenshots at intervals, slowly and clumsily, and it still missed things. That is where the jank came from.
This is the detail engineering teams should sit with. Generation capability is compounding. Verification capability is lagging. The model can produce a world faster than it can look at one.
We see the small-scale version of this every day with code generation. The model writes the diff in seconds. The expensive, irreplaceable step is the human (or the test suite) looking at the result and saying: not quite, fix the camera angle at frame thirty. When review is slow, vague, or scattered, the speed of generation buys you nothing. You just accumulate unreviewed output faster.
Karpathy's two-hour run needed screenshots and patience. Your team's AI-generated code, copy, and designs need the same thing in structured form: a place where the artifact, the feedback on it, and the decision about it live together. That is the bet behind how we build Kahoona — tasks, commits, PRs, and their review conversation on one surface, so the loop between "generated" and "approved" stays tight instead of dissolving into chat threads. 👉 See how it works
What to take from the pelican
Three things, we think.
First, the pelican test is retiring. Simple composition benchmarks no longer discriminate between models. The interesting evaluations now look like Karpathy's: long-horizon, multi-file, spatially or logically coherent projects with a real budget.
Second, reprice your backlog. The correct question is no longer "can a model do this well?" but "what have we not built because a human would never spend the time?" Some of those items are now nearly free.
Third, budget for review, not just generation. The model's blind spot — it cannot easily perceive its own output — is your team's blind spot too if feedback has no home. Generation at $10 is only cheap if catching the jank is also cheap.
The pelican got off the bicycle and built Middle-earth, badly, for ten dollars. The next constraint is not what models can make. It is whether your workflow can keep up with what they make.
Related: AI Video Just Hit 30 Seconds, and the Bottleneck Moved
Top comments (0)