Assessment design
A Portfolio Piece Counts When You Can Defend Its Decisions
A portfolio project is still worth something when AI could have built the same thing, provided you can account for the decisions in yours. Reviewers ask which approach you tried first and dropped, why you picked one option over an available alternative, and what broke along the way, because detectors cannot reliably tell who did the work. A sixth polished project adds less than being able to walk through the choices behind the first one. Build fewer projects and keep the record of how each one got made.
The takeThe build-more-projects advice was written for a world where making the thing was the scarce resource. That world is gone, and most portfolio checklists have not caught up with it. A candidate who ships one project with a documented failure and a rejected alternative gives a reviewer something to test. A candidate who ships six clean, generated projects gives them nothing to ask about. The portfolio's job was never proving you can produce an artifact; it was proving you can reason about one, and that job has not changed.
Where Olive fits
Open a role and see what the work shows
If the assessment an employer sends is Olive, using the AI assistant is the point: it is a role-grounded assignment worked openly with one. A person writes the report afterward, naming what you framed, what you delegated and what you verified in words rather than a score, and you receive the identical copy the employer does, free.
Rank your shortlistWhat Reviewers Actually Ask About a Portfolio Now
A reviewer looking at a portfolio that AI plainly touched does not stop to ask whether it did. The working assumption is that it did, and the real questions are narrower: which approach you tried first and abandoned, why you chose one structure over an available alternative, and what broke during the build. Detectors cannot answer any of that, and the published tests say they cannot reliably answer the narrower question of authorship either.
The tools that claim to settle authorship do not hold up under testing. Five general AI-text detectors, plus GPTSniffer, a detector built specifically for code, were run against AI-generated code drawn from three benchmark sets, and their accuracy came in mostly under 0.6 1. Those were short benchmark functions rather than whole repositories, so nothing in that study even reaches the scale of a portfolio project. A separate test of twelve public detection tools plus two commercial ones used in academic settings reached the same verdict from the other direction: the tools were neither accurate nor reliable, and leaned toward calling AI text human rather than the reverse 2. There is no working meter to point at your portfolio, which is why the questions moved to you.
That shift changes what belongs on a project page. A features list answers 'what does it do', which an assistant can answer as well as you can, in the same voice, for any project. The questions a reviewer is actually asking, why this data structure and not the obvious one, what the second version fixed that the first got wrong, where the assistant's suggestion was confidently bad, live nowhere on most project pages built to older advice. Writing toward those questions is the whole redesign this piece is arguing for.
Build Fewer Projects, Keep the Decision Trail
Ship one or two projects you can walk through blind rather than six you would need notes to explain. For each one, keep a short record while you build it: the alternative you considered and rejected, the moment something broke and what you changed, and where an assistant's first pass was wrong. That record is the actual deliverable now. The finished screen or repository only shows that decisions happened somewhere. The record is what lets a reviewer check them.
A worked example beats a description of one. Say you built a small booking tool. The record is not 'used AI to help with the backend.' It is: tried a single shared calendar table first, hit a conflict bug the second week, split it into per-resource tables after reading how a similar tool handled double-booking, and rejected the assistant's suggestion to add real-time sync because the project did not need it and the added complexity was not worth the two hours it would have cost. Four sentences, and a reviewer now has four places to ask a follow-up question.
The employer side of this exact question tells reviewers the artifact cannot settle who did the work. The guidance on how to tell who did the work on an AI-built portfolio is to ask what the candidate decided rather than to inspect the output for tells, and it says plainly that keeping no record is not itself a mark against anyone. That is the same conversation you should be ready to have about your own work, unprompted, before anyone asks.
Say Where AI Did the Work
Name the boundary before anyone makes you find it. State plainly which parts an assistant drafted, generated, or scaffolded, and which parts you designed, tested, or rewrote by hand. A reviewer's job is to locate that boundary anyway, through questions if you do not supply it, so disclosing it yourself costs nothing and gets you credit for the part that is actually yours.
A short note at the top of a project page does this cheaply: which files or sections an assistant generated, which ones you wrote and why, and one thing the assistant got wrong that you caught. That note is not a confession. It is the same information a reviewer would extract from you in conversation anyway, offered up front instead of pried out, which is the difference between looking prepared and looking cornered.
Employers cannot settle this from the artifact either, and more of the process is moving toward live conversation. In Greenhouse's 2026 survey of 373 hiring managers in the UK, Ireland and Germany, 37% named detecting AI-generated or heavily AI-assisted applications among their top hiring challenges, and 31% said they conduct more in-person, on-site interviews, which the report does not tie to that challenge 3. A portfolio review is heading the same direction: expect a walkthrough, not a grade on the deliverable alone. Keeping a running record of what you actually did with AI is what makes that walkthrough easy instead of a scramble to remember.
A Rough Project With a Defensible Trail Outranks a Generated One
A rough project you can account for gives a reviewer more to work with than a polished one you cannot. The credential-shaped instinct, another certificate, another polished sample, spends the next month in the wrong place. In a stated-choice experiment with 543 US hiring managers and HR specialists, raising a hypothetical candidate's relevant experience from zero to two years raised the probability of that profile being chosen by 21.4 percentage points, more than degree modality or institution type moved it 4.
That experiment measured degrees rather than certificates or portfolio pieces, and its outcome was a choice between written profiles rather than a real hire, so the transfer is an inference and worth naming as one. The shape of the finding is still the one this piece is arguing: substance a reviewer can question outweighs another item on the list. A career changer with one real, defensible project and an honest account of what an assistant did on it is closer to that finding than a career changer with five showcase pieces and no memory of building any of them.
Defensible does not mean rough for its own sake. Keep the projects you can defend, retire the ones you can no longer remember building, and let the record do what the count used to do.
Common questions
Should I remove old portfolio projects that AI clearly helped with?
Not for that reason alone. Remove a project if you can no longer explain the decisions in it, and keep it if you can. The signal a reviewer is reading for is whether you can account for the choices, not whether an assistant touched any part of the build.
Do I have to disclose that I used AI on a portfolio project?
Nobody is asking for a disclaimer on every page. What matters is answering honestly when asked which parts were yours, what you generated, and what you changed afterward. Being ready to say where AI did the work is different from adding a badge to every project you list.
What if my portfolio project failed or is unfinished?
An unfinished project with a clear account of what broke and what you tried next is more useful to a reviewer than a finished one you cannot explain. Write down what stopped working and what you would try if you kept going. That is evidence too.
How many portfolio projects do I actually need?
Fewer than older advice suggests. One or two projects you can walk through in detail, including the parts that did not work, do more for a reviewer than five you can only describe in general terms.
References
- 1. An Empirical Study on Automatically Detecting AI-Generated Source Code: How Far Are We? arxiv.org Supports that detectors built specifically for code cannot reliably verify who wrote the code in a portfolio.
- 2. Testing of Detection Tools for AI-Generated Text arxiv.org Supports that AI-text detectors generally are neither accurate nor reliable enough to judge a portfolio's write-up.
- 3. The 2026 AI in Hiring Report (Section 3: hiring manager challenges; Fig. 2: forms of candidate fraud observed) cdn.prod.website-files.com Supports that detecting AI-assisted applications is a widely cited hiring challenge and that more in-person interviewing is reported alongside it, without the report linking the two.
- 4. Examining Employers' Perceptions of Online Credentials: A Discrete Choice Experiment sr.ithaka.org Supports that demonstrable relevant experience outweighs credential type, applied here to portfolio substance over project count.
4 sources, numbered by first appearance. How Olive sources claims
General guidance for hiring teams. What works at one company and one volume may not transfer to yours.
Olive assesses how a person works with AI. It does not detect AI-written documents, and it never produces a score, a ranking, or a match percentage for a person. Candidates read the same report the employer reads.