One Person, Leading an Army of AI: How a 10-Year Frontend Developer Built an Online Document System Used by Dozens of Teams

Last year, someone asked me: with AI this strong, how can a frontend developer like you keep competing? I didn't answer directly, because at that time I was busy using AI to write code for me—and what I produced is now used by dozens of internal teams and over a thousand people every day to write requirements, log weekly reports, and build knowledge bases.

It's called Lingyi Docs (零一文档). This article isn't an ad for it (though I'll sneak in a link). It's more of a confession: how a person who has written frontend for more than ten years has been working alongside AI for the past two years, and a few things I've increasingly come to think matter—technology, and what people in this profession are actually worth.

Who I am and why I panicked

I've been writing frontend for over ten years. From "use jQuery for everything" and hand-rolling components, to React + TypeScript engineering, then monorepo and micro-frontends. I caught both the messiest and the most respectable years of frontend.

Earlier, we competed on frameworks, engineering, and who had the faster build; in the past two years the script flipped—now AI writes code directly for you. I have to admit, I was panicked for a while. Not the kind of panic from fearing unemployment, but the fear that the "proficiency" I'd spent ten years accumulating—knowing APIs by heart, having stepped in every pit, being able to spin up a scaffold with my eyes closed—would suddenly be worthless.

Later I figured out one thing that made me steadier: AI writes fast, but that doesn't mean AI knows what to write. It isn't lacking speed; it's lacking "why we're doing this, what level of completeness counts as done, and who's responsible when something goes wrong." Those are exactly the things I've accumulated over ten years.

So I changed my way of working: I stopped racing AI on keystrokes, and moved into the position of "raising requirements + accepting and verifying results," letting it do the tedious but necessary work I didn't want to do.

Lingyi Docs is how that got "chased" out of me.

How it came to be

The origin is plain, even a bit frustrating.

We had several teams that needed to write documents, record requirements, and store knowledge bases every day. The requirement was one sentence: "Multiple people need to be able to edit together, data can't leave the company, and preferably it shouldn't cost anything."

I looked through the available options one by one: SaaS was either expensive or required data to leave the domain (compliance had a one-vote veto); self-hostable commercial offerings had terrifying price quotes, the "contact sales" routine; building a collaborative editor from scratch? Just collaboration conflicts, offline merging, and those few points would eat up a quarter and still might not be stable.

Before, this would have been a dead end for me—how could one person build an "online document system"? But by then I'd been using AI coding tools for a while, and I had a judgment: the cost of implementation had dropped a lot, and what remained hard was architecture and trade-offs—which happened to be exactly what I should do.

So I started. Not with a pretty plan, but writing along the way: first solving my own team's weekly-report pain, then adding collaboration, then a knowledge base, and later when teams were all working on Agents, I integrated MCP.

Now it runs inside the company, with dozens of teams actually using it. By "actually using" I mean that every day people are arguing over requirements, pasting screenshots, writing weekly reports—a system nobody uses wouldn't be that lively.

Why I insisted it must be self-deployable

As I worked, I got more and more certain of one thing: Documents aren't documents; documents are data. And it's the most valuable and most sensitive part of a company—requirements, contracts, weekly reports, client information, product plans that haven't shipped. All of it lives there.

But the reality is, most of that data sits in someone else's SaaS. The AI era sharpens this contradiction: on one hand everyone uses large models and has Agents reading their document bases; on the other, the compliance red line for data leaving the country is tightening. Financial, government, and enterprise clients simply don't allow materials to be placed on third-party clouds; compliance has a one-vote veto.

I've worked on internal systems for a few years and know this dilemma too well: either pay for a self-hostable commercial solution (price quotes that scare people off, and you have to beg the vendor), or build your own from scratch, which costs too much. Many teams end up choosing "we'll just use SaaS for now," which is equivalent to handing over their core data.

So Lingyi Docs has a line I hold firm: it must be deplorable privately. Not the "contact sales for a solution" kind of private deployment, but one where you pull the code and run a single Docker command on your own servers, and the data stays in your own database from beginning to end, never passing through any third party.

That is the root of this project. Everything before—collaboration, MCP, multi-dimensional tables—exists to serve this: to let a team, without depending on any external vendor, own its document system and pull the data back into its own hands. The more advanced AI gets, the more important this becomes: you can use the best models and the smartest Agents, but your source material has to be somewhere you control.

Being fair: what I did, and what AI did

I want to make this explicit, because it's directly about how technical people position themselves. Online there are too many feel-good posts like "I built a XX in one day with AI," which look exciting but mislead people. My actual division of labor is this:

My work:

• Set the architecture. How to split the monorepo—core engine (core-*) and editor (editor-*) separate, application layers (web / admin / server) independent. This split decides whether the thing stays maintainable.
• Settled the hardest technical choices. For example, real-time collaboration using CRDT or OT—I made the call; what should be open source and what stays commercial, that line I drew.
• Acceptance and judgment. For the code AI gives me, I have to review, run, test. If it's wrong, I send it back to rewrite, and several rounds are common. Many times its first draft is still far from "usable."

AI's work:

• About 80% of the boilerplate code, repeated components, and CRUD interfaces. I could write those too, but they're tedious and it writes fast.
• First drafts of test cases and documentation (including the long comments you see in the repo now—many were written by it first, then I edited).
• Some areas I'm not familiar with—like a low-level algorithm—I let it produce an initial version, then I add business logic and fix boundaries.

My feeling in one sentence: AI is like an intern with very fast hands but not much thinking; I'm the one who has to own the result and make trade-offs at key forks. It handles the grunt work, but the steering wheel has always been in my hands.

This is also what I increasingly think matters. I'll talk about it separately later.

What it can actually do now

You might think I'm bragging if I say one person did this. Let me be concrete about what runs and is actually used now:

Module	What it does now	Status
Multi-dimensional table	Multiple field types, multiple views (table / calendar / kanban / gantt / gallery), formula engine, conditional formatting, dashboards	Open source, runs
Mind notes / mind map	Canvas engine, topics, node styles, outline view	Open source, runs
Whiteboard	Free canvas, connectors, shapes, embeddable mind maps	Open source, runs
Rich text document	Headings, lists, tables, code blocks, Markdown / Mermaid, outline navigation	Still being written
Survey	Form design, data collection and analysis	Still being written

Some honest notes:

• The multi-dimensional table is where I spent the most effort. Teams currently use it mainly for requirements, scheduling, and progress tracking; multiple view switching and formulas are all there.
• Mind notes and whiteboard are drawn with a Canvas engine; they're lightweight but enough for daily use.
• Rich text documents and surveys are not yet up to a presentable standard—I'm not hiding them, they're just not finished.
• The core items—real-time collaboration, import/export (DOCX/XLSX/Markdown), knowledge base, and the MCP mentioned above—are all open source, so you can pull the code and see.
• The AI assistant and RAG are commercial-licensed right now, not in the open-source part. I'll say it in advance so you're not confused when you pull the code and find a feature needs a license.

Also, it's not just a website you can open. I split the core engine into npm packages, so if you want to embed a table or mind map in your product, just import them:

npm install @lingyi-doc/core       # Core engine (no UI dependencies)
npm install @lingyi-doc/editor     # React editor components
npm install @lingyi-doc/mind-map   # Pure Canvas mind map engine

A few technical decisions (for fellow coders)

If you write code, the next few paragraphs may matter more. I'll go over a few key decisions and the pitfalls I hit.

Real-time collaboration: why CRDT, not OT

Multiple people modifying the same cell, disconnecting mid-edit and reconnecting, two devices editing independently—these are the real pitfalls of collaborative editing, not "being able to type at the same time."

I originally considered OT (Operational Transformation), but OT requires a transformation logic on the server, complex state machines, and heavy operations. Later I chose CRDT (Conflict-free Replicated Data Type) + HLC (Hybrid Logical Clock) , with WebSocket for real-time sync. The advantage of CRDT is that conflicts are resolved at the data-structure level, and the frontend can handle it without the backend carrying a complex transformation burden.

A pit I hit: early on, offline edits after reconnecting occasionally lost content. The root cause was an HLC clock regression that wasn't handled well—the timestamps of local operations during offline were out of sync with the server, and they were treated as old data on merge and dropped. Later I pre-cached local operations into a pending-sync queue and, after reconnection, applied them with causal order. That made it stable.

In short, for collaboration, I'd suggest not reinventing the wheel; reuse existing patterns. Lingyi Docs' collaboration engine is open source, and the architecture docs are in the repo—following them beats figuring it out yourself.

Making Agents able to read my documents: MCP

First, to be clear, MCP wasn't the main motivation for building this system—I'll talk about that later. MCP was forced out by a need mid-project: teams were building AI Agents, but their own document base had no standard interface. Data was in their own hands (per the last section), but Agents couldn't read it—if an Agent wanted to "read last week's requirements doc" or "write a weekly report to the knowledge base," it all had to be copied manually, which was awkward.

So I implemented MCP (Model Context Protocol, spec 2024-11-05) in Lingyi Docs, supporting Streamable HTTP. Cursor, Claude Desktop, self-hosted Agents, even CI pipelines—any standard-protocol client can read my knowledge base and documents.

Endpoint is simple:

POST /api/v1/mcp
Authorization: Bearer mcp_<token>
Content-Type: application/json
MCP-Protocol-Version: 2024-11-05

Permissions are controlled with Scopes, and MCP tokens are a completely separate system from the login JWT—that point I insisted on, because an Agent's credentials shouldn't be mixed with a person's account.

Scope	Description
kb:read / kb:write	Read/write for knowledge base and directory nodes
doc:read / doc:write	Read/write for documents (including multi-dimensional table writes)
ai:rag	Vector semantic search and indexing

In Cursor, it's a single config block:

{
  "mcpServers": {
    "lingyi-doc": {
      "url": "https://your-domain.com/api/v1/mcp",
      "headers": { "Authorization": "Bearer mcp_xxxxxxxx" }
    }
  }
}

Once connected, a typical workflow works: list_knowledge_bases → create_kb_document → update_document (write Markdown) → embed_document (build index) → search_knowledge (verify retrieval). Your Agent can now write documents, build indexes, and search on its own, without manual copying.

I've made the full MCP design (how tokens are signed, how Scopes are divided, what Tools/Resources exist, how auditing is done) public in docs/design/mcp-module-design.md in the repo—feel free to adapt it or submit PRs.

Runs by itself: Docker self-hosting

This is critical for government enterprises and financial institutions—data can't leave the domain, so SaaS is out. So I didn't make "private deployment" a paid service; instead I built it as an open-source capability, with the goal that a single command gets it up:

cp deploy/docker/.env.example deploy/docker/.env
npm run docker:up -- --with-mysql --migrate
# Web: http://127.0.0.1/   Admin: http://127.0.0.1/admin/

Environment requirements are just three things: Node.js 18+, MySQL 8 / PostgreSQL 15, Redis 6+. No other dependencies.

A bit abstract: what a 10-year frontend developer is worth in the AI era

I talked about collaboration, MCP, private deployment—the concrete stuff. But back to my opening sentence: my biggest motivation for building this system and writing this piece isn't that any particular tech is cool, but that I wanted to figure out: in the AI era, what is the value of a frontend developer like me who's been writing for ten years?

You can skip this if you only want tech, but I think it matters more than the tech. It's also what made me willing to take one person plus an army of AI and grind this system from zero to something actually used.

After ten years, I remember clearly what frontend used to be about: hand speed, remembering APIs, staying up late, experience with pitfalls. Now AI is faster, more comprehensive, and untiring than you.

So where does our personal value go? Over the two years I've worked with AI, I slowly gathered some observations:

First, from "writing code" to "defining problems." When a vague requirement comes in, people who can break it into a clear plan are scarce. No matter how strong AI is, someone has to tell it "what I want, where the boundaries are, what counts as done." The ability to define a problem—AI can't replace that yet.

Second, from "implementing" to "judging." AI can give you ten options, but you have to pick the right one and explain why. This sense of trade-offs—"I know where to compromise, where not to"—comes from ten years of pit-stepping, not from prompt engineering.

Third, from "solo operator" to "responsible for the result." When deployment breaks, users complain, data is wrong, in the end they still come to you. AI won't be woken up at 3 a.m. to fight a fire, and it won't take responsibility for whether this system lives or dies. People who can carry responsibility are always valuable.

People often ask: can one person plus AI equal a team?

My answer: it can equal "getting the thing built," but not "making sure the thing is fully backed up." A real usable product needs someone accountable for it, someone to do the unglamorous but necessary work—deployment, ops, replying to users, making the call among several plausible options. AI handled 80% of the grunt work for me, but I'd advise keeping that remaining 20% of decision-making in your own hands.

In the end, personal value probably isn't "how many frameworks you know, how many APIs you remember," but: can you take something from 0 to a real 1, and make it truly used?

Wrap-up

Lingyi Docs is open source. It's not perfect—multi-dimensional tables, mind notes, and whiteboard run and are fun to play with; rich text and surveys are still being filled in. I've fully published the MCP module design docs. It's something I built while being pushed by users (those dozens of teams), not a carefully packaged demo.

Open source link: https://github.com/James-Nie/lingyi-doc
Online demo (login to use): https://lingyidoc.com

Writing this isn't to convince you to use something, but to find a place to talk. If you're also thinking about—

• How frontend should position itself in the AI era;
• How one person with AI can hold up against "I need both X and Y";
• Where a technical person's individual value should go;
• Or you're working on document collaboration / private deployment / Agents connecting to knowledge bases, and you've hit pitfalls—

Let's talk in the comments. No courses for sale, no private traffic, just honest chat.