DEV Community: GooDesign AI

Why AI Room Renders Look Fake — and the Pipeline Fixes That Actually Work

GooDesign AI — Mon, 02 Nov 2026 01:18:53 +0000

Show an AI room render to someone who's never seen one and they'll say "looks great." Show it to anyone who's listed a property, sold furniture, or stood in an actual living room, and you'll often get a squint and a pause. Something is off. They usually can't name what. They're right anyway.

That squint is the whole problem this post is about. At goodesign we generate photorealistic room designs from a single photo, which means we live or die by that squint. Over the past year we've dissected hundreds of renders that "felt fake" and traced the feeling to a short list of root causes — some fixable in the pipeline, some only manageable, and a few we simply can't fix yet. Here's the full breakdown, including the parts that didn't work.

Where does the "fake" feeling come from?

Fakeness is almost never one big error. It's the sum of small violations of physics that human vision catches automatically and consciousness reports as a vague unease. A shadow pointing the wrong way. A sofa that's slightly too large for the gap it sits in. A countertop with the specular behavior of a bowling ball.

We sort every "this looks off" report into four buckets: light, scale, material, and geometry. Each bucket has its own cause and its own fix, and the fixes stack — a render with perfect lighting can still fail on scale, and one that nails both can still be disqualified by a single moved window.

Before the bucket-by-bucket tour, one framing rule that saves endless argument: the model can only be as honest as its input. A dark, tilted, cluttered phone photo forces the renderer to guess, and guessed geometry is where most artifacts are born — melted chair legs, wavy baseboards, shadows with no owner. If only one room's renders keep drifting, that room is the variable. Reshoot before you touch anything else.

With that said, here are the four buckets.

Bucket 1: Lighting — the model lights everything evenly

Real rooms have one dominant light source and everything else is falloff. Sun through the west window, lamps doing the heavy lifting after dark, one bright kitchen under-cabinet run. Real photographs record that hierarchy: bright walls near the source, corners falling into gentle shadow, a single shadow direction shared by every object in the room.

Diffusion models, by default, light everything evenly. Flat, bright, shadowless-ish. It looks generous in a thumbnail and wrong within seconds, because evenly lit rooms don't exist. Every object casting a soft ambiguous shadow in a slightly different direction is a physics violation stacked on every other one, and the eye sums them.

The fix that actually moved the needle for us: every render inherits an explicit light spec derived from the input photo — direction, warmth, and time of day — unless the user overrides it. The spec gets phrased concretely in the prompt, because vague light words produce vague light. There's a line from our knowledge hub piece on materials and light that we've basically internalized as an engineering spec: "One named source with one direction reads as photography almost immediately; mixed or sourceless light reads as CGI…"

In practice the phrases that work are short and physical:

"Soft daylight from the left window" — source, direction, quality, seven words.
"Bright, even, true-to-life daylight" for listing-style shots, where even beats dramatic.
"Lamps on, overheads off" for evening interiors — lamps sit at eye level and read as lived-in; a bright ceiling pool reads like a hotel lobby at check-in.

The second half of the lighting fix is restraint. The temptation with a dim render is to lift every shadow until the room sparkles. That's exactly how you get the over-bright, flat, showroom look. Real rooms have corner falloff. We generate with the light spec and then explicitly resist shadow-lifting beyond what the spec calls for. One more practical note: when a render "looks right but feels fake," the problem is usually the light, not the furniture — relighting the same scene beats restyling it almost every time. Realism lives in the light.

Bucket 2: Scale — the model doesn't know what a centimeter is

A diffusion model has never measured a room. It doesn't know the sofa in your photo is 230 centimeters long or that your doorway is 76 centimeters wide. It knows what sofas look like relative to other things in the average training photo, which is a different and much noisier kind of knowledge.

The classic failure: you ask for a king bed and get something that reads as a twin against the wall, because the bed's size was resolved relative to a wall whose own scale the model improvised. Or a dining set renders handsomely and is silently too large for the room, which nobody notices until delivery day in the real-world version of the same layout.

What works, in order of impact:

Name the piece and its size class in the prompt. "Full-size king bed, two nightstands" outperforms "bed" by a wide margin, because you've given the model the semantic frame it needs to pull the right prior. This is also our standard advice to users who report wrong-scale furniture: re-render that swap alone, with the piece named.
Anchor the scene with architectural facts. Doors, windows, and baseboards have roughly standard dimensions, and they survive the render better than furniture does. We use detected architectural elements as scale anchors and generate furniture to be consistent with them, not with the average of training photos.
Do one change per render. Scale errors cluster in overloaded prompts — "new sofa, oak floor, gray walls, bigger window, plants, a dog" is six jobs in one pass, and quality drops on all six. When the model has to resolve conflicts ("bigger window" vs. "same room"), geometry silently loses.

Here's the honest residue: even with all three in place, a render can be a few centimeters optimistic per piece, and the optimism compounds across a layout. A sofa can look perfect in the render and still be ~20 cm too long for your wall. That's why our accuracy guide says plainly that renders are good enough to inform decisions and not good enough to place orders from. The render is a hypothesis. The tape measure is the experiment.

Bucket 3: Material — the plastic problem

The third bucket is surfaces with the wrong optical behavior: countertops that reflect like wet plastic, floors with a uniform studio sheen, fabrics with no weave at all. Call it the plastic problem. It's the reason a render can have correct light, correct scale, correct layout — and still read as a video game.

Two causes, two fixes. The first cause is the model's aesthetic prior: glossy renders photograph well at thumbnail size, so the training data rewards shine. The fix is to specify matte where matte belongs. Matte oak, matte black steel, honed stone, washed linen. In our experience, capping the material list at about four named surfaces keeps the render coherent — stack more than roughly four material demands and the model starts averaging them, and the room goes muddy. One material word per surface beats a paragraph of stone adjectives.

The second cause is mixed lighting on glossy surfaces, which produces highlights in physically impossible places. This is where buckets 1 and 3 meet: a scene with two competing light directions renders plausibly matte surfaces with CGI-looking specular streaks. Fix the light spec first; the plastic often disappears with it. If it doesn't, swap the surface for a matte equivalent and re-render that region alone rather than regenerating the whole frame.

Bucket 4: Geometry — the tells that disqualify a frame

The last bucket is the one buyers and clients catch fastest, because it violates structural common sense rather than optics. Our knowledge hub keeps a list of the seven buyer-facing tells, and it's worth reproducing the categories: floating or sinking furniture, wrong-scale pieces, missing or contradictory shadows, warped architecture (bowed walls, crooked frames), rippling hard surfaces like countertops, duplicated or impossible objects (the three-armrest sofa), and furniture that ignores the room's function, like a bed parked across a door.

Three of those deserve engineering comment.

Moved windows and doorways are generation, not editing. If a render shows a window where your photo has a wall, the model didn't edit your room — it invented a new one inspired by it. This is the single most serious failure for anything buyer-facing, because it misrepresents the actual property. Our rule is blunt: treat any render that changed a wall line, window position, or doorway as rejected, regardless of how good it looks. This is why edit-in-place modes exist and why anything shown to buyers should come from one: the edit-in-place path preserves wall positions, window shapes, and floor direction by construction.

Mirrors break depth. A mirror doubles the scene and the model's depth reasoning with it — reflections drift out of sync with the room, and the eye catches the disagreement instantly. We don't have a real fix; our working mitigation is to treat mirrors as damaged regions, render around them, and flag rooms with large mirrors as high-attention cases.

Text and faces stay unreliable. Asked-for signage melts into letterform soup at 100% zoom, and faces in photos or art warp. The fix is editorial, not technical: don't request text in renders, and crop both out of anything publishable.

The diagnostic tool for all of the above costs nothing: the two-minute audit. Put the render and the original photo side by side, zoom to 100%, and compare — wall lines first, then window geometry, then shadow direction, then every piece of furniture's contact with the floor. Most tells appear within ten seconds of honest looking.

What the gallery looks like when this all works

Everything above is easier to see than to read. These pairs are from our public gallery — 35 before/after pairs, 7 rooms across 5 transformation types, each generated from a single input photo.

What to look for in each pair, in order: wall lines and window positions identical to the before, one consistent shadow direction, furniture touching the floor with real contact shadows, and surfaces that stay matte where matte belongs.

The honest list: what we still can't fix

Any post about fixing fakeness that doesn't include this list is selling something.

Mirrors, as above — mitigated, not solved.
Fine text and faces — unreliable; crop them.
Complex ceiling angles, staircases, glass furniture, and patterned floors — geometry drift concentrates exactly where the interesting architecture is. Flat-walled rectangular rooms are the easy case; if your room isn't one, expect to iterate.
Input quality is a hard ceiling. Three or four iterations repair most frames. Beyond that, the input photo is the limiting factor and no amount of re-rolling will fix it — motion blur and missed focus can't be recovered by anything downstream.
Scale is still estimated, not measured. Centimeter-level accuracy from pixels is not on the menu. Renders inform; tape measures decide.

And one warning from outside our walls that we take seriously: a real Massachusetts listing got called out for "fake staging, ambitious proportions, and impossible furniture angles" — a physics-defying rug, an unverifiable built-in cabinet — and the damage wasn't limited to one photo. Once buyers catch one dishonest frame, they discount every honest one in the listing. This is also why disclosure costs nothing: a render labeled "virtually staged" survives scrutiny perfectly well, because scrutiny finds exactly what the label promised — a redesigned photo, not a redesigned room. The unlabeled version is the one gambling the listing's credibility on buyers not looking closely.

If you take one thing from this post

Fake-feeling renders are rarely a model-quality problem in the abstract. They're a specific, nameable list: even lighting with no source, unresolved scale, glossy averaged materials, and drifted geometry. Fix them in that order, one change per render, and audit at 100% zoom against the original before anything goes in front of a client or a buyer.

If you want to run your own room through the pipeline and audit the result yourself: goodesign takes one photo, renders in about a minute, and your first 5 credits are free with no credit card. The full write-up this post draws from — including the complete seven-tell checklist — is in our knowledge hub piece on why AI renders look fake.

This article was drafted with AI assistance and edited/fact-checked by the Goodesign engineering team.

Prompt Integrity: We Stopped Letting the LLM Rewrite Your Prompts — Here's What Broke

GooDesign AI — Mon, 02 Nov 2026 01:18:40 +0000

The failure report that changed how we build goodesign is the kind you can reconstruct from almost any prompt-rewriting pipeline, because they all break the same way. Picture a completely ordinary session: a user uploads a photo of their living room, types a five-word prompt — "make it cozy, keep the rug" — and gets back a render where the rug was gone, the sofa had visibly grown, and the whole scene had slid from afternoon daylight into warm evening lamplight.

Nothing about that output was broken in the model sense. The image was sharp, the shadows were plausible, every chair leg touched the floor. It just wasn't what the person asked for. The rug — the one thing they had explicitly protected — was the first thing to go.

We traced it, and the culprit wasn't the image model. It was us. An LLM sitting in the middle of our pipeline, added months earlier to "help" users who type vague requests, had rewritten those five words into a 140-word template before the render ever started. This post is about what that rewrite broke, why prompt rewriting loses intent in the first place, the two-layer architecture we replaced it with, and how we test for intent loss now. If you build anything where a user types words and a generative model draws pictures — AI room design, virtual staging, photo editing, anything — this is the failure mode I'd put at the top of your list.

The prompt that came back wrong

Here is roughly what our expansion layer produced from "make it cozy, keep the rug":

"A cozy living room interior with warm ambient lighting, plush textiles, soft throw blankets, layered cushions in warm earth tones, an inviting oversized sofa, a soft evening glow from table lamps, photorealistic, professional interior photography."

Read it next to the original and the damage is easy to miss, because nothing in it is wrong. That's what makes prompt rewriting dangerous. Line by line:

The user's only hard constraint — keep the rug — is gone entirely. It isn't paraphrased or weakened. It's just not there.
"Cozy" got decoded as evening lighting. That is one interpretation of cozy. It was not this user's interpretation, and it happened to require changing the one thing in the photo the user liked.
The template stacked enough soft-furniture adjectives that the renderer, averaging all those simultaneous demands, quietly reallocated "softness" — the rug became throw blankets and cushions.

The individual edits all looked defensible. Warm light is cozy. Big sofas are cozy. Nothing in the output contradicted the word "cozy." It contradicted the person. And because the rewrite happened silently between the text box and the renderer, the user had no way to know their words were never the words the model saw.

Why rewriting loses intent: words are not specifications

The first thing to understand is what a short prompt actually contains. In a room-design prompt, users mix at least three kinds of content:

Intent — what they want changed ("make it cozy")
Constraints — what must not change ("keep the rug")
Rendering parameters — the physical facts a renderer needs: light direction, camera height, material names, counts

Users are good at the first two and usually silent on the third, because the third is our job, not theirs. The expansion layer was written as if all three were missing. So it inflated rendering parameters (lighting adjectives, furniture descriptions), inflated intent into a full aesthetic manifesto, and dropped the constraint — because constraints are the one thing an expansion model has no reason to carry.

That last point deserves emphasis. "Keep the rug" is negative space in a sentence. It describes what should not happen. A language model trained to add helpful detail has essentially zero gradient toward preserving an instruction to not add detail. In our own logs, once we went looking, the keep-clause was reliably the first casualty of rewriting. Intent and parameters survived rewrites in various mangled forms; constraints tended to simply vanish.

The second problem is the word-to-image gap. "Cozy" does not map to any geometry. When a diffusion model reads "cozy," it resolves the adjective through its training priors — the statistical average of every cozy living room in its captioned training data. That average skews warm, textile-heavy, and evening-lit. When our LLM rewrote the prompt, it wasn't translating the user's intent into renderer language, because there is no such translation. It was replacing the user's private meaning of "cozy" with the training distribution's public meaning. The rewrite didn't add information. It substituted a different person's taste and called it help.

Third: rewriting has a direction bias. Language models are rewarded for fluent, detail-rich, confident text, so a rewriter normalizes unusual input toward the middle of the distribution. The more specific and unusual the user's request, the more the rewrite sands it down. Vague prompts get inflated; specific prompts get flattened. Both directions move the output away from the user and toward the average.

And there's a quiet authority transfer nobody signs up for. Once your pipeline decodes "cozy" into a fixed list of signifiers — lamps, throw blankets, earth tones — you have decided, for every user, forever, what cozy means. Some of your users mean candles and rain on the window. Some mean a deep sofa and a bright, crisp winter-lit room. A rewrite can't know. It can only pick one and disguise the choice as neutrality.

The fix: a verbatim layer and a parameter layer

We did not remove the LLM from the pipeline. Truly vague input ("fix this room") genuinely benefits from defaults. What we changed is where the model is allowed to act, and in what shape.

Layer 1: the user's text is immutable. Whatever the user typed goes to the renderer byte-for-byte, first in the composed prompt. No synonym upgrades. No reordering. No cleanup of typos, no expansion of "cozy" into "warm, intimate, inviting" — that triple-synonym move is precisely how you get averaged mush, because each synonym is another vote for the mean. If the user's sentence is short, the render starts from a short sentence, and the fill comes from Layer 2 where we can see it.

Layer 2: structured supplement, not prose. A small, cheap model call classifies what the user actually specified, then emits a strict JSON object of rendering parameters — light source and direction, time of day, camera height, up to about four material anchors. It may only fill fields the user left empty. The JSON is serialized into a short bracketed hint that gets appended after the user's text, never interleaved with it, never substituted for it. Our materials guide makes the same point from the user side: one named material per surface beats paragraphs of mood adjectives, because past roughly 30 words of stacked demands, the model starts averaging them. The supplement layer exists to add the technical floor a photo-real render needs — nothing more.

Constraints leave prose entirely. "Keep the rug" no longer lives in the prompt text, where it competes with forty adjectives and loses. It gets extracted into a machine-readable keep-list that drives the edit-in-place controls directly: locked regions, preserved wall color, preserved window geometry. A constraint expressed as code is a constraint the pipeline cannot paraphrase away.

The supplement layer runs under four rules:

Never contradict. If the user said "bright daylight," the layer is forbidden from appending a warm-evening hint. User wins, always.
Never touch the user's substring. The composed prompt is user_text + hint, and the boundary is tested.
Idempotent. Running the supplement twice changes nothing.
Valid JSON or nothing. If the classifier is unsure, it emits an empty object and the render proceeds on the user's words alone. Uncertainty degrades to silence, not to creativity.

If you've read our public prompting guide, this architecture will look familiar, because the user-facing advice describes the same shape: lead with an action verb, name one style direction, list 2–3 anchor pieces with a finish, give placement cues, and finish with an explicit keep list. The pipeline now respects that structure instead of flattening it.

One honest trade-off: with rewriting gone, a genuinely lazy prompt produces a more literal — sometimes plainer — render than it used to. We think that's correct. The old way felt magical partly because it was making decisions the user never delegated.

How we test prompt integrity now

You can't fix intent loss you can't see, so the first thing we built was visibility: the user's raw text is logged separately from the model-facing composed prompt, permanently. Every support conversation about "that's not what I asked for" now starts with a diff.

Then we built a regression suite around the concept of annotated intent. Every prompt in the golden set carries tags:

{
  "prompt": "make it cozy, keep the rug",
  "must_keep":    ["rug", "wall color", "window geometry"],
  "must_change":  ["overall mood"],
  "must_not_introduce": ["evening lighting", "rug removal"],
}

On every change to the model, the hint layer, or the composer, the golden set re-renders and gets scored: a VLM judge checks each tagged constraint, and a rotating human pass spot-checks the judge, because VLM judges are themselves models with their own lazy priors — they will happily grade "the rug is still there" as true if the rug's color changed. The judge scores; humans arbitrate.

The boundary cases in the set matter more than the happy paths:

Constraints-only prompts. "Don't change anything, just brighten it." The pipeline must treat this as a lighting edit, not a redesign invitation.
Contradictory prompts. "Cozy but bright daylight." The user wins; the hint layer stays silent rather than picking a side.
Non-English prompts. The product runs in 8 languages, and user words pass through untouched in all of them. The supplement layer may localize its hints, but it may not translate the user's sentence into English first — that's a rewrite with extra steps.
Counting language. "Two nightstands, one large piece of art." Exact counts survive; "some" and "a few" from the hint layer never override a stated number.
Junk. Empty strings, emoji-only input, 400-word rambles. Ramblers get length-capped from our side — the user's first N words survive, our words get cut.

Finally, the keep-list is treated as an API contract. If a render violates a tagged keep-constraint, that's a bug with a reproducing case, not a vibe to shrug at.

What changed after launch — shown with images, not dashboards

I'm suspicious of posts that claim "+38% user satisfaction" without a methodology, so I won't invent one. What I can show is what the pipeline produces now. Our public gallery is 35 before/after pairs — 7 rooms across 5 transformation types, every pair generated from a single input photo. These two pairs are straight from it; notice in each that the fixed features of the room survive the transformation.

What actually changed, described honestly and qualitatively:

User adjectives now show up as themselves. When someone's prompt survives to the renderer intact, the render reflects their version of "cozy," not the template's.
Keep-constraints mostly survive. Not 100% — on cluttered scenes the model still sometimes fights a locked region — but violations are reproducible from the golden set now, which is the difference between a bug and a ghost.
Composed prompts got much shorter, because a large fraction of their former length was ours, not the user's. Shorter prompts also mean cheaper renders and, usefully, easier diffing when something goes wrong.

What didn't change, because no amount of prompt hygiene fixes it:

Renders still can't measure. If the actual wall is 3.4 meters and the sofa in the render reads as 2.6, nobody in the pipeline knows. Scale is estimated from pixels; a tape measure is still the final word before anyone buys furniture.
The model still drifts on mirrors, fine text, and complex ceiling lines. Those are model limitations, not prompt-layer ones.
Vague input still produces default-flavored output. We made the defaults honest and inspectable. We didn't abolish them, and users who type three words and expect a miracle will still get a competent render of somebody's taste — just with their own words, verbatim, at the front of it.

Three rules for anyone shipping a similar pipeline

1. Log the user's raw text separately from the model-facing prompt — forever. The single most useful debugging artifact we have is the pair (what the user said, what the model saw). If you only log the second, every intent-loss bug is invisible by construction.

2. If you must expand user input, expand into structured parameters, never prose. JSON fields can be unit-tested, diffed, suppressed, and audited. Free-text expansion can only be regretted. The entire class of "the LLM overrode the user" bugs shrinks to "the classifier misfiled a field," which is a much smaller animal.

3. Move constraints out of language and into product surfaces. A "keep this wall" checkbox beats a keep-clause any rewriter can eat. Every constraint you can express as code instead of tokens is a constraint the pipeline cannot paraphrase away. The prompt is the worst place to store the user's non-negotiables — it's the one part of the stack whose entire job is to change.

None of this is exotic. The hard part wasn't engineering; it was accepting that "helpful" and "faithful" are different objectives, and that we had optimized for the one users never asked for.

Try it on your own room

If you want to see how the pipeline behaves on your photos: goodesign takes one room photo and renders a redesign in about a minute. Your first 5 credits are free, no credit card required, and 1 credit is 1 render. And if you'd rather write prompts by hand, the five-part pattern — action, style, anchors, placement, keep list — is laid out in the prompting guide linked above.

This article was drafted with AI assistance and edited/fact-checked by the Goodesign engineering team.