Ethan Mollick, Associate Professor at The Wharton School and author of Co-Intelligence, recently shared something that caught my attention: he wrote, "I asked Opus 4.6 in Claude Code to "build me Borges's Library of Babel. This must be an original implementation." An hour later it delivered this." His only feedback, he added, was to include the vestibules Borges described between the rooms.

That short post is doing a lot. It is a quick demo of how far AI-assisted coding has come, and it is also a clever choice of benchmark: a famous thought experiment that is both literary and brutally technical once you try to implement it.

"The AI implemented a Feistel cipher so each possible book has a single real location, you can search for text across the Library & find the book."

Below, I want to expand on what Mollick is pointing at: why this particular project is such a good test of modern code models, what the cryptography detail implies, what "search" means in a space that is effectively infinite, and why this kind of post spreads.

A one-hour build that feels impossible

Mollick describes a familiar experience for many developers in 2026: you ask for something that sounds like it should be a months-long side project, and a coding model produces a working prototype shockingly fast. The striking part is not just that it renders a Library of Babel-like interface, but that it respects key constraints.

Borges's "Library of Babel" is not simply a big library. It is a conceptual machine: a combinatorial space of all possible books of a fixed format, arranged in an architectural maze of rooms. When you translate that into software, the obvious naive approach (generate books and store them) fails immediately. The space is too large.

So a real implementation needs to be mostly virtual. It should be able to:

Define an address scheme for "rooms" and "books"
Produce the content of the book at an address deterministically
Ensure the mapping is stable and ideally one-to-one
Support a usable way to find a book that contains a target string

That is why Mollick mentioning the Feistel cipher matters. It hints this is not just random text generation with a pretty UI. It is an engineered mapping.

Why the Library of Babel is a great software test

As a prompt, "build me Borges's Library of Babel" is deceptively compact. It tests multiple competencies at once:

Product sense and UX

Borges describes repeating hexagonal rooms and vestibules. Mollick nudged the model to add vestibules, and that is exactly the kind of detail that separates a toy from an artifact. You need navigation, wayfinding, and constraints that make the space feel coherent.

Systems thinking

You cannot store the library. You have to compute on demand. That pushes you toward deterministic generation (a function that maps an address to text) rather than persistence.

Correctness and reproducibility

If I go to the same address tomorrow, I should see the same book. If two people share an address, it should resolve to the same content. Otherwise the library is not a library, it is a slot machine.

The "original implementation" constraint

Mollick explicitly asked for an original implementation. That is interesting because it mixes a creative constraint with a software constraint. In practice, it pressures the model to synthesize an approach rather than clone a known repo structure, even if it uses standard building blocks.

The cryptography twist: one book, one address

Mollick says the AI "implemented a Feistel cipher so each possible book has a single real location." In plain terms, a Feistel network is a way to build a reversible permutation from a function that might not be reversible. It is a classic construction used in block ciphers.

Why use a cipher-like permutation here?

You want an address space (room, shelf, volume, page, maybe) that maps to a specific book.
You want that mapping to be evenly distributed, so nearby addresses do not yield nearly identical texts.
You may want the ability to go both ways: from address to book content, and in some controlled way from a book fingerprint to an address.

A Feistel-based approach can provide a deterministic shuffle over a finite space of "book IDs." That means every possible book corresponds to exactly one ID and one location, rather than appearing multiple times or colliding.

Key idea: in a virtual infinite library, "location" is really an index, and the index must be stable.

This is a subtle point that gets lost in many generative demos. Random generation is easy. Deterministic generation with a meaningful bijection is harder, and it is closer to what engineers need when they build reproducible systems.

Search across infinity (practically)

Mollick also notes you can "search for text across the Library & find the book." That sounds impossible at first, because searching all possible books is not feasible.

So what could "search" mean here?

Targeted construction: If you want a book containing a specific snippet, you can construct a book that contains it by embedding the snippet at a known offset and filling the rest with arbitrary characters. In a Library of Babel setting, that book must exist. The trick is producing an address that maps to it.
Indexing by constraints: You can treat the query as a set of constraints and solve for an address that satisfies them, rather than scanning.
Probabilistic search: You can sample addresses until you find a hit. This works for longer run times and shorter queries, but it is not guaranteed quickly.

A deterministic mapping plus a reversible or partially reversible transform makes the first option plausible: you can create a desired book content, compute its ID, then compute its location. If the system is truly one-to-one, that "find" operation is well-defined.

The deeper takeaway is that the "search" feature is a proxy for something else: can an AI-generated codebase connect a user-facing promise to a real algorithmic mechanism rather than handwaving?

What this says about AI coding in 2026

Mollick's story is not "AI wrote some code." It is "AI shipped a compact system design." The jump from code completion to end-to-end implementation is about coordination:

picking the right abstractions (address space, book ID, deterministic generator)
selecting a proven algorithmic primitive (Feistel construction)
integrating UI, navigation, and performance considerations
responding to feedback (add vestibules) without collapsing the design

That also suggests a practical workflow shift:

Humans set the target and constraints ("original implementation," match Borges, include vestibules).
Models draft the architecture and the first working version.
Humans validate: does the mapping collide, is search real, are there edge cases, is the code maintainable?

The responsibility does not disappear. It moves. Verification, testing, and careful specification matter more because output volume is no longer the bottleneck.

Why Ethan Mollick's post traveled

Even with only a few sentences, the post has strong "viral post" mechanics that are worth copying ethically:

A surprising constraint: "This must be an original implementation" is a strong hook.
A clear time box: "An hour later" sets expectations and creates wonder.
A culturally resonant artifact: Borges gives it instant narrative weight.
One concrete technical detail: "Feistel cipher" signals seriousness to technical readers.
A single piece of feedback: adding vestibules shows a human in the loop.

If you care about LinkedIn content and content strategy, that combination is powerful: a human story, a specific demo, and one credible technical anchor. It invites both "wow" reactions and substantive discussion.

Takeaways you can apply

If Mollick's Library of Babel experiment makes you want to run your own, here are a few practical prompts and checks:

Ask for something that forces determinism, not just generation: "same input, same output."
Require a reversible mapping or at least a collision analysis.
Add one small, high-signal feedback item (like vestibules) to test iteration.
Demand an explanation of the core algorithm in plain English, then verify it.
Treat "search" claims skeptically until you understand the mechanism.

And if you are posting your results: show the artifact, name one constraint, name one technical choice, and share what you changed.

This blog post expands on a viral LinkedIn post by Ethan Mollick, Associate Professor at The Wharton School. Author of Co-Intelligence. View the original LinkedIn post →