August 15, 2026 · 2 min read

Four exhibits shipped blank while every check passed

Four live animations on my AethrDesign case study shipped as blank rectangles. Locally they had rendered correctly every time I looked at them.

The cause was a difference I had configured myself. My development and production servers do not send the same content-security policy; development is deliberately looser so React's refresh tooling can run. The Lottie player I had embedded evaluated a string inside its loader, which development allowed and production refused. The canvas mounted, the script stopped, and four exhibits sat on the page as empty plates.

Nothing threw. Nothing logged. Every check I ran locally passed, because locally there was nothing wrong.

The four exhibits, running. In production they were four blank rectangles until someone opened the real site. This is what they render now, on the case study.
Four live Lottie exhibits from the AethrDesign case study, rendering the Rets AI onboarding sequence: select a template, upload documents, review structured output, analyze and export

The same failure, quieter

The other one ran for months. Every blurred image placeholder on this site, the low-resolution preview that fills an image box while the real file loads, was malformed: the generator glued a data: prefix onto a string that already carried one. The browser silently declined all thirty-six of them.

The symptom was that pages felt slightly emptier than they should while you scrolled. That is not a thing anyone files a bug about, and it is not a thing a test asserts unless someone suspected it first.

A better prompt was never the missing piece

Both failures were catchable. The exhibits needed one check against the deployed page under the production policy, which I now run before I call a deploy done. The placeholders needed someone to open a rendered page and ask whether the placeholder was actually decoding.

What no prompt supplies is the suspicion. Writing that check requires already knowing that a development server relaxes its policy, and that a data URL can be rejected without raising anything. Both are facts about a material, and I know them because I have spent time in that material rather than only reviewing output from it.

That is the practical case for staying close to implementation. AI-built work fails quietly more often than it fails loudly: an error is visible, but wrongness renders, ships, and sits there looking finished.

Where the line sits now

Most of the typing on this site is delegated, and the share keeps growing. What has not moved is the part where I open the real thing and check it against what it was supposed to do.

I do not write React to be fast at writing React. I stay near the material so my questions about it stay specific, because a reviewer who cannot name the likely failure is approving work rather than checking it.

Related Writing