Agentic Software Engineering

Agentic Software Engineering

Grundlagenmodul · WPF / WASP · Informatik Bachelor · TH Köln · WiSe 26/27

SE-Aktivitäten mit agentischer KI durchführen, steuern und kritisch bewerten.

Die Studierenden führen Software-Engineering-Aktivitäten sowohl manuell als auch mit Coding-Agenten durch. Sie lernen, die Effizienz- und Qualitätsvorteile von Coding-Agenten zu nutzen, ohne den Überblick zu verlieren oder die Verantwortung abzugeben.

Das Modul Agentic Software Engineering (ASE) vermittelt die Fähigkeit, klassische Software-Engineering-Aktivitäten mit agentischer KI durchzuführen, zu steuern und kritisch zu bewerten. Das Modul orientiert sich an den Aktivitäten des Software Engineering Body of Knowledge (SWEBOK): SE-Grundlagen werden aufgefrischt und um die Perspektive KI-gestützter Entwicklung ergänzt.

Dabei reflektieren die Studierenden fortlaufend ihre eigene Rolle: Wie verändert sich meine Rolle in einem Softwareprojekt? Wodurch stärke ich mich, wodurch schwäche ich mich? Wieviel Überblick brauche ich, um mit KI effizient zu arbeiten? Das Modul vermittelt nicht nur den aktuellen Stand, sondern die Fähigkeit, sich an neue KI-Entwicklungen anzupassen.

Dieses Modul ist Teil der Wahlspezialisierung (WASP) „Agentic Software Engineering" (ASE) und kann auch separat als Wahlpflichtfach belegt werden.

Studiengang: Informatik Bachelor, TH Köln

Modultyp: Grundlagenmodul (5 ECTS) der WASP „Agentic Software Engineering" (auch separat als WPF belegbar)

Zeitraum: WiSe 26/27

Charakter: Workshopbasiert mit Live-Demonstrationen, praktische Übungen

Kontakt: Prof. Dr. Uwe van Heesch, Anja Bertels M.Sc.

Inhalt

Learning Outcome

Die Studierenden führen Software-Engineering-Aktivitäten sowohl manuell als auch spezifikationsgetrieben mit agentischer KI durch und bewerten die entstehenden Artefakte und Prozesse (WAS), indem sie

um komplexe Softwareprojekte zu realisieren, in denen agentische KI die Umsetzung unterstützt, während der Mensch Architekturentscheidungen, Qualitätsverantwortung und Prozesssteuerung behält (WOZU).

Themen

Orientiert am Software Engineering Body of Knowledge (SWEBOK):

Zusätzlich, jenseits klassischer SWEBOK-Inhalte:

Didaktik

Workshopbasiert. Jede Sitzung folgt einem dreiteiligen Muster:

  1. Fachlicher Input – SE-Konzepte, Best Practices, Demonstration agentischer KI
  2. Manuelle Arbeitsphase – Studierende führen die SE-Aktivität selbst durch, Peer-Reviews
  3. KI-gestützte Arbeitsphase – Dieselbe Aufgabe mit Coding-Agenten, Vergleich und Reflexion

Eine gemeinsame Fallstudie zieht sich durch alle Sitzungen, anhand derer die verschiedenen SE-Aktivitäten durchlaufen werden.

KI-gestützte Lernbegleitung: Ein vorkonfigurierter Lernbegleiter-Agent steht zur Verfügung, der durch sokratische Dialoge beim Verstehen der Konzepte hilft, statt fertige Lösungen zu liefern. Er begleitet jede Person individuell, passt sich dem jeweiligen Kenntnisstand an und dokumentiert den Lernfortschritt. Wöchentliche Kontextdateien halten den Agenten auf dem aktuellen Stand der Kursthemen, sodass er gezielt zu den gerade behandelten Inhalten unterstützen kann.

Technologiestack

Prüfungsform

Die Bewertung ist individuell. Bewertet werden die praktische Anwendung der SE-Techniken mit agentischer KI, die Qualität der Steuerung und die Reflexion über den eigenen Lernprozess.

1. Portfolio (40%, prozessbegleitend, individuell)

Jede Person führt von Anfang an ein eigenes Portfolio in einem individuellen Git-Repository. Details siehe Portfolio-Leitfaden.

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

Im Walkthrough wird der gesamte Inhalt des Portfolios besprochen: SE-Artefakte, Agentenkonfiguration, Entscheidungen und Reflexionen.

Bewertungsrubric

Kriterium Gewicht 0 Punkte 1 Punkt 2 Punkte 3 Punkte
Portfolio (40%)
SE-Artefakte (Requirements, Architektur, ADRs) 2 Keine oder triviale Artefakte. Artefakte vorhanden, aber unvollständig. Zusammenhänge zwischen Artefakten fehlen. Vollständige Artefakte. Zusammenhänge (Anforderung → Architektur → Design) sind erkennbar und dokumentiert. Artefakte sind systematisch als Steuerungsgrundlage für Agenten konzipiert. Qualität der Spezifikation wird anhand von Agenten-Ergebnissen reflektiert.
Agentensteuerung (Konfiguration, Prompts, Anpassungen) 2 Keine substanzielle Steuerung erkennbar. Grundlegende Konfiguration vorhanden. Agentenverhalten wurde nicht systematisch beobachtet. Steuerung wurde iterativ verbessert. Beobachtungen des Agentenverhaltens führten zu dokumentierten Anpassungen. Systematische Optimierung: Hypothese → Änderung → Beobachtung → Ergebnis. Grenzen der Steuerbarkeit werden reflektiert.
Arbeitsplanung (WBS, Abhängigkeiten, Parallelisierung) 2 Keine Arbeitsplanung erkennbar. Ad-hoc-Vorgehen. Arbeitspakete nicht explizit identifiziert. Arbeitspakete und Abhängigkeiten sind modelliert. Parallelisierungsmöglichkeiten wurden identifiziert. Fortschritt wurde überwacht, Blockaden erkannt und dokumentiert. Planung wurde anhand von Erfahrungen angepasst.
Wöchentliche Reflexionen 2 Keine oder nur sporadische Einträge. Einträge sind deskriptiv oder abstrakt-generisch. Keine konkreten Situationen, keine persönlichen Erkenntnisse erkennbar. Einträge beschreiben konkrete Situationen und eigene Reaktionen. Überraschungen, Fehleinschätzungen und Kurskorrekturen werden benannt. Reflexion zeigt authentischen Lernprozess: Unsicherheiten, Aha-Momente, Frustration und deren Überwindung. Eigene Grenzen werden ehrlich benannt, verallgemeinerbare Einsichten aus spezifischen Erlebnissen abgeleitet.
Mündlicher Walkthrough (60%)
Begründung von SE-Entscheidungen 3 Entscheidungen können nicht begründet werden. Begründungen ohne Bezug zu SE-Konzepten. Entscheidungen werden mit SE-Konzepten begründet (z. B. „ADR wegen Nachvollziehbarkeit für künftige Agenten"). Alternativen und Trade-offs werden differenziert diskutiert.
Begründung von Steuerungsentscheidungen 3 Agentensteuerung kann nicht erklärt werden. Steuerung wird beschrieben, aber nicht begründet. Steuerungsentscheidungen werden anhand von Beobachtungen begründet. Zusammenhang zwischen Spezifikationsqualität, Steuerung und Ergebnisqualität wird hergestellt.
Reflexion der eigenen Rolle 3 Keine Reflexion. Deskriptiv („Ich habe X gemacht"). Kritische Einordnung: Was hat funktioniert? Wo habe ich die Kontrolle verloren? Was würde ich anders machen? Verallgemeinerung: Wie verändert sich die Rolle des SE durch Coding-Agenten? Eigene Stärken/Schwächen werden benannt.
Umgang mit Nachfragen 3 Nachfragen können nicht beantwortet werden. Antworten bleiben oberflächlich. Sachlich und differenziert. Wissenslücken werden offen benannt. Fundiert und reflektiert, auch über den eigenen Fall hinaus.

Notenberechnung

Insgesamt sind maximal 60 Punkte erreichbar (20 Gewichtspunkte × 3 Punkte). 0 Punkte in einem der Portfolio-Kriterien führen automatisch zum Nichtbestehen. Bei „Wöchentliche Reflexionen" sind mindestens 2 Punkte erforderlich.

NotePunkte
1,054–60
1,350–53
1,747–49
2,044–46
2,341–43
2,738–40
3,035–37
3,332–34
3,728–31
4,024–27
5,00–23

Portfolio-Leitfaden

Das Portfolio ist das Git-Repository als Ganzes: Produktivcode, SE-Artefakte, Agent-Konfiguration, Commit-Historie und ein strukturierter portfolio/-Ordner mit Dokumentation und Reflexionen. Im mündlichen Walkthrough gehen wir gemeinsam durch beides – Artefakte und Dokumentation.

Aufbau des Repositories

ihr-repo/
├── src/                          # Produktivcode
├── docs/
│   ├── requirements/             # Anforderungsspezifikation
│   ├── architecture/             # C4-Diagramme, ADRs
│   └── ...
├── AGENTS.md                     # Agent-Konfiguration
├── portfolio/                    # Dokumentation und Reflexionen
│   ├── week1.md                  # Wöchentliche Reflexion
│   ├── week2.md
│   ├── ...
│   └── week7.md
└── ...

Das Repository hat zwei Säulen:

  1. Die Artefakte – SE-Dokumente (Requirements, Architektur, ADRs), Agent-Konfiguration, Produktivcode und Commit-Historie
  2. Der portfolio/-Ordner – Wöchentliche Reflexionen und Dokumentation von Entscheidungen

Die Artefakte als Portfolio

Die SE-Artefakte sind nicht nur Mittel zum Zweck – sie sind ein wesentlicher Teil des Portfolios.

Commit-Historie: Die Commits erzählen eine Geschichte. Insbesondere der Wechsel zwischen manueller Arbeit und Agentenarbeit sollte im Commit-Verlauf nachvollziehbar sein. Achten Sie auf aussagekräftige Commit-Messages, die zeigen, wer (Sie oder der Agent) was gemacht hat.

SE-Artefakte: Requirements, Architektur und ADRs zeigen, wie Sie das System spezifiziert haben – und ob diese Spezifikationen als Steuerungsgrundlage für Agenten geeignet waren. Die Qualität der Spezifikation zeigt sich in der Qualität der Agenten-Ergebnisse.

Agent-Konfiguration: Die AGENTS.md und ihre Entwicklung über die Wochen zeigt, wie Sie die Agentensteuerung verbessert haben – welche Anpassungen Sie vorgenommen haben und warum.

Der portfolio/-Ordner

weekN.md – Wöchentliche Reflexionen: Jede Woche schreiben Sie einen kurzen Eintrag (ca. ½–1 Seite). Die folgende Struktur dient als Orientierung. Falls Sie Unterstützung beim reflektierenden Schreiben benötigen, empfehlen wir das Engineering Reflection Guidebook.

# Woche N – [Thema]

## Was habe ich gemacht?
Kurze Beschreibung der umgesetzten SE-Aktivitäten und 
Agenteninteraktionen mit Verweisen auf relevante Commits oder Dateien.

## Entscheidungen und Begründungen
Welche SE-Entscheidungen und Steuerungsentscheidungen habe ich getroffen und warum?
Was habe ich an der Agent-Konfiguration geändert und mit welchem Ergebnis?

## Wie habe ich gelernt?
Was hat der Agent gut gemacht, was schlecht?
Wo habe ich die Kontrolle behalten, wo verloren?
Was habe ich diese Woche anders gemacht als letzte Woche, und warum?

## Offene Fragen / Nächste Schritte
Was ist noch unklar? Was würde ich beim nächsten Mal anders machen?

Worauf Sie achten sollten

Begründen, nicht nur beschreiben: Der häufigste Fehler ist rein deskriptive Dokumentation. Erklären Sie warum Sie etwas so gemacht haben und welche Alternativen Sie erwogen haben. Schwach: „Ich habe den Agenten die Architektur erstellen lassen." Besser: „Ich habe die Architektur zunächst selbst skizziert und dann den Agenten gebeten, sie in C4-Notation auszuarbeiten. Der Agent hat dabei die Service-Grenzen anders gezogen als ich – nach Prüfung habe ich seine Variante übernommen, weil..."

Grenzen benennen: Zeigen Sie, dass Sie wissen, wo Ihr Ansatz an seine Grenzen stößt. Beispiel: „Bei der Anforderungsanalyse war der Agent hilfreich für die Strukturierung, aber bei der Priorisierung hat er nur generische Kriterien genannt. Die tatsächliche Priorisierung musste ich selbst vornehmen."

KI-Einsatz ehrlich dokumentieren: Es geht nicht darum, ob Sie Agenten nutzen, sondern wie reflektiert Sie damit umgehen. Halten Sie fest, was Sie delegiert haben, was Sie übernommen und was Sie verworfen haben, welche Fehler der Agent gemacht hat und was Sie dabei gelernt haben.

Iterative Verbesserung sichtbar machen: Zeigen Sie, dass sich Ihr Ansatz über die Wochen entwickelt hat. Dokumentieren Sie nicht nur den Endzustand, sondern den Weg dorthin – was Sie an Ihrer Arbeitsweise und der Agentensteuerung geändert haben und warum.

Umfang

Das Portfolio soll substanziell, aber nicht aufgebläht sein: ca. ½–1 Seite pro wöchentlicher Reflexion. Bei den SE-Artefakten gilt Qualität vor Quantität – es ist besser, wenige Artefakte gut durchdacht zu haben als viele oberflächliche.

Voraussetzungen

Literatur

© Prof. Dr. Uwe van Heesch, Anja Bertels M.Sc. – TH Köln · Letzte Änderung: 25.08.2026