Two chatbots, two portfolios
An AI engineering portfolio is the work you show an employer, and it should show how you decide. Two people each show a chatbot. One shares a screenshot. The other shares an eval table, a list of known failures and a week's running cost.
A hiring manager learns far more from the second. This lesson is about building that second kind of portfolio from your capstones.
By the end of this lesson
Note
I can check a portfolio project against a checklist that shows judgement.
Key words
| Word | What it means |
|---|---|
| Portfolio | work you show to an employer |
| Repository | a project's folder of files and history |
| README | the first file a visitor reads |
| Known limits | what the project does badly, said plainly |
| Reproducible | someone else can run it and get the same results |
The cells students fill in are left blank in this preview.
A README says what, why and how
A visitor gives your repository a minute or two. The README has to carry that minute.
Say what the project does in one sentence. Say why you built it, and who it is for. Then say how to run it in a few steps, with fixed sample data, so it is reproducible. Put the eval results near the top, not at the bottom.
Worked example: a README outline
| Heading | What goes under it |
|---|---|
| What it does | One sentence: answers staff questions from 40 policy documents |
| Why I built it | The problem, and who has it |
| How to run it | Three steps, with the sample documents included |
| Eval results | 18 of 20 right, no guesses, with the date of the run |
| Known limits | Slow on long documents; misses questions about tables |
| What I would do next | One or two changes, each with a reason |
The cells students fill in are left blank in this preview.
Evidence and limits show judgement
Anyone can claim a feature works. Evidence is a number someone can check: an eval score, a cost, a latency.
Known limits matter just as much. Saying where your project fails shows that you tested it. It also shows you know what to fix next. The program checks a README's headings against a checklist.
Try it: check a README
# The headings found in a capstone README.
headings = ["What it does", "How to run it", "Eval results"]
checklist = [
"What it does",
"Why I built it",
"How to run it",
"Eval results",
"Known limits",
"What I would do next",
]
missing = 0
for item in checklist:
if item in headings:
print("ok ", item)
else:
print("missing ", item)
missing = missing + 1
print(missing, "of", len(checklist), "missing")
# Add "Known limits" to headings, then press Run again.
Safe, honest and yours
Before a repository goes public, check three things. No secrets: no keys or passwords, anywhere in its history. No personal data: use made-up names and sample documents.
And it is yours: say which parts an assistant wrote, and credit any code you reused. Add a licence, so others know what they may do with it.
A common mistake
Warning
Many people think a portfolio should only show what works. Hiding every failure reads as never having tested. State the known limits and what you would do next, because that judgement is what a reviewer is looking for.