DEV Community

sun young
sun young

Posted on

The Hardest Part of Document Automation Isn't the AI. It's the .docx File.

#automation #software #softwaredevelopment

Every team doing document automation hits the same wall, and it's never where they expect.

The request sounds simple: generate dozens of contracts or reports automatically. Then you discover the real obstacle — the Word file format isn't designed to be generated by programs.

A .docx is a ZIP archive full of XML. To produce one, you assemble OOXML by hand: styles, numbering, tables, headers, footers. Throw in tracked changes, cross-references, or field codes and it falls apart.

So the industry standard becomes: take a Word template, run a script that swaps placeholders. It works — until someone edits the template and the script breaks.

The root cause is a positioning mismatch: mainstream office suites are built for humans, not for programs.

A project approaching it from the foundation

WordCraft (10275 stars, Apache-2.0) is a clean-room rewrite of a word processor in pure Rust.

It replicates Word's workflow — ribbon, styles, tables, tracked changes, citations, mail merge. Reads and writes .docx (OOXML), plus .odt, .rtf, .html, .md, .tex, .txt. Runs natively on macOS, Windows, Linux, and BSD, and in the browser via WebAssembly.

But the line that caught my attention is how the project describes its own target:

For users who want a fast, offline, command-line and AI-agent-drivable alternative to Word.

"Agent-drivable" is the differentiator. The document stops being something you operate with a mouse and becomes something a program can call and an agent can orchestrate. There's a wordcraft-cli in the workspace.

Why this matters for enterprise AI

Document automation is one of the most common — and most underestimated — AI use cases.

In a bidding/tender project I worked on, the client's real pain was blunt: dozens of proposal documents per day, rigid formatting rules, hours of manual filling. The template-substitution approach has a low ceiling for that.

With a programmable document engine, the division of labor changes:

  • The model handles content (what to say)
  • The engine handles structure and formatting (how it looks)
  • The two connect via CLI or API

This is the same principle I apply elsewhere: give deterministic work to deterministic tools. Don't make the model hand-assemble XML.

Current state — be realistic

  • Version 0.6.1, very early
  • README does not document a launch command for the app
  • Requires Rust 1.90+ (edition 2024)
  • apps/wordcraft-cli exists but is undocumented
  • Pulling crates.io dependencies may need a mirror in some regions 
git clone https://github.com/storytold/wordcraft
cd wordcraft
Enter fullscreen mode Exit fullscreen mode

My read

Too early for production document pipelines. But the direction is the right one: once documents become programmable objects, enterprise document automation actually has a scalable answer — instead of everyone staying stuck at placeholder substitution and paying for it in production.

Worth putting on the watch list.

I localized the README to Chinese with a quick-start section covering the Rust version requirement, build approach, format support, and dependency mirroring: https://github.com/yangshun2005/wordcraft-cn

If it's useful, a star on the original repo helps the authors.

Top comments (0)