herzogfloria/AISE502
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
AISE502/Modulbeschreibung_AISE502_v2_2026.md

21 KiB
Raw Permalink Blame History

Modulbeschreibung: AISE502 – AI in SE II

Feld Wert
Autor/in Herzog Florian
Ausgabestelle Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS)
Geltungsbereich Departement
Klassifizierung Nicht klassifiziert
Version 2.1.0
Ausgabedatum 8. September 2026 (Inhalte an die ausgelieferten Vorlesungen 1–14 angeglichen)

Hinweis: Dies ist die Kurzfassung. Die ausführliche Fassung mit Phasenlogik, Meilenstein-Tabelle und Literaturapparat ist Modulbeschreibung_AISE502_v3_2026.md (Version 3.1.0) mit dem zugehörigen Confluence-Export. Beide Fassungen beschreiben denselben Kurs; massgeblich für den Sitzungsplan ist die eingereichte Semesterinformation (semesterinformation_HS26_AISE502_AIinSE2.xlsx).

Modul

Feld Wert
Name AI in Software Engineering II
Kürzel AISE502
ECTS-Punkte 4
Typ Pflichtmodul
Verantwortliche/r Herzog Florian
Semester 5. Semester

Leitidee

Das Modul "AI in Software Engineering II" stellt das Software Engineering grosser, langlebiger Systeme in den Mittelpunkt und behandelt Künstliche Intelligenz als integralen Bestandteil moderner Softwarearchitekturen. Aufbauend auf den Grundlagen aus "AI in Software Engineering I" (LLMs, Prompting, RAG, Clean Code, erste Agenten-Konzepte) verschiebt sich der Fokus von der einzelnen AI-Funktion hin zum Entwurf vollständiger Software-Systeme, in denen AI-Komponenten zur Laufzeit mitarbeiten.

Der Kurs ist architektur-zentriert und folgt einem eigenen, englischsprachigen Vorlesungsskript: "A Theory of Architecture--Application Fit". Dieses entwickelt eine messbare Entscheidungstheorie der Softwarearchitektur -- Architektur als Menge schwer umkehrbarer, qualitätsgetriebener Entscheidungen, getroffen durch den systematischen Abgleich von Anforderungsprofilen (zehn Anwendungsklassen) und Fähigkeitsprofilen (sieben Architektur-Patterns) über zwölf gemeinsame Profildimensionen, dokumentiert in einem ADR und über den Lebenszyklus empirisch überprüft (Fitness Functions, DORA-Metriken).

Die Leitfrage lautet: Wie entwerfe, begründe und betreibe ich die Struktur eines Software-Systems so, dass es seine Qualitätsattribute erfüllt und über Jahre wartbar bleibt -- auch dann, wenn einzelne Komponenten nicht-deterministisch, fehlbar und kostenintensiv sind?

Künstliche Intelligenz erscheint dabei in zwei gleichwertigen Rollen:

  • AI als Werkzeug zum Bauen (Achse A): Studierende setzen moderne agentische Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen Evidenz (randomisierte Studien mit positiven wie negativen Befunden), mit Architektur-Dokumentation als Agenten-Kontext und Fitness Functions als Leitplanken.

  • AI als Komponente im System (Achse B): Studierende entwerfen Architekturen, in denen LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese nicht-deterministischen Komponenten engineering-tauglich -- gekapselt (Gateway, Ports), asynchron integriert, beobachtbar, getestet (Eval-Harness) und abgesichert (Ontologie-Guard).

Den verbindenden roten Faden bildet die Erkenntnis (Annahme A6 der Theorie), dass die ingenieurmässige Disziplin, die man zum Bauen mit AI benötigt, dieselbe ist wie jene, die man zum Einbetten von AI benötigt: AI erweitert den Qualitätsattributraum, ändert aber die Methode nicht. Durch ein durchgehendes Gruppenprojekt -- eine modulare, AI-gestützte Portfolio-Analyse-Plattform -- wenden die Studierenden den gesamten Architektur- und Engineering-Bogen praktisch an.

Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt etwa 60 % zu 40 %.

Voraussetzungen

  1. AI in Software Engineering I (AISE501)
  2. Software Technik I und II
  3. Maschinelles Lernen, Deep Learning
  4. Mathematik-Grundlagen, Informatik-Grundlagen

Lernergebnisse

Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:

  1. Architektur als Entscheidungsproblem behandeln:

    • Architektur als Menge schwer umkehrbarer Entscheidungen verstehen und mit Rationale dokumentieren (Architecture Decision Records, C4-Sichten, ISO/IEC/IEEE 42010).
    • Die zwölf Profildimensionen (ISO/IEC 25010:2023-verankert, je mit Antwortmass und Messinstrument) als gemeinsames Koordinatensystem anwenden.

  2. Anforderungsprofile konstruieren:

    • Architektur-relevante Anforderungen als sechsteilige Qualitätsszenarien mit Antwortmass formulieren und über einen Utility Tree gewichten.
    • Anwendungsklassen als Anforderungsprofile R(a) charakterisieren -- Gewichte, Workload-Shape und regulatorische Knock-out-Constraints.

  3. Architektur-Patterns beherrschen und ihre Fähigkeitsprofile herleiten:

    • Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal, Microservices, Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, Ursprungsproblem, Taktiken und Fähigkeitsprofil C(p) erklären und vergleichen.
    • Open-Source-Referenzsysteme im Quellcode inspizieren und Engineering-Konsequenzen (Build, Test, CI/CD, Betrieb, Teamstruktur) ableiten.

  4. Die Passung berechnen, begründen und verteidigen:

    • Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und Workload-Shape-Gate, Veto mit dokumentierten Mitigationen, ordinale Rangbildung mit Sensitivitätsanalyse) und die 7×10-Matrix als Explikationsmodell nutzen.
    • Hybride als Normalfall erkennen und Evolutionspfade planen (Strangler Fig).

  5. Verteilte Ränder robust gestalten:

    • Schnittstellen und Kontrakte entwerfen und versionieren; synchrone und asynchrone Kommunikationsmuster situationsgerecht einsetzen.
    • Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback, Dead-Letter Queue, idempotenter Consumer) gegen unzuverlässige externe Abhängigkeiten einsetzen.

  6. AI als Systemkomponente integrieren (Achse B):

    • AI-Komponenten hinter stabilen Schnittstellen kapseln (Port, LLM-Gateway, Anti-Corruption-Layer) und deterministische von nicht-deterministischen Systemteilen strikt trennen.
    • Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren und ihre Ökonomie bewerten; Domänenwissen (Ontologie) zugleich als Architektur-Vertrag und als Halluzinations-Guard einsetzen.
    • Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge, Domänen-Axiome) und als CI-Gate betreiben.

  7. Entscheidungen messbar machen, betreiben und weiterentwickeln:

    • Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in CI/CD (Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und Observability (Logging, Metriken, Tracing).
    • Token-Kosten und Latenz messen und optimieren (Caching, Batching, Model-Routing); Conway's Law und Team Topologies als dritte Passungsdimension berücksichtigen.

  8. AI als Werkzeug professionell einsetzen sowie Ethik und Verantwortung reflektieren (Achse A):

    • Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten und agentische Werkzeuge mit ADRs als Kontext und Tests als Leitplanken einsetzen; Ausgaben kritisch prüfen und verantworten.
    • Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen im sensiblen Anwendungskontext Finanzdaten bewerten; neue Bedrohungsklassen (Prompt Injection, OWASP LLM Top 10) im Threat-Modeling berücksichtigen.

Leistungsnachweis

Anteil Komponente
50 % Praxisprojekt (modulare AI-gestützte Plattform, Gruppenarbeit) -- Requirements-Dossier (A1, Woche 3), Architektur-Dossier mit ADR und Messvertrag (A2, Woche 7), Implementierung, Abschlusspräsentation mit Architektur-Verteidigung (A3, Woche 14)
50 % Schriftliche Modulschlussprüfung, 60 Minuten, open book (Skript und eigene Unterlagen in Papierform), closed internet -- Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse, keine reine Faktenabfrage

Unterrichtssprache

Deutsch mit englischen Unterlagen und Papern (Skript, Folien, Übungen und Prüfung in Englisch).

Eingangskompetenzen

Sicherer Umgang mit Python, Versionsverwaltung (Git) und grundlegenden Software-Engineering- Prinzipien (Clean Code, SOLID). Grundverständnis von LLMs, Prompting und RAG aus AISE501. Grundlagen in Statistik und maschinellem Lernen.

Inhalte

Der Kurs umfasst 14 Sitzungen zu je 4 Lektionen, dem Vorlesungsskript (Teile I--V) folgend. Das klassische, architektur-zentrierte Software Engineering bildet die Substanz (~60 %); AI erscheint als kurze AI-Linse an den einzelnen Themen sowie in zwei eigenen Sitzungen zur AI-Dimension (Sitzungen 12 und 13). Ein durchgehendes Projekt verschränkt beide Achsen. Wochen 1--7 sind Designphase (2 L Vorlesung + 2 L Übung), Wochen 8--13 Implementierungsphase (3 L Vorlesung + 1 L Standup/Coaching), Woche 14 Synthese und Präsentationen (1 L + 3 L).

1. Das Entscheidungsproblem und das Framework (Teil I)

  • Inhalte: Vier Produktionssysteme, zwei Fakten (Stack Overflow, Monzo, Segment, Prime Video); Architektur als schwer umkehrbare Entscheidungen; die fünf Framework-Elemente (R(a), C(p), fit, ADR, Messvertrag); die Annahmen A1--A6; ADR/MADR und C4.

  • AI-Linse (A): Ein Agent erstellt ADR-Entwürfe -- der Mensch verantwortet die Entscheidung.

  • Projekt: Kickoff -- Teams, Repository und Werkzeug-Setup, Domänenverständnis, Ontologie-Skizze, rohe Stakeholder-Wünsche.

2. Das Koordinatensystem: zwölf Profildimensionen (Teil I)

  • Inhalte: Die zwölf Dimensionen mit Antwortmass und Messinstrument; ISO/IEC 25010:2023 als Vokabular; ASR und Quality Attribute Workshop; sechsteilige Qualitätsszenarien; Utility Tree → Gewichte; R(a) aus Gewichten, Workload-Shape und Constraints.

  • AI-Linse (B): Nicht-Determinismus, Latenz und Kosten als Dimension D12 der AI-Integrierbarkeit.

  • Projekt: Requirements-Workshop I -- Qualitätsszenarien mit Antwortmass, Utility Tree beginnen.

3. Nachfrage, Angebot, Passung: das formale Modell (Teil I)

  • Inhalte: C(p) über Taktiken; das dreistufige, nicht-kompensatorische Matching-Verfahren am Mini-Match des Kursprojekts (C10 gegen L, MM, MS); warum keine gewichtete Summe; ADR/MADR mit Messvertrag als Abschluss.

  • AI-Linse (A/B): Der LLM-Provider hinter einem Port; ein Agent entwirft den MADR, ein Mensch zeichnet ihn.

  • Projekt: Requirements-Workshop II -- R(Plattform) finalisieren, Ontologie als Vertrag. Abgabe A1 (Ende Woche 3).

4. Patterns I: ein Deployable (Teil II)

  • Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je Ursprungsproblem, Topologie, Architecture Quantum, Fähigkeitsprofil, Anti-Patterns; Modulgrenzen als CI-Gegenstand (Spring Modulith, import-linter, ArchUnit, Packwerk).

  • AI-Linse (B): Der Port als Anti-Corruption-Layer, der die LLM-Komponente austauschbar macht.

  • Projekt: Architekturstudium I -- healthchecks (Django), Apache Fineract und Cosmic Python im Code; C4-Kontext- und Container-Entwurf.

5. Patterns II: verteilte Topologien (Teil II)

  • Inhalte: Microservices und Event-Driven Architecture; Sagas vs. ACID; der verteilte Monolith; Broker- vs. Mediator-Topologie; die sieben Resilienz-Grundmuster; Fallstudien (Netflix, Uber DOMA, Monzo, Segment-Rückbau).

  • AI-Linse (B): Ein LLM-Aufruf als unzuverlässiger Remote-Call; Queues absorbieren Latenz, Rate-Limits und Ausfälle.

  • Projekt: Architekturstudium II -- Ränder entwerfen (Ingestion-Queue, Resilienz gegen API-Ausfall), Service-Kontrakte skizzieren, Matrix-Vorfilter.

6. Patterns III: Batch und Serverless, Verallgemeinerung -- und die eigene Klasse C10 (Teil II; Teil III)

  • Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; Stepping Back -- Architecture Quantum, "Partitioning beats distribution", konsolidierte Fähigkeitstabelle, Ausblick Agenten-Orchestrierung; danach C10, die AI-native Advisory-Plattform (Klasse des Projekts) mit dem Spiegelpaar C1/C2 als Vorschau.

  • AI-Linse (B): Serverless und Pipelines als natürliche Heimat von Ingestion und Evaluation.

  • Projekt: Der Match -- drei Stufen für die eigene Plattform, Architekturentscheid, ADR-Entwurf.

7. Die Passung: drei Fälle, das Verfahren, die Matrix (Teil IV)

  • Inhalte: Drei durchgerechnete Matches (C6 Shape-Gate, C1 Veto und Mitigationen, C2 ordinale Lesung mit Sensitivitätsanalyse); das Verfahren im Allgemeinen; die 7×10-Matrix lesen; Einführung des Messvertrags (Fitness Functions, DORA).

  • AI-Linse (A/B): Der Messvertrag als Betriebslizenz auch für agentisch erzeugten Code.

  • Projekt: Lösungsdesign finalisieren (Service-Schnitt, Kontrakte, Walking-Skeleton-Plan, Messvertrag mit Zahlen); Design-Review-Gate, Abgabe A2 (Ende Woche 7).

8. Anwendungsklassen I: C1--C5 (Teil III)

  • Inhalte: Anwendungsklassen als ASR-Bündel; C1 Kernbanking, C2 Social/Content, C3 Back-Office, C4 ERP, C5 E-Commerce -- Herausforderungen mit Zahlen und Regulatorik, Anforderungsprofile und die reale Architekturwahl (LMAX vs. Monzo, Instagram, Shopify, Fineract).

  • AI-Linse (B): Die Latenzklasse, nicht die Genauigkeit, entscheidet über die Platzierung einer AI-Komponente; Agenten schlagen vor, deterministische Services entscheiden und buchen.

  • Projekt: Sprint 1 -- Walking Skeleton beginnen (MarketDataService, minimaler ResearchAgent, stabile API).

9. Anwendungsklassen II: C6--C9 und zehn Profile nebeneinander (Teil III)

  • Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging; die dritte Konsistenzsemantik (Reproduzierbarkeit, Freshness-Kontrakt); zehn Profile nebeneinander mit fünf klassenübergreifenden Beobachtungen.

  • AI-Linse (B): Text-to-SQL nur auf der governierten semantischen Schicht; keine LLM-Aufrufe pro Event im Stream.

  • Projekt: Coaching; Walking Skeleton fertigstellen -- Meilenstein: läuft End-to-End.

10. Hybride, Evolution und das achtstufige Entscheidungsverfahren (Teil IV)

  • Inhalte: Hybride als Normalfall; Fit als Funktion der Zeit; Migrationsstrategien (MonolithFirst, Strangler Fig, Sacrificial Architecture; Segment, Prime Video, Shopify); das achtstufige Verfahren an ADR-007; Matrix-Zeilenbegründungen.

  • AI-Linse (B): Die AI-Schicht als bewusst ersetzbare Sacrificial Architecture hinter einem Port.

  • Projekt: Coaching; deterministische Services (Performance, Risk, Optimization) mit exakten Tests gegen die Referenzvektoren.

11. Der Messvertrag, Conway's Law und die Grenzen der Theorie (Teil IV)

  • Inhalte: Fitness Functions in CI/CD (Taxonomie, drei Instrumentenfamilien); die vier DORA-Metriken und der Kopplungs-Befund; Kostenverlauf von Änderungen (Boehm vs. Menzies); Conway's Law und Team Topologies; sechs Grenzen der Theorie.

  • AI-Linse (A/B): Eval-Harness-Pass-Rate und Token-Budget als neue Fitness-Function-Typen mit alter Mechanik.

  • Projekt: Coaching; Resilienz auf allen externen Aufrufen, verifizierte Graceful Degradation -- Meilenstein: deterministischer Kern vollständig getestet und resilient.

12. AI-Dimension I: Achse A -- Evidenz und Konsequenzen; Achse B -- Grundlagen (Teil V)

  • Inhalte: Zwei widersprüchliche RCTs (Copilot +55.8 % vs. METR −19 % samt Wahrnehmungslücke) und ihre Auflösung; der Verifikations-Engpass; ADRs und Agenten-Instruktionsdateien als Kontrollschnittstelle; Achse B: der Sentiment-Call falsch und richtig verdrahtet, drei Komponententypen, LLM-Gateway-Referenzarchitektur, Eval-Harness-Grundlagen.

  • Projekt: Coaching; AdvisorAgent mit 2--3 Sub-Agenten hinter dem Gateway (Pflichtteil), Ontologie-Guard auf allen Insights aktiv.

13. AI-Dimension II: Bedrohungen, verschobene Matrix, Orchestrierung -- und Synthese (Teil V)

  • Inhalte: OWASP LLM Top 10 und Prompt Injection als Architekturproblem; EU AI Act als Knock-out-Constraint; die fünf Zellverschiebungen der Matrix; Agenten-Orchestrierung als achtes, emergentes Kompositionsmuster und die Ökonomie der Autonomie; Synthese und Prüfungsorientierung.

  • Projekt: Coaching; Eval-Harness als CI-Gate, Kosten- und Latenz-Dashboard, Threat-Model, Hardening, Topologie-ADR; Kür: autonomes Planning, Self-Repair, Model-Routing -- Meilenstein: Eval-Harness im CI, Guard aktiv, Kosten-Observability.

14. Synthese, Präsentation und Architektur-Verteidigung

  • Inhalte (1 L): Die Theorie-Pipeline in einem Satz; eine Disziplin an zwei Bindungsstellen; Prüfungsorientierung und Q&A -- kein neuer Stoff.

  • Reflexion: Wo half und wo schadete die AI -- im Bauen (A) und im System (B)?

  • Projekt (3 L): Präsentationen, Architektur-Verteidigung und Peer-Reviews -- Abgabe A3.

Praxisprojekt: AI-Augmented Portfolio Intelligence Platform

Als durchgehendes Gruppenprojekt entwickeln die Studierenden eine modulare Analyse- und Advisory-Plattform für Aktienportfolios (kein Trading, kein echtes Geld -- ausschliesslich Analyse und Empfehlung). Die Plattform ist im Skript als zehnte Anwendungsklasse (C10) durchmodelliert; ob ihre Services als ein Deployable oder als mehrere ausgeliefert werden, ist die Architekturentscheidung der Teams in Woche 6, die in Woche 14 verteidigt wird. Die Plattform:

  • bezieht strukturierte externe Daten (Börsenkurse, z. B. via Yahoo Finance) -- mit Live-API und verpflichtendem Cache-/Snapshot-Fallback;

  • bezieht unstrukturierte externe Daten (Firmen-News, Web-Berichte) und wandelt sie über eine AI-Komponente in strukturierte, gegen die Ontologie validierte Insights um;

  • berechnet Risiko-, Performance- und Portfolio-Optimierungs-Kennzahlen (Formeln und Testvektoren werden vorgegeben; die Lernleistung ist das Engineering darum herum);

  • stellt die Funktionalität API-first bereit, mit einem dünnen Dashboard (z. B. Streamlit) nur zur Demonstration.

Zentrale Architekturregel: Agents propose; deterministic services decide and book. Die AI-Agenten dürfen quantitative Werte ausschliesslich über die deterministischen Services beziehen und interpretieren -- niemals selbst berechnen. Diese Trennung von deterministischen und nicht-deterministischen Systemteilen ist die prüfbare Manifestation von "AI engineering-tauglich machen" und wird bewertet.

Beispielhafte Service-Landschaft (Bounded Contexts): MarketData-Service, News-Ingestion, Risk-Service, Performance-Service, Optimization-Service, Portfolio-Service sowie ein orchestrierender Advisor-Agent mit spezialisierten Sub-Agenten (Research-, Risk-, Optimization-Agent) hinter einem einzigen LLM-Gateway. Eine Ontologie der Anlagedomäne (Asset-Klassen, Sektoren, Regeln) dient als Architektur-Vertrag und als Halluzinations-Guard.

Meilensteine: M1 Requirements und Ontologie (Wochen 1--3, Abgabe A1) · M2 Architekturentscheid und Lösungsdesign (4--7, Abgabe A2 mit Design-Review-Gate) · M3 Walking Skeleton (8--9) · M4 deterministischer Kern und Resilienz (10--11) · M5 Multi-Agent-Orchestrierung, Evaluation und Hardening (12--13) · M6 Präsentation und Architektur-Verteidigung (14, Abgabe A3).

Abstufung Pflicht / Kür:

  • Pflicht (bestehensrelevant): aus der Ontologie abgeleitete Architektur mit ADRs und C4-Sicht; vollständig und exakt getestete deterministische Services; orchestrierter Advisor-Agent mit 2--3 Sub-Agenten über klare Service-Kontrakte; Ontologie-Guard; Resilienz gegen Ausfall externer Datenquellen; Eval-Harness für die AI-Komponente; Observability für Kosten und Latenz über das einzige LLM-Gateway; der Messvertrag aus A2 (Modulgrenzen-Check, Eval-Schwelle, Token-Budget) in CI verdrahtet.

  • Kür (für Spitzennoten): autonomes Planning (der Advisor entscheidet selbst über Tool- und Sub-Agent-Aufrufe), Self-Repair-Loops, Model-Routing, Deployment mit CI/CD und Tracing.

Lehr- und Lernmethoden

Lehrtechniken: Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops.

Lernaktivitäten: Studium des Skripts und der Literatur, Inspektion realer Open-Source-Systeme, Übungsaufgaben, Bearbeiten von Problemen und deren Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.

Lehrmethode: Präsentation; Einzel-, Partner- und Gruppenarbeit; E-Learning.

Struktur

Element Stunden
Online-, Hybrid- oder Präsenzunterricht 42 h
Selbststudium (Skript, Lektüre und Projekt) 78 h
Total 120 h (4 ECTS)

Literatur

Leitmedium:

  • AISE502 Lecture Notes -- A Theory of Architecture--Application Fit, F. Herzog, Fachhochschule Graubünden, 2026 (englisch; wird abgegeben).

Methodische Hauptquellen der Theorie:

  • L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, 4. Aufl., 2021.

  • M. Richards, N. Ford: Fundamentals of Software Architecture, 2. Aufl., O'Reilly, 2025.

  • N. Ford, R. Parsons, P. Kua, P. Sadalage: Building Evolutionary Architectures, 2. Aufl., O'Reilly, 2022.

  • N. Forsgren, J. Humble, G. Kim: Accelerate, IT Revolution, 2018.

Begleitend:

  • I. Sommerville: Modernes Software-Engineering, Pearson, 2020 (deutschsprachiger Anker).
  • S. Newman: Building Microservices, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader).
  • Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR).