The Sustainable Island 2027 · AI Use Policy, version 2
A proposal for the teachers' meeting on 2 October 2026. It builds on Heinz's draft from May. His principle, structure and most of his wording stay. v2 adds how students record their AI use, what they hand in, and how we grade it. It also suggests replacing the presentation on 21 January with group visits.
70 seconds · sound on
From arrival to the graded report: building with AI, catching its mistakes, daily notes, the group visits on 21 January, the bus trip on 22 January, and the AI report. Drawn in code with p5.brush, narrated with the open Kokoro voice, with original music. Subtitles are in the player menu.
Summary
If you cannot explain a line of code to your teacher or a teammate, it does not belong in your project.The Golden Rule from Heinz's draft, unchanged in v2.
Where v2 starts
In May, Heinz wrote the first shared AI policy for the Sustainable Island. Until then each school handled AI on its own. The draft settled the key question: students may use AI, and what we assess is whether they understand what they hand in. v2 would not exist without it.
Students are encouraged to use AI — but must maintain genuine understanding of every line of code they submit.
Kept word for word
It does not matter whether code was written by the student, a teammate, or an AI. Every student must be able to explain any code within their area of contribution.
Kept word for word. The first new rubric item grades exactly this.
Read, understand and, if needed, modify AI-generated code before committing it.
Kept, with one addition: leave the Co-Authored-By lines that agents add
What you asked, what the AI returned, what you changed and why, what you learned.
The same four questions become the daily notes
Code reviews, spot checks and the final presentation, rather than trusting a written declaration.
The research backs this choice. v2 builds the walkthrough on it.
This is not a punishment — it is a way to make sure the project is a real learning experience.
Kept word for word, together with the integrity checklist
Draft → v2
The changes do two things. They make every requirement something we can assess, and they add the AI report, so students practise using AI to explain and compare their work.
| Area | Draft | v2 | Why |
|---|---|---|---|
| Permitted use | Five permitted uses: boilerplate, concepts, exploring approaches, reviewing own code, documentation and comments | The same five, now as examples, plus: building features with an AI agent, and generating reports, explanations and visual comparisons | It benefits the whole group. Students learn to use AI to generate reports, explain complex topics and compare solutions in a visual, easy-to-understand way |
| Comments | §2 AI may help write documentation and comments. §4.1 AI-generated comments are not acceptable | §4.1 keeps its aim: comments the student understands and could explain in their own words. AI may help write them | The two sections contradicted each other, and nobody can tell who wrote a comment. Understanding is what §4.1 was after, and the walkthrough with a teacher checks it in a way we can grade |
| AI log | For each interaction: what you asked, what it returned, what you changed, what you learned | The same four questions, answered once a day. The AI turns the day into an HTML page: the notes word for word, its own account, and interactive explanations | An agent session can have hundreds of interactions. A daily entry is realistic, and git shows when it was written |
| Teach-back | Explain AI code to a teammate before merging. Listed as an assessment method | Kept as a recommended habit. Removed from the assessment | We have no way to assess it |
| Code reviews | 10–15 min walkthrough with a teacher or a peer | With a teacher. Counts toward Understanding your code, together with the walkthrough | Only what a teacher sees can count toward a grade |
| Interviewsnew | Not covered | Design sprint interviews must be with real people | The problem has to come from real users, not generated ones |
| AI reportnew | Not covered | report/index.html with six sections, built with AI from the notes | Students practise turning their work into a clear, visual report. Other teams learn from it |
| Grading | Methods listed, no rubric item | Two rubric items: Understanding your code and The AI report | Every requirement in the policy now has a place in the grade |
| 21 Januarynew | Not covered. Today each group presents its design and GitHub to everyone | Group visits: three pairs of teachers, each pair from two different countries, ask every group the same questions. One asks, the other marks | No presentation area in the classroom, which students complained about last year. The same questions make the groups comparable, and the visit is a natural place to talk through each student's code |
| Penalties | This is not a punishment | Kept. Adds: declared AI use is never penalised, and no AI detectors are used | Fear of penalties is the main reason students hide AI use |
January 2027
Teams interview real people. AI can help prepare the questions and sort the notes. Each student starts a notes file in the team repository.
Teams set up report/notes/ and agree who owns which part of the code.
Every day: students commit their notes and the AI's account. Teachers run code reviews and spot checks, which count toward Understanding your code.
Three pairs of teachers, each from two different countries, visit each group where it works and ask every group the same questions. Design, Design Sprint, UI and GitHub are graded. The teachers also look at the notes and give feedback (not graded). Option A: Understanding your code is graded here.
Product, Presentation and Q&A are graded. Teams submit the link to their AI report. Option B: Understanding your code is graded here.
Teachers review the front end and back end code, and grade The AI report alongside it.
Team deliverable
A web page in the team repository, published with the app. Students use AI to build it from their notes. Turning work into a clear report, explaining complex topics and comparing solutions visually are the skills we want them to practise, and every other team can learn from the result.
The entries shown are invented examples of the content we expect. Section 4, “What the AI got wrong”, is the most valuable part: it shows the students checked the AI's work.
Daily, in the repository
Heinz's log asks four good questions: what you asked, what came back, what you changed, what you learned. v2 asks them once a day instead of after every interaction. The student writes the notes in their own words; the AI then turns the day into one HTML page with those notes, its own account, and interactive explanations of anything complex. Notes and account check each other.
One student's project days, from the first commit to the graded report.
The prompt students use
Go through our sessions from today and the git log. Make one HTML page with today's notes. First my notes below, word for word. Then your own short, factual account: what you built or changed (with commit hashes), what I asked you to explain, where you were wrong and how it was caught, and what I changed in your code. Do not flatter me. Make the page as easy to understand as possible: use interactivity and animations to explain anything complex. My notes: …
## Tuesday 19 January - Asked for the recycling map. It put our API key in a VITE_ variable, so it was visible in the browser. - Changed: moved the key to the server (e18a0b7), because anyone could copy it. - Did not understand useEffect cleanup. Learned it from two explanations, then rewrote the fetch with AbortController. - Decided on Postgres, not MongoDB as the AI suggested: our data is all related.
## AI account, Tuesday 19 January - Built the recycling map component (a41c9e2) and the /api/points CRUD routes (7d03b18). - Explained useEffect cleanup twice. The student rewrote the fetch (c92f4d1). - Wrong: I put the API key in a VITE_ variable, which exposes it in the browser. Caught by the student; moved to the server (e18a0b7). - Changed by the student: I trusted the user id sent by the client. The server now reads it from the token.
Raw transcripts are not committed, because they can contain personal data and secret keys. Students keep them until grades are given, and a teacher may ask to see the relevant part during a code review. Tools without session history, such as a browser chat, get one line in the student's own notes.
Two new rubric items
Two separate items, because they measure different things. One is about each student, the other about what the team produced. Both use the bands we already use.
| 10-point | 0–2 | 3–4 | 5–6 | 7–8 | 9–10 |
|---|---|---|---|---|---|
| 7-point | 02 | 4 | 7 | 10 | 12 |
| Meaning | Missing | Bad | Mediocre | Expected | Exceeding |
| Understanding your codeEach student | Cannot explain own code | Explains own code only with help | Explains what most of own code does, but not why, or struggles with follow-up questions | Explains own code with confidence, including why it is built that way, and answers follow-up questions | Explains the trade-offs and alternatives, and can change or debug the code on the spot |
| The AI reportEach team, with notes and a tutorial per student | No report page or notes | Thin report. The git history shows the notes were written at the end | All sections present. Notes on most days. Some AI mistakes documented | Notes every day, tied to commits. Clear decision log with visual comparisons. AI mistakes documented with the commits that fixed them. Every tutorial is clear | Catches subtle mistakes (security, outdated or invented APIs). Backs comparisons with real measurements. Tutorials teach other students something new |
Understanding your code could be split into
The AI report could be split into
Understanding your code is graded per student. The current rubric grades the team, and peer evaluation adjusts each student's grade. We need to agree how an individual item fits into that.
21 January · suggestion
On 21 January the groups do not present. Three pairs of teachers visit each group where it works and ask every group the same questions. One teacher asks, and the other marks the answers on the rubric. Every pair mixes two countries: the same blending we ask of the students.
6 teachers, two from each school, in pairs from two different countries. One asks the questions, one marks.
per pair, with about 8 groups in the project: about 1½ hours for each pair.
per visit: about 15 minutes of group questions, plus 3–5 minutes per student if Understanding your code is graded here. In 2026 the groups had 3–4 students.
Three mixed pairs of teachers visit eight groups.
Why visits
What we need to agree on
Every group gets the same questions in the same order. Each question belongs to a rubric item, so every answer can be marked.
| Rubric item | The asking teacher says | Students show |
|---|---|---|
| Design Sprint | Who did you interview, and what did you learn that changed your idea? Which UN goal does your solution support? | Interview notes, problem statement |
| Design | Walk us through the main user flow. Which design decision are you least sure about? | The prototype |
| UI - Figma/XD | Which screens are designed, and how closely does the app follow them so far? | The Figma file next to the app |
| GitHub | How do you use branches and pull requests? Who reviewed the last pull request, and what did they find? | Branches, pull requests, commit history |
| AI notesFeedback, not graded | What has the AI got wrong so far, and how did you find out? | report/notes/ |
| Understanding your codeOption A, per student | For each student, the teacher picks a commit or file from their notes: “Walk us through this. Why is it built this way? What would you change if…?” | The student's own code |
For discussion
3–5 minutes per student. In 2026 there were 35 students in 9 groups of 3–4.
Suggestion
Grade The AI report in the post assessment, together with the thorough review of the front end and back end code.
In context
The current items and descriptions from the March 2026 assessment, with the two new items where we suggest they go.
| 10-point | 0–2 | 3–4 | 5–6 | 7–8 | 9–10 |
|---|---|---|---|---|---|
| 7-point | 02 | 4 | 7 | 10 | 12 |
| Meaning | Missing | Bad | Mediocre | Expected | Exceeding |
| Design | It looks like they did not think about design at all | It looked like the UI was all over the place with no clear focus | The UI had some structure and UX was tolerable | The UI had a good hierarchy and made sense. The UX was pleasant | The UI was very pleasant to look at and the UX was like a dream |
| Design Sprint | The group did not do a design sprint | It was poorly done and missing some key aspects | It was done but could have been more useful for the project | It was a good design sprint that guided the project | The project solves a real problem with great UX |
| UI - Figma/XD | There was no design document | There was some design but it was poorly made and did not look like the final project at all | All the pages had been designed but could have had more structure | It was a well designed project file and the design guided the final outcome | The design was very clean and professionally made |
| GitHub | They did not use Git in the project | Only one branch and rarely committed | Branches were used but commits and pull requests could have been more frequent | The GitHub guide was followed as expected | They used GitHub to its full potential and the project benefited from great management |
| Understanding your codeEach student Option A | Cannot explain own code | Explains own code only with help | Explains what most of own code does, but not why, or struggles with follow-up questions | Explains own code with confidence, including why it is built that way, and answers follow-up questions | Explains the trade-offs and alternatives, and can change or debug the code on the spot |
| 10-point | 0–2 | 3–4 | 5–6 | 7–8 | 9–10 |
|---|---|---|---|---|---|
| 7-point | 02 | 4 | 7 | 10 | 12 |
| Meaning | Missing | Bad | Mediocre | Expected | Exceeding |
| Product | There was no product | It was not live and/or hardly useable | It was live but barely an MVP | It was good and worked how it should | It was a amazing to see how much they had accomplished in this time frame |
| Presentation | There was no presentation | It was unorganized and hard to follow | It showed what they had done but could have been more clear | It was clear and showed the collaboration and the project in a clear way | It was an exceptional presentation that kept me focused the whole time |
| Q&A | There was no Q&A session | The Q&A session was poorly handled and did not address key questions | The Q&A session addressed some questions but lacked depth | The Q&A session was well-handled and addressed most of the key questions | The Q&A session was exceptional, addressing all key questions thoroughly and engaging the audience |
| Understanding your codeEach student Option B | Cannot explain own code | Explains own code only with help | Explains what most of own code does, but not why, or struggles with follow-up questions | Explains own code with confidence, including why it is built that way, and answers follow-up questions | Explains the trade-offs and alternatives, and can change or debug the code on the spot |
| 10-point | 0–2 | 3–4 | 5–6 | 7–8 | 9–10 |
|---|---|---|---|---|---|
| 7-point | 02 | 4 | 7 | 10 | 12 |
| Meaning | Missing | Bad | Mediocre | Expected | Exceeding |
| Front end | The project did not have any front end | Only a static page with poorly written code | Some variable naming and/or folder structure problems | It looks good and well organized | It was surprisingly well organized, documented and readable |
| Back end | The project did not have any back end | It is very simple, unfinished and/or unorganized | It has some functionality but was missing error handling or security issues | It is a well organized code that took good care of serving data to the front end | It is extremely well written, secure and the errors are well handled |
| The AI reportEach team, with notes and a tutorial per student New | No report page or notes | Thin report. The git history shows the notes were written at the end | All sections present. Notes on most days. Some AI mistakes documented | Notes every day, tied to commits. Clear decision log with visual comparisons. AI mistakes documented with the commits that fixed them. Every tutorial is clear | Catches subtle mistakes (security, outdated or invented APIs). Backs comparisons with real measurements. Tutorials teach other students something new |
Research, 2023–2026
of students at King's Business School did not declare their AI use, even though the coursework coversheet required it. They feared penalties and found the rules unclear.
Gonsalves, Assessment & Evaluation in Higher Education, 2025 [1]of student repositories named an AI tool across three cohorts (203 repositories, 23,065 commits). Saying what the AI actually contributed stayed rare.
Parreira, Sinha, Sandhaus & Ju, 2026 [2]of essays by non-native English writers were wrongly flagged as AI-written by detectors. Every student in this project writes in a second language.
Liang et al., Patterns, 2023 [3]that only tell students what they may do create an “enforcement illusion”. What works is changing the assessment itself, so the task checks the skill.
Corbin, Dawson & Liu, Assessment & Evaluation in Higher Education, 2025 [4]Short code interviews scaled across weekly TA sections and got students discussing their own programs. The walkthrough in Understanding your code uses the same idea.
Kannam, Yang, Dharm & Lin, SIGCSE 2025 [5]2 October 2026
Or agree on changes, and merge the branch once they are in.
Three pairs of teachers, each pair from two different countries, two or three groups each, and the same questions for every group. Do we agree on the question list, the pairs and which groups each pair visits?
In Danish vocational programmes, AI is not a permitted aid in exams or exam preparation unless the programme's fagbilag allows it [6]. TECHCOLLEGE: does any part of the project count as an exam? El Rincón: are there Spanish or Canarian rules to add?
TECHCOLLEGE · El Rincón
During the group visits on 21 January, or at the final presentation on 29 January. If on 29 January: how do we split the students between the teachers?
And do we keep each new item as one grade, or split them into the smaller parts?
Understanding your code is per student. Today the team gets a grade and peer evaluation adjusts it for each student.
A link to the AI report in the team hub, the two new items in the teacher evaluation, and a per-student score for Understanding your code.
Tækniskólinn can build this
v2 asks students to keep their raw transcripts until grades are given. Do we agree on that, and on when they are deleted?
Assignment/draft-proposal-AI.md, version 2
This document defines how AI tools may be used in The Sustainable Island 2027 project. Students are encouraged to use AI — but must maintain genuine understanding of every line of code they submit.
AI is a learning tool, not a replacement for understanding.
Students may use AI tools (ChatGPT, GitHub Copilot, Claude, etc.) to:
These are examples. Any use of AI is allowed as long as you meet the core requirement in section 3, with one exception: the interviews in the design sprint must be with real people. AI may help you prepare questions and sort your notes, but it must never invent interviews, answers or users.
It does not matter whether code was written by the student, a teammate, or an AI. Every student must be able to explain any code within their area of contribution.
The Golden Rule
If you cannot explain a line of code to your teacher or a teammate, it does not belong in your project.
Understanding will be checked through code reviews, the final presentation, and unannounced spot-checks.
All code must include comments that you understand and could explain in your own words. AI may help write them (see section 2). Comments should show that the author understands what the code does.
Each student keeps a brief log of their AI use as part of the project documentation. At the end of every project day, note:
A few bullet points per day is enough. Write them in your own words.
Then ask your AI agent to turn the day into an HTML page: your notes word for word, followed by the AI's own account of how it was used. Ask it to make the page as easy to understand as possible, with interactivity and animations wherever they help to explain something complex (a before-and-after of a fix, how data flows through the app, a step-by-step walkthrough). Save it as report/notes/<date>-<your-name>.html and commit it the same day. You can use this prompt:
Go through our sessions from today and the git log. Make one HTML page with today's notes. First my notes below, word for word. Then your own short, factual account: what you built or changed (with commit hashes), what I asked you to explain, where you were wrong and how it was caught, and what I changed in your code. Do not flatter me. Make the page as easy to understand as possible: use interactivity and animations to explain anything complex. My notes: …
If you used a tool without a history (for example a chat in the browser), add a line about it to your notes. Do not commit raw chat transcripts, as they can contain personal data or secret keys; keep them until grades are given.
You must be able to explain every commit you have made. Read, understand, and if needed modify AI-generated code before you commit it. If your tool adds a line such as Co-Authored-By to a commit, leave it there.
Before merging AI-generated code, explain it to at least one teammate. If you cannot explain it, it is not ready to merge. This is a habit we recommend; it is not graded.
Each team publishes an AI report as a web page, report/index.html, and submits its link with the other project links. Use your AI to build it from the daily notes pages, and make it interactive and easy to understand. It has these sections:
| Method | Description | When |
|---|---|---|
| Code Review Sessions | 10–15 min walkthrough with a teacher | During the project |
| Spot Checks | A teacher may ask about any snippet at any time | At any point |
| Group Visits | Two teachers from different countries visit each group and ask every group the same questions: one asks, one marks | January 21 |
| Final Presentation | Students explain their technical decisions | January 29 |
| AI Usage Log Review | The daily notes pages and the AI report, including their git history | Post assessment, with the review of the front end and back end |
Two items in the project rubric cover AI use, on the same 10-point and 7-point scale as the other items:
We grade how critically you used AI, not how much you used it. We do not use AI detectors: they are unreliable, and they wrongly flag people who write in a second language, which is all of us.
Using AI that you have declared in your notes is never penalised. What matters is whether you understand the result.
The following may apply:
This is not a punishment — it is a way to make sure the project is a real learning experience.
Using AI is fine. Submitting AI output you do not understand — and presenting it as your own — is not.
AI can make you a better developer, but only if you engage with it critically and take responsibility for what ends up in your code.
Before you commit, ask yourself:
- ✓ Can I explain every line?
- ✓ Could I explain my comments in my own words?
- ✓ Have I logged today's AI use, and is today's notes page committed?
- ✓ Would I be comfortable walking a teacher through this right now?