cd /news/generative-ai/the-hardest-part-of-ai-interior-desi… · home › topics › generative-ai › article
[ARTICLE · art-149116] src=dev.to ↗ pub= topic=generative-ai verified=true sentiment=· neutral

The hardest part of AI interior design isn't the AI

A developer spent several months building an AI interior design app after finding that image-to-image models regenerate rooms rather than redesign them, moving windows and erasing architectural features. The fix was a default-deny system of prompt "locks" that hold architecture, space type and room function fixed unless the user explicitly names an element to change, plus a post-generation validation pass with retries under a hard time limit. The developer also found that shared scene classes caused hallucinations — gardens inherited a balcony's "preserve the railing" instruction and came back with invented railings — and split the classes so each space only names features it actually has.

by read4 min views1 publishedOct 11, 2026

Ask any image model to "redesign this living room in Scandinavian style" and it will give you a beautiful Scandinavian living room.

It just won't be your living room.

The window moved. The room got longer. That weird load-bearing column your builder left in the middle of the floor is gone. The model didn't redesign your room. It generated a new one that happens to be the same genre of room. It looks incredible and it's completely useless, because you can't buy any of it, you can't show it to a contractor, and you can't act on it.

I've spent the last several months building an app around this one problem. Almost nothing written about AI interior design talks about it, so here's what I learned.

Image-to-image generation has a dial between "follow the input" and "follow the prompt." Turn it toward the input and you get your room back with slightly different cushions. Turn it toward the prompt and you get a gorgeous room that isn't yours.

There is no setting in the middle that means "keep the architecture, change the contents." The model has no concept of architecture. It has pixels and a text prompt.

So the naive approach, one model and one prompt and a strength slider, fails in both directions, and there's no value you can pick that makes it work. I shipped that version. People tried it once and never came back, which is the correct response.

The fix wasn't a better model. It was being specific about what must not change, on every single request, without the user asking.

A redesign request in our system now carries a set of locks that get assembled into the prompt regardless of what the user typed. Roughly: one lock holds the architecture still, one says what kind of space this is, and one says what the room is for.

The rule underneath it: everything in the photo is locked unless the user explicitly names it. If someone says "change the sofa," the sofa is unlocked and nothing else is. If they say nothing, nothing structural is unlocked. Default-deny, the same way you'd write a firewall.

This sounds obvious written down. It took me a long time to get here, because the instinct is to give the model freedom and hope it uses it well. It doesn't. Freedom is how you lose the window.

My first version of this had three scene classes: interior, outdoor, and exterior. Gardens and balconies shared the "outdoor" bucket.

Gardens started coming back with railings.

The balcony lock said "preserve the railing and the building edge," because balconies have those. Gardens don't. But they shared a class, so the garden prompt inherited "preserve the railing," and the model, being obedient, invented a railing to preserve.

The fix was splitting them up so that each kind of space only ever names the things that space actually has

I think that lesson applies well beyond interiors. A shared abstraction that mentions features some members don't have will cause the model to hallucinate those features into existence. The model reads your prompt as a description of reality. If your prompt describes a railing, there's a railing now.

Locks reduce drift. They don't eliminate it. So there's a check after generation that compares the result against the original on the things that were supposed to be locked, and retries when the room has clearly moved.

The constraint that matters here is time. Nobody waits three minutes to see a sofa. So the retries run against a hard clock, and if validation hasn't passed by the time it runs out you get the best attempt rather than an error. Users forgive an imperfect result far more readily than they forgive waiting.

If you want to see where this ended up, the tool is free to try without an account at [decorin.ai](https://decorin.ai). Upload a photo of a real room, not a staged one, and check whether the window stayed where you left it. That's the actual test.

If anything here doesn't add up, or you've hit the same problem and solved it differently, tell me in the comments. I'm still working on this and I'd rather hear where I'm wrong than not hear it. Happy to answer questions about any part of it
── more in #generative-ai 4 stories · sorted by recency
── more on @decorin.ai 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/the-hardest-part-of-…] indexed:0 read:4min 2026-10-11 · —