**Summary**
The speaker argues that to break into AI/ML you need self‑driven, end‑to‑end projects—not tutorial follow‑alongs. The process starts by picking a simple, personal problem, then drafting a minimal spec that covers data needs, storage, model choice, and deployment (e.g., dashboard, app, API). Aim for an MVP quickly, then iterate.
Four concrete project ideas are presented as resume‑worthy examples:
1. **Shelf Scanner** – A mobile‑friendly web app that uses a phone photo of a bookshelf, extracts titles via OpenAI’s GPT‑4 Vision (with a Google Vision fallback), and returns personalized reading recommendations. It includes a Postgres DB, basic caching, rate limiting, monitoring, and a simple Express/React stack deployed on Vercel.
2. **Pack Vote** – An AI‑powered group travel planner. Users create a trip, invite friends, collect preferences via Twilio SMS surveys, and receive AI‑generated destination suggestions (using a model gateway that can route to OpenAI, Anthropic, or DeepSeek). The group votes with a rank‑choice system. Features include prompt engineering, A/B testing, cost tracking, Prometheus metrics, and full test coverage.
3. **Are you a cat?** – A tongue‑in‑cheek MLOps learning project that classifies selfies as “cat” or “not cat.” It builds a complete pipeline with ZenML (training, deployment, inference), MLflow for experiment tracking and model serving, data validation (DeepChecks), configuration management, caching, and a Streamlit UI that logs feedback to S3 for future retraining.
4. **Days to Banana Death** – A computer‑vision regression project where you photograph bananas over time, label images with days until spoilage, and fine‑tune a pretrained ResNet (or similar) to predict remaining freshness. The output is a simple web app that takes a camera photo and returns a prediction (optionally with confidence). It demonstrates data collection, image handling, fine‑tuning, and deployment (e.g., FastAPI + lightweight front end).
Throughout, the speaker stresses breaking work into small steps, using tools like ACFlow for weekly planning and time‑blocking, and focusing on learning the full AI product lifecycle—data ingestion, modeling, deployment, monitoring, and iteration—rather than just model accuracy. These projects showcase initiative, end‑to‑end engineering, and production‑ready thinking, making them impressive to employers.
We need to extract key facts from the text, no opinions, each fact numbered, short sentences. The text is a transcript of a talk about AI/ML projects. We need to pull factual statements: e.g., "Follow-along tutorial projects aren't going to help you get a job in AI or machine learning." That's a claim, but it's presented as fact? It's more of an opinion? Might be considered opinion. The instruction: "Don't include opinions." So we need to avoid statements that are subjective. We need to stick to objective facts: e.g., "The speaker shares four example AI/ML projects." "Project number one is Shelf Scanner, an AI-powered book discovery app." etc. Also facts about what they used: "Used OpenAI's GPT-4 vision API for extracting bookspine text." etc. Avoid statements like "This API works well but is kind of expensive." That's somewhat opinion. Better to stick to factual descriptions: "The speaker used OpenAI's GPT-4 vision API." "They added limits to usage." etc.
We need to give each fact a number and keep them short sentences.
Let's go through the transcript and extract factual statements.
I'll parse sections:
- Opening: "You already know that followalong tutorial projects aren't going to help you get a job in AI or machine learning." That's an opinion. Skip.
- "Instead, you need self-motivated end-to-end projects, things you scoped, built, and shipped independently." That's advice, maybe opinion. Skip.
- "what does that actually mean? And how can you do it with no experience?" Not fact.
- "Today, I'm sharing four example a IML projects that would impress me if I was reviewing your resume to join my team at Amazon." Fact: speaker is sharing four example AI/ML projects. Could be considered fact.
- "These are not going to be cookie cutter projects that you've seen before." Opinion.
- "They're all projects I've either built personally or were designed by one of my mentees." Fact.
- "There are no ideas from Chachi PT or Kaggle projects other people have on their resumes." Fact (though maybe opinion). It states there are no ideas from those sources. We'll treat as fact.
- "I'll go through how to turn a problem in your life into a spec and all the components you need to include to demonstrate you have the skills." Not fact.
- "My goal is to inspire you to build genuinely cool, possibly even useful projects that you're excited about and help get you where you want in your career." Opinion.
- "Let's get started. Before we get into the example projects, let me lay out how I approach project planning." Not fact.
- "This will hopefully clear up a lot of the overwhelm and mysteriousness that new folks have when trying to come up with real projects." Opinion.
- "The first step in creating a project, whether it's for your portfolio or even at your job, is to identify a problem you want to solve." Fact (step description).
- "This can be anything." Not needed.
- "As you'll see in the example projects, the problems we're solving range from figuring out what to read next to how long until a banana goes mushy." Fact: examples of problems.
- "It's fine to keep it simple and possibly even silly." Opinion.
- "After that, we're going to do the simplest possible system design." Opinion? It's a plan.
- "We're going to answer these questions." Not fact.
- List of questions: "First, what kind of data will you need and how will you get it? Then, how will you store the data? What kind of model will you use? Think of simple baselines and then more complicated models to try. How will you deploy your model? In other words, how will users interact with your outputs? So, will you produce predictions that are just saved to a database? Will you have a dashboard the user can play around with? Or will you maybe even build a whole app?" These are questions, not facts.
- "Spend a couple of days working on a spec, but don't try to anticipate every problem or make it the most optimal possible design." Advice.
- "Your goal should be to get an MVP working as fast as possible and learn and improve from there." Advice.
- "Now, here are some examples of putting this into practice." Not fact.
- "Project number one, Shelf Scanner, an AI powered book discovery app." Fact.
- "For this app, I wanted to solve an annoying little problem I had recently." Opinion.
- "I was at a book sale and I didn't recognize any of the books on the shelves, so I didn't know what to buy and I ended up just not buying anything." Fact (personal experience). Could be considered fact.
- "My idea to solve this problem was pretty simple." Opinion.
- "You put in your reading preferences and Goodreads data, take a picture of the bookshelf with your phone and an AI model recognizes the books and makes recommendations." Fact (description of idea).
- "You can save stuff to read later or just buy the books directly on Amazon." Fact (feature).
- "I deliberately kept the app really basic with no user accounts or payments." Fact.
- "I bought a domain on Squarespace and deployed it." Fact.
- "For data collection and storage, I needed some way to store user reading history and preferences." Fact.
- "So, I used a Postgress database to handle image uploads from phones." Fact (though typo: Postgres).
- "I used Molter middleware and I just used device-based session management instead of user accounts." Fact.
- "The AI pipeline was pretty simple." Opinion.
- "I didn't train any models at all." Fact.
- "I just used OpenAI's GPT40 vision API for extracting bookspine text and identifying what's on the shelf." Fact (though GPT-4 vision? Actually GPT-4 with vision). We'll note.
- "This API works well but is kind of expensive." Opinion.
- "So I added limits to how much it can be used and I put the Google Vision API as a fallback." Fact