Disclosure: I'm the founder of Hadaa, an AI landscape design tool. I use it as the worked example here because it's the system this actually happened to — the lesson is the point, not the product.
There's a failure mode I now watch for in every system I build, and it has nothing to do with the model, the framework, or the infra. It's this: you can spend a year perfecting a pipeline that operates on the wrong input.
Here's how I learned it.
The pipeline that worked
We build software that turns a landscape design into photorealistic renders. For about ten months, the entire thing rested on one assumption I never once stopped to examine: the input is a sketch. A pro uploads a rough drawing of the yard, the engine reads it and produces a render.
And it worked. People paid for it. So we did what you do with something that works — we optimized the hell out of it. Better reading of the sketch. Better inference of what the lines meant. Better handling of ambiguity. Ten months of honest, measurable engineering progress on the sketch-to-render path.
The thing is, every one of those improvements was in service of a harder and harder guessing game. A sketch is a lossy proxy for the real design. We were pouring effort into reconstructing information that had been thrown away before the file ever reached us.
The one sentence
I got on a call with a pro to debug why one of his renders didn't match what he'd pictured. We were looking at his sketch together and he said, completely offhand:
"Yeah, the sketch is just the rough version. The real drawing is the CAD file."
He shared the .dwg. I opened it. And it was one of those quiet, slightly sickening moments where the floor tilts.
The file had everything the sketch had discarded. Every layer. The plant legend with exact species. Spot levels. Retaining walls. Sheet notes. All the information we'd built an elaborate engine to infer — the customer already had it, in full, sitting in a file on his laptop the whole time.
We'd built a beautiful machine for reconstructing a plan from a blurry photo of it, while the plan itself was one upload away.
The general lesson
This generalizes way past landscaping. So much AI product work is quietly an exercise in recovering information from a degraded representation — OCR'ing a scan when the source doc exists, parsing a transcript when structured data was available, re-deriving intent from a UI screenshot when there was an API. The lossy proxy is seductive because it's what the user happens to hand you first. It feels like the input. It usually isn't the source of truth.
The question I should have asked in month one — and now ask on day one — is: "Is this the real artifact, or a lossy picture of it? And if it's a picture, where does the real one live?"
Almost always, the real one lives somewhere boring and accessible, and reaching for it is less work than the heroics you'd otherwise spend compensating for what the proxy lost.
So we stopped guessing and started reading the file directly.
Reading the source of truth is its own kind of hard
I want to be honest that "just read the real file" is not a free lunch. Turning a CAD drawing into a render that actually matches what was drawn is brutal. The only way we found to get it right was to get on call after call with real pros and ask them for real, messy, live project files — never clean demos. Every single call broke something: a house on a slope with walls floating in the air, a roof overshooting the walls, retaining walls that didn't step the ground, garden lights that didn't look like lights, plants that all rendered identical.
Two things came out of that grind that I'd recommend to anyone building on a "real" source artifact:
1. Measure fidelity as a number, not a vibe. We built a test set of real drawings with hand-made answer keys, purely so we could measure how much of a drawing's meaning a render preserved and how much it lost. "Meaning and loss" is now a value we track on every change. You cannot improve "does the output match the input" if match is a feeling.
2. Discover that half your "loss" is upstream. A lot of what looked like our engine losing information turned out to be drawings that never carried it cleanly in the first place — inconsistent layers, missing legends. That pushed us to write up a CAD drawing standard for landscape plans: the layer and legend conventions that make a drawing read cleanly for a machine. When you consume a real-world artifact at scale, you often end up having to define what "clean" looks like.
Where it landed
We ship to this engine every day now, and we eat the cost of being wrong on purpose: every rendered view is checked back against the original drawing, up to three times, until it matches — and if it still can't, the customer pays nothing. A miss is on us, not them. That guarantee is terrifying and it's also the best forcing function we've ever had, because it means "meaning and loss" isn't an internal metric, it's money.
If you want to see where the source-of-truth path ended up, this is the engine now: turning a landscape DWG into a photoreal render.
The takeaway
Our old engine wasn't bad. It was good engineering built on an assumption we never had the humility to question. One customer questioned it for us, in passing, and the single most important technical decision we made this year came out of one offhand sentence on one call.
Before you optimize a pipeline, interrogate its input. Ask whether you're reading the artifact or a lossy photo of it. The expensive mistakes aren't the bugs in your code — they're the assumptions you never thought to put under test.
Has a single conversation ever flipped a core assumption in something you'd been building for months? I'd genuinely like to hear it.
Top comments (0)