RSS Amplifier

AI Weekender · Apr 16, 2026

How to Learn AI by Building Real Projects (Not Tutorials)

0
Sign in to vote or save

This page did not load. You can still read it on the original site — the toolbar below keeps your place in the directory.

A practical system: ship a live MVP, iterate from user feedback, and learn only what blocks you

Note: AI Weekender has moved. New posts are published at ai-weekender.com, and this Substack is now an archive.

To keep receiving weekly issues, please subscribe at ai-weekender.com instead of here.


Every meaningful technical skill I’ve learned was the result of a failure:

  • When Excel crashed at 100k rows, I learned SQL.

  • When SQL couldn’t produce visualizations, I learned Python.

  • When visualizations couldn’t account for risk and make predictions, I studied Machine Learning.

In AI engineering, we often get paralyzed by the “stack”. We think we need to master LangChain, Pinecone, and React before we can ship a full-stack AI product.

Building a weekend prototype using an iterative, “just-in-time” learning framework (image generated by author)

But the most effective way to learn is out of necessity, learning specifically to unblock a production goal. This “just-in-time” learning model has pulled me out of tutorial hell, and ensures every hour spent learning has a direct ROI.


TL;DR

  • The Sunday Rule: If you can’t ship a live URL in a weekend, you’re probably over-scoping.

  • Improve via Iterations: Let user complaints dictate your roadmap, not your “Grand Vision.”

  • Start with a Boring Stack: Use the tools you know to solve the problems you don’t.


Learning Through Iterations

I spent the past six months iterating on a production AI tool. I shipped a basic MVP in a weekend and let the subsequent “walls” I hit dictate every iteration:

  1. A Stateless Prototype: I shipped a pure LLM interface for practicing Cantonese.

  2. Adding User Authentication: My first user told me they were tired of repeating themselves every chat, so I added user authentication and how to load conversation history. This taught me session management and database persistence.

  3. Adding specialized tools and UI state: Over the next few months, different users came back asking for more: “I want to understand grammar patterns, not just chat.” They wanted different interaction modes, so I created 4 specialized modes for conversations, translations, learning grammar, and building vocabulary.


    I added buttons so users can toggle between modes, and I had to learn conditional logic and UI state management.


    After shipping this, I watched as engagement dropped. I panicked and figured out that user queries evolve with each turn and conversations rarely stay in one agentic mode. Having to manually select the appropriate agent created too much friction.

  4. Adding agentic routing: I shipped an agentic router so the system can weave between different agentic modes automatically based on the user’s query. That taught me prompt-based routing and intent classification.

I added 4 modes and engagement dropped (screenshot by author)

Before I shipped v1, I had a grand vision for pronunciation correction and complex features. I was wrong.

User feedback became my roadmap, and it’s better than anything I’d planned in isolation. Not only does this keep me honest, but also ensures that every code change I make serves a verified need.


Weekend Constraints Force Discipline

Most weekend AI projects fail from overscoping, not technical difficulty.

The most useful constraint I’ve found the Sunday URL Rule: “Can I put this behind a URL by Sunday?”

This forces you to make senior-level trade-offs that most hobbyists avoid:

  • UI Trade: Do I need a custom React component, or will a simple Streamlit interface prove the concept?

  • Feature Trade: Do I need five agentic modes, or would one robust prompt solve a pain point?

  • Tech Trade: Do I need a vector database today, or can I start with a simple JSON file for context?

My weekend v1s are always “boring.” They are rarely pretty, and they are never as smart as the version in my head, but shipping a barebones MVP and iterating on real friction beats shipping an over-engineered prototype that no one ever sees.

If you’re building this weekend, use this checklist to stay on track:


Closing Thoughts

I’ve bought courses and read many tutorials, often just to avoid the discomfort of not knowing. I’ve procrastinated on projects because I felt “unqualified” to build complex systems.

But the most sophisticated architectures I’ve built weren’t planned in a vacuum, they were the only logical solutions to the problems my users surfaced.

The most effective way to learn is to get started and keep learning as you go. I’ve picked up new skills with every iteration, and realized that the most durable expertise is built in the gaps between what you know and what your users need.

Don’t wait for permission or mastery. Ship the small, boring, barebones v1 this weekend.

What are you shipping this weekend?


Note: AI Weekender has moved. New posts are published at ai-weekender.com, and this Substack is now an archive.

To keep receiving weekly issues, please subscribe at ai-weekender.com instead of here.

Read on aiweekender.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.