The Librarian 2: What AI Game Building Can and Cannot Do

The Direct Answer

The Librarian 2 is strong evidence that one person can now turn a specific game idea into a surprisingly complete browser prototype with AI coding agents. It is not evidence that making a good commercial game has become easy, or that game developers are obsolete.

Matt Wolfe used Claude Code with Opus 5 for the broad first build, then moved the project to Codex with GPT-5.6 Sol for refinement. The agents compressed implementation: 3D rendering, procedural floors, progression, bosses, disasters, generated audio, menus, and a playable loop appeared much faster than a conventional solo build. The expensive work immediately moved somewhere else: deciding what was fun, spotting what felt wrong, explaining the intended behavior, testing edge cases, balancing the loop, and choosing which imperfections mattered.

Watch the Build

Video and project credit: Matt Wolfe. Watch the original episode on YouTube, follow Matt on X, and explore FutureTools.

Source Note

Matt's video and transcript are the source for the model workflow, the reported 90-minute first build, the 10,400-line and 33-module counts, and the problems found during the recorded playtests. These are creator-reported results from one project, not a controlled model benchmark.

The public repository and its complete design reference are the source of record for the current architecture, controls, testing, fixed bugs, and known gaps. The repository has continued to evolve, so its present state should not be treated as the exact code snapshot visible at every moment in the video.

Link Map

What Matt Actually Built

The premise is deliberately absurd and mechanically clear: children pull items from shelves, loose items raise a Chaos meter, and the librarian must collect and file them before closing time. The sequel turns that loop into a 3D roguelite with generated floor plans, upgrade drafts, persistent progression, bosses, disasters, character choices, and branch-specific environments.

In the video, Matt reports a first version of roughly 10,400 lines across 33 modules with no separate asset files. The current repository confirms the unusual zero-asset architecture: textures, materials, character geometry, sound effects, and music are generated in code at boot. Its README describes vanilla ES modules, Three.js, postprocessing, and Vite rather than a conventional game engine.

The Two-Model Workflow

The useful pattern is a staged handoff, not a model tournament.

1. Define the game before the implementation. Matt supplied the original loop and a sequel brief: 3D, procedural levels, roguelite upgrades, persistent progression, bosses, and disasters.
2. Let one agent create a coherent vertical slice. Claude Code handled the first broad pass and used browser interaction to test and rebalance its own output.
3. Play the build before expanding it. Matt immediately found reversed movement, unclear pickups, weak navigation cues, missing menu escape paths, camera problems, and balance issues.
4. Checkpoint the project. He moved the code to GitHub before changing models, creating a recoverable state rather than letting one long session become the only copy of the work.
5. Write the context into the repository. A detailed design file gave the next agent architecture, formulas, controls, known bugs, rationale, and constraints.
6. Use a second agent for bounded refinement. Codex then worked on camera behavior, navigation, projectiles, lighting, readability, and other specific problems.
7. Put another person in front of it. Producer Dave's live playtest exposed confusion the builder had already learned to work around.

The model switch may have helped, but the bigger improvement came from changing the task. The first agent faced an open construction problem. The second received a working system, a written reference, observed failures, and narrower acceptance targets.

The First Playtest Was More Valuable Than More Code

The first build looked impressive and still failed basic interaction tests. Forward and backward movement felt reversed. The player could enter long screens without a reliable back path. Pickups and objectives were difficult to read. The map and directional cues did not communicate enough. Some encounters were too punishing; other systems existed without teaching the player why they mattered.

These are not cosmetic details. They are the game. A code review can prove that a compass function returns a direction. Only a playtest shows whether a new player notices it, trusts it, and can act before the chaos meter overwhelms them.

The repository's current design document shows what happened after those failures became explicit. It lists fixed softlocks, stale input listeners, a CSS specificity bug that blocked scrolling, inverted movement, per-run resource leaks, audio-graph failures, and balance spirals. That list is more persuasive than a one-shot demo because it preserves the mistakes as engineering knowledge.

The Design Document Was the Real Model Handoff

A fresh agent does not need every chat message. It needs the durable state of the project. The current DESIGN.md explains what the game is, how each mechanic works, why formulas were chosen, where code lives, which bugs were already fixed, how to test the system, and what remains incomplete.

That file performs four jobs:

1. Specification: it defines intended behavior instead of forcing the agent to infer design from code.
2. Memory: it records why choices changed, so later revisions do not reintroduce rejected behavior.
3. Test map: it connects mechanics to deterministic seeds, lifecycle checks, reachability, balance trajectories, and browser recipes.
4. Handoff contract: a person or different model can continue without replaying the entire original session.

This is context engineering in a practical form. Keep decisions close to the code, make them reviewable, and update the reference when accepted behavior changes.

What AI Handled and What the Human Still Owned

Matt's own verdict is the right one: the result was good enough to impress and play, but not something he would put on Steam and sell. The gap was not another thousand lines of code. It was the accumulated standard of a finished game.

Prototype Is Not the Same as Product

The current repository is more mature than the early build in the video. It reports automated mechanics, lifecycle, deterministic-seed, and generator-reachability tests, plus scripted balance work and local telemetry. It also names the remaining gaps: a broader human playtest cohort, online competition, mobile touch controls, more boss combinations, and possible bundle-size work.

A Game-Building Workflow Worth Copying

1. Write one sentence for the player loop. Include the action, pressure, reward, and fail state.
2. Choose a ten-minute vertical slice. One level, one enemy family, one progression choice, one loss, and one win condition.
3. Separate simulation from presentation. Keep rules, random seeds, scoring, and progression testable without rendering.
4. Define a performance budget before visual polish. Set target devices, frame time, memory, draw calls, bundle size, and load time.
5. Give the agent a test contract. Require build, unit tests, deterministic seeds, a browser walkthrough, and a written list of unresolved risks.
6. Play after every meaningful loop change. Do not let the agent stack five untested mechanics because each one looked plausible in isolation.
7. Commit accepted states. Use version control before model changes, broad refactors, balance passes, and art-direction experiments.
8. Record the why. Update the design reference with accepted formulas, rejected approaches, fixed bugs, and known gaps.
9. Use a naive playtester. Watch silently. Convert every confusion into either an interface change, a tutorial change, or a design simplification.
10. Only then expand content. More bosses and worlds cannot rescue an unreadable core loop.

Reusable Build Brief

ROLE
Build a small browser game as a verifiable vertical slice.

PLAYER LOOP
The player [action] while [pressure increases].
Success means [measurable win]. Failure means [measurable loss].

SCOPE
- One level and one complete 8-10 minute run
- One enemy or obstacle family
- One upgrade choice with a visible gameplay effect
- One tutorial that teaches by successful action
- One win state, one fail state, pause, restart, and settings

ARCHITECTURE
- Keep simulation and rendering separate
- Seed gameplay randomness for reproducible tests
- Put tunable values in one documented data layer
- Do not add dependencies without explaining why
- Write DESIGN.md with architecture, controls, formulas, decisions,
  fixed bugs, test recipes, and known gaps

VERIFICATION
- Run the production build
- Test lifecycle, save/reset, win/loss, and upgrade paths
- Run at least 20 deterministic seeds for reachability
- Measure frame time, memory, load time, and bundle size
- Complete a keyboard-only browser walkthrough
- Report failures honestly; do not call the project finished while tests fail

HANDOFF
Return the playable build, test results, changed files, unresolved risks,
and the next three highest-value playtests.

The brief is intentionally smaller than Matt's sequel. The point is to prove one loop before asking an agent to manufacture a content catalog around it.

Final Verdict

Anyone with a clear idea can now make a game-shaped thing that would have required far more specialized implementation effort a few years ago. That is a real change. It expands who can prototype, makes experiments cheaper, and gives experienced developers more leverage.

The Librarian 2 also shows why "game development is cooked" is the wrong conclusion. AI can generate systems faster than a person can evaluate them. That makes taste, restraint, playtesting, instrumentation, and technical judgment more important, not less.

The winning workflow is not one prompt to finished game. It is brief -> build -> play -> measure -> document -> checkpoint -> revise -> test with someone new. Claude Code and Codex accelerated the middle. Matt still owned the loop.

Video Chapters

• 00:00 - Why Game Dev Isn't Cooked
• 03:29 - The Librarian 2 Plan
• 04:39 - Two Model Workflow
• 05:19 - Building V1 With Claude Code
• 08:32 - First Playtest and Bug Fixes
• 12:48 - GitHub Backup and Model Handoff
• 14:19 - Fine-Tuning With Codex
• 15:52 - Live Playtest With Dave
• 20:05 - Is Game Dev Actually Cooked?
• 21:25 - Final Tweaks and Verdict

Sources

• Matt Wolfe: Anyone Can Make Amazing Games Now (Easy)
• The Librarian 2 playable site
• The Librarian 2 repository and README
• The Librarian 2 complete project reference
• The original Librarian game and source repository
• Three.js
• Vite