The Interface the AI Couldn't Design
How We Build
Andrey Balbekov is a Visual Designer at Fantasy. Using Claude Code, he built a node-based AI workflow tool for architectural visualization, modeled on Fantasy’s own Canvas platform. Every feature worked on the first try. The interface was unusable until he opened Figma and drew a wireframe.
The problem
Andrey’s brother works in architectural visualization in New York and needed a tool that connected multiple AI image APIs into one pipeline. The existing options were too generic or too expensive. Andrey had been using Fantasy Canvas, a node-based tool, and figured he could build something focused on a single domain. So he did.
What made you actually do this?
“My day-to-day client work involves confidential AI projects where the security restrictions meant I couldn’t experiment with Claude Code on that account. So I was looking for something to build on my own time.
“My brother works in architectural visualization in New York. He uses a tool that connects external APIs, NanoBanana, Fling, others, into one workflow. You run images through a pipeline of AI services. But the tool is broad, and you’re paying for things you don’t need.
“I’d been using Fantasy Canvas, our own node-based tool, and I thought: why not build something with the same principle, but focused on one specific domain? Architectural visualization was the test case; a real workflow with real users and real problems. It was my test drive project.”
How the features found him
The tool started simple: connect different APIs through a visual node interface, where each node does one thing. Then real use shaped it. Andrey and his brother were staging rooms, comparing golden hour renders against blue evening color schemes, and every time they hit something the tool couldn’t do, Andrey asked Claude Code to build it.
“All the features came from actual use cases. We were doing design explorations for architectural clients, staging rooms with different furniture, comparing a golden hour render against a blue evening color scheme. Every time we discovered something we needed, I’d ask Claude Code: can you help me build this feature, what do we need? And it would just build it. The features were decided by the workflow itself.”
Cloud, local, and the passport
“Before this, I’d only built a simple Chrome extension. This was much more complex. The first real decision was: should this live in the cloud or run locally?
“I learned that when you’re using paid APIs with secret keys, putting the tool in the cloud creates security problems. Anyone could potentially access those keys. That’s why I built it on Electron, running locally on my machine. My API keys for NanoBanana, Magnific, whatever I plug in, they don’t go anywhere.
“The other thing I learned is that you should keep a kind of passport for your product. Internal documentation that tells the AI what the system is, how it was built, what the architecture looks like. That way, if someone else picks up the project, or if you come back to it after a break, the AI can read that documentation and understand the whole thing without scanning everything from scratch.”
Where the AI hit its limits
This is where the build got interesting. Claude Code could produce every feature Andrey asked for, and every feature worked. But the AI had no opinion about how those features should be organized on screen.
“For example, I built a prompt editor where you select prompts for different categories: staging, camera angles, replacement, lighting. The AI built the whole thing. But the interface it gave me was awful. One long, scrollable modal with everything stacked vertically. You had to scroll and scroll, and it was hard to understand what was going on.
“The functionality was all there. I had the prompts, I had the ability to see groups of prompts, I had every button. But from a user experience standpoint, it was very unclear how to actually work with it.”
The wireframe moment
“I drew a simple wireframe in Figma. Just boxes. Very rough. And with a couple of iterations, Claude Code reorganized all the components to align with my wireframes.
“That was the moment I realized something. You don’t need technical skills to shape how a tool works. You can draw something on paper, hand it to the AI, and say: make it look like this. Even without any programming background, just using your hand and a piece of paper, you can adjust and refine the experience.
“I ended up doing this several times throughout the build. Every time the AI produced something that worked but felt wrong to use, I’d sketch what it should look like and have Claude Code rebuild it.”
Why nodes instead of a conversation
“When you work through code directly, it’s like a feed. You type something in, you get a result, and you’re still inside the feed. Everything happens at once. You can’t isolate one step and refine it without affecting everything else.
“With nodes, you control each step individually. You can bake repeatable tasks into a single node, adjust the settings for different projects, and build a pipeline you can reuse. When you’re working on design systems, for example, you already know the steps: create variables from these colors, generate components, check accessibility. You don’t need to explain that to the AI every time. You just drag in the node and run it.
“That’s what I want to explore next at Fantasy. Wrapping repeatable design tasks into nodes: documentation, setting up token systems, rewiring variables, removing hidden layers, checking for accessibility, helping with naming. You could build a pipeline for each of those workflows and refine it over time, instead of starting from scratch in a code conversation every time.”
The prompt editor was the proof. Claude Code produced a single scrollable modal with every control stacked vertically. It worked. It was also completely unusable. Andrey drew boxes in Figma, and two iterations later the layout made sense. The AI could build anything he described, but it couldn’t see that what it had built was hard to use. That required a designer.
What to try this week
Think about a workflow you run through multiple tools in sequence. A render pipeline. A review process where assets get passed manually between platforms. Andrey’s approach was to describe each step as a separate node and let Claude Code connect them into a local tool, scoped to the one pipeline he actually needed.
Build the connections first. When the first version works but feels wrong, sketch what it should look like and hand Claude Code the drawing. That sketch is the design work. Andrey’s Chrome extension experience was enough to build the rest.
Questions to sit with
- 01.What tool do you use every week that works but feels wrong, where you've already imagined the fix?
- 02.If a rough wireframe is enough to reshape an interface, what's actually standing between your judgment and a working product?
- 03.How many workflows are you tolerating because you assumed the fix required an engineer?