A hiring manager gives your portfolio ninety seconds, opens one link, and decides whether to spend five more minutes. An AI portfolio that gets read has three deployed projects rather than thirty repositories, a live URL and a number on each, and a paragraph per project written for someone who will not run the code. Everything else on this page is detail on those three sentences.
The evidence that this is what employers want is in what they write. In our count of 315 AI job ads from July to September 2026, production or shipped appeared in 39% of postings, a portfolio or GitHub in 17%, a degree in 12%. They are asking to see the thing.
What is wrong with most AI portfolios?
They are lists of tutorials. A GitHub profile with forty repositories — a sentiment classifier on the IMDB dataset, a Titanic survival notebook, a chatbot that wraps one API call — tells a hiring manager that you followed forty tutorials, which is not nothing but is not evidence you can build. Worse, it hides the two projects that are yours under thirty-eight that are everyone's.
The second failure is the README that explains the technology instead of the outcome. "This project uses LangChain, Pinecone and GPT-4 to implement RAG" is a parts list. "Answers questions about 2,400 pages of council planning documents; 84% correct on a 200-question test set; the 32 failures are mostly tables" is a result, and it is the sentence that gets the next five minutes.
How many projects, and which ones?
Three, and they should be different from each other in kind. A good set in 2026:
- A deployed, model-backed application a stranger can use. A live URL, an input box, something useful happens. A retrieval system over a corpus you care about; an agent that does a small real task with two or three tools; a classifier on real data with a real decision behind it. This is the one you lead with.
- An evaluation. A test set you built, a number, and the list of failures with your explanation of why. This can be a project on its own — "I evaluated three models on this task and here is what I found" — and it is the rarest thing in candidate portfolios. Evals appeared in 23% of ads; almost no junior candidate can show one.
- Something that ran in production and broke. A short write-up: what happened, how you found it, what you changed, what you would monitor now. Employers hire for the second incident. If you have not had one, make the deploy of project 1 real enough that you will.
If you have a fourth, it should be a classical machine-learning project on tabular data — a forecaster or a classifier with scikit-learn — because a minority of roles still lead with that and it shows range.
What should the write-up for each project say?
Five things, in this order, in under 150 words: who it is for and what it does; the live link; how you know it works (the number and the test set); what broke or surprised you; what you would do next. Write it for a hiring manager who will not clone the repo — most will not. Put the same paragraph at the top of the README, on the project's page in your portfolio, and in the LinkedIn post about it.
Leave out the parts list. If they want to know it uses Postgres and a container, the repo will tell them.
Does the code quality matter?
Yes, at the second look, so make the first thing they open clean. A hiring manager who gives you the five minutes will open the main file. It should have tests, a README that runs in three commands, no secrets in the history, and no commented-out blocks from your debugging. It does not need to be beautiful. It needs to look like the work of someone who expects other people to read it.
If the project was built with a coding agent — and in 2026 most are — say so in one line and be ready to explain every part of it. The question "walk me through why this function is here" is the one that separates people who directed the tool from people who pasted its output. How can you tell if a candidate can actually use AI is the version of this written for the interviewer's side.
Where should the portfolio live?
On one page you control, with the three projects at the top, and links out to the live apps and the code. A personal site, a Notion page, a single well-organised GitHub profile README — the platform does not matter; the ninety-second experience does. Pin the three repositories. Archive or hide the tutorials. Put the same three links on your LinkedIn.
A graded record is the stronger version of this, because it is a third party saying the work was assessed. Every project in a Square 1 bootcamp is deployed, graded against a published rubric and recorded; the hiring leaderboard is where that record becomes visible to employers who have agreed to read it instead of a CV. Whether or not you study with us, the principle is the same: evidence someone else checked beats evidence you assert.
What if I do not have a production incident yet?
Deploy project 1 to real users and wait. Post it somewhere people will use it — a community you belong to, a subreddit, your old team — and watch the logs. Within a fortnight something will break: a prompt injection, a cost spike, an input you did not expect. That is the incident, and the write-up of it is worth more to your portfolio than another project. What is prompt injection is the one to read before the deploy, for obvious reasons.
The checklist
- Three projects, different in kind, pinned; everything else archived.
- Each has a live URL and a number you can defend.
- Each write-up: for whom, the link, how you know it works, what broke, what next — under 150 words.
- The first file a reader opens is clean and tested; no secrets in the history.
- One page you control, the same three links on LinkedIn.
- Built with a coding agent? Say so, and be able to explain every line.