Most portfolio projects we see in 2026 were built with help from an AI tool — ChatGPT, Claude, Cursor, Copilot, or one of the app builders that turn a prompt into a deployed site. That is not a problem. Professional developers work the same way now, and pretending otherwise would be silly.
The problem is a different one. A growing number of candidates ship a project they cannot explain. The code runs, the demo looks good, and the first "why did you do it this way?" produces silence. The interview ends there, whether the interviewer is a person or an AI.
This post is about closing that gap.
How interviewers can tell
Nobody needs a detector. The tells are in the conversation:
- You can describe what the project does but not how. "It uses JWT for auth" — fine. "Where is the token stored, and what happens when it expires?" — nothing.
- You cannot explain a choice that was made. Why Postgres and not a file? Why is this a background job? If the answer is "the tool chose it", the interviewer now knows who built the project.
- The code has patterns you do not recognise. AI tools love certain idioms. If your repo has a retry decorator you cannot describe, that is visible.
- You cannot change it live. Asked to add a small feature on the spot, you do not know which file to open. This is the single strongest tell, and the one Iber's interviews lean on.
None of these are about whether AI was used. They are about whether you understand the thing you are presenting as yours.
The four-step routine
Do this for every project you build with AI help. It turns generated code into code you own.
1. Read every file it wrote, once, out loud
Not skim. Read. If a line does not make sense, ask the tool to explain it, then rewrite it in your own words — or delete it if it is not needed. AI-generated projects are typically 30–50% larger than they need to be; trimming them is a fast way to learn what every part does.
2. Break it on purpose
Comment out a line in the auth middleware. Change a database column name. Kill the API key. Watch what fails and where the error surfaces. Then fix it. You will learn the shape of the system in an hour, and you will have real answers when asked what happens when things go wrong.
3. Rewrite one part by hand
Pick the module that matters most — the parser, the matching logic, the query that does the real work — and rewrite it yourself without the tool. It does not have to be better. It has to be yours. This is the part you will talk about in the interview, and The hard part paragraph of your README.
4. Write down three decisions and their alternatives
For each: what you chose, what else you could have done, and why you did not. "SQLite because it is one file and this has one user; would move to Postgres if two people needed it at once." Three of these, ready, will carry most of a project interview.
What to say when asked
Say the truth, briefly, then move on to the decisions: "I scaffolded it with Cursor and rewrote the scoring module by hand because the generated version recomputed everything on each request. Here is what changed."
That answer signals three things every interviewer wants: you use modern tools, you read what they produce, and you know where the weak part was. Hiding the AI usage signals the opposite and is usually obvious anyway.
How this plays out on Iber
Iber does not ask whether you used AI to build something. The AI interview asks about the code that exists: why it is structured the way it is, what breaks under load, what you would change. Follow-up questions react to what you actually said, so a vague first answer gets a sharper second question rather than a pass.
Some roles add a challenge on your own repository — a small change requested live, in the browser. If you did the four steps above, that is ten comfortable minutes. If you did not, it is the moment the gap shows.
The interview also considers what you present as your own. Claiming a generated project as fully hand-written and then failing to explain it is treated as inconsistency, because that is what it is. Saying "built with AI, here is what I changed and why" is treated as an engineer describing their process.
The short version
Use the tools. Then do the work that makes the result yours: read it, break it, rewrite the part that matters, and know three decisions cold. A project you can explain and modify live is a strong project regardless of how the first draft was written. A project you cannot is a liability, no matter how good the demo looks.