Clay Tablets and Code: An ERP Dream Reborn in the Ancient Near East

From Scribes to Systems

For years, I dreamed of building my own ERP system. It wasn't a typical tech ambition—it was a quiet obsession, rooted in my fascination with the ancient Near East. I studied computer science in college, but after graduation, I barely wrote a line of code. My mind was full of blueprints, but my fingers couldn't translate them into syntax.

My day job pulled me deeper into enterprise software—first with digital transformation projects, then at a domestic ERP vendor, and later at a Big Four firm. I saw countless business processes, financial reconciliations, and chaotic go-lives. Slowly, a model of an ERP system crystallized in my head: how transactions flow, how vouchers are generated, how reports balance. But a model is just a model if you can't build it.

Then AI came along. And that dormant dream—inspired by the meticulous record-keeping of ancient Mesopotamian scribes—suddenly became possible.

The First Trap: Interface Obsession

When I first started, I poured my energy into the UI—button placements, field linkages, the whole visual dance. I thought that was the real craft. It wasn't. The real crux turned out to be how business documents translate into accounting language. A purchase receipt must record inventory and accounts payable; a production issue moves materials to work-in-progress; a sale triggers revenue and receivables. Three actions, three sets of debit-credit logic.

My first version let each module generate its own vouchers—each business unit did its own accounting, its own way. It broke fast. Balances didn't match. Purchasing said payables were one number, finance said another. Everyone was sure they were right.

So I restructured. No module generates vouchers anymore. They only emit business events, and a centralized voucher engine translates them. Each document type has a mapping rule: purchase receipt in, the engine debits inventory and credits payables. Sales confirmed, it pulls revenue and receivables. All vouchers feed into a single ledger table, and the balance sheet and income statement are just projections—read-only.

The essence of integrated business and finance isn't bolting modules together. It's a translation pipeline from business action to accounting language. Centralize that translation, make it configurable, and future modules just hang a mapping on the engine. No more begging finance to reconcile.

The Second Trap: Model Chaos

With the framework settled, I hit the next snag: which AI model to use. Early on, I got greedy. Module A got one model, module B another—I thought I'd get the best of each. Disaster. The code styles clashed: naming, structure, error handling—all different personalities. Fixing A broke B, and fixing B broke A again. Bugs outnumbered features.

Worse was letting different models take turns rewriting the same logic. The second model couldn't follow the first's context, so it rewrote things its own way—logic went haywire. Each piece looked fine in isolation, but together they fell apart. Debugging was torture because every segment seemed correct on its own.

After testing a few, I settled on GLM5.2. One model wrote the entire project from start to finish. The style stayed consistent, and when I had to modify something, I knew where it connected. Even the messy parts followed the same thought process, so I could pick up the thread. My takeaway: for solo AI development, one reliable model beats a committee of clever ones. If I'd learned that six months earlier, I'd have saved myself tens of thousands of lines of code.

The Third Trap: Version Control

I didn't take version control seriously at first. Files piled up in folders with names like final_v2, real_final, final_final_no_really. Then a big refactor broke the core voucher engine, and I couldn't roll back. No clean version existed. I had to rewrite it from scratch.

That happened more than once. Each rewrite wiped out days of work—and worse, it drained my morale. By the second rewrite, I started doubting the whole project was possible. And it burned tokens.

Finally, I got disciplined. Git, branches, the works. The main branch only accepted verified code; feature branches were for experiments. If something broke, I could revert in ten minutes. I also made a habit: at the end of each day, I merged what worked into the main branch, leaving unstable code on branches overnight.

Without version discipline, a solo project is like writing code on a cliff edge. You think you're saving time, but you're one step from losing everything. When you're alone, no one backs you up. A crash is a real crash.

The Fourth Trap: MCP-ifying Everything

Once the system ran, I wanted to make it smarter. Traditional ERP is menu-driven and form-heavy—clunky and slow. So I wrapped my core modules—purchasing, production, sales, finance—as MCP servers, each with dozens of tools behind a functional API. Query stock, create a purchase order, pull a P&L—each action became a discrete tool. I hooked them into WorkBuddy, and now I could just say, "Check how much of this material we have," and the tool fired without opening a screen.

Tool granularity was a balancing act. Too coarse, and one tool did ten things—the conversation layer couldn't figure out intent. Too fine, and dozens of near-identical tools confused the caller. I settled on one tool per business action, with clear names, so the dialogue could understand what I wanted.

But the sneakiest trap was hiding in MCP design. I'd put some calculations outside the API layer, thinking the frontend could handle them. Amount subtotals, tax, document summaries—all computed in the UI. It worked fine in the interface because the frontend executed the math. But dialogue-based calls don't run frontend code—they just pass parameters and get results. So the numbers came out wrong. Voucher amounts didn't match, reports disagreed with the actual business.

This was the hardest bug to find. The UI looked perfect—open a document, digits were right. Only dialogue calls showed errors. I stared at the same transaction, compared the interface against the dialogue, and got two different numbers. I was baffled.

I did a major API upgrade. Every calculation, no matter how trivial, moved into the backend. Both the frontend and the dialogue layer now only pass parameters and display results—they touch no accounting logic. I also added a double-check: the same figure gets computed through two independent paths, and if they don't match, the system blocks it from becoming a voucher. That's a dual safety net for data.

After that, everything stabilized. Numbers from dialogue, from the UI, and from reports finally agreed. The lesson: MCP interfaces must be fully backend. Anything the frontend computes evaporates when called by dialogue. Conversation-based operations forced me to make APIs cleaner, which was an unexpected bonus.

What AI Didn't Loosen

Looking back, I see that AI loosened the reins on writing code, but not on thinking through the business. Lots of people assume AI can design a system for them. It can't. It can only write what you've thought through. The gap between those two is where all the traps live.

None of these four traps were one-and-done. Every reset cost time, morale, and hours of staring at the screen doubting myself. But in the end, AI gave me the muscle, not the judgment. It didn't make development easier—it just made it possible for one person to shoulder the weight of enterprise-grade software. The price is that you have to make every call yourself, with no one to hit the brakes.

That dream I'd carried for years—inspired by ancient Near Eastern scribes who tracked grain and silver on clay—is now running in beta. It's not perfect. Modules need polish, reports need tuning, and the dialogue occasionally mishears me. But it really does generate a balance sheet on its own.