What I Learned Building a Real Web Product With AI-Assisted Development

I started experimenting with AI-assisted development because I wanted to see how far I could take a real product without following the traditional development process.

Not a demo, not a weekend landing page, but something with a database, scheduled jobs, APIs, user accounts and thousands of dynamically generated pages.

The interesting part for me wasn't simply generating code with AI. It was learning where AI is genuinely useful and where you still need to understand what the system is actually doing.

*AI is great at building, but you still need to think about architecture
*
One thing I learned quickly is that asking an AI tool to "build feature X" works surprisingly well for isolated features.

The problems appear when the application becomes larger.

A change to one part of the system can affect:

• database queries
• caching
• authentication
• background jobs
• SEO
• API limits
• performance

At that point, the important skill becomes asking better questions.

Instead of:

Add this feature.

I now prefer something closer to:

Audit the existing implementation first, explain which components will be affected, and only then propose the safest implementation.

That small change in approach has prevented a lot of unnecessary problems.

*Real data changes everything
*
Working with real-world data is very different from building a simple CRUD tutorial.

You suddenly have to deal with:

• inconsistent data
• duplicates
• missing fields
• rate limits
• failed imports
• retries
• normalization
• background processing

A system that works perfectly with 100 records can behave very differently with tens of thousands.

Performance problems often appear in places you didn't expect.

For example, a small lookup performed once is irrelevant.

Perform that same lookup tens of thousands of times during an import and suddenly it becomes one of the slowest parts of the application.

*Automation needs observability
*
Another lesson was that automated jobs should never be a black box.

If a process imports thousands of records every day, I want to know:

• when it started
• when it finished
• how many records were processed
• how many were created
• how many were skipped
• how many failed
• where the time was spent

Without those numbers, debugging becomes guesswork.

Adding basic metrics and logs often provides more value than adding another feature.

*Vibe coding works best when combined with verification
*
I like the term "vibe coding", but I don't think it means blindly accepting generated code.

For me the useful workflow is:

1. Describe the desired outcome.
2. Let AI inspect the existing implementation.
3. Ask it to explain the risks.
4. Make one controlled change.
5. Test the result.
6. Measure what changed.

AI makes development incredibly fast, but speed also makes it easier to introduce problems quickly.

The faster the development process becomes, the more important verification becomes.

*Building something real is the best way to learn
*
I've learned considerably more from building and maintaining a live application than from experimenting with isolated examples.

A real product forces you to think about things that tutorials often skip:

• reliability
• deployment
• database performance
• SEO
• monitoring
• user experience
• edge cases
• cost

AI lowers the barrier to creating software, but the interesting part still comes from understanding the problem you're trying to solve.

That's what I'm exploring now: using AI tools to build practical products while learning more about the engineering decisions behind them.