Autonome Coding-Agenten
mit OpenClaw

Forschungsorientiertes Projekt, in dem Studierende in Kleingruppen (ca. 2–5 Personen) ihren eigenen autonomen Coding-Agenten auf Basis von OpenClaw in einer kontrollierten Docker-Umgebung entwickeln. Der Agent erhält klar definierte Rechte (z. B. GitHub-Zugriff, Internetrecherche, Ticketbearbeitung) und wird als persönlicher „Coding Companion" konzipiert.

Der Fokus liegt darauf, Agenten, Pipelines und Konfigurationen so einzurichten, dass die Agenten qualitativ hochwertigen Code erzeugen. Dazu wird das im Grundlagenmodul CCQ erlernte Wissen angewendet: Die Agenten erhalten z. B. eine passende Definition of Done, müssen Code-Coverage-Ziele erreichen und Mutation-Testing Quality Gates bestehen. Zusätzlich werden Architectural Guardrails in den Agent Instructions eingesetzt. Letztlich ist es das Ziel, dass die Agenten wartbaren, sicheren Code erzeugen, also die gleichen Qualitätskriterien erfüllen wie menschliche Entwickelnde.

Als Arbeitsgrundlage definiert jede Kleingruppe in Absprache mit dem Dozenten ein eigenes Scrum-Projekt. Dieses dient als Fallstudie, um zu analysieren, wie die Agenten mit fachlichen Anforderungen umgehen und technische Constraints berücksichtigen. Scrum-Artefakte wie Product Backlog, Sprint Backlog, Scrum Board, Definition of Done und Sprints sind relevant, da die Agenten damit arbeiten. Auf Ceremonies wie Standups, Reviews und Retrospektiven kann hingegen verzichtet werden. Stattdessen wird beobachtet und konfiguriert, wie die Agenten Tickets abarbeiten. Welche Rolle diese Ceremonies in einem Team aus Menschen und Agenten spielen und wie sie sich verändern müssten, ist dabei ein lohnenswerter Reflexionsgegenstand.

Dieses Projekt ist Teil der Wahlspezialisierung (WASP) „Continuous Code Quality und Autonome Agenten" (CCQ). Die WASP besteht aus dem Grundlagenmodul CCQ, das auch als eigenständiges Wahlpflichtfach belegt werden kann, und diesem Projekt. Der Projektteil setzt die Teilnahme am Grundlagenmodul voraus.

Zusammenhang: Grundlagenmodul CCQ und Projekt

Das Grundlagenmodul CCQ vermittelt die Grundfähigkeiten, um Code-Qualität in CI-Umgebungen kontinuierlich sicherzustellen, u. a. durch automatisierte Tests, Coverage-Tools, Mutation-Testing-Tools, SAST-Scanner und Linter. Im Projekt werden diese Kompetenzen angewendet, um Agenten zu konfigurieren und eine Infrastruktur zu schaffen, in der die Agenten automatisch Code erzeugen, der die definierten Qualitätskriterien erfüllt. Das geschieht teils durch Agentenkonfiguration, teils durch Pipeline-Jobs, teils durch Architectural Guardrails und Review Guidelines, die wiederum von Review-Agenten verwendet werden. Die Agenten iterieren so lange, bis ihr Code alle Quality Gates passiert. Über dieses System können die Studierenden dann wiederum iterieren, um z. B. Durchlaufzeit oder Token-Nutzung zu optimieren.

Ziel ist es, Studierenden einen echten Wettbewerbsvorteil zu verschaffen: Sie verlassen das Studium nicht nur mit fundierten Entwicklungskompetenzen, sondern mit einem funktionsfähigen, reflektiert konzipierten persönlichen Coding-Agenten.

Inhalt

• Learning Outcome
• Didaktisches Grundprinzip
• Projektstruktur
  • Phase 1 – Grundlagen & Setup
  • Phase 2 – Explorative Agentenentwicklung
  • Phase 3 – Mini-Projektphase
  • Phase 4 – Auswertung und Reflexion
• Prüfungsform
• Budget- und Token-Modell
• Datenschutz- und Sicherheitskonzept
• Mehrwert für Studierende

Learning Outcome

Die Studierenden konzipieren einen autonomen Coding-Agenten, der in einem Softwareprojekt selbstständig qualitätsgesicherten Code erzeugt (WAS), indem sie

• den Agenten containerisiert in einer kontrollierten Umgebung betreiben,
• Agent Instructions mit Definition of Done, Architectural Guardrails und Review Guidelines formulieren,
• CI/CD-Pipelines mit Quality Gates (Code Coverage, Mutation Testing) für den Agenten konfigurieren,
• das Verhalten des Agenten systematisch beobachten, dokumentieren und iterativ optimieren,
• sowie Konfigurationsentscheidungen, Fehlversuche und Erkenntnisse explorativ erarbeiten und reflektiert dokumentieren (WOMIT),

um beurteilen zu können, unter welchen Bedingungen autonome Coding-Agenten Code erzeugen, der die gleichen Qualitätskriterien erfüllt wie von Menschen geschriebener Code (WOZU).

Didaktisches Grundprinzip: Prozess vor Produkt

Da das Terrain neu ist (Agentensysteme, autonome KI, OpenClaw), stehen im Zentrum:

• Systematisches Explorieren
• Konfigurationsentscheidungen begründen
• Alternativen testen und verwerfen
• Sicherheits- und Rechtekonzepte evaluieren
• Reflektierter Einsatz von KI-Tools

Der Fokus liegt bewusst nicht auf einem perfekten Endprodukt, sondern auf dem systematischen Erkenntnisgewinn. Die Bewertung orientiert sich primär am Prozess.

Projektstruktur

Phase 1 – Grundlagen & Setup

Phase 2 – Explorative Agentenentwicklung

Phase 3 – Mini-Projektphase

Phase 4 – Auswertung und Reflexion

Prüfungsform

Die Bewertung ist individuell, auch wenn in Kleingruppen gearbeitet wird. Die Ergebnisse der Agenten (der von ihnen erzeugte Code) fließen nicht in die Note ein. Bewertet wird der Prozess: Konfiguration, Reflexion und Begründung von Entscheidungen.

1. Portfolio (40%, prozessbegleitend, individuell)

Jede Person führt von Anfang an ein eigenes Portfolio mit:

• Konfigurationsentscheidungen
• Architekturdiagrammen
• Token-Nutzung
• Fehlversuchen und Iterationen
• Wöchentlichen Reflexionen
• Dokumentiertem KI-Einsatz

2. Mündlicher Walkthrough (60%, individuell)

Im Walkthrough wird der gesamte Inhalt des Portfolios besprochen: Agentenkonfiguration, Entscheidungen, Reflexionen. Der von den Agenten erzeugte Code fließt nicht in die Bewertung ein.

Bewertungsrubric

Kriterium	Gewicht	0 Punkte	1 Punkt	2 Punkte	3 Punkte
Portfolio (40%)
Agentenkonfiguration	2	Keine substanzielle Agentenkonfiguration erkennbar, die über Defaults hinausgeht.	Grundlegende Konfiguration (z. B. Agent Instructions, Prompts, Skills) vorhanden, aber kaum begründet oder nur oberflächlich iteriert.	Konfiguration ist dokumentiert begründet und wurde nachweislich in mehreren Iterationen verbessert.	Konfiguration wurde systematisch anhand von Metriken oder Beobachtungen optimiert. Jede Iteration ist mit Hypothese, Änderung und Ergebnis dokumentiert.
CI/CD-Pipeline und Quality Gates	2	Keine Pipeline vorhanden oder nicht funktionsfähig.	Pipeline enthält grundlegende Jobs aus dem Grundlagenmodul. Quality Gates sind konfiguriert.	Pipeline ist umfassend. Quality Gates sind so konfiguriert, dass Agenten iterieren müssen, bis alle Gates passiert sind. Die Konfiguration ist begründet.	Über die im Grundlagenmodul erarbeiteten Methoden hinaus wurden eigenständig weitere Maßnahmen zur Verbesserung der Outputqualität konzipiert und umgesetzt. Die Wirksamkeit dieser Maßnahmen ist dokumentiert und evaluiert.
Prozessdokumentation und Reflexion	3	Keine oder nur minimale Dokumentation. Keine Reflexion erkennbar.	Dokumentation ist lückenhaft. Reflexion bleibt deskriptiv (Was wurde getan?) ohne kritische Einordnung.	Entscheidungen und Fehlversuche sind für jede Phase des Projekts dokumentiert. Reflexion benennt konkret, was funktioniert hat und was nicht, und leitet daraus Änderungen ab.	Dokumentation des explorativen Prozesses für jede Phase des Projekts. Reflexion ordnet Ergebnisse in den Gesamtkontext ein, erkennt Grenzen des eigenen Ansatzes und formuliert offene Fragen.
Container-Setup und Betriebsumgebung	1	Kein funktionsfähiges Container-Setup vorhanden.	Agent läuft in einem Container, aber Konfiguration ist undokumentiert oder nicht reproduzierbar.	Container-Setup ist dokumentiert und reproduzierbar. Rechte und Zugriffe sind kontrolliert konfiguriert.	Container-Setup ist dokumentiert, reproduzierbar und begründet. Konfigurationsentscheidungen zu Rechten, Volumes und Zugriffskontrolle sind nachvollziehbar abgeleitet.
Mündlicher Walkthrough (60%)
Fachliche Begründung von Entscheidungen	4	Entscheidungen können nicht begründet werden oder werden ausschließlich mit Verweis auf externe Quellen erklärt.	Einige Entscheidungen werden begründet, aber der Bezug zum Grundlagenmodul CCQ bleibt vage.	Entscheidungen werden nachvollziehbar begründet. Der Bezug zwischen CCQ-Grundlagen und Agentenkonfiguration wird an konkreten Beispielen hergestellt.	Entscheidungen werden auf Nachfrage zu jedem Aspekt begründet. Auf Nachfragen werden Alternativen und deren Vor-/Nachteile differenziert diskutiert.
Transferleistung und Beurteilung	4	Keine Transferleistung erkennbar. Erkenntnisse werden nicht über den eigenen Fall hinaus eingeordnet.	Erkenntnisse bleiben weitgehend auf den eigenen Fall beschränkt. Verallgemeinerungen sind oberflächlich.	Es wird nachvollziehbar beurteilt, unter welchen Bedingungen der eigene Agent qualitativ hochwertigen Code erzeugt und wo die Grenzen liegen.	Erkenntnisse werden über den eigenen Fall hinaus verallgemeinert. Es wird fundiert beurteilt, welche Faktoren die Outputqualität autonomer Coding-Agenten bestimmen.
Umgang mit kritischen Nachfragen	4	Nachfragen können nicht beantwortet werden oder führen zu Widersprüchen.	Nachfragen werden beantwortet, aber Antworten bleiben an der Oberfläche.	Nachfragen werden sachlich und differenziert beantwortet. Wissenslücken werden offen benannt.	Nachfragen werden ohne Hilfestellung fundiert und reflektiert beantwortet, auch über den unmittelbaren Kontext des eigenen Projekts hinaus.

Notenberechnung

Insgesamt sind maximal 60 Punkte erreichbar (20 Gewichtspunkte × 3 Punkte). 0 Punkte bei „Agentenkonfiguration", „CI/CD-Pipeline und Quality Gates" oder „Prozessdokumentation und Reflexion" führen automatisch zum Nichtbestehen.

Note	Punkte
1,0	53–60
1,3	50–52
1,7	47–49
2,0	44–46
2,3	41–43
2,7	38–40
3,0	35–37
3,3	32–34
3,7	28–31
4,0	24–27
5,0	0–23

Budget- und Token-Modell

Die für das Projekt benötigten API-Accounts (z. B. OpenAI) werden den Studierenden-Gruppen aus dem Lehrbudget bereitgestellt. Die Token-Nutzung wird pro Gruppe überwacht und ist mit individuellen Limits versehen, um einen bewussten und effizienten Umgang mit den Ressourcen zu fördern.

Datenschutz- und Sicherheitskonzept

Für den Lehrkontext werden grundlegende Schutzmaßnahmen getroffen. Diese sind für den Einsatz im Rahmen des Projekts ausreichend, wären für einen produktiven Einsatz jedoch nicht hinreichend. Eine kritische Reflexion dieser Einschränkung wird von den Studierenden erwartet.

• Fiktives Projekt ohne reale personenbezogene Daten
• Pseudonyme für Studierende in allen öffentlichen Umgebungen (LLMs und Projekt)
• Trennung von realer Identität und Bot-Zugriff
• Minimale Rechtevergabe (Least-Privilege-Prinzip)
• Container-Isolation
• Volumes mit kontrollierten Dateirechten

Mehrwert für Studierende

• Praktische Erfahrung mit autonomen Agentensystemen
• Docker- und Rechtekonzepte
• KI-Engineering-Kompetenz
• Starkes Profil für Bewerbungen
• Bei herausragenden Ergebnissen besteht die Möglichkeit, an einer wissenschaftlichen Publikation mitzuwirken