How Do You Tell Who Did the Work on an AI-Built Portfolio?

Why 'Did You Use AI?' Is the Wrong Question

Because the honest answer is yes, and no tool settles it either way. A study of fourteen detection systems found them neither accurate nor reliable, biased toward calling generated text human-written, and worse again once the text is lightly edited ¹. So the useful question is not whether a model was involved in the portfolio project. It is what the candidate decided while it was.

That reframe costs you nothing, because the answer you need was never in the artifact. A portfolio piece shows output. Hiring an early-career person is a bet on judgment: what they do when the model is confidently wrong, which happens often enough that 66% of developers name "AI solutions that are almost right, but not quite" as their biggest frustration with these tools ².

Treat the project as a claim rather than as evidence, then go looking for the record behind it. The method in How to Verify 'Uses AI Daily' in Ten Minutes transfers here almost unchanged. And settle one thing before the call: a detector output is not a finding you can act on, which Do AI Detectors Work on Resumes and Cover Letters? covers in full.

Ask These Three Questions, in This Order

Ask what they threw away, where the model was wrong, and what is still broken. In that order, each question is harder to answer from a project you did not build, and none of them can be answered by re-reading the README. Someone who made the calls answers in specifics within about ten seconds. Someone who accepted them answers in categories.

1. Which approach did you try first, and what made you drop it?

Ownership shows up as a discarded branch. A person who built the thing has a first architecture, a first color system, or a first join that produced duplicate rows, and a reason it went. The reason is the tell. "It was slow" is a memory. "It was slow because every render refetched the whole list, and I only found that when the demo hit 400 items" is a decision.

2. Where was the model confidently wrong, and how did you find out?

This is the highest-yield question in the set, because the failure is universal and the discovery is personal. In the same survey, 45% of developers report that debugging AI-generated code takes more time than they expect ². Anyone who shipped an AI-assisted project has an incident here, with a moment attached: the test that failed, the page that 404'd, the number that came out ten times too large. Someone who prompted their way to a working demo and stopped answers with a category instead ("it hallucinated a library") and cannot say when.

3. What is still wrong with it, and what would you fix with another week?

Real authors have a list and are slightly annoyed about it. The answer names something specific and unglamorous: the test suite that only covers the happy path, the mobile breakpoint that was never finished, the two data sources whose totals still differ by 3%. A borrowed answer offers improvements a model would suggest for any project at all: add more tests, improve the UI, scale the database.

What Record to Ask For, by Field

Every discipline already keeps a record of its own work, and that record is what a finished artifact leaves out. In code that is commit history and issue threads. In design it is layer and version history, plus the frames that came before the final one. In analysis it is source notes, the raw extract, and the reconciliation that got two totals to agree. A single walk-me-through script misses in two of those three fields.

Code. Ask for a repository link, then read the shape of the history rather than the metadata inside it. Author name, email and date are all settable at commit time, through `--author`, `--date` and the `GIT_AUTHOR_DATE` environment variable ³, so no field in a commit proves who typed it. The pattern is harder to stage: small commits with reversals in them, review comments the candidate argued back on, an issue thread where the design changed mid-build. One initial commit of 4,000 lines is not disqualifying, but it is not evidence either, and asking about it is fair.

Duplication is worth a glance while you are in there. Across 211 million changed lines of code, GitClear measured copy-pasted code rising from 8.3% to 12.3% of changes between 2021 and 2024 while refactored code fell from 25% to under 10% ⁴. Repeated near-identical blocks prove nothing on their own. But "why is this function here three times?" separates an author from an assembler in about one sentence.

Design. Ask for the file, not the export. Version history, named layers, component structure and abandoned frames are the record. A designer who owns the work opens the file and shows you the version where the navigation sat on the left, and says what moved it. A handed-over comp has tidy final frames, no history worth scrolling, and layers named Group 47.

Analysis and research. Ask for the notebook, the query, and the number that did not reconcile. Every honest analysis has a moment where two sources disagreed and somebody chose. Ask which one they took, why, and what the answer would have been the other way. A model produces a confident chart from a file it never questioned. A person who did the analysis remembers the rows they threw out and can tell you how many.

The same problem arrives one stage later with two finalists holding the same deliverable, and Two Finalists, Same Output: How to Tell Who Did the Thinking takes it from there.

Write the Rubric Before the Call

Decide what a good answer sounds like before you hear one, or you will end up grading fluency. Write three or four lines per question (what a specific answer contains, what a thin one contains) and use the same sheet for every candidate on the role. Ask everyone the same three questions in the same order, and write the answers down in the same place.

This matters more than it looks, because the failure mode is not a candidate fooling you. It is a reviewer deciding that a nervous candidate, or one writing in a second language, "sounds like AI" and quietly marking them down. How to Stop Managers Rejecting Candidates for 'Sounding Like AI' makes the full argument. The short version: a hunch applied unevenly across a pool is what gets a process challenged, and a detector result does not rescue it ¹.

Hold the walkthrough to two rules.

• Send the questions in advance. Preparation is not the leak it looks like. A candidate who built the project prepares by remembering. One who did not prepares by inventing, and an invented answer is easier to catch once it has had time to get tidy.
• Ask about the project they submitted, not the project you would have built. The subject is authorship, not architecture. Drifting into "why didn't you use Postgres" turns a fifteen-minute screen into an unstructured technical interview, which is a different instrument answering a different question.

What This Still Won't Tell You

A walkthrough captures a candidate describing how they checked something. It cannot capture them checking it. The three questions test recall and specificity, which track authorship closely enough to be worth twenty minutes. But a well-rehearsed narration of somebody else's build is producible, and the tools that would produce it are the ones under discussion.

So keep it in proportion. This is a strong screen and a weak gate. Use it to decide who gets a real work sample, not to decide who gets an offer.

If your volume allows it, the stronger move is to skip ahead: put every shortlisted candidate in front of a short piece of occupational work with an AI assistant available, and watch what they do. That is cheaper per hire than it sounds, and Is It Cheaper to Assess Every Applicant Than to Screen Resumes? does the arithmetic. What you are reading for does not change: what got framed before anything got generated, what got refused, and what got checked against something outside the conversation.

Read the portfolio as a claim about capability. Production got cheap and judgment did not. The claim is still worth reading; it just stopped being the evidence.

See a sample report >