A Series: Building a SaaS with AI as my teammate
In my previous post, I talked about treating AI less like a code generator and more like a new engineer joining the team.
That experiment has been interesting.
What surprised me wasn't that AI generated bugs.
It was that it continuously made perfectly reasonable engineering decisions... based on assumptions I never told it.
And those assumptions slowly shaped the architecture of my project.
The first surprise: package selection 📦
When I started the implementation, I gave AI a lot of context about the project.
It knew the tech stack.
It knew the goal.
It knew this was a side project.
So I asked it to scaffold the application.
The packages it picked were completely reasonable.
After all, it knew this wasn't intended to become a huge enterprise application.
Only after reviewing the pull request did I realize something.
I had never actually explained the quality I wanted. 😅
In my head, this project sat somewhere between:
- a weekend hackathon project
- a production-ready service I'd confidently deploy
I wanted something lightweight enough to move fast, but structured enough that I wouldn't regret decisions six months later.
AI had no way of knowing that.
It optimized for exactly what I described: a side project.
And that was when I realized something:
AI doesn't just need to understand what you're building. It needs to understand how you think about building it.
Small technical decisions become big later 🧐
The more PRs I reviewed, the more examples I found.
One migration generated by AI looked like this:
- no
updated_atcolumn - only an
up.sql - no
down.sql
Again...
Nothing was technically broken.
If this were a quick prototype, I'd probably merge it without thinking twice.
But then I started asking myself:
"Wait... what happens when I need to rollback this migration?" 🤔
"What happens when I want automatic timestamps later?" 🤔
"Why did AI choose this?" 🤔
The answer was simple.
Because I never told it otherwise.
AI wasn't optimizing for long-term maintainability.
It was optimizing for:
"Make this feature work."
And honestly, that's a completely reasonable assumption when you tell it:
"This is a side project."
The problem?
A "side project" can mean many things.
It can mean:
- something I'll delete next month 🗑️
- something I'll use personally for years 🚀
- something that might eventually become a real product 🌱
AI doesn't know which one you mean unless you tell it.
My workflow changed 🔄
Originally my workflow looked like this:
Prompt AI
↓
Generate code
↓
Merge
Simple.
Fast.
But also risky.
Now it looks much more like working with another engineer:
Generate code
↓
Review PR
↓
Ask AI why it made certain decisions
↓
Ask for alternatives
↓
Research tradeoffs
↓
Decide myself
And this honestly feels much closer to how engineering worked before AI.
Before AI, we would:
- read official documentation 📚
- search through GitHub issues
- browse Stack Overflow discussions
- read engineering blogs
- compare different approaches
The difference now?
AI gives me a starting point much faster.
I can ask:
"What are the tradeoffs?"
Then:
"Give me an example where this approach fails."
Then:
"What if this grows from one engineer to five?"
And suddenly, a decision that might have taken hours of research becomes a much faster conversation.
AI shouldn't own architectural decisions 🚫🤖
One thing I've become careful about is letting AI "recommend" a solution.
Large language models are very persuasive.
Sometimes they'll even say:
"Personally, I think Option A makes more sense."
And sometimes I catch myself thinking:
"Hmm... maybe you're right." 👀
But confidence isn't the same as correctness.
So instead of asking:
"Which one should I choose?"
I ask:
- What are the tradeoffs?
- When does each approach fail?
- What problems appear later?
- What situations would make me regret this decision?
The goal isn't for AI to make the decision for me.
The goal is for AI to help me make a better decision.
This project is really an experiment 🧪
The application I'm building isn't just another side project.
It's become an experiment in understanding how AI behaves when context is incomplete.
Every time AI surprises me, I don't immediately think:
"AI got this wrong."
Instead I ask:
"What assumption did it make because I never gave it enough information?" 🤔
Those moments have actually become the most valuable part of this project.
Because every missing piece of context becomes another instruction I can add.
Every review becomes another lesson.
Every decision becomes another piece of information about how I want my AI teammate to work.
And slowly...
AI starts feeling less like an autocomplete tool.
And more like a teammate who understands how our engineering team works. 🤝
In Part 3, I want to explore another interesting pattern I've noticed: how AI changes when you stop treating prompts as one-off requests and start building reusable engineering context.
Top comments (0)