Can you put a project on your resume if AI wrote most of the code?
You built something with an AI assistant doing much of the typing, and now you're not sure what you're allowed to claim. Here is where the honest line sits and how to word it.
By Howard Davner
You spent a weekend building a small app. An AI assistant produced a large share of the code, you steered it, fixed what broke, and got it running at a public URL. Now you're looking at a blank resume bullet and wondering whether writing "built" is honest.
It can be. Whether it is depends less on how much code the assistant typed and more on what you're claiming and whether you can back it up.
The short answer
Yes, you can put an AI-assisted project on your resume, provided three things are true:
- What you claim is accurate.
- You understand the project well enough to explain it.
- You would answer honestly if someone asked how you built it.
The line isn't "AI touched it" versus "AI didn't touch it." The line is between ownership and authorship. You can own a project you didn't type every line of. You can't claim authorship of work you didn't do.
Two pieces of common advice that are wrong
"Never mention AI, nobody needs to know." This is a bad plan because interviews exist. If you list a project and can't explain how the login works, the hiding doesn't matter, because the gap shows within a few questions. Concealment also means that when someone asks directly, you're improvising an answer to a question you hoped to avoid.
"If you used AI, it doesn't count." This ignores what a project shows. Choosing what to build, cutting scope so it's finishable, deciding how the pieces connect, debugging when the output is wrong, and deploying it where a stranger can use it are all real work. Plenty of that work is still yours when an assistant writes the boilerplate.
What you are actually claiming
When a recruiter or hiring manager reads a project line, they are asking a quiet question: could this person do something like this on my team? So think about what you contributed that transfers.
- Scoping. You decided what the project would and would not do.
- Design decisions. You chose the data model, the tools, the tradeoffs.
- Integration. You made separate pieces work together.
- Debugging. You found out why it broke and fixed it.
- Shipping. You deployed it, and it stays up when someone else opens it.
If you did those, you have something to claim. If you pasted in a prompt and accepted whatever came back, you have a demo you didn't build, and the honest move is to spend a few more hours making it yours before listing it.
A test before you list it
Ask yourself these questions with no assistant open:
- Can I explain, in plain language, what happens from the moment a user clicks the main button to the moment they see a result?
- If someone asked me to change one behavior, could I find where to change it?
- Can I name one thing that broke while I built it and how I found the cause?
- Can I say why I picked this approach over an obvious alternative?
- Can I say which parts I understand least?
If you can answer most of these, list it. If not, read the code file by file, break something on purpose, and fix it. That hour is what turns generated output into a project you can defend.
How to word the bullet
The risk is in verbs and specifics. Claiming precise technical authorship you can't support is where people get caught.
Weaker wording:
- "Wrote a custom recommendation algorithm from scratch." (Did you?)
- "Developed a full-stack application." (Says nothing about what it does.)
Stronger wording describes the problem, what you built, the stack, and the outcome you can verify:
- "Built and deployed a web app that lets users upload a CSV of expenses and see spending by category; React front end, Python API, hosted at [link]."
- "Designed the data model and connected a third-party weather API to a dashboard; debugged rate-limit and timezone errors before launch."
Notice that neither line says "AI-assisted" and neither lies. They describe what you did. The link lets the reader check the result in seconds, which does more for credibility than any adjective.
If you want to be transparent on the page, put it in the README, not the bullet. A short "How I built this" section can say which tools you used, including an AI assistant, and what you wrote, changed or debugged yourself. Readers tend to trust a project more when it's specific about its own process.
What to do if an application asks about AI use
Some employers have policies, and some application forms ask directly. Follow what they ask and answer truthfully. Don't treat it as a trap. "I used an assistant to generate first drafts of some components, then reviewed, changed and tested them, and I made the architecture decisions" is a normal, honest answer if it's true.
How this plays out in the interview
Expect to be asked to walk through the project. Pick one part, ideally the part that gave you the most trouble, and prepare to go one level deeper than feels comfortable.
- Explain the flow of data through the app.
- Describe a bug and how you diagnosed it.
- Say what you'd change if you had another week, and why.
- Be ready for "what does this part of the code do?" on a file you open cold.
If you hit something you don't know, say so and reason out loud. "I leaned on the assistant for this piece, so let me think through what it must be doing" sounds like someone who can work. Bluffing sounds like someone who can't.
What gives weak projects away
- A README that reads like generic filler and never mentions a decision.
- Features with no reason behind them.
- A live link that's dead or shows an error.
- Code the author can't locate or explain.
- A bullet whose claims are bigger than the project.
Every one of these is fixable, and none of them is about whether an assistant was involved.
Where a working link helps
A project someone can open and use answers the first question a reader has, which is whether it exists and works. That's the idea behind Provieo: you start from a job description, scope and build a real project, deploy it to a URL, and then turn it into a resume bullet and interview prep you can actually explain. Whatever tools you use to build, the standard is the same. Make it real, understand it, and describe it accurately.
Frequently Asked Questions
Do I have to say I used AI to build a project?+
You don't need to put it in every resume bullet, but you must never deny it or imply you wrote code you didn't. A short note in the README about how you built it is a good habit. If an application or interviewer asks directly, answer plainly and specifically.
Is a project I built with AI worth less than one I coded by hand?+
Not automatically. A reader cares whether it works, whether the choices behind it make sense, and whether you can explain it. A hand-coded project you can't discuss is weaker than an assisted one you understand well.
What if an interviewer asks me to explain code I don't fully understand?+
Say which parts you understand well and which you leaned on the assistant for, then reason out loud about what the unfamiliar part is probably doing. Guessing confidently and being wrong costs you more than admitting a gap. The better fix is to read every part of the project before you list it.
How do I word a resume bullet for an AI-assisted project?+
Describe what you decided, built, connected and shipped, and name the real technologies. Avoid verbs that claim sole authorship of specific code, such as 'wrote a custom algorithm', unless you did. Link to the live project so the reader can judge the result themselves.
Put a working link in your next application.
Paste the job you're applying to. Provieo designs a project against that exact listing and walks you through deploying it, so what a recruiter clicks is the work itself, not a description of it.
Free to use, and your first deployed project is free. Or tailor your resume to the same posting.