Dev.to AI 🤖 Ai 👁 0 📖 4 min read

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

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 l

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

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.

Why models do this

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.

What actually worked: tell the model what it's not allowed to touch

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.

The scene-class mistake I made

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.

Validating the output

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.


What I'd tell someone starting this

  1. Your differentiator is the constraint, not the generation. Anyone can call an image model. The product is in what you refuse to let it change.
  2. Default to locked. Make the user name what they want changed. The failure mode of too-locked is "nothing happened," which is confusing. The failure mode of too-free is "this isn't my house," which is worthless.
  3. Never let an abstraction describe features its members don't have. See: the phantom railing.
  4. Budget the wall-clock time before you budget the quality. A perfect result that takes four minutes loses to a good one in twenty seconds.

If you want to see where this ended up, the tool is free to try without an account at 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

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.