Usually yes, but only within the rules your capstone instructor sets, and those vary from course to course. Where AI coding tools are allowed, US university policies converge on three requirements: disclose which tool you used and for what, mark AI-generated code in the work itself, and be able to explain and defend every line you submit.
Can I use AI coding tools on my senior capstone project?
Most senior capstones are code-heavy, and most students now write code with an assistant open: Copilot in the editor, Cursor, or a chat window. So the question comes up early in the semester. Is this allowed, and what happens if a reviewer thinks the project is "AI-built"?
There's no national rule. Every US university leaves the answer to the course, and many leave it to each instructor. But the written policies we read agree on more than you'd expect.
What do university policies agree on?
We read four sources: guidance from Stanford's Board on Conduct Affairs, Carnegie Mellon's teaching center, the computer science school at Austin Community College, and the electrical engineering and computer science (EECS) school at Oregon State. They differ in tone, but four points come up again and again.
The instructor sets the rules, and "nothing in the syllabus" is not permission. Stanford's generative AI guidance says that without a clear instructor statement, AI should be treated like help from another person, and that using it to substantially complete an assignment isn't allowed. Oregon State's EECS guidance on AI use policies is stricter: with no stated policy, students may make only routine grammar corrections. Austin Community College's CSIT policy says instructors may allow, restrict or require AI on each assignment.
Disclosure is the price of using it. Every source that allows AI asks you to say so. Austin CC says it plainly: "You must disclose any AI tool used in completing your work." Its example is a comment in the code saying where an AI tool shaped a function and that you checked and changed the logic. Oregon State asks for the tool, the kind of interaction and the part of the work it touched, and adds that a one-line disclosure is usually enough. It also asks that AI-generated code be attributed inside the work itself, not just in a note at submission. Stanford tells students to disclose "when in doubt."
You must understand what you submit. Oregon State expects students "to be able to explain and defend any work they submit." Austin CC requires you to verify outputs and understand the material. For a capstone, which usually ends with a demo and questions, this is the test that matters.
Undisclosed use is treated as misconduct. The sample policies from Carnegie Mellon's Eberly Center range from a full ban to active encouragement. But the samples that allow AI still require you to acknowledge it, and one says outright that using AI without acknowledgment will be treated as plagiarism. At Austin CC, consequences run from a lower grade to failing the course.
Where do they disagree, or stay silent?
How much AI is allowed. This is the real split. Carnegie Mellon's examples cover the whole range, from banning AI even for brainstorming to encouraging it on every assignment with citations. Oregon State sorts uses into categories. Debugging your own code and asking AI to explain an algorithm count as "coding assistance." Having AI produce the work itself is the highest-stakes category, banned unless the instructor allows it.
Whether tools in your editor count. Only Oregon State says it outright: Copilot- and Cursor-style tools count even when they feel like autocomplete. The others don't address it. That doesn't mean they're exempt.
Detection. Oregon State warns faculty that code-similarity tools can flag possible misconduct but don't prove AI use. The other sources say little about it.
Capstones specifically. None of the four writes rules for capstones or senior design. Oregon State comes closest, warning that industry sponsors may restrict AI on their deliverables. So for a capstone, your instructor's syllabus and any sponsor agreement are the rules that apply.
A checklist before you open the assistant
- Find the written rule. Read the capstone syllabus, the department's AI policy and your school's honor code. If a sponsor is involved, read their agreement too.
- Ask in writing if it's unclear. A short email works: "Am I allowed to use Copilot or Cursor for implementation and debugging, as long as I disclose it?" Keep the reply.
- Decide your own line. A safe default: AI can help you debug, explain unfamiliar code, write tests and draft boilerplate. Design decisions, the core algorithm and your results should be yours.
- Log as you go, not at the end. One line per real session: date, tool, what you asked, what you kept. Ten minutes a week is enough.
- Mark AI-shaped code where it lives. A short comment near the code, plus one paragraph in your report or README on how you used AI.
- Never let AI make your results. Test data, measurements and screenshots must come from your system actually running.
- Rehearse the defense. Pick the three most AI-assisted parts of your code and explain each one out loud, without notes: what it does, why it's built that way, and what you changed.
The log is the step people skip, and it's the one that helps most if anyone asks questions. A dated record of how you worked shows how the project came together in a way a detector score can't.
A simple way to write the disclosure
Keep it short and specific. For example:
I used GitHub Copilot for autocomplete and ChatGPT to debug two database errors and to draft unit tests. I designed the architecture and the matching algorithm myself, and I reviewed, tested and modified all generated code. AI-assisted sections are marked in comments.
Specific is better than vague. "Used AI for some coding" invites questions. A clear list of what AI did and didn't do answers them before they're asked.
How STARC handles AI use
STARC's one-person company cohort assumes you build with AI. The application's 48-hour task asks you to build a one-page tool with any AI tool. But STARC's rule is also that you do the work and it gets reviewed. Every weekly build log includes how you used AI that week, next to what shipped and where you got stuck, and nobody else builds your product for you. It's the same habit this checklist describes: use the tools openly and keep an honest record.
The first cohort hasn't run yet. The rules are on the How it works page, and common questions are in the FAQ.
The short version
Find your instructor's written rule before you start, and ask if there isn't one. Disclose the tool and what it did, mark AI-shaped code in the code itself, keep a short dated log, and be ready to explain every line. If you couldn't defend a part in front of the panel, rewrite it until you can.
Related questions
Does autocomplete in my editor count as using AI?
Under at least one engineering department's guidance, yes. Oregon State's EECS guidance says AI built into tools like Copilot, VS Code and Cursor falls under its policy even when it feels like autocomplete. Assume it counts unless your instructor says otherwise.
My syllabus doesn't mention AI. Am I free to use it?
Don't assume so. At Stanford, the default without an instructor statement treats AI like help from another person, and Oregon State's EECS default allows only routine grammar fixes. Ask your instructor in writing before you start.
Can AI detection software prove I used AI on my code?
No single tool settles it. Oregon State's guidance tells faculty that a code-similarity flag isn't proof of AI use. What actually protects you is a record of how you worked and the ability to explain your code.
What if my capstone has an industry sponsor?
Check twice. Sponsored projects can carry their own restrictions on AI tools, and Oregon State's guidance tells students to ask their instructor before using AI on sponsor deliverables.
Want to build your own product?
The OPC cohort: 12 students, 8 weeks, one real product with real users.
Last updated: 2026-10-21. Written by the STARC team. Rules quoted here come from our transparency page; if they change, this post is updated.
More questions
How do I prove my app's user numbers are real?
How a student can back up the user numbers for an app or side project on a resume or in an interview: define the metric, keep evidence, and show it.
How do I post a build log online that's honest and still gets read?
How a student can build in public on X, LinkedIn or Reddit without inflating numbers: what to post, how to show evidence, and what to disclose.
My AI-built website is slow: what can a student actually fix?
Why a website you built with AI loads slowly, how to tell whether it's slow for everyone or only some visitors, and the fixes worth doing first.