One thing I have been using AI for lately is not writing code first.
It is finding the weird parts of a feature before I build it.
That sounds less exciting than generating an app from a prompt.
But honestly, it has been more useful.
When a feature is still in my head, it usually feels simple.
A staff member gets a shift.
They confirm it.
The owner sees the status.
Or someone cannot make it.
They tap a button.
Another person covers the shift.
Clean enough.
But once I start asking what can go wrong, the feature gets more real.
That is where AI has been helpful.
Not as the person making the product decisions.
More like a patient reviewer that keeps asking annoying questions.
The first version of an idea is usually too clean
When I describe a feature to myself, I naturally describe the happy path.
The user does the expected thing.
The system responds correctly.
The page updates.
Everyone understands what happened.
That is the version I want to build because it is easy to picture.
But real workflows are not usually that clean.
Someone does not respond.
Someone responds late.
Two people click the same button.
A shift changes after it was already confirmed.
Someone should not see all the details yet.
The owner needs to know what changed, but the staff member does not need the whole admin view.
None of these are strange cases once you think about them.
But I often do not see them when I am only thinking about the main flow.
I use AI to slow the feature down
The main thing AI helps me do is slow the feature down.
Instead of jumping straight from idea to page, I ask it to walk through the flow step by step.
For example:
What happens before the user clicks this button?
What happens immediately after?
Who needs to know?
What should change on the page?
What should not change yet?
What happens if the user clicks twice?
What happens if another person acts at the same time?
What happens if the action fails?
These questions are simple.
But they force the feature to become more specific.
And a specific feature is much easier to build than a vague one.
I do not ask AI to decide the product
This is the part I try to be careful about.
AI can generate a lot of possible rules.
Some of them are useful.
Some of them are too complicated.
Some of them sound smart but do not fit the actual product.
So I do not treat the answer as the final decision.
I treat it as a list of things to inspect.
For example, AI might suggest a full approval system, priority ranking, advanced eligibility rules, notification queues, audit logs, and role-based visibility.
Some of that might be right later.
But for an MVP, not all of it belongs in the first version.
The useful question is not:
Can this be more complete?
It is:
What is the smallest rule that keeps the workflow clear?
That question still has to come from me.
AI can help me see the options.
It cannot know which tradeoff is right for the product.
A small example: the cover shift flow
The cover shift flow looked simple at first.
A staff member says they cannot make it.
The shift becomes available.
Someone else takes it.
The owner sees that it is covered.
But when I asked AI to look for edge cases, more questions came up.
What if two people try to take the shift?
What if the original staff member changes their mind?
What if the owner already assigned someone manually?
What if the shift starts soon?
What if the person trying to cover it should not see the full address yet?
What if the claim fails?
What should the second person see?
Those questions changed the shape of the feature.
The UI was no longer just a button and a card.
There had to be a rule behind the button.
There had to be a clear state after the action.
There had to be a polite failure message if someone was too late.
That is the kind of thing I want to find before writing too much code.
Edge cases are not always extra features
I used to think edge cases were mostly things you handle later.
Build the main version first.
Clean up the weird parts later.
Sometimes that is still true.
But I am starting to see that some edge cases are not really optional.
They are part of the core workflow.
If two people can claim the same shift, that is not a rare technical detail.
It affects whether the schedule can be trusted.
If someone can see private job details before accepting a shift, that is not just a UI detail.
It affects what information the product exposes.
If the owner cannot tell whether a shift is confirmed or still waiting, that is not a small visual issue.
It affects the whole reason the product exists.
So I try to separate two types of edge cases.
Some are future complexity.
Some are core clarity.
AI is useful for listing both.
Then I still have to decide which ones matter now.
The prompt that usually helps me
The most useful prompt is not very fancy.
It is usually something like this:
Here is the feature I am building. Walk through the workflow as different users. Find the edge cases, unclear states, permission issues, and failure cases. Do not add big new features. Focus on what would make the MVP confusing or unreliable.
That last part matters.
If I do not say that, the answer can become too big.
AI will happily design a full enterprise system if I let it.
But I am not trying to build everything.
I am trying to find the parts that would make the first version break trust.
That is a smaller and more useful goal.
I still need to decide what to ignore
The hardest part is not getting suggestions.
The hard part is deciding what to ignore.
AI can make a feature feel bigger than it needs to be.
It can turn one button into ten flows.
It can make the MVP feel like it needs admin approvals, complex permissions, advanced logs, and detailed rules before anything ships.
That is dangerous.
So after I get the edge cases, I try to sort them into three groups.
Must handle now.
Can handle with a simple default.
Can ignore until real users prove it matters.
For example, double-claiming the same shift probably needs to be handled now.
A full eligibility ranking system probably does not.
A simple “already covered” message might be enough for the first version.
That sorting step is where product judgment still matters.
What this changes before coding
Doing this before coding changes the build in a few ways.
The database model becomes clearer.
The status names become clearer.
The UI actions become narrower.
The error messages become less surprising.
The dashboard knows what needs attention.
The staff view does not accidentally become an admin view.
It also helps me write better implementation prompts.
Instead of asking for a vague feature, I can ask for a specific flow.
Not:
Build a cover shift feature.
But:
When a shift needs cover, show limited details to eligible staff. Let one staff member claim it. The server should confirm the claim only if the shift is still open. If another person already claimed it, show a simple already-covered message.
That is much easier to build.
And much harder to misunderstand.
What I learned from using AI this way
The biggest lesson is that AI is more useful when I give it a smaller job.
Not:
Build my product.
But:
Help me see what I am missing.
That is where it has been the most helpful.
It does not replace product thinking.
It makes product thinking harder to avoid.
It forces me to write down the flow.
It shows me where my words are vague.
It gives me possible failure cases.
Then I still have to choose what belongs in the MVP.
For small tools, that has been a good balance.
AI helps me move from a clean idea to a more realistic workflow.
But the product still has to be decided by the problem, not by the prompt.
Top comments (0)