Updated: 26 Jun 2026, 13:45
Assessment Logic and Generative AI Use Policy
Table of contents
DEUTSCH
Scroll down for a German translation of this page
Assessment Logic
Assessment consists of four elements:
| Assessment type | Examination | Team Points | Individual Points | Totals |
|---|---|---|---|---|
| Gate to examination | Assignment | n/a | n/a | n/a |
| Examination | First Submission | 30 | 20 | 50 |
| Examination | Oral Examination | 5 | 30 | 35 |
| Examination | Final Submission | 15 | – | 15 |
| Totals | 50 | 50 | 100 |
Rubric: Assignment (ungraded gate to examination)
| Category | Criteria |
|---|---|
| Team Composition | Team name and list of contributors Team repository that examiner can “git pull” (cannot be changed later) Meta-goals per contributor: target grade and personal goals |
| Value Proposition | Target user with a plausible problem and team’s (app-based) solution proposal App must implement a two-sided platform |
| Target Scope | Visual scoping of Web App, primarily via scribbles of UI screens |
Notes
Achievement of “Value Proposition” and “Target Scope” criteria are assessed via an in-class peer review format. Informed by these results, the Lecturer decides “pass / rework / fail”. Rework due date is announced by Lecturer.
Students must pass the mandatory Assignment (“Studienleistung”) to be eligible for subsequent examination.
Rubric: First Submission
| Category | Team | Individual | Criteria |
|---|---|---|---|
| Product Discovery | 10 | – | - Evidence folder with “raw material” aimed to (1) define design challenge, (2) understand target user(s) with their core problem(s), (3) propose solution elements, and (4) test ideas - Value Proposition: what is the problem? Who has it? How to solve it with an App? |
| Product Delivery | 20 | – | - Happy Path derived from Value Proposition (clear priorities) - After “git clone”: within 10 min, examiner can reproduce App Happy Path locally by following README.md instructions (-3…-8: screen recording of Happy Path as fallback) - App fulfils all Mandatory Requirements - Data Model visualized and described, must match implementation |
| Individual Contribution | – | 20 | - Individual contributions listed and backed up by proof (primarily through exemplary git commit traces) - Top 3 contributions explained: my contribution, why I am proud of it, which challenge I overcame - At least 2 relevant Design Decisions in the mandatory format, with proof of regarded options (tangible self-created artifacts like repo branches, not list of links or similar) - Contributed to app source code |
| Totals | 30 | 20 | 50 |
Mandatory Requirements and Forbidden Technology
Mandatory Requirements are checked with First Submission, see rubric above.
Forbidden Technology is checked with First Submission, and again with Final Submission.
- Accidental inclusion of Forbidden Technology may be remedied after First Submission, within 2 weeks of Lecturer notice.
- If any Forbidden Technology is detected with Final Submission, it is automatically awarded 0 Points (out of 15).
- The Team is fully accountable for not including any Forbidden Technology, also if Lecturer doesn’t catch it with First Submission, but notices it in Final Submission.
| Mandatory Requirement | Forbidden Technology |
|---|---|
| Written in Python | Any (even minor) use of JavaScript / TypeScript; exception: JS functionality bundled with Bootstrap |
| Use of Flask | Replacing Flask with another web app framework, e.g., FastAPI |
| Use of Jinja2 | Replacing Jinja2 with another templating engine, e.g., Mako |
| App handles multiple HTTP requests with varied business logic (no content website) | – |
| SQLite, with exactly one database file checked into repository | Any other database technology (including NoSQL databases), or remote hosting of database |
| User roles, including authorization flow(s) | – |
| At least 1 “headless” API that delivers a JSON file | – |
| Must be executable natively on a current Windows or MacOS system | Packaging any part of your App in a Docker container, a Virtual Machine, or similar |
Rubric: Oral Examination
| Category | Team | Individual | Criteria |
|---|---|---|---|
| Outlook | 5 | – | - Planned improvements / refinements from First to Final Submission, with reasoning how they are aligned with (1) Value Proposition and (2) current state of App |
| Design Insight | – | 10 | - When asked, able to logically / reasonably explain particular decision(s) in own area of responsibility - Shows overall intimacy with problem space, target user, proposed solution |
| Code Insight | – | 15 | - Demonstrates technical mastery; signals: (1) easily navigates in codebase; (2) answers are convincing (not wrong/ reasonable) and to-the-point; (3) can assess consequences of proposed changes |
| Communication | – | 5 | - Stays within time budget; shows conversational ability under pressure (remains calm/ professional in examination setting) |
| Totals | 5 | 30 | 35 |
Rubric: Final Submission
| Category | Team | Individual | Criteria |
|---|---|---|---|
| Consistency | 10 | – | - Goal achievement since Oral Examination assessed - It is easy for examiner to see how App is faithful to Value Proposition - No part of the Final Submission contains inconsistencies |
| Submission Usability | 5 | – | - Git repo without clutter (e.g., no venv/ folder) - Documentation on publicly accessible website and automatically built from .md files (e.g., via GitHub Pages) - After “git pull”: examiner can easily run functional App by following README.md instructions |
| Totals | 15 | – |
Generative AI Use Policy
Principle
The goal of this Module is to assess your understanding and ability to create, not the output quality of a tool. You must maintain human agency over every line of code and every sentence that you submit.
Permitted Tools
You are allowed to use Generative AI for assistance. You are fully responsible for any result that you submit, you must understand and be able to explain it. Permitted tools:
- Chat-based interfaces (e.g., ChatGPT, Perplexity), e.g., for brainstorming, to learn about concepts and technologies, to explain encountered errors.
- IDE code completion (e.g., Copilot within Visual Studio Code) for small snippets or boilerplate code.
Prohibited Tools
The use of Agentic AI is FORBIDDEN. This includes any AI-based tool that plans and executes several steps autonomously, modifies files, manages repositories, generates code structure, etc. without step-by-step intervention by you. This includes the creation of git commits (and commit messages) on your behalf.
Exemplary tools that are forbidden include, but are not limited to: Aider, Antigravity, Claude Code, Codex, Copilot Chat Agents, Cursor, OpenClaw, OpenCode, Replit.
Disclosure
You must maintain a comprehensive AI Directory, as per FB1 Regulations on Generative AI Use. “Catch-all” disclosure (like “AI Tool used for bugfixing”) is generally not sufficient.
Again, any use of Agentic AI is forbidden.
Verification and Sanctions
Your ability explain the artifacts you created (code and documentation) is a crucial verification mechanism.
- Oral Examination: Your individual grade depends on your ability to explain your own results.
- Undisclosed Tool Use: If detected at any point, (e.g., Oral Examination), your Individual Points are capped at 10 (out of 50).
- Forbidden Tool Use: If detected at any point, you will fail the Module for Misconduct (“Täuschung”).
DEUTSCH
(DE) Prüfungslogik
Die Prüfung erfolgt in vier Teilen:
| Art | Name | Team | Individuell | Gesamt |
|---|---|---|---|---|
| Voraussetzung zur Prüfung | Studienleistung | n/a | n/a | n/a |
| Prüfung (schriftlich) | First Submission | 30 | 20 | 50 |
| Prüfung (mündlich) | Oral Examination | 5 | 30 | 35 |
| Prüfung (schriftlich) | Final Submission | 15 | – | 15 |
| Gesamt | 50 | 50 | 100 |
Bewertungsraster: Studienleistung (unbenotete Prüfungsvoraussetzung)
| Kategorie | Kriterien |
|---|---|
| Team Composition | Teamname und Auflistung der Mitglieder Team-Repository, das Prüfer*in per “git pull” abrufen kann (kann später nicht mehr geändert werden) Meta-Ziele je Mitglied: angestrebte Note und persönliche Ziele |
| Value Proposition | Zielnutzende mit nachvollziehbarem Problem und dazu passender App-basierter Lösungsidee des Teams |
| Target Scope | Visuelles Scoping der Web-App, insbesondere durch Skizzen von UI-Screens |
| Team Size | 3+ Personen: Team muss eine zweiseitige Plattform implementieren |
Hinweise
Die Erfüllung von “Value Proposition” und “Target Scope” werden per Peer-Review in der Übung bewertet. Auf Grundlage dieser Ergebnisse entscheidet die Lehrperson über “bestanden / zu überarbeiten / nicht bestanden”. Die Frist zur Überarbeitung wird von der Lehrperson bekanntgegeben.
Studierende müssen die verpflichtende Studienleistung bestehen, um zur anschließenden Prüfung zugelassen zu werden.
Bewertungsraster: First Submission
| Kategorie | Team | Individuell | Kriterien |
|---|---|---|---|
| Product Discovery | 10 | – | - Nachweis-Ordner mit „Rohmaterial“, das darauf abzielt, (1) die Design Challenge zu definieren, (2) die Zielnutzer*innen mit ihren Kernproblemen zu verstehen, (3) Lösungselemente vorzuschlagen und (4) Ideen zu testen - Value Proposition: Was ist das Problem? Wer hat es? Wie kann es mit einer App gelöst werden? |
| Product Delivery | 20 | – | - Happy Path, abgeleitet aus der Value Proposition (klare Prioritäten) - Nach “git clone” kann Prüfer*in innerhalb von 10 Minuten den Happy Path der App lokal nachbilden, indem er/sie den Anweisungen in der README.md folgt - App erfüllt alle Mandatory Requirements - Datenmodell visualisiert und beschrieben, muss mit der Implementierung übereinstimmen |
| Eigener Beitrag | – | 20 | - Eigene Beiträge aufgelistet und durch Nachweise belegt (hauptsächlich durch beispielhafte Git-Commits) - Top-3-Beiträge erklärt: mein Beitrag, warum ich stolz darauf bin, welche Herausforderung ich überwunden habe - Mindestens 2 relevante Design Decisions im verpflichtenden Format, mit Nachweis der betrachteten Optionen (greifbare, selbst erstellte Artefakte wie Repository-Branches, keine Linklisten o.Ä.) - Hat wesentlich zum zum App-Quellcode beigetragen |
| Gesamt | 30 | 20 | 50 |
Mandatory Requirements und Forbidden Technology
Die Mandatory Requirements (DE: verbindliche Anforderungen) werden mit der First Submission überprüft, siehe Bewertungsraster oben.
Mandatory Requirements werden mit der First Submission und erneut mit der Final Submission überprüft.
- Eine versehentliche Nutzung von Forbidden Technology (DE: unerlaubte Technologien) kann nach der First Submission innerhalb von 2 Wochen nach Hinweis durch die Lehrperson entfernt werden.
- Wenn bei der Final Submission verbotene Technologien festgestellt werden, werden automatisch 0 Punkte vergeben (von 15).
- Das Team ist vollständig dafür verantwortlich, keine Forbidden Technology zu verwenden, auch wenn die Lehrperson dies bei der First Submission nicht bemerkt, sondern erst bei der Final Submission feststellt.
| Mandatory Requirement | Forbidden Technology |
|---|---|
| In Python geschrieben | Jegliche, auch geringfügige Nutzung von JavaScript / TypeScript; Ausnahme: mit Bootstrap gebündelte JS-Funktionalität |
| Verwendung von Flask | Ersetzen von Flask durch ein anderes Web-App-Framework, z.B. FastAPI |
| Verwendung von Jinja2 | Ersetzen von Jinja2 durch eine andere Template-Engine, z.B. Mako |
| App verarbeitet mehrere HTTP-Requests mit unterschiedlicher Geschäftslogik (keine reine Content-Website) | – |
| SQLite, mit genau einer Datenbankdatei, die ins Repository eingecheckt ist | Jede andere Datenbanktechnologie (einschließlich NoSQL-Datenbanken) oder Remote-Hosting der Datenbank |
| Benutzerrollen, einschließlich Autorisierungs-Flow(s) | – |
| Mindestens 1 “headless” API, die eine JSON-Datei bereitstellt | – |
| Muss nativ auf einem aktuellen Windows- oder macOS-System ausführbar sein | Packaging irgendeines Teils der App in einem Docker-Container, einer virtuellen Maschine oder Ähnlichem |
Bewertungsraster: Oral Examination
| Kategorie | Team | Individuell | Kriterien |
|---|---|---|---|
| Ausblick | 5 | – | - Geplante Verbesserungen / Verfeinerungen von der First Submission bis zur Final Submission, mit Begründung, wie sie sich aus (1) der Value Proposition und (2) dem aktuellen Stand der App heraus ableiten |
| Design-Verständnis | – | 10 | - Kann auf Nachfrage bestimmte Entscheidung(en) im eigenen Verantwortungsbereich logisch / nachvollziehbar erklären - Zeigt insgesamt Vertrautheit mit dem Problemraum, den Zielnutzer*innen und der vorgeschlagenen Lösung |
| Code-Verständnis | – | 15 | - Durchdringt die App technisch; Anzeichen: (1) findet sich leicht im Code-Repository zurecht; (2) Antworten sind überzeugend (nicht falsch / nachvollziehbar) und auf den Punkt; (3) kann die Folgen vorgeschlagener Änderungen einschätzen |
| Kommunikation | – | 5 | - Schafft es, gestellte Fragen innerhalb des Zeitbudgets zu beantworten - Zeigt Gesprächsfähigkeit unter Druck - bleibt in der Prüfungssituation ruhig / professionell - Insgesamt effektiver Kommunikationsstil (klare Aussagen, korrekte Begriffe, Blickkontakt, …) |
| Gesamt | 5 | 30 | 35 |
Bewertungsraster: Final Submission
| Kategorie | Team | Individuell | Kriterien |
|---|---|---|---|
| Konsistenz | 10 | – | - Umsetzung von Verbesserungen / Verfeinerungen seit der First Submission reflektiert - Für Prüfer*in ist leicht erkennbar, wie die App an der Value Proposition ausgerichtet ist - Kein Teil der Final Submission enthält Inkonsistenzen |
| Nutzbarkeit der Abgabe | 5 | – | - Git-Repository ohne unnötige Artefakte (z.B. kein venv/-Ordner) - Dokumentation auf öffentlich zugänglicher Website und automatisch aus .md-Dateien erstellt (z.B. über GitHub Pages) - Nach “git pull” kann Prüfer*in die funktionsfähige App leicht ausführen, indem er/sie den Anweisungen in der README.md folgt |
| Gesamt | 15 | – |
(DE) Richtlinie zur Nutzung Generativer KI
Grundsatz
Die Bewertung zielt auf Ihr Verständnis und Ihre Fähigkeit zum Erstellen eigener Ergebnisse, nicht auf die Ausgabequalität eines Tools. Jede Codezeile und jeder Satz in der Dokumentation muss von Ihnen vollumfänglich verstanden und verantwortet werden - Sie haben Human Agency, nicht das KI-Tool.
Erlaubte Tools
Sie dürfen generative KI zur Unterstützung verwenden. Sie sind vollständig für jedes Ergebnis verantwortlich, das Sie einreichen; Sie müssen es verstehen und erklären können. Erlaubte Tools sind:
- Chatbasierte Oberflächen (wie ChatGPT, Perplexity), z.B. für Brainstorming, zum Erfragen von Konzepten und Technologien oder zum Erklären aufgetretener Fehler.
- IDE-Codevervollständigung (z.B. Copilot in Visual Studio Code) für kleine Code-Snippets oder Boilerplate-Code.
Verbotene Tools
Die Nutzung agentischer KI ist VERBOTEN. Dazu zählt jedes KI-basierte Tool, das mehrere Schritte autonom plant und ausführt, Dateien verändert, Repositories verwaltet, Code-Strukturen erzeugt usw., ohne dass Sie Schritt für Schritt eingreifen. Dies umfasst auch das Erstellen von Git-Commits und Commit-Nachrichten in Ihrem Namen.
Beispielhafte Tools, die verboten sind, umfassen unter anderem: Aider, Antigravity, Claude Code, Codex, Copilot Chat Agents, Cursor, OpenClaw, OpenCode, Replit.
Offenlegung
Sie müssen ein umfassendes KI-Verzeichnis gemäß “FB1 Regelung zur Nutzung Generativer KI” führen. Eine pauschale Beschreibung wie “KI-Tool für Bugfixing verwendet” ist in der Regel nicht ausreichend.
Nochmals: Jede Nutzung agentischer KI ist verboten.
Überprüfung und Konsequenzen
Ihre Fähigkeit, die von Ihnen erstellten Artefakte (Code und Dokumentation) zu erklären, ist der zentrale Überprüfungsmechanismus.
- Oral Examination: Ihre individuelle Bewertung hängt davon ab, wie gut Sie Ihre eigenen Ergebnisse erklären können.
- Nicht offengelegte Tool-Nutzung: Wird diese zu irgendeinem Zeitpunkt festgestellt, z.B. in der Oral Examination, werden Ihre individuellen Punkte auf 10 begrenzt (von 50).
- Nutzung verbotener Tools: Wird diese zu irgendeinem Zeitpunkt festgestellt, bestehen Sie das Modul wegen Täuschung / Fehlverhalten nicht.
Oral Examination Q&A Simulation
Ziel: Simulation der mündlichen Prüfungssituation. Die Studierenden üben zu erklären, warum sie bestimmte Designentscheidungen getroffen haben und wie ihr Code funktioniert.
Dauer: 90 Minuten
Gruppengröße: Dreiergruppen (3 Studierende)
Rollen:
- Candidate: Die Person, die ihren konkreten Beitrag erläutert.
- Examiner: Stellt Fragen auf Grundlage des Fragenkatalogs.
- Observer: Macht sich Notizen für die Feedback-Runde und achtet auf die Zeit.
Ablauf
| Zeit | Inhalt | Hinweis |
|---|---|---|
| 0:00 - 0:05 | Intro | - Format vorstellen und Fragen klären. - Dreiergruppen bilden (aus verschiedenen Teams). |
| 0:05 - 0:25 | Vorbereitungsphase | - Gegenseitig Zugriff auf Git-Repo inkl. Doku geben. - 10 min je Repo: Basierend auf der dokumentierten “Individual Contribution” versuchen, sich in den relevanten Repo-Teil (Code + Doku) einzufinden. |
| 0:25 - 0:45 | RUNDE 1 | Candidate: Student*in A |
| 2 min | Kontext | Student*in A fasst kurz den eigenen Beitrag im Projekt zusammen |
| 10 min | Q&A | Student*in B (Examiner) stellt 1-2 Fragen zu Design-Verständnis und 1-2 Fragen zu Code-Verständnis; 10 min gesamt = 4x 2:30 min: - 30s Frage - 60s Antwort - 30s ggf. Feedback/Nachfrage - 30s ggf. präzisierte Antwort |
| 3 min | Feedback | Student*in C (Observer) gibt strukturiertes Feedback: - Was war überzeugend? - Was war offensichtlich am schwierigsten? - Wie war das Zeitmanagement? |
| 5 min | Rollenwechsel | - A → Observer, B → Candidate, C → Examiner - Kurze Vorbereitung auf nächste Runde |
| 0:45 - 1:05 | RUNDE 2 | Candidate: Student*in B |
| 1:05 - 1:20 | RUNDE 3 | Candidate: Student*in C |
| 1:20 - 1:30 | Debriefing im Plenum |
Fragenkatalog
Anleitung:
- Als Examiner wählst Du 1-2 Fragen aus Kategorie 1 (Designverständnis) und 1-2 Fragen aus Kategorie 2 (Codeverständnis).
- Stelle keine allgemeinen Fragen. Nutze den konkreten Kontext der jeweiligen App, sweit es Dir möglich ist.
- Stelle anspruchsvolle, aber faire Fragen - keine “gemeinenen” Fragen.
Kategorie 1: Designverständnis
Fokus: Begründung von Entscheidungen / Alternativen
- In Deiner Doku hast du [Option A] und [Option B] in [Design Decision] betrachtet. Du hast dich für [Option A] entschieden. Was war der konkrete Nachteil von [Option B], der diese Option für dieses Projekt untragbar gemacht hat?
- Du hast entschieden, [Design Decision] so zu lösen: [Entscheidung]. Was war der eine ausschlaggebene Grund, dass Du so entschieden hast?
- Zeige mir den Git-Branch oder das Artefakt, in dem Du das alternative Design getestet hast. Welche Daten oder Beobachtungen aus diesem Test haben dazu geführt, dass du es verworfen hast?
Fokus: Problemraum / Nutzerempathie
- Du hast [Zielnutzer*in] als primäre Zielgruppe auf der Angebotsseite genannt. Wie adressiert Deine App direkt einen Schmerzpunkt dieser Nutzergruppe – und nicht nur einer allgemeinenen Nutzerin?
- Wenn Du ein Feature aus dem aktuellen Umfang entfernen müsstest, um die User Experience für die Nachfrageseite zu verbessern: Welches wäre das und warum?
- Beschreibe ein Szenario, in dem Dein aktueller UI-Flow eine*n Erstnutzer*in verwirren könnte. Wie hast Du dieses Risiko im Design reduziert?
Fokus: Systemarchitektur / Ablauf
- Wie spiegelt Dein Datenbankschema die Business-Logik von [konkretes Feature der App] wider? Führe mich durch die Beziehungen.
- Wenn diese App morgen auf 10.000 Nutzer*innen skalieren müsste: Welcher Teil Deines aktuellen Designs würde zuerst scheitern, und wie würdest Du ihn neu gestalten?“
Kategorie 2: Codeverständnis
Fokus: Navigation / Struktur
- Öffne Deine
app.py(oder die zentrale Routen-Datei). Zeige auf die Zeile, in der die Anfrage für [konkrete Seite] verarbeitet wird. Führe mich durch den Ablauf: Wie gelangen die Daten aus der SQLite-Datenbank in das Jinja2-Template? Benenne die konkreten Funktionen oder Methoden, die beteiligt sind. - Ich sehe, dass Du [Library/Modul] importiert hast. Warum hast du diese spezifische Library gewählt? Welche konkrete Funktionalität hat sie bereitgestellt, die wesentlich war?
- Schau in Deine Git-Historie. Identifiziere einen Commit, in dem Du ein wichtiges Problem gelöst hast. Worum ging es dabei und wie bist Du vorgegangen?
Fokus: Logik / Implementierungsdetails
- Schau Dir diese konkrete Funktion an: [auf eine komplexe Abfrage oder Schleife zeigen]. Erkläre, was passiert, wenn die Eingabedaten fehlerhaft oder leer sind. Wie behandelt Dein Code diesen Fall?
- Du hast hier ein [konkretes Pattern, z.B. Decorator, Mixin, Factory] verwendet. Warum war dieses Pattern notwendig? Wie würde der Code aussehen, wenn Du ihn ohne dieses Pattern geschrieben hättest?
- Erkläre den Unterschied zwischen Deiner Umsetzung von [Feature X der App] und [Feature Y der App]. Unterscheiden sich die Implementierungsstrategien? Wenn ja, wieso? Wenn nein, wieso nicht?
Fokus: Was wäre-wenn-Fragen
- Wenn ich Dich bitten würde, ein neues Feld zur Tabelle [Tabellenname] hinzuzufügen: Was müsstest Du genau im Python-Code ändern? Führe mich in einer logischen Reihenfolge durch.
- Angenommen, wir möchten die Nutzer-Authentifizierung ändern. Welche Teile Deiner aktuellen Codebasis wären am stärksten betroffen? Schätze den Aufwand ein: niedrig, mittel oder hoch – und begründe warum.
- Du hast erwähnt, dass Du auf [konkreter Codebeitrag] besonders stolz bist. Wenn Du diesen Code heute mit Deinem jetzigen Wissen neu schreiben müsstest: Was würdest Du ändern, um besser zu machen? Definiere zunächst “besser”.
Copyright © 2026 Prof. Dr. Alexander Eck. All rights reserved.