The Art of Painting with AI: Lessons from Building a Digital Studio

The Dream of a Digital Canvas

For years, I dreamed of building my own digital painting studio. I studied computer science in college—operating systems, databases, software engineering—but after graduation, I barely wrote a line of code. The blueprint was in my head, but my fingers froze at the keyboard. The dream stayed a dream.

Then I spent over a decade in the art-tech industry, working on digital projects for major galleries, then at a software company that made tools for artists, and later at a consulting firm. I saw how artists managed their workflows, how galleries tracked provenance, and how messy it got before any system went live. Slowly, a model of a painting management system formed in my mind—how a brushstroke becomes a stroke in a database, how a palette becomes a color profile. But a model is just a model if you can't build it.

When AI Finally Picked Up the Brush

AI changed that. Now that system is in beta. It can automatically generate records from sketches, paintings, and sales, roll those records into a ledger, and spit out a balance sheet for my art business. Even better, I've wrapped the core modules as MCPs—each with dozens of tools that act as the system's functions. Plug them into WorkBuddy, and I can ask in plain language: "Check how much ultramarine we have," or "Create a purchase order for canvas." It just works.

But I don't want to tell you a smooth success story. I want to share the four big pitfalls I hit—the ones that made me want to delete everything and start over. If I can help you skip a few steps, it's worth it.

Pitfall One: The Translation Layer

In the beginning, I spent most of my energy on the interface and workflow—how buttons should be arranged, how fields should interact. I thought that was the real craft. But the real crux is how a business action becomes accounting language. Buying paint means recording inventory and accounts payable. Using materials in a painting means moving them to work-in-progress. Selling a piece means recognizing revenue and receivables. Each action carries its own set of debits and credits.

My first version had each module generate its own records. But it fell apart quickly. The totals didn't match. Purchasing said the payable was one number; finance said it was another. Everyone thought they were right. So I restructured: modules no longer generate their own records—they just emit business events, and a central engine translates them.

Each document type has a mapping rule. A purchase order comes in, and the engine debits inventory and credits payable. A sale is confirmed, and the engine generates revenue and receivable. All records go into the same ledger, and the balance sheet and income statement are just projections of that table—read-only.

The essence of integrating business and finance isn't bolting two modules together. It's a translation pipeline from business action to accounting language. The rules must be centralized and configurable, not scattered across modules. After that, adding a new module is just a matter of hanging a mapping on the engine, and the records come out on their own.

Pitfall Two: The Model Temptation

Code is written by AI, but the model choice is a trap. Early on, I got greedy: I let model A write one module and model B write another, thinking I'd get the best of both. Disaster. A's interface style clashed with B's—naming, structure, error handling—all different personalities. Fixing A broke B, and fixing B broke A. Bugs multiplied faster than features.

Even worse was letting different models take turns editing the same logic. The second model couldn't follow the context the first one left, so it rewrote things in its own way, and the logic got mangled. Each piece looked fine on its own, but together they didn't run. Debugging was a nightmare because every chunk was individually correct.

After testing a bunch, I settled on GLM5.2. From then on, one model wrote the entire project. The style stayed consistent, and I could predict where things connected. When something was messy, it was the same model's logic, so I could pick it up. My advice: when you're building something solo with AI, don't be greedy. One model that works is better than three that are clever. If I'd learned that six months earlier, I'd have saved tens of thousands of lines of code.

Pitfall Three: Version Control Discipline

For the first few days, I didn't use Git properly—or at all. I saved files by date in folders: final, final2, real final, real final no changes. Then a big refactor broke the core translation logic, and I couldn't roll back because there was no clean version. I had to rewrite it from scratch.

That happened more than once. Each rewrite meant two or three days of work down the drain, and worse, it sapped my morale. By the second rewrite, I started doubting whether I could ever finish. Plus, it burned tokens.

Eventually, I got serious about Git. I created a branch for each phase, kept the main branch only for verified code, and let feature branches go wild. If something broke, I could switch back in ten minutes. I also developed a habit: before wrapping up each day, I merged whatever was stable into main and left the unstable stuff on a branch overnight.

Without version discipline, a solo project is like painting on a cliff. You think you're saving time, but you're one misstep away from losing everything. When you're alone, there's no one to catch you. It's just you and the void.

Pitfall Four: The MCP Trap

When the system finally ran, I got into MCPs. Traditional ERP relies on menus and forms—click, click, click. Too clunky. I wrapped purchasing, production, sales, and finance into MCPs, each with dozens of tools. From checking inventory to creating a purchase order to pulling a profit report, every action became a separate tool. Plugged into WorkBuddy, I could say, "Check how much of material X we have," and it would call the tool. No interface needed.

The tool granularity took some tuning. Too coarse—one tool doing ten things—and the conversation gets confused. Too fine—dozens of similar-looking tools—and the caller is lost. I ended up splitting by business action: one action, one tool, with clear names.

But the sneakiest pitfall was hidden in the MCP design. I initially put some calculation logic outside the interface layer, thinking the frontend could handle it. Subtotals, taxes, and document summaries were computed on the frontend. It worked fine when the system ran as a UI, because the frontend executed the calculations. But conversational calls are different—they just pass parameters and get results. They don't run the frontend. So the numbers were wrong. The records didn't match, and the reports didn't tie out.

This was the hardest bug to find. The interface looked perfect; the document numbers were right. Only when called through conversation were they off. I stared at the same transaction, checked the UI, checked the chat, and got two different numbers. Baffling.

I upgraded the interface. All business calculations, no matter how small, moved into the backend. The frontend and conversation layer only pass parameters and display results—they don't touch any math. I also added a double-check in the backend: the same number is calculated two ways, and if they don't match, it's blocked before entering the ledger. Double insurance.

After that, the data finally stabilized. The numbers from chat, the UI, and the reports were all the same. The lesson: MCP interfaces must be fully backend. Any calculation done on the frontend evaporates when called through conversation. The interface has to withstand being called directly, because conversation won't fill in the gaps. Ironically, conversational interaction forced me to make the interfaces cleaner—a happy accident.

The Real Takeaway

AI loosens the reins on writing code, but it doesn't loosen the reins on thinking clearly about the business. A lot of people think AI can figure out the system for them. But AI only writes it; the thinking is still yours. That gap is where the pitfalls live.

None of these four pitfalls did I clear on the first try. Every retry came with a cost—time, morale, and those moments staring at the screen doubting myself.

In the end, AI provides the muscle, but the judgment is still yours. It doesn't make development easier; it just lets one person handle the weight of enterprise software. The price is that you make every call yourself, and no one hits the brakes for you.

That dream I had for years is now running in beta. It's not perfect—the modules need polish, the reports need tuning, and sometimes the conversation mishears me. But it actually generates its own balance sheet now. And that's something.