When an AI Builds a Browser‑Based Office Viewer From Scratch

The headline on the project’s GitHub page is a bold one: "This entire codebase — Rust parsers, TypeScript renderers, tests, and tooling — was implemented by Claude (Anthropic’s AI assistant) through iterative prompting. No human‑written application code exists in this repository." The repository, yukiyokotani/office-open-xml-viewer, is a fully‑featured, browser‑based viewer that can render Word (.docx), Excel (.xlsx), and PowerPoint (.pptx) files to an HTML Canvas element.

The claim in context

The claim is not just a marketing gimmick; it is a statement about the capabilities of large‑language‑model (LLM) code generation. The project uses:

• Rust for the core parsers, compiled to WebAssembly for speed and safety.
• TypeScript for rendering logic that draws the parsed document onto a canvas.
• Storybook for a live demo and component playground.
• A set of npm packages (@silurus/ooxml/docx, @silurus/ooxml/xlsx, @silurus/ooxml/pptx, and an optional @silurus/ooxml/math for equations) that expose headless engines and UI‑ready renderers.

The developers claim that every line of application code—parsers, renderers, tests, tooling—was produced by Claude through a series of prompts. The only human involvement, they say, was in setting up the repository, configuring CI, and packaging the final product.

Why this matters

1. Demonstrates a new workflow

If a functional, production‑grade library can be produced by an LLM with minimal human touch, it changes how teams think about onboarding, code reviews, and maintenance. The project’s architecture is modular: the Rust parsers are compiled to WebAssembly, and the TypeScript renderers are pure canvas code. This separation makes it easier to audit the AI‑generated code because each layer has a clear responsibility.

2. Opens a dialogue on AI‑generated code quality

The repository includes a comprehensive test suite, visual regression tests, and a Storybook demo that showcases rendering fidelity across dozens of Office features. The fact that these tests pass suggests that the generated code is not only syntactically correct but also functionally sound for a wide range of documents.

3. Raises security and maintenance questions

• Security: The code is built with safety in mind. It uses roxmltree for XML parsing, which is XXE‑safe by default, and limits ZIP entry sizes to avoid zip‑bomb attacks. However, the project also exposes a maxZipEntryBytes knob that can be overridden, and it relies on WebAssembly modules that were generated by the AI. Auditing such modules for subtle bugs or vulnerabilities is non‑trivial.
• Maintenance: AI‑generated code can be harder to read for humans, especially if the model injects unconventional patterns or lacks documentation. The repository includes a packages/markdown sub‑project that converts Office files to GitHub‑flavored Markdown, but the core parsers and renderers are largely auto‑generated.

Evidence from the repository

Component	AI‑generated?	Notes
Rust parsers	Yes	Compiled to WebAssembly, uses roxmltree, no external entity resolution
TypeScript renderers	Yes	Canvas 2D API, supports text, images, tables, charts
Math engine (MathJax + STIX Two Math)	Optional	Not bundled unless imported, keeps bundle size down
Storybook demo	Yes	Provides live examples for each format
Node‑side parsers (@silurus/ooxml-node)	Yes	Thin wrappers around WASM, useful for CI and CLI tools
VS Code extension (ooxml-viewer)	Yes	Registers custom editors for Office files
MCP server (ooxml-mcp-server)	Yes	Rust server exposing structured queries for AI agents

The README also details how to install the packages, how to bundle them with Vite or Webpack, and how to enable optional features like Google Fonts. The code is open‑source and licensed under MIT, so anyone can inspect or fork it.

Counter‑perspectives

1. “It’s still a human‑written project”

Some developers argue that the presence of a README, CI scripts, and packaging logic means the project is not truly AI‑written. They point out that the developers had to decide on architecture, set up the repository structure, and write documentation—all tasks that require human judgment.

2. “AI code can be buggy”

While the test suite passes, critics note that AI often generates code that works for the test cases but fails on edge cases. For example, the MathJax integration is optional; if a user forgets to import the math engine, equations will silently disappear. The project also relies on roxmltree, which may not handle every XML nuance in Office files.

3. “Security is a moving target”

Even with limits on ZIP entry sizes, the project exposes a maxZipEntryBytes option that can be overridden. An attacker could set this to a very high value to trigger a denial‑of‑service. Moreover, the WebAssembly modules themselves are compiled from AI‑generated Rust, and any subtle memory safety issue could be hard to detect.

4. “Maintenance overhead”

Future contributors may find it challenging to understand the codebase if they are not familiar with the conventions the AI used. The lack of inline comments in some generated files can slow down onboarding. The project’s own documentation is thorough, but the code itself is still a product of an LLM.

What the community is doing

• Code reviews: Some contributors are actively reviewing the AI‑generated code, looking for anti‑patterns and potential bugs.
• Benchmarking: Others are comparing performance against existing libraries like mammoth.js or xlsx-populate.
• Feature requests: The issue tracker has several open tickets for missing Office features (e.g., animations in PowerPoint, advanced conditional formatting in Excel).
• Security audits: A small team has begun a formal audit of the WebAssembly modules and the Rust parsers.

Takeaway

The office‑open‑xml‑viewer project is a tangible example of what can be achieved when an LLM is given a clear set of prompts and a robust development environment. It shows that AI can produce complex, multi‑language codebases that pass functional tests and integrate cleanly with modern tooling. At the same time, it highlights the need for human oversight, security best practices, and clear documentation when adopting AI‑generated code.

Whether this will become a common workflow or remain a niche experiment depends on how the community addresses the counter‑arguments. For now, the project stands as a provocative case study in the evolving relationship between developers and large‑language‑model assistants.

---

Explore the repository: https://github.com/yukiyokotani/office-open-xml-viewer

Try the demo: https://silurus.github.io/office-open-xml-viewer

Read the docs: https://github.com/yukiyokotani/office-open-xml-viewer/tree/main/docs