Stop Collecting Tutorials and Start Building AI Projects That Solve Real Problems

I have eleven browser tabs open right now. Four of them are AI tutorials I “definitely” am going to finish. Two are GitHub repos I starred eight months ago and never cloned. This is not a flex. This is a confession.

For a long time, I thought the path to getting good at AI was simple: watch enough videos, read enough guides, collect enough bookmarks, and one day I’d just know how to build things. It doesn’t work that way. I only started actually improving once I stopped studying AI and started pointing it at problems I actually had.

Here’s the shift that changed things for me, plus a few small projects that prove the point, none of them fancy, all of them useful.

The trap: learning AI by collecting AI

Tutorials feel productive. You watch someone build a chatbot, you nod along, you maybe even type out the code with them. Then you close the tab, and you couldn’t rebuild it from scratch if your life depended on it.

The problem isn’t the tutorials. It’s that “How do I use this tool?” is the wrong starting question. It puts the tool first and the problem second, so nothing sticks, there’s no friction, no stakes, nothing forcing you to actually understand what you built.

The better question is boring, but it works: what’s annoying me this week that I could automate away?

Project one: the inbox triage script nobody asked me to build

My actual problem was email. Specifically, the fifteen minutes every morning I spent deciding what was urgent, what was a newsletter, and what I’d “get to later” (a lie I told myself daily).

So I built a tiny script that pulled unread subject lines and senders, sent them to an LLM with a short classification prompt, and tagged each one as urgent, FYI, or noise.

import openai

def classify_email(subject, sender):
    prompt = f"Classify this email as URGENT, FYI, or NOISE.\nFrom: {sender}\nSubject: {subject}\nReply with one word."
    
    response = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0
    )
    return response.choices[0].message.content.strip()

That’s it. That’s the whole clever part. The unglamorous part connecting it to my actual inbox via API, handling rate limits, deciding what “urgent” even meant for me, took way longer and taught me more than any tutorial had.

Pro tip I picked up the hard way: when you’re prompting for classification tasks, set temperature to 0. You want consistency, not creativity, and I learned this only after my script called the same recurring newsletter “urgent” three days in a row and “noise” on the fourth.

Project two: the meeting notes nobody wanted to write

Every team has that person who hates writing meeting summaries. For a while, that was me. So I recorded meetings (with important details), transcribed them, and had a model extract action items and decisions instead of a full transcript.

The lesson here wasn’t really about the AI part. It was that summarization prompts live and die on constraints. “Summarize this” gives you mush. “List only action items, each starting with a verb, max 10 words,” gives you something your team will actually read.

Project three: the file graveyard on my desktop

Like a lot of people who download things “for later,” my desktop turned into a junkyard of PDFs with names like Untitled-47.pdf. I built a small tool that read the first page of each file, generated a short embedding, and clustered similar documents into folders automatically.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
summaries = ["doc summary 1", "doc summary 2"]
embeddings = model.encode(summaries)

Was it perfect? No. It occasionally grouped a tax form with a recipe because both mentioned “April.” But it got me 80% of the way to an organized desktop, which is 80% more organized than it had ever been.

What actually changed for me

None of these projects was impressive on paper. No one’s hiring me off the strength of an inbox sorter. But each one forced me to deal with the unglamorous stuff tutorials skip: authentication, edge cases, what happens when the API times out, and what “good enough” actually means for a real task.

That’s where the learning lives. Not in the demo. In the duct tape.

If you’re stuck wondering what to build next, don’t open another course. Look at your own week. What did you do twice that a script could do once? What email did you reread three times because you didn’t trust your first read? That annoyance is your project idea, and it’s a better teacher than any 40-part YouTube series.

Start small. Time-box it to a weekend. Solve your own problem first, the resume, the impressive portfolio piece, that can come later.