flowchart LR
A[Anforderungen] --> B[Entwurf]
B --> C[Implementierung]
C --> D[Test]
D --> E[Deployment]
E --> F[Betrieb]
A -. KI hilft bei .-> A1[Analyse & Strukturierung]
B -. KI hilft bei .-> B1[Varianten & Dokumentation]
C -. KI hilft bei .-> C1[Code & Refactoring]
D -. KI hilft bei .-> D1[Testfälle & Fehlersuche]
F -. KI hilft bei .-> F1[Monitoring & Support]
KI-gestützte Softwareentwicklung
Prof. Dr. Robin Nunkesser
Einführung in KI-gestützte Softwareentwicklung
Was bedeutet das konkret?
- KI unterstützt Menschen entlang des gesamten Software-Lebenszyklus
- Nicht nur Codegenerierung, sondern auch Analyse, Tests, Dokumentation und Review
- Ziel: höhere Geschwindigkeit, bessere Qualität und schnelleres Lernen
- Wichtig: KI ist ein Assistenzsystem, kein Ersatz für fachliche Verantwortung
Typische Einsatzfelder
- Anforderungen strukturieren und User Stories schärfen
- Architekturvarianten vergleichen und Risiken diskutieren
- Boilerplate, Tests, SQL, Regex und Dokumentation erzeugen
- Fehlermeldungen, Logs und Stack Traces analysieren
- Wissensaufbereitung, Onboarding und Projektkommunikation unterstützen
GitHub Copilot als Standardwerkzeug
Warum Copilot hier der naheliegende Referenzfall ist
- In der Vorlesung ist GitHub Copilot das Standardwerkzeug für KI-gestützte Entwicklung
- Es verbindet Inline-Vorschläge, Chat, Codeverständnis und Agenten-Workflows in der IDE
- Damit eignet es sich gut, um allgemeine Prinzipien an einem konkreten Tool zu zeigen
- Die Grundidee bleibt allgemeingültig: KI ist Assistenz, kein Ersatz für Engineering-Verantwortung
Typische Fähigkeiten von Copilot
- Code erklären, entwerfen, ergänzen und refaktorieren
- Tests, Dokumentation, Regex, SQL und kleine Skripte erzeugen
- Fehler, Logs und Compiler-Meldungen einordnen
- bei Navigation und Onboarding in größeren Codebasen helfen
- repetitive Aufgaben beschleunigen, aber nicht fachliche Entscheidungen abnehmen
KI im Software-Lebenszyklus
Wo der Nutzen besonders hoch ist
- repetitive Aufgaben mit klaren Mustern
- Arbeit in unbekannten Frameworks und APIs
- Einarbeitung in Legacy-Code
- Sammeln von Testfällen und Randbedingungen
- Prototypen und erste Lösungsskizzen
Realistische Grenzen
- KI halluziniert APIs, Randfälle und Sicherheitsannahmen
- Domänenwissen, Priorisierung und Architekturentscheidungen bleiben menschlich
- Generierter Code ist nicht automatisch korrekt, wartbar oder sicher
- Ohne Review und Tests steigt das Risiko technischer Schulden
Gute Arbeitsweise mit KI
Human-in-the-loop
- Kontext sichtbar machen: Datei, Ziel, Randbedingungen und Fehlermeldungen
- erst verstehen und planen, dann Änderungen ableiten
- nur den nächsten kleinen Schritt umsetzen
- Ergebnis durch Verifikation absichern: Build, Tests, Linter oder Review
- iterativ verbessern und Verantwortung beim Menschen behalten
Sicherer Arbeitsablauf mit KI
flowchart TD
A[Problem verstehen] --> B[Prompt mit Kontext]
B --> C[KI-Vorschlag]
C --> D[Review durch Entwickler]
D --> E[Build, Tests, Linter]
E --> F[Einsatz im Projekt]
D -- unklar/falsch --> B
E -- Fehler gefunden --> B
Welchen Kontext KI-Tools typischerweise nutzen
- die aktuelle Datei, Auswahl und offene Tabs
- relevante Projektdateien und Nachbardateien
README.md, Fehlermeldungen, Logs und Terminalausgaben- Projekt- und Builddateien wie
package.json,pyproject.toml,pom.xmloder.csproj - in strukturierten Setups zusätzlich Regeln aus
.github/copilot-instructions.mdund.github/instructions/*.instructions.md - Freigaben für Lesen, Schreiben und Terminalzugriff im aktuellen Tool-Setup
Risiken und Governance
- keine sensiblen Daten ungeprüft in Prompts kopieren
- Lizenz- und Urheberrechtsfragen beachten
- Security-Checks trotz KI konsequent beibehalten
- Entscheidungen dokumentieren und nachvollziehbar machen
- Teamstandards für erlaubte Einsatzszenarien definieren
Kompetenzen, die wichtiger werden
- Prompting und Kontextaufbereitung
- Code Review und Testdesign
- Architekturverständnis
- Daten- und Sicherheitsbewusstsein
- kritisches Hinterfragen von Ergebnissen
Integration in IDEs
Überblick
- Vorschläge erscheinen direkt im Editor
- Copilot Chat kann Fragen zur aktuellen Datei, Auswahl oder zum Projekt beantworten
- Terminalfehler, Logs und Compiler-Meldungen lassen sich in den Dialog einbeziehen
- Gute Ergebnisse entstehen durch iteratives Nachfragen statt Einmal-Prompts
- Zusätzlich unterstützen neuere Workflows stärkeres Planen, Handoffs und Agentenrollen
Häufige Aktionen im Chat
| Aufgabe im Chat | Typischer Nutzen |
|---|---|
| erklären | Code, Architektur oder Fehlermeldung einordnen |
| beheben | gezielte Verbesserung bei Fehlern oder Warnungen |
| testen | Unit-Tests oder Testideen erzeugen |
| dokumentieren | Kommentare, README-Abschnitte oder ADR-Notizen |
| optimieren | Lesbarkeit, Laufzeit oder Speicherbedarf prüfen |
Die verfügbaren Kommandos können je nach IDE und Version leicht variieren.
Nützliche Referenzen
| Beispiel | Nutzen |
|---|---|
Wo sind die Tests in #MyFile.cs? |
bezieht eine bestimmte Datei ein |
Wie sind #MyFile.cs und #MyFile2.cs verbunden? |
verknüpft mehrere Artefakte |
Erkläre #MyFile.cs:66-72 |
fokussiert auf einen konkreten Ausschnitt |
Gibt es eine Löschmethode in dieser #solution? |
fragt projektweit nach Zusammenhängen |
Merksatz
- Copilot ist ein Produktivitätsverstärker – kein Autopilot
- Besonders wertvoll bei Fleißarbeit, Erklärungen und ersten Entwürfen
- Verantwortlich für das Ergebnis bleibt immer das Entwicklungsteam
Prompt Engineering
Einführung
- Gute Prompts liefern Ziel, Kontext und Randbedingungen
- Je präziser die Aufgabe, desto brauchbarer das Ergebnis
- Besonders wichtig: gewünschte Sprache, Stil, Frameworks und Ausgabeformat
- Nachfragen und Verfeinern gehört ausdrücklich zum Prozess
Ein einfaches Muster für gute Prompts
- Ziel: Was soll erzeugt oder erklärt werden?
- Kontext: Sprache, Framework, vorhandene Schnittstellen
- Nebenbedingungen: Fehlerbehandlung, Performance, Security, Stil
- Ausgabeformat: nur Code, Tabelle, schrittweise Erklärung, Tests
- Qualitätskriterium: woran erkenne ich eine gute Antwort?
Iteratives Prompting
flowchart TD
A[Aufgabe formulieren] --> B[Kontext ergänzen]
B --> C[Antwort bewerten]
C --> D[Nachschärfen oder eingrenzen]
D --> E[Code testen]
E --> F[Ergebnis übernehmen]
C -- noch unklar --> B
E -- Fehler / Lücken --> D
Deutsch oder Englisch?
- Für Programmieraufgaben funktionieren englische Prompts oft etwas stabiler
- Für Fachinhalte, Lehrkontexte und Diskussionen ist Deutsch oft angenehmer
- Mischformen funktionieren gut: fachliche Einleitung auf Deutsch, technische Details auf Englisch
- Wichtiger als die Sprache ist die Präzision des Kontexts
Wahl des Modells
| Aufgabe | Sinnvoller Modelltyp |
|---|---|
| schneller Entwurf, Q&A, Doku | schnelles Allround-Modell |
| Debugging, Architektur, knifflige Logik | stärkeres Reasoning-Modell |
| Refactoring, Tests, API-Nutzung | code-starkes Modell |
| Arbeit mit Screenshots oder Diagrammen | multimodales Modell |
Neuere Modelle in VS Code / Copilot
- Der Model Picker bietet je nach Plan und Freischaltung unterschiedliche Modellklassen
- Praktisch zählen vor allem drei Fragen:
- Brauche ich schnelle Entwürfe oder tiefes Reasoning?
- Brauche ich starke Codequalität oder multimodale Verarbeitung?
- Ist Auto für die Aufgabe ausreichend oder wähle ich bewusst manuell?
- Für Reasoning-Modelle lässt sich zusätzlich der Thinking Effort anpassen
- Konkrete Modellnamen ändern sich regelmäßig und sollten als Beispiele behandelt werden
Verfügbarkeit kann je nach Copilot-Tarif, Organisation und Preview-Features variieren.
Neue Modi: Planen mit Agents
- Früher sprach man oft von Chat Modes; in VS Code heißt das heute stärker Agents bzw. Custom Agents
- Ein Planning Agent kann bewusst nur Lese-Tools verwenden und zunächst einen Umsetzungsplan erzeugen
- Danach ist ein Handoff an einen Implementierungs- oder Review-Agent möglich
- Das ist besonders nützlich für größere Änderungen, Migrationen und strukturierte Aufgaben
flowchart LR
A[Plan-Agent<br/>Analyse & Planung] --> B[Implementation-Agent<br/>Code ändern]
B --> C[Review-Agent<br/>Prüfen & Absichern]
Agentic Development
Planen, Umsetzen, Prüfen
- Agentic Development teilt komplexe Aufgaben in Rollen und Schritte auf
- Typische Kette:
- Plan erzeugen
- Umsetzung durchführen
- Ergebnis prüfen und absichern
- Vorteil: strukturierteres Arbeiten, bessere Nachvollziehbarkeit und weniger unkontrollierte Änderungen
- Besonders hilfreich bei Refactorings, Migrationen und größeren Feature-Wünschen
Typischer Ablauf
flowchart TD
A[Aufgabe / Feature-Wunsch] --> B[Plan-Agent]
B --> C[Schritte, Risiken, Annahmen]
C --> C1[Plan-Freigabe & Scope-Gate]
C1 --> D[Implementierungs-Agent]
D --> E[Codeänderungen]
E --> F[Review- oder Test-Agent]
F --> F1[CI-Check]
F1 --> G[Menschliche Abnahme / nächste Iteration]
Didaktische Einordnung
- Gut geeignet, um systematisches Vorgehen zu demonstrieren
- Macht deutlich, dass KI nicht nur Antworten gibt, sondern Workflows unterstützt
- Trotzdem bleibt menschliche Kontrolle entscheidend
Agent-Workbenches
Was ist eine Agent-Workbench?
- Ein eigenes Repo oder Arbeitsbereich für die Zusammenarbeit zwischen Mensch und KI-Agenten
- Bündelt Playbooks, Prompt-Vorlagen, Projektpläne, Entscheidungen und Reviews
- Hilft, wiederkehrende Aufgaben systematisch statt ad hoc zu bearbeiten
- Besonders nützlich bei Lehre, Refactorings, Migrationen und wiederholbaren Workflows
Typische Struktur
playbooks/für Vorgehensmodelletemplates/für Copy-Paste-Schablonenprompts/recurring/für bewährte Standardpromptsprojects/für konkrete Vorhaben mitplan.md, Fragen und Status
Empfohlene Arbeitsweise
- passendes Playbook auswählen
- mit einem Template einen kleinen Plan erzeugen
- den Agenten zunächst analysieren und strukturieren lassen
- offene Punkte und Entscheidungen dokumentieren
- erst danach in kleinen, verifizierbaren Slices implementieren
flowchart LR
A[Playbook] --> B[Plan / offene Fragen]
B --> C[Agent bearbeitet einen kleinen Slice]
C --> D[Build, Tests, Review]
D --> E[Dokumentation & Learnings]
Empfehlungen für Human-in-the-Loop
- Kontext zuerst, dann Umsetzung
- Planen vor Implementieren
- Agenten lieber mit kleinen, klaren Slices arbeiten lassen
- Ergebnisse immer durch Verifikation absichern: Build, Tests, Review oder reale Ausführung
- wichtige Entscheidungen schriftlich festhalten
- stabile Zwischenstände früh committen
- Verantwortung bleibt trotz KI beim Entwicklungsteam
Demo: Plan-Agent in der Praxis
Beispielprompt
Erwarteter Nutzen
- noch keine Codeänderung
- trotzdem sofort ein belastbarer Startpunkt
- sinnvolle Zielarchitektur und erster Projektzuschnitt werden sichtbar
- Risiken und offene Fragen werden früh geklärt
- gute Grundlage für Kick-off, Teamdiskussion und erste Umsetzung
Lehrbotschaft
- Erst verstehen und planen, dann implementieren
- KI unterstützt damit nicht nur beim Codieren, sondern auch beim Vorgehen
Analyse: Was der Plan produziert hat
Ergebnis auf einen Blick
Der Agent lieferte ohne Nachfrage einen vollständigen Plan (plan.md):
- Scope: In-Scope und Out-of-Scope klar abgegrenzt
- Projektstruktur:
study-companion/mitfrontend/,backend/,shared/,data/ - User Stories: 6 Stories in P0 und P1, je mit Akzeptanzkriterien
- Milestones: M0 Projektbasis → M1 Aufgabenverwaltung → M2 Lernsession
- Risiken: 5 Risiken mit Gegenmassnahmen
- Iterationspläne: Slices, Schritt-für-Schritt-Plan und Done-Kriterien für Iteration 1 und 2
Das klingt solide. Aber: der Agent hat dafür viele Entscheidungen still selbst getroffen.
Annahmen statt Rückfragen
Der Plan enthält einen Abschnitt “Produktannahmen” — der aber Entscheidungen sind, keine Fragen:
| Annahme im Plan | Was hätte man fragen sollen? |
|---|---|
| Einzelnutzer, keine Lerngruppen | Zielgruppe geklärt? |
| Webanwendung für Desktop und Mobile | Welches Gerät ist primär? |
| Kein Login in den ersten zwei Iterationen | Reicht ein Demo-Benutzer für die Bewertung? |
| KI, Upload, Kalender sind Out-of-Scope | Ist das mit dem Auftraggeber abgestimmt? |
| Persistenz nicht festgelegt | Reicht Browser Storage oder braucht es ein Backend? |
Keine dieser Annahmen wurde vorab als Frage gestellt — sie stehen einfach im Plan.
Offene Fragen — aber zu spät
Die Fragen tauchten auf — leider am Ende des Plans, nicht am Anfang:
- Soll der MVP rein lokal laufen oder früh eine persistente Backend-Speicherung enthalten?
- Ist Mobile-First oder Desktop-First wichtiger?
- Soll eine Lernsession zwingend an eine Aufgabe gebunden sein?
- Welche minimalen Kennzahlen sind für das erste Dashboard wirklich nützlich?
- Reicht ein einzelner Demo-Benutzer oder wird früh ein Login benötigt?
decisions.md blieb leer — keine einzige Entscheidung wurde formell festgehalten.
→ Vollständige Liste: open-questions.md
Lehrbotschaft aus der Analyse
- Ein KI-Agent plant schnell und strukturiert — aber oft nicht vorsichtig
- Fehlende Rückfragen führen zu einem Plan, der auf Annahmen aufbaut
- Annahmen sind nicht automatisch falsch — aber sie sollten explizit und bestätigt sein
- Besser: den Agenten explizit anweisen, zuerst Fragen zu stellen, bevor er plant
Demo: Implementierung und Review
Beispielprompt für einen Implementierungs-Agenten
Beispielprompt für einen Review-Agenten
Nutzen im Unterricht
- zeigt die Trennung von Planung, Umsetzung und Prüfung
- verdeutlicht unterschiedliche Rollen von KI im Entwicklungsprozess
- unterstützt sauberes, nachvollziehbares Vorgehen
Architekturarbeit mit Copilot
Architekturwünsche als Constraints
- Nicht nur “clean” fordern, sondern klare Architekturregeln setzen
- Beispielregeln:
- UI greift nicht direkt auf Infrastruktur zu
- Neue Use Cases laufen über Ports
- Für neue Services sind Unit-Tests Pflicht
- Keine Secrets in Code, Prompt oder Logs
Plan-Gate vor Implementierung
- Erst Plan prüfen und freigeben, dann umsetzen
- So bleibt Scope kontrollierbar und nachvollziehbar
Kleine Slices statt großer Umbauten
- Pro Slice ein fachlicher Schritt plus ein Architekturziel
- Beispiel:
- Slice 1: Projektstruktur + erstes Vertical Slice
- Slice 2: Ports ergänzen + Testabdeckung erhöhen
- Slice 3: Review-Fixes + Dokumentation (ADR)
Review-Checkliste mit Architekturfokus
- Prüfen nicht nur auf Stil, sondern auf Schichten und Abhängigkeiten
- Findings priorisieren: Risiko zuerst, Kosmetik zuletzt
CI-Gates und Entscheidungen
- Merge nur mit grünen Mindest-Gates:
- Build
- Tests
- Linter/Analyzer (falls vorhanden)
- Wichtige Architekturentscheidungen kurz als ADR festhalten
- Ergebnis: reproduzierbare Teamarbeit statt Einzelprompt-Optimierung
Alt vs. Neu in 60 Sekunden
Früher: prompt-zentriert
- Fokus auf einzelne Antwortqualität
- Architekturwünsche nur als Text im Prompt
- Umsetzung oft in großen Blöcken
- Review eher stil- als risikoorientiert
- Qualität stark personenabhängig
Heute: workflow-zentriert
- Fokus auf Plan -> Gate -> Slice -> Review -> CI
- Architektur als verbindliche Constraints und ADRs
- Kleine, überprüfbare Iterationen
- Review mit Risiko- und Architektur-Checkliste
- Qualität reproduzierbar im Teamprozess verankert
Tools und Ausblick
Typische Toolklassen
- Coding Assistants wie GitHub Copilot
- KI-gestützte Reviews und statische Analyse
- Test- und Dokumentationsassistenten
- Such- und Wissenssysteme für große Codebasen
- agentische Werkzeuge für mehrstufige Aufgaben
Zukunftsaussichten
- stärkere Integration in IDE, CI/CD und Ticketsysteme
- multimodales Arbeiten mit Code, Diagrammen, Screenshots und Logs
- repository-aware und agentische Workflows nehmen zu
- erfolgreiche Teams kombinieren KI-Geschwindigkeit mit Engineering-Disziplin
- KI wird Assistenz breiter machen, aber Verantwortung nicht ersetzen
Fazit
Quintessenz
- GitHub Copilot ist ein sehr nützliches Werkzeug für den Alltag
- Den größten Nutzen bringt es mit gutem Kontext, klaren Prompts und konsequenter Prüfung
- Besonders in Lehre und Praxis zeigt sich:
- schneller Einstieg
- mehr Varianten und Ideen
- aber weiterhin Bedarf an sauberem Engineering
