Vibe coding made me care more about edge cases
by•
As a product designer, I usually start by thinking through the main user flow first.
Vibe coding makes that flow surprisingly easy to turn into something that works.
The harder part starts right after.
What happens when there’s no data? What if an action fails? What should happen while something is loading? Can the user undo what they just did?
AI can get me to a working happy path very quickly, but I still find myself spending a lot of time thinking through everything around it.
In a weird way, vibe coding has made me pay more attention to edge cases, not less.
For designers and builders who vibe code, when do you start thinking about edge cases? While building the first version, or only after the main flow works?
22 views
Replies
I sketch the unhappy states right alongside the first working flow: empty, loading, error, and "what does undo restore?" Building a Linux design tool, I found undo was the one that hurt most when it came late, because every action has to be designed as reversible from the start. Empty and error states are cheap to add later, but undo shapes the architecture, so I decide it on day one.
I start one step earlier. Before the agent writes code, freeze one acceptance check for the happy path and one for the most expensive failure. Edge cases that change architecture, like undo, idempotency, and permissions, belong in the first design. Loading and empty-state polish can follow.