Every AI Portfolio Looks the Same Right Now
A RAG chatbot.
A sentiment analyser.
A fine-tuned model on Hugging Face.
Hiring managers see hundreds of them every week.
They're not impressed — they've already seen the tutorial you followed.
What they're actually looking for is evidence that you can:
- Take a vague brief
- Figure out what to build
- Scope a v1
- Ship it
- Explain every decision you made
That's a completely different skill.
And almost nobody is practising it.
What I Did
Over the past year, I've been applying to and interviewing with AI-native companies.
I kept every take-home assignment, interview brief, and product challenge I received.
Eventually, I turned five of those briefs into open-source portfolio projects that anyone can work through.
Each project is based on a real-world problem from a real company.
There are:
- No tutorials
- No step-by-step guides
- No example solutions
Just:
- The original brief
- Evaluation criteria
- A build-log template
- A framework for making decisions
The goal isn't to copy a solution.
The goal is to practise thinking like an AI-native builder.
The Repository
GitHub: github.com/ai-native-builder/ai-portfolio-projects
The 5 Real-World Briefs
1. Ember Coach Hire — Self-Serve Booking Product
Ember is a tech-first electric bus company.
Their coach hire bookings are still handled manually.
Your task is to design and build a self-serve booking flow that supports multiple trip types.
What makes it hard
Most candidates focus on the booking form.
They miss two important constraints:
- Different trip types require different business logic
- Electric vehicles introduce operational constraints diesel operators don't have
The challenge isn't building forms.
The challenge is understanding the business.
Category: Product / Booking
2. Creative Ops Platform — Workflow Automation
A social media team manages content approvals through spreadsheets and email chains.
Leadership, PR, and legal all review the same content.
But they're reviewing it for completely different reasons.
What makes it hard
There are actually two approval systems hidden inside one workflow.
Legal review is deterministic.
Marketing review is collaborative.
Most candidates merge them together.
Strong builders recognise they're fundamentally different systems.
Category: Automation / Workflow
3. Legal Contract Review Agent
A small in-house legal team reviews a constant stream of low-risk commercial contracts.
Most contracts are 80% boilerplate.
The queue is always longer than the day.
What makes it hard
You must:
- Source realistic contracts yourself
- Decide where AI can be trusted
- Decide where humans must stay involved
- Build a real evaluation framework
"It looks correct" is not an evaluation.
Category: Agent
4. B2B Outreach Agent — Hospitality
A London hospitality group wants more corporate bookings.
Their outreach process is entirely manual.
Someone:
- Finds businesses
- Finds contacts
- Copies data into a spreadsheet
- Writes emails
What makes it hard
This is actually a multi-stage system:
- Find
- Enrich
- Verify
- Write
Each stage has different tools, risks, and failure modes.
Most candidates swap a company name into a template and call it personalization.
That's not personalization.
Category: Agent / Automation
5. Multi-Agent Orchestration — EdTech
An education platform runs two AI systems:
- Admissions Agent
- Career Advisor
Both were built independently.
They don't share context.
A learner asking:
"What programme is right for me and what jobs does it lead to?"
gets bounced between two disconnected systems.
What makes it hard
You must:
- Design an orchestration layer
- Build a working prototype
- Write a strategy memo defending your architecture
The memo is evaluated just as seriously as the code.
Category: Agent / Architecture
What You're Actually Practising
These aren't coding exercises.
They're decision-making exercises.
Every brief teaches the same skill from a different angle.
Discovery First
Understand the business before writing a line of code.
Explicit Scoping
Write down:
- What you're building
- What you're not building
- Why
Build Logs
Document decisions while you're making them.
Not afterwards.
Honest Evaluation
Score yourself against objective criteria before asking for feedback.
What Hiring Managers Actually Want
Hiring managers at AI-native companies are not looking for polished demos.
They're looking for evidence of judgment.
They want to see:
- How you approach ambiguity
- How you make trade-offs
- How you handle constraints
- How you communicate decisions
A perfect demo can be generated by AI.
A trail of good decisions cannot.
The Framework Behind Every Project
Every brief references PRINCIPLES.md, a set of decision-making principles inspired by Nassim Taleb.
Via Negativa
Remove before you add.
Barbell Strategy
Keep the core stable.
Experiment at the edges.
Skin in the Game
Irreversible actions require explicit approval.
Robustness Over Optimisation
Simple systems that fail gracefully beat clever systems that collapse.
These principles aren't abstract.
Every one maps to a real product or architecture decision inside the projects.
How To Use These Projects
- Read
PRINCIPLES.md - Pick a brief
- Do discovery before touching code
- Fill in your build log
- Self-score against the criteria
- Share your work for feedback
The process matters more than the final output.
One More Thing
Most people build portfolio projects to show they can code.
The builders who get hired at AI-native companies build portfolio projects to show they can think.
The difference becomes obvious within the first five minutes of an interview.
Resources
GitHub: github.com/ai-native-builder/ai-portfolio-projects
Community: r/AINativeBuilder
Job Board: ai-native-builder.com