One Thing I Learned About Working with AI Today
While working on my project today, I ran into a classic AI collaboration problem, again.
AI is fast. So fast that sometimes I catch myself assuming "it started writing" means "it understood." It doesn't. Maybe it got 80% of what I meant, and the other 20% turns into rework later on.
What I actually learned today wasn't some magic prompt. It was a much more basic workflow: align first, then build.
The problem isn't that AI is slow. It's that I'm impatient
This is how I used to work with AI:
Describe what I need, have it analyze the problem, then tell it to go change the code.
That's fine for small tasks. But in a real project, like the business logic, back-office flows and data processing in a restaurant SaaS, a lot of what matters isn't visible in the code itself.
Some logic looks convoluted because we got burned before. Some fields look redundant because real stores actually use them. Some parts can't be casually refactored because the downstream ops workflow depends on them.
AI doesn't know any of that context by default.
If I don't spell it out up front, it moves forward with whatever "looks reasonable." You end up with code that might not be wrong, but doesn't necessarily solve my problem.
Today I changed the order
Today I deliberately changed the first step.
Instead of asking "Can you build this for me?"
I started asking: "First, tell me in your own words what problem you think I'm trying to solve."
It's a tiny change, but the difference is obvious.
When the AI restates the problem, I can immediately see whether it got the point. Did it drift from the goal? Did it pull things into scope that shouldn't be touched? Did it miss any edge cases?
If the restatement is off, I don't let it write a single line.
Next, I have it list the acceptance criteria:
- What does "done" look like?
- Which existing behavior has to stay the same?
- Which files or modules should it avoid touching?
- How do we verify the change afterward?
These questions feel slow, but they're way cheaper than rework.
The smallest next step beats the big plan
I used to like asking AI for the full plan in one go.
Now I'd rather have it take just the smallest next step.
Not because AI can't handle big tasks, but because in real projects a lot of decisions have to be validated as you go. Especially as a solo builder, I'm product, engineering and ops all at once. I can't just care whether the code is elegant. I also have to care whether it'll hold up in production.
So now I keep the loop tight:
- Change one thing.
- Run it.
- Check the result.
- Confirm nothing in the existing logic broke.
- Then move on to the next step.
It's not flashy, but it fits indie development really well.
AI is a great teammate, but it's not the project lead
My biggest takeaway today: working with AI doesn't mean outsourcing your brain.
AI can write code, dig into bugs, break down plans and flag risks. But I'm the one who sets the project's boundaries, makes the business calls, and owns the outcome in the end.
So here's my new workflow:
Restate the problem → Align on boundaries → Write acceptance criteria → Make the smallest change → Run and verify → Move to the next step.
This process isn't about whether AI can write code. It's about how I cut down on misunderstandings and rework.
For an indie developer like me, working full-time on my own products and content, that matters a lot more than hunting for the perfect prompt.
If you're using AI on real projects too, try not rushing it into building. First, have it tell you what it thinks it's supposed to do.
That one step can save you a lot of headaches down the line.
When you work with AI, what trips you up most: misunderstandings, code quality, or verification? Let me know in the comments. I'll keep documenting the real mistakes and workflows I run into every day.