Edgecase - AI-Assisted Edge Case & Empty State Generator

In almost every design review I've sat in, someone eventually asks the same question: "What does this look like when it's empty? What happens if this fails? What if someone does this twice?" Too often, the honest answer is "we haven't gotten there yet." By launch, those states either don't exist or get written in the final days of a sprint with placeholder copy like "Something went wrong."

I've watched this pattern repeat across every product I've designed - a government platform used by thousands of people, an AI-powered restaurant SaaS, a consumer marketplace. The happy path gets weeks of design attention. Everything outside it gets twenty minutes before a deadline.

That's backwards. For a real person using the product, the moment something breaks or comes up empty is often the moment they decide whether to trust it at all. I wanted to see whether AI-assisted tooling could make designing for these moments as fast and natural as designing the happy path - and, just as importantly, I wanted to be deliberate about how AI was used in the solution, not just that it was used.

Before deciding what the tool should look like, I had to define what "good" actually meant here. Three things had to be true. It had to be fast enough to use mid-sprint - if checking for edge cases takes longer than skipping them, designers will keep skipping them, however clever the tool behind it is. It had to sound like the product, not like a template - generic AI copy like "Something went wrong" or "No results found" is exactly the problem I was trying to solve, not a solution, and would give teams false confidence that a state was "handled." And it had to be visual, not just written - a sentence of microcopy doesn't tell a designer whether a state actually holds up in a real layout; they need to see it, not just read about it.

This is where the project became more interesting as a design exercise than a pure engineering one. The obvious approach was to route every generation through a live AI model call - type a flow, get AI-written states back in real time. I chose not to, and the reasoning was a genuine AI product design trade-off, not a technical shortcut: a live model call would have been too slow to feel instant mid-sprint, too unpredictable to trust in a design review, and impossible to guarantee stayed on-brand across a whole product - exactly the three requirements I'd just defined as non-negotiable. So I designed a system that uses AI where it adds real value: I built the entire tool using Claude Code as my AI development partner, moving at a pace solo development wouldn't otherwise allow within a one-week hackathon, while keeping the actual runtime experience fast, deterministic, and fully reviewable. Every piece of output copy was hand-authored and tuned across three tones, so what a designer sees is consistent and predictable, not a fresh AI guess every time. I think this is an underrated AI product design skill: knowing which part of a workflow benefits from AI acceleration, and which part needs predictability more than novelty. Not every AI-shaped problem needs a live model in the loop at runtime.