Should You Use AI to Build Your Portfolio?

Short answer: yes, and the rule is ownership. You can use AI for anything, as long as you can explain every line you present. That single constraint decides every specific question people ask about this, and it is the constraint interviewers actually test.

Pretending otherwise would be unrealistic. Professional developers use these tools daily, and a hiring manager who believes you built a full-stack application in 2026 without touching one is not paying attention. The question was never whether to use AI. It is what you are left holding afterwards.

Why ownership is the whole rule

Your portfolio is a claim: I can build this kind of thing. The interview is where the claim gets checked, and the check is almost always the same — pick something from your portfolio and ask you to go deeper.

Walk me through what happens when a user submits this form. Why did you use a queue here rather than doing it inline? What happens if two people do this at the same time?

If you understand your project, these are easy questions and you enjoy them. If AI wrote a substantial part you did not read, you get about ninety seconds in before the conversation stops working, and there is no recovery. Not because you used AI — because the portfolio made a claim that turned out to be false.

That is why the rule is not "use AI less". It is "use AI in ways that leave you understanding more, not less".

Where it genuinely helps

Scoping. This is the most underused application and it is where AI is best. Describe your project idea and ask what the smallest useful version is, what to cut, and what you are underestimating. You will get a reasonable MVP breakdown in thirty seconds, and scope discipline is the thing that most often decides whether a project gets finished.

Reviewing your own code. Paste a file you wrote and ask what is wrong with it — edge cases, error handling, a race condition, something you would regret in six months. This is genuinely valuable because it is adversarial against your own work, and it teaches you what to look for. You still decide what to change.

Explaining unfamiliar code. When you are reading a library's source or a codebase you have inherited, asking for an explanation of a section is faster than working it out cold — and you end up understanding it, which is the point.

Drafting documentation you then rewrite. A README draft from a description of your project is a reasonable starting skeleton. Rewrite the problem, decisions and what-was-hard sections in your own words, because those are the parts you will be asked about and the voice mismatch is noticeable.

Rehearsing explanations. Ask it to interview you about your own project. Give it your README and ask for ten questions a technical interviewer would ask. Then answer them out loud. This is genuinely effective preparation and almost nobody does it.

Generating test cases. "What edge cases should I test for a date-range filter?" produces a list you would have taken twenty minutes to think of, and each item is something you can then implement yourself.

Where it quietly costs you

Generating a whole project you have not read. The obvious one. The output usually works, which is exactly the problem — it feels like progress and it produces a repository you cannot defend. If you do generate substantial code, treat it as a first draft written by someone else: read every file, understand every decision, and rewrite the parts you would have done differently.

Writing your About section and project descriptions. AI-written portfolio copy has a recognisable register — balanced, enthusiastic, slightly weightless. Reviewers see a lot of it now, and it reads as generic rather than as bad. Your own plainer sentences are more distinctive. "I got into programming automating the rota at the pub I worked at" is not something a model would have written and it is worth more than three polished paragraphs.

Inflating your skills list. Watching a model use Kubernetes is not experience with Kubernetes. The skills section is the easiest place to over-claim and the easiest place to get caught, because it is a list of invitations to be questioned.

The specific questions people ask

Can I use an AI-generated project on my portfolio? Only if you have read it, understood it, modified it substantially, and can explain it. At that point it is arguably yours. If you cannot walk through the architecture without looking, it is not portfolio evidence — it is a liability sitting on your CV.

Should I say I used AI? You do not need to disclose it any more than you would disclose using Stack Overflow or a library. What you must not do is claim you did something you did not. If asked directly — and some interviewers do ask now — answer honestly and describe your workflow. "I used it for scoping and code review, and I wrote the core logic myself" is a completely good answer.

Will using AI make my portfolio look generic? It can, and mostly through the writing rather than the code. Three symptoms: every project description has the same rhythm, the About section could belong to anyone, and the technical decisions sound reasonable but unspecific. The fix is to write those three things yourself, badly if necessary. Specific and slightly clumsy beats fluent and anonymous.

Is it worth building an AI project to show I can use AI? Only if you would find it interesting anyway. A wrapper around a chat API is the new to-do app — very common, and it does not demonstrate much, because the hard parts are hidden behind the API. If you do build one, the interesting engineering is everywhere the model is not: retrieval, evaluation, cost control, latency, handling failures and bad output, prompt versioning. Build a project where that is the substance.

A workflow that keeps ownership

For each project:

1. Scope it with AI, decide yourself. Ask what the MVP is, then choose.
2. Write the core logic yourself. Whatever is actually interesting about the project — the scheduling algorithm, the concurrency handling, the data model — write that by hand. It is the part you will be asked about, and it is the part where you learn.
3. Use AI freely for the boilerplate. Configuration, forms, CRUD, test scaffolding. Read it, but do not agonise over it.
4. Review your own code with it. Then decide what to act on.
5. Draft the docs with it, rewrite the thinking sections yourself. Problem, decisions, what was hard.
6. Have it interview you before the interview does.

The through-line is that AI accelerates everything except the understanding, and understanding is the product.

The test

Pick your strongest project. Close the laptop. Explain it out loud for two minutes: the problem, the approach, the hardest part, what you would change.

If you can, the tools were doing their job. If you cannot, that is worth knowing now rather than in twenty minutes of silence across a desk — and the fix is to go back and read your own project until you can.

The free toolkit includes the case-study template that makes the two-minute explanation easy to write, and Developer Portfolio Builder has a 50-prompt library covering scoping, review, documentation and interview rehearsal, with the ownership rules attached to each one.