Cindy Zhu.
Free guides
CareerResource collection

5 GitHub repos to build a strong AI portfolio

Hey, it's Cindy 🌱 GitHub repos to build a strong AI portfolio, plus how to turn one into an original project you can show.
btw the waitlist for AI System Club is now open! If you're keen on using AI to automate your content, video editing, job search, business or build AI agents, feel free to sign up (only if you want to hehe). Ps. the waitlist gets first dibs:)

A portfolio gets more interesting when someone can see what you changed and why. These repositories give you useful starting structures. Your part is choosing a real problem, testing the result and making it easy for another person to understand your work.


part 01

Choose the result before choosing the repository

Write one sentence: “This helps [person] do [task] using [input], and returns [output].” Our worked example is a public-information assistant that answers workshop questions from a small set of published documents and shows the supporting source.

Decide what you can build with the time and skills you have. If Python is new, a small interactive data app is a more manageable starting point than a production deployment pipeline. If you already build models, choose a project that shows evaluation or operations rather than another introductory notebook.

The learning materials and repositories below are public, but model APIs, hosting and cloud infrastructure can cost money. Begin locally. Read the licence before adapting or publishing code, retain required attribution and explain which parts came from the starting repository.


part 02

1. LLM Zoomcamp: show how you evaluate an information assistant

DataTalks.Club's LLM Zoomcamp covers the pieces behind an assistant that answers from a knowledge base, including retrieval and evaluation. Follow the setup and the first relevant lesson before changing the dataset.

For your own version, collect a small set of public documents you have permission to use. Write ten realistic questions and identify the source paragraph for each answer before testing the assistant. Include questions the documents cannot answer.

Your portfolio can then show a useful distinction: did the search find the right information, and did the final answer use it correctly? A failure in retrieval is different from an answer that ignores a good source. Describe one failure you fixed and one limitation that remains. You need Python familiarity and whatever model access your chosen lesson requires; public lessons do not cover a separate API bill.


part 03

2. Made With ML: turn a notebook into organised model code

Made With ML is useful when you want to learn how training, evaluation, prediction and serving fit together. Read its environment and setup instructions rather than installing a random collection of packages from an old tutorial.

A portfolio adaptation could classify support requests into a few categories using a permitted, labelled dataset. Establish a simple baseline first. Keep a held-out test set separate from the data used to improve the model, and show examples where the system confuses two categories.

The result should include the dataset description, how you split it, the baseline and the command that reproduces your evaluation. That is more informative than a single accuracy number with no context. Choose this path when you can already read Python and want a more maintainable project structure.


part 04

3. MLOps Zoomcamp: show what happens after a model works

MLOps Zoomcamp includes experiment tracking, orchestration, deployment and monitoring. There's no live cohort planned for 2026, but the full course is available self-paced. Do not assume a self-paced certificate is included.

Bring a small model with a clear input and output. Record the data version and settings for each experiment, then document how you would detect a change in input data or prediction quality. For example, a support classifier may receive an increasing number of requests unlike its training examples.

This route expects programming and tooling familiarity, including command-line work and Docker in relevant modules. Cloud services can have their own charges. Build the smallest local version first and include instructions for shutting down any cloud resources you create. Your original contribution is the operating decision: what gets monitored and what happens when it changes.


part 05

4. Full Stack FastAPI Template: make the project usable

The Full Stack FastAPI Template provides an application starting point with a Python backend, React interface, database support and tests. It is a template, not an AI model or a completed portfolio project.

Use it when your idea needs users to interact with records or a more complete application interface. For example, a support triage app could accept a request, suggest a category and let a person correct it. That correction should be stored explicitly rather than silently treated as a perfect prediction.

Follow the repository's setup guide in a new copy. Get its original app running before adding the AI feature. Document what the template supplied and what you built. Review configuration and deployment requirements before exposing it publicly; using a template does not automatically make your application production-ready.


part 06

5. Streamlit: build a demo people can explore

Streamlit is a Python library for interactive apps. It is useful for a dataset explorer, model comparison or a small demonstration around an existing analysis. Follow the installation guide to create an isolated environment and install it.

For the workshop assistant, a small interface could accept a question and display both the answer and supporting excerpts. For a classifier, use sample inputs and a threshold control so visitors can see how behaviour changes. Make the limitations visible beside the result.

Once your environment is ready, a local app normally runs with streamlit run app.py. The file must exist and its dependencies must be installed. Get a tiny page rendering before connecting an API. Local software use and hosted model calls are separate cost decisions.


part 07

Build one project in five passes

  1. Define the user, input, output and one thing the project will not do. Write your test cases before polishing the interface.
  2. Run the upstream example unchanged. Record the repository version or commit and its setup instructions.
  3. Replace the example data or problem with your own permitted material. Keep the first adaptation small enough to debug.
  4. Test normal inputs, ambiguous inputs and missing information. Save actual results and explain failures without inventing benchmark numbers.
  5. Package a runnable demo, a clear README and a short walkthrough. Another person should be able to understand the point without reading every file.

part 08

Use this prompt to turn the repository into your project

copy this prompt
I want to build a portfolio project using this repository: [URL]. My experience is [experience], my available time is [time], and the problem I want to solve is [problem]. Read the current README and setup instructions before recommending a plan.

Propose the smallest original adaptation with a clear user, input, output and success check. Separate the upstream code from the work I need to add. Identify dependencies, data permissions, model access and possible hosting or API costs, then guide me through running the original example before changing it.

Create an implementation plan and a test set covering normal cases, missing information and failure cases. When there is running code, inspect the actual results and help me fix one meaningful weakness. Finish with a README covering setup, architecture, evaluation, limitations and attribution, plus a two-minute demo outline. Do not claim anything ran or passed unless it actually did, and do not invent hiring outcomes or performance numbers.

part 09

What a strong README should answer

Explain who the project is for, what goes in and what comes out. Show the quickest local setup, required environment variables by name without secret values, and one reproducible example. Include the tests you ran, the result and the limitation a reviewer should know first.

If installation fails, check the repository's documented runtime version and lockfile before changing unrelated packages. If the output looks good but evidence is weak, improve the evaluation before adding another feature. If the demo needs a paid API, provide recorded example outputs clearly labelled as examples, while keeping the live path optional.

Your finish line is one project you can explain, run and critique. A repository cannot guarantee a job; your decisions and evidence give someone useful material to assess. Start by writing the one-sentence project promise, then find more walkthroughs in all free guides.

Keep building from here. Find more practical walkthroughs in my free guide library.
the waitlist is now open

AI System Club is launching soon

Build AI systems with me through recorded lessons you can follow at your own pace. Join the waitlist for first access and the founding price.

btw this list gets first dibs
the moment doors open :)