It should say something specific about code, not extend the prose-disclosure clause and assume it covers software. A computer science thesis or final-year project is graded partly on code the student wrote, and an AI assistant that completes functions, suggests whole algorithms or generates test cases changes what “the student’s own work” means in a way a general essay-writing disclosure rule does not anticipate. A CS faculty needs three additions to the university’s general AI policy: a disclosure format built for code rather than prose, a position on licensing risk when AI-suggested code echoes training data, and a rule for what an examiner is entitled to ask about authorship at defence.
Why a general AI-use policy does not transfer cleanly to code
Most university AI policies are written around prose: an essay, a literature review, a discussion chapter. They ask a student to disclose whether AI helped draft, edit or generate text, and they usually treat the intellectual content — the argument, the analysis — as the thing that must remain the student’s own. Code does not separate as cleanly into “content” and “expression” the way prose does. A student can describe an algorithm’s design entirely in their own words while an AI assistant wrote every line that implements it, and a policy built for prose has no clause that catches that case, because the disclosure question it asks — did AI help you write this? — does not distinguish design from implementation. A computer science faculty’s own addition needs to ask a different question: which parts of this codebase reflect your own design decisions, and which parts did an AI tool generate from a specification you wrote?
Should AI-assisted code be disclosed the same way as AI-assisted prose?
No — the disclosure needs a different structure, not just a different checkbox. A workable model separates three categories rather than a single yes/no: code the student designed and wrote unassisted; code the student designed and an AI tool implemented from a specification, pseudocode or detailed prompt the student wrote; and code an AI tool suggested unprompted (autocomplete-style) that the student accepted with only minor edits. The third category is where most disputes actually happen, because a student who accepted dozens of AI-completed lines from a tool like GitHub Copilot without materially altering them has a thinner claim to authorship than the disclosure form’s usual language implies. A per-file or per-module disclosure appendix, rather than one blanket statement at the front of the thesis, is what lets an examiner actually locate which parts of a 4,000-line codebase fall into which category.
What is the licensing risk when AI-generated code enters a thesis codebase?
Code-completion tools are trained on large public repositories, and it is well documented — including in the copyright litigation filed against GitHub Copilot in US federal court in late 2022, alleging that suggested completions reproduced licensed open-source code without attribution — that a generated function can closely match, or in rarer cases exactly reproduce, a snippet carrying a specific open-source license with its own attribution or share-alike requirements. For a thesis, this is a genuinely different risk category from academic misconduct: a student who unknowingly embeds a GPL-licensed function into a codebase the university might later want to publish, patent-protect or commercialise through a spinout has created a licensing liability that has nothing to do with whether the work was academically honest. A CS faculty’s AI-use policy should require students to run any code-completion tool’s own license-check feature where one exists (several mainstream tools now flag public-code matches on request), and to document the check in the disclosure appendix, rather than leaving licensing exposure to be discovered only if the code is ever reused outside the thesis itself.
How does this interact with code-similarity detection tools already in place?
It sits upstream of it. Source-code similarity detectors such as MOSS and JPlag — compared for computer science departments in code-similarity tools for CS departments — are built to catch code copied between students or from an external repository; they compare structure and token patterns across submissions, not against an AI model’s training data, and they were never designed to answer the disclosure question at all. A student can submit code that is entirely original relative to every other submission a similarity tool checks against, and still have generated a large share of it with an AI assistant with no disclosure. The two checks answer different questions — did you copy from another student or a known source, versus did you disclose how this code was produced — and a faculty that only runs the similarity tool has no coverage on the second question at all.
Should the policy distinguish AI-assisted code from AI-authored code?
Yes, and the line is design authorship, not typing. A student who specifies an algorithm’s logic, data structures and edge cases in detail, then uses an AI tool to translate that specification into working code in a particular language, has done the intellectually demanding part of the work themselves — the code is assisted. A student who asks an AI tool to “write a function that does X” with no prior design and accepts the result has not made the design decisions the thesis is meant to demonstrate — the code is AI-authored, whatever disclosure label gets attached to it. A policy that only asks whether AI was used, without asking who made the design decisions, cannot tell these two situations apart, and they should not be graded the same way.
What should the disclosure statement actually require?
Four elements, specific enough that two examiners would read the same statement the same way: which modules or files involved AI assistance, at which of the three levels set out above; which tool was used (naming the specific product, since different tools carry different training-data provenance and licensing-check capability); whether the student ran any available license-check feature on AI-suggested code before including it; and a statement, in the student’s own words, of what design decisions in the AI-assisted sections were theirs. The fourth element is the one most template disclosure forms omit, and it is the one an examiner actually needs at defence to ask a substantive question about a specific module rather than a generic one about AI use overall.
How does this differ from the university’s general AI policy?
The general policy set out in what a university AI policy should include covers disclosure mechanism, the assistance-versus-intellectual-content test, burden of proof and equity of access — all of it written with prose assessment as the implicit default case. A computer science faculty does not need to duplicate any of that; it needs a discipline-specific appendix that answers the three questions a prose-oriented policy cannot: how disclosure is structured for code rather than text, what a licensing check requires, and what an examiner may ask about design authorship at defence. Professional bodies in the field, including the ACM’s own Code of Ethics and Professional Conduct, already set a general expectation of honesty about how a system was built and what its real authorship is — the faculty-level policy is what turns that general professional expectation into a specific, checkable thesis requirement. Coursework AI rules are a separate, usually stricter category again: a thesis runs for a year or more and ends as a piece of independent research, where how AI rules differ for a doctoral thesis compared with coursework sets out why a permission-per-assessment model built for a single module does not transfer to a long-running project, a point that applies just as directly to a taught-masters or undergraduate final-year software project as it does to a doctorate.
What can an examiner ask about AI-assisted code at defence?
Anything covered by the disclosure appendix, and nothing that treats disclosed AI assistance as automatic grounds for suspicion. A viva panel should be entitled to ask a student to walk through the design logic of any module — disclosed as AI-assisted or not — and a student who cannot explain the design decisions behind code they submitted, regardless of who typed it, has a genuine problem the disclosure process is meant to surface. This is a narrower, code-specific instance of the broader viva-structuring question covered in how a data science or AI thesis viva panel should be structured, where the thesis’s research object is itself a model rather than, as here, code being one component of a conventional software or systems project.
Who owns rolling this out: department, faculty, or examiner training?
All three, at different points. The disclosure-format decision belongs with the department or programme team that already owns the assessment criteria for the final-year or thesis module, since it has to match how the project is actually marked. The licensing-check requirement is better set at faculty level, because it is a risk-management question that applies uniformly regardless of which specific project a student is doing, and a faculty-wide requirement is easier for a research-office or technology-transfer contact to support consistently than a department-by-department patchwork. Examiner training is the piece most often skipped: an examiner who has never seen a code-specific disclosure appendix before will not know what to ask about it, and a short briefing — what the three disclosure levels mean, what a documented license check looks like, and what a reasonable design-authorship question sounds like — is a low-cost addition to the standard examiner briefing most graduate schools already run before a defence period.
Where Tesify fits
Tesify does not write a student’s code and has no view into a codebase’s design decisions — that judgement stays with the supervisor and the examiner. Where it helps is the writing that sits around the code: the design rationale, the methodology chapter and the disclosure appendix itself, drafted inside a workspace supervisors can see rather than off-platform where nothing is logged. The Tesify for Institutions platform gives a computer science faculty the same oversight over the written half of a software thesis that a disclosure appendix is meant to give over the code half. A free departmental pilot lets one cohort test the disclosure workflow before any procurement decision.
Frequently asked questions
Does a general university AI policy already cover AI-generated code?
Not adequately. Most general policies are written around prose disclosure and do not ask the code-specific questions a computer science faculty needs answered: which modules were AI-assisted, at what level, and who made the design decisions.
Is using an AI code-completion tool automatically academic misconduct?
No. Disclosed, design-led AI assistance is a legitimate and increasingly normal part of software development. The concern is undisclosed use, or code accepted with no underlying design work by the student at all.
What is the difference between AI-assisted and AI-authored code, in practice?
Whether the student made the design decisions — the algorithm, the data structures, the edge cases — before an AI tool implemented them, versus asking an AI tool to produce a function with no prior design specification.
Do code-similarity detectors like MOSS or JPlag catch undisclosed AI use?
No. They compare structure and token patterns between submissions or against known sources to catch copying, not against an AI model’s training data, and they do not check whether AI assistance was disclosed.
What licensing risk does AI-generated code actually carry?
A generated function can closely match code carrying a specific open-source license with attribution or share-alike terms. This is a licensing-liability question, separate from academic misconduct, and it matters most if the codebase is later published, patented or commercialised.
Should students run a license check on AI-suggested code before submission?
Where the tool offers one, yes, and the check should be documented in the disclosure appendix rather than assumed unnecessary because the code was only used for a thesis.
What four things should a code-specific disclosure statement require?
Which modules involved AI assistance and at what level; which specific tool was used; whether a license check was run; and a statement in the student’s own words of the design decisions behind the AI-assisted sections.
Can an examiner still question a student about disclosed AI-assisted code at defence?
Yes. Disclosure is not immunity from questioning. An examiner can ask about the design logic of any module, and a student unable to explain design decisions behind code they submitted has a real problem regardless of who typed it.