An AI engineer portfolio: what a project that gets you hired looks like
The Ship AI Engineer team · Published 2026-09-30
An app that sends a question to a language model and prints the answer was impressive a few years ago. Today it's an afternoon's work, and the person hiring knows it. If that's the only AI project in your portfolio, it earns you nothing, because every candidate has one.
A credible project doesn't mean a bigger project. It means the same small idea in a state that's ready to meet a real user. The difference isn't in the architecture, it's at the edges: what happens when the model doesn't answer, when the input is unexpected, when the bill grows. Below are the signs that make a project credible, then five ideas that each show a different skill.
Six signs that make a project credible
It runs with one command. Someone who clones the project should be able to start it with a few lines from the README: dependencies pinned, an example config file present, their own API key the only thing they need. A project that needs an email exchange with you before it runs is a project that gets closed before anyone assesses it.
It says what it does and what it doesn't. The first paragraph of the README should say who the project is for and which problem it solves. A sentence like "works on these kinds of documents, not on scanned PDFs" isn't a weakness; it's the fastest proof that you know the subject.
It has thought about failure. When the provider returns a transient error, does it wait and retry? Is there a timeout if a request hangs? When the model returns broken JSON, does the user see a meaningful message or a stack trace? A few lines that handle those three cases show the difference between a demo and a product.
It has a measurement. A small hand-made test set (thirty questions will do) and a score. A candidate who can say "when I changed the chunk size, the rate of retrieving the right source went from here to there" always beats one who says "I think it works well". Running that measurement again being a single command matters as much as the measurement itself.
It knows its cost. A short note estimating how many tokens an average request uses and what a thousand users a day would add up to in a month. The calculation is arithmetic: tokens per request × requests per day × unit price. Very few candidates do it, and the ones who do show they see the model as a line item. You can try how an architecture choice changes the cost in the cost game.
Its secrets are safe. No API key in the repository, a .env.example file
instead, and a note on where the key goes. Not even in old commits: a deleted file
stays in Git history, and public repositories are scanned automatically.
Five project ideas
Each one shows a different skill. You don't need all of them; two done well are stronger than most portfolios.
1. A document assistant that cites its sources. A system that answers questions about an organisation's or a community's documents and shows, under each answer, which piece of which document it came from. The skill it shows: answering from your own data (RAG). Where the person hiring looks first: what happens when they ask something the documents don't answer. If it says "the documents don't cover this" instead of making something up, the project gets taken seriously. The usual weak spot: cutting documents into fixed-length chunks that split tables and headings down the middle.
2. A classifier with a measurement. A small service that sorts incoming support messages by topic and urgency. The skill it shows: evaluation. Where the person hiring looks first: the hand-labelled test set and the short table showing how the score moved as the prompt changed. The usual weak spot: looking only at overall accuracy, when what matters is how often an urgent message gets marked "not urgent".
3. An agent with a budget. An agent that completes a task using a few tools (a search function and a calculator, say). The skill it shows: tool use and controlling the loop. Where the person hiring looks first: the stop conditions: a step limit, a cost limit, and what happens when a tool fails. The usual weak spot: never passing the tool's error message back to the model; without knowing what went wrong, the model retries the same call again and again.
4. A structured data extractor. A tool that pulls specific fields out of messy documents such as invoices or CVs and produces JSON validated against a schema. The skill it shows: getting output a program can read. Where the person hiring looks first: what it does when validation fails. Inventing a default value is the worst answer, because it erases the trace of the error. The usual weak spot: accepting fields like dates and currencies without a format check.
5. A small live app with real users. One of the ideas above, running on the internet with sign-in and limits against abuse. The skill it shows: shipping. Where the person hiring looks first: an address, a monitoring view and a short note that starts "in the first week this broke, and here's how I fixed it". The usual weak spot: leaving the endpoint that calls the model open without a rate limit. Examples of how real projects break after launch are on the failure cases page.
How should you present it?
The top of the README is the only part someone giving your project two minutes will read. Put these there, in this order: a one-sentence description, how to run it, a screenshot or sample output, the measurement result and the known limits. The technical detail can sit below.
Then add a few sentences on why the project is designed the way it is. A paragraph that starts "I tried this first, it didn't work because of that, so I did this" says more than the code itself, because what the person hiring really wants to know is how you think when things go wrong.
These skills build on each other and come far more easily in order. We cover the order in our roadmap post, and how to judge a course on these terms in our course-choice post.
Sources
- GitHub: secret scanning: how keys that reach a repository are detected, and why they have to come out of the history too. (added 2026-09)
- The Twelve-Factor App: config: why config and secrets live apart from the code. (added 2026-09)
- Anthropic: Reducing hallucinations: techniques for letting a model say "I don't know". (added 2026-09)
- JSON Schema: Getting started: the standard way to validate structured output. (added 2026-09)
- Choose a License: plain-language summaries of which licence to put on a public repository. (added 2026-09)
Keep reading
2026-10-06
Resources worth following as an AI engineer: what to read, and when
A new post, model or tool appears in this field every day, and trying to follow all of it is the fastest way to learn none of it. A handful of resources that genuinely help, and the stage of learning at which each one is worth reading.
2026-10-05
Being an engineer in the age of AI: code got cheap, structure didn't
Writing code has never been this fast. But code produced quickly amplifies whatever structure sits underneath it. Why engineering matters more today, not less, and where to go deeper.
2026-10-02
Shipping an AI application: spending caps, caching, monitoring and model changes
In an ordinary web app every request costs roughly the same. In an app with a language model inside, it doesn't. Capping cost when you ship, using caching safely, watching the right things, and being ready when the provider retires a model.
2026-09-27
Prompt injection and abuse: why the server has to be the single source of truth in an AI app
An application with a language model inside carries every security problem of an ordinary web app and adds new ones. Why prompt injection can't be fully prevented, how to limit the damage, protecting the endpoint, and why the model's output can't be trusted.
2026-09-23
Building your first test set for an LLM application: a guide to evaluation
You changed the prompt and the answers look better. Do they? Building a first test set, taking a baseline, seeing what the average hides, the limits of one model grading another, and watching the system once it's live.
2026-09-19
When should you fine-tune, and when is it a waste of time?
Training a model on your own data is an attractive idea. Most of the time it's the wrong tool. What fine-tuning teaches and what it doesn't, how it compares with prompting and RAG, data quality, leakage, LoRA, and licences on open models.
2026-09-14
7 questions to ask before you pick an AI engineering course
Seven questions worth asking before you spend money and months on an AI engineering course. A short answer to each, and the concrete sign you can check in the syllabus before you buy.
2026-09-09
AI with image and audio input: the costs and failures your tests don't show
Handing a model a photo or a recording isn't the same as sending text. Request size, unreadable images, sentences invented in silence, generation that takes seconds, and an image paid for again on every turn.
2026-09-04
When don't you need an agent? Building and stopping a tool-using system safely
"Agent" is today's most requested and most easily misbuilt thing. The difference between a fixed workflow and an agent, why tool descriptions are critical, how to stop the loop, and how to protect irreversible actions.
2026-08-31
Why does RAG give wrong answers? Most failures are in retrieval, not the model
When a system that answers from your documents says something wrong, the model is the first suspect. Most of the time the culprit is the chunk it was given. Finding where the failure is, containing invention, citing sources and measuring properly.
2026-08-26
How to become an AI engineer: a roadmap that builds products, not models
Most roadmaps in the search results describe a different job. What the AI engineers being hired today actually know, the order to learn it in, and what makes each stage "done".
2026-08-21
When do you actually need a vector database? A practical guide to embeddings
The first step people take after deciding to build semantic search is usually picking a vector database. Most of the time it's an early step. What an embedding is, what a similarity score doesn't tell you, and the real reasons to move to a database.
2026-08-17
Managing prompts like code: versions, templates, schemas and tests
A prompt that works in a chat window quietly breaks inside an application. Keeping prompts in the repository, separating user input from instructions, validating the answer against a schema, and shipping a change only after measuring it.
2026-08-12
Why LLM APIs break under real traffic: rate limits, retries and timeouts
Three errors you never saw in development arrive together in the first busy hour. Telling 429 from 5xx, retrying properly, setting timeouts, and keeping the product up when the provider goes down.
2026-08-07
Do you need maths to become an AI engineer?
The honest answers to the six questions that stop people before they start: maths, degrees, machine learning, Python, hardware and money. Short answers first, reasons after.
2026-08-07
An AI engineer is not a machine learning engineer
Search "how to become an AI engineer" and the first page teaches linear algebra, CNNs and training loops. That is a different job. Here is what the work actually is, and what you can skip.