[ EXECUTIVE TEARDOWN // TL;DR ]
- Reviewers check whether anything runs, whether you made the hard decisions, whether you can explain a trade-off, and whether anything is measured.
- The strongest piece is a live retrieval assistant on the portfolio itself, with a visible refusal path and its index exposed as an MCP server.
- A product with a readable trust boundary, such as a propose-and-confirm agent, gives reviewers something to disagree with, which is the point.
- Include one measured before-and-after result and one plainly told failure; both raise credibility more than another success.
An AI engineer portfolio has one job: let a stranger verify, in a few minutes and without talking to you, that you have put a model into production and understood what happened. Most portfolios fail that test not because the work is weak but because the site shows a list of technologies instead of a system someone can inspect. This post is the checklist I used to build mine, with this site as the worked example, including the parts I got wrong.
What a hiring manager is actually checking
Nobody reading an AI engineer portfolio is impressed by the words RAG, agents or fine-tuning any more. They are looking for four things, in roughly this order.
- Does anything here run? A live system beats a screenshot, and a screenshot beats a bullet point.
- Did you make the hard decisions, or follow a tutorial? Retrieval thresholds, refusal behaviour, cost controls, the boundary between what the model proposes and what the system commits.
- Can you explain a trade-off in writing? One honest paragraph about a failure is worth more than ten about a success.
- Is any of it measured? Latency, cost per request, eval scores, a payload reduction with a before and after.
Example 1: a live, grounded assistant on the site itself
The strongest example an AI engineer can put on a portfolio is a retrieval system that answers questions about the portfolio. It is self-demonstrating: the visitor asks, the system cites its source, and when asked something the site does not cover, it refuses instead of guessing.
On this site that is the concierge on the home page. It runs on a Cloudflare Worker, embeds the question with Workers AI, retrieves from a Vectorize index built from the site's own content, and declines below a confidence threshold. The same index is exposed as an MCP server, so a reviewer can connect it from inside Claude and interrogate it there. The design decisions are written up in semantic caching for edge RAG and the pipeline is re-indexed automatically after every deploy.
What makes it a portfolio piece rather than a widget is that the refusal path is visible. Ask it something it cannot know and watch it say so. That one behaviour answers the "did you follow a tutorial" question.
Example 2: a product with a trust boundary you can read
The second example is a shipped product where the AI can do damage if it is wrong, and the architecture stops it. For me that is Sable, a local-first finance agent. Every record lives in on-device SQLite with no cloud backend, and every action the model wants to take is rendered as a review card a person confirms. A hallucination's blast radius is one dismissed card.
The portfolio piece is not the app. It is the write-up of why the model never touches money. A reviewer can disagree with the design, and that is the point: it gives them something to disagree with.
Example 3: a measured engineering result
Every AI engineer portfolio should contain at least one number that was measured rather than estimated, with the before and the after. Mine is a 94% payload reduction on a workflow engine's graph serialisation. It is not an AI result. It is there because it shows the habit of measuring, which is the same habit that makes LLM cost control and evals possible. The FinOps side of that habit is in the AI FinOps playbook.
Example 4: the operating model, written down
Senior roles are increasingly about how you work with AI tools, not only how you build AI products. A portfolio can show that directly: a description of the workflow, what is automated, what is reviewed, and what the constitution files say. Mine is in one architect, Claude Code and MCP, with a 30-day plan a team could copy. Pipelines on this site, such as the weekly AI-drafted post that opens a pull request for review rather than publishing, are that model running in public.
What I got wrong, which is also an example
For four months this site was invisible to Google because an entrance animation shipped its hidden state into the static HTML, so the crawler's snapshot was blank. A separate mistake before that was an auto-publishing pipeline that flooded the site with commodity explainer posts, which got the whole site treated as low value. Both are documented in the repository and both are on this page on purpose. An AI engineer portfolio that admits what broke is more credible than one that does not, because every reviewer knows something broke.
A checklist you can apply to your own
- One live system a visitor can poke, with a visible refusal or guardrail.
- One product where the AI could do harm and the architecture prevents it, with the reasoning written down.
- One measured result with a before and after, even if it is not about AI.
- One description of how you work with AI tools, specific enough to copy.
- One failure, told plainly.
- Source code or a repository link for at least one of the above.
- No fabricated metrics, testimonials or dates. Reviewers check.
Templates and themes do not matter much. The list above does. If you would rather see the whole thing applied, the projects page is the index and the hire page is where it leads.
~/keep-reading
- 6 min readMERN Stack Developer vs Full Stack Developer: What ChangesEvery MERN developer is a full-stack developer, but not the other way round. What MongoDB, Express, React and Node fix in place, where the two titles diverge in real work, and which one to hire or become.
- 6 min readThe AI-Native Portfolio: Landing Lead RolesA portfolio that lists 'used ChatGPT' reads junior. One that demonstrates systems architecture — RAG, agents, guardrails, latency budgets — reads like the lead they're trying to hire. Here's how to build the second one.
- 8 min readWhatsApp Chatbot for Business: Monthly SaaS vs Owning ItWhat a WhatsApp chatbot really costs in India: Meta's per-message fees, WATI and Interakt plans over three years, and when an owned AI bot is cheaper.
YK
Yaseen Khatib · Full-Stack AI Engineer
Ships autonomous AI products solo — five in the last twelve months. More about Yaseen →
Want this built for your business?
I build what this post describes for clients — RAG chatbots on your own documents, AI added to systems you already run, custom software — at fixed prices you see before we start. Hiring instead? I'm open to senior and lead roles.
See services and prices →I'm hiring
Originally published at yaseenkhatib.streamerosai.com/blog/ai-engineer-portfolio-examples/.
Top comments (0)