Collaboration, Academic Integrity, AI, and Support
Documentation, instructors, peers, search, and generative AI can all support software development. These sources are part of learning, but they do not remove your responsibility for the work you submit.
Individual exercises and permitted collaboration
Exercises are completed and submitted individually. You may work in a group, discuss approaches, show your code to other students, compare implementations, debug together, and help someone who is stuck. Collaboration should help every participant develop their own understanding; it should not leave one person unable to explain their submission.
Do not publish exercise solutions publicly. This includes posting a solution in a public code repository, question-and-answer site, shared archive, or other location where it remains broadly available. If you store coursework in an online Git repository, keep the repository private.
When helping another student, prefer explaining the relevant principle, asking a diagnostic question, or examining evidence together. You may show code, but make clear why it behaves as it does and let the other student make and verify the changes in their own work.
Academic integrity
Permitted collaboration does not change the individual nature of a submission. You are responsible for knowing what your submitted code does, checking that it meets the requirements, and being able to explain the principles it applies. Do not misrepresent somebody else’s work or understanding as your own.
Using AI as a study and development tool
You may use AI tools while working on exercises. Ordinary exercise work follows one principle:
You remain responsible for understanding, adapting, and verifying the work you submit.
AI can help explain a small piece of code, propose a debugging hypothesis, compare approaches, or draft an implementation that you then inspect. Give it a specific question and enough relevant context to make the answer checkable.
For version-sensitive questions, include the course’s runtime and library versions. A configuration example for a different SvelteKit release may look reasonable and still be inapplicable. Prefer the supplied scaffold and version-matched official documentation over an unsupported generated claim.
Do not accept a broad rewrite merely because it removes one visible error. Ask which observation supports the diagnosis, what changed, and whether the change preserves the original requirements.
Do not submit credentials, session cookies, personal data, confidential material, or information about other people to an AI service, whether or not the prompt is public. Before sharing code or configuration with any external service, remove secrets and include only the context needed for the question.
Check your own understanding
After significant assistance, be it from a peer, a teaching assistant, or an AI tool, explain the result to yourself. Identify where the behavior runs, which input it trusts, and which state it changes. Make a small requirement change yourself. Then explain what the tests establish and which realistic mistakes they would miss.
Your understanding should be strong enough that you can explain the relevant principles to another person. If you cannot explain where the code runs, what input it trusts, which state it changes, or what a test establishes, continue studying and checking the result before treating the exercise as complete.
Assessment-specific conditions
Aalto University students complete examinations without AI support. Do not assume that the exercise policy applies to an examination, another separately controlled assessment, or to a different course.
Where to get support
For Aalto University students, support information is published on the MyCourses page of the current course offering. Use that page for current support channels, schedules, contact details, and instructions for private administrative matters.
When asking for help, include the following information in one focused report:
- the exercise and part of the materials you are working on;
- your goal, the result you expected, and what happened instead;
- the exact command or action that reproduces the issue and the first relevant error;
- the smallest relevant code/configuration, recent changes, and checks already tried;
- the course/starter version when the problem may depend on the environment.
For example:
I am working on “Exercise: equipment requests” in Part 3’s “API Contracts & Validation” chapter. I expected the request test to succeed. It returns an error after I changed the route handler. Starting from the supplied baseline works. Here is the command, the changed file, and the first error. I have not changed dependencies.
This is more useful than “the application is broken.” Paste error text when possible; an uncropped screenshot of an entire desktop rarely makes the relevant evidence easier to read.
Give useful help
When answering another student’s question, help them locate the responsible layer and interpret the evidence. Ask what they expected, what they observed, and which smallest change reproduces the problem. Explain a principle or demonstrate a smaller neutral example when that makes the idea clearer.
Do not take control of the whole exercise or turn a support discussion into a collection of finished solutions. Keep discussion constructive and respectful, and allow people to ask basic questions without ridicule.