Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist W-JAX Together?
W-JAX Together ist ein neues Diskussionsformat der W-JAX, das den Austausch über Themen aus dem Konferenzprogramm vertieft. Teilnehmende, Speaker und Expert können offene Fragen diskutieren, eigene Erfahrungen einbringen und unterschiedliche Perspektiven miteinander vergleichen.
2. Wie funktioniert W-JAX Together?
W-JAX Together nutzt moderierte Gesprächsformate und festgelegte Spielregeln, um einen strukturierten und möglichst partizipativen Austausch zu ermöglichen. Je nach Thema kommen unterschiedliche Methoden zum Einsatz, die regeln, wie Themen ausgewählt werden, wer zu Wort kommt und wie Ergebnisse zusammengeführt werden.
3. Welche Methoden werden bei W-JAX Together eingesetzt?
Bei W-JAX Together kommen unter anderem Lean Coffee, UX Fishbowl und Liberating Structures zum Einsatz. Zu den beschriebenen Methoden gehört außerdem 1-2-4-All, bei der Teilnehmende zunächst allein über eine Frage nachdenken und ihre Gedanken anschließend in immer größeren Gruppen zusammenführen.
4. Was ist Lean Coffee und wie wird es bei W-JAX Together genutzt?
Bei einem Lean Coffee bringt die Gruppe selbst Themen für die Diskussion ein und priorisiert sie gemeinsam. Dadurch bestimmen die Teilnehmenden mit, welche Fragen und Erfahrungen im Rahmen von W-JAX Together ausführlicher diskutiert werden.
5. Welchen Nutzen hat W-JAX Together für den Arbeitsalltag?
Die bei W-JAX Together eingesetzten Methoden können auch in eigenen Teams und Projekten verwendet werden. Wer beispielsweise Lean Coffee, eine Fishbowl oder eine Liberating Structure auf der W-JAX erlebt, erhält damit praktisches Handwerkszeug für strukturierte und partizipative Diskussionen im Arbeitsalltag.
6. Wer kann an W-JAX Together teilnehmen?
An W-JAX Together können Teilnehmende der W-JAX mitmachen, die ein Thema weiterdiskutieren, eine eigene Frage einbringen oder einer Diskussion zunächst zuhören möchten. Eigene Erfahrungen, Beiträge und Ideen sind ausdrücklich erwünscht; die Formate finden parallel zu den Vorträgen der Hauptkonferenz statt.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist Spring AI und wofür wird es verwendet?
Spring AI abstrahiert die APIs und Konfigurationsparameter verschiedener LLM-Anbieter. Interfaces wie ChatClient und ChatModel bieten ein einheitliches API und erleichtern dadurch den Wechsel zwischen Modellen und Anbietern.
2. Wie ruft man ein LLM mit Spring AI 2.0 auf?
Für den Aufruf eines LLM benötigt eine Spring-Boot-Anwendung einen modellspezifischen Spring-Boot-Starter und die entsprechende Modellkonfiguration. Über ChatClient lässt sich anschließend ein Prompt erstellen und entweder mit stream() reaktiv oder mit call() blockierend ausführen.
3. Was ist der Unterschied zwischen System-Prompt und User-Prompt?
Der System-Prompt definiert die Rolle des Modells und allgemeine Vorgaben wie Schreibstil, Zielgruppe oder Einschränkungen. Der User-Prompt enthält dagegen die konkrete Anfrage, die das LLM bearbeiten soll.
4. Wie funktioniert Chat Memory in Spring AI?
Ein LLM ist zustandslos und kennt vorherige Nachrichten nicht automatisch. Spring AI speichert deshalb über Chat Memory relevante Nachrichten einer Konversation und fügt sie bei späteren Modellaufrufen erneut dem Prompt hinzu.
5. Was sind Advisors in Spring AI?
Advisors bilden eine Verarbeitungskette um den Aufruf eines ChatModel. Sie können einen Prompt vor dem Modellaufruf verändern und die erzeugte Antwort anschließend prüfen oder anpassen, wodurch sich Funktionen wie Chat Memory, Logging oder Guardrails von der eigentlichen Anwendungslogik trennen lassen.
6. Wie funktioniert Structured Output mit Spring AI?
Mit Structured Output kann Spring AI eine LLM-Antwort direkt in einen definierten Java-Typ überführen. Dafür erzeugt Spring AI aus dem gewünschten Typ ein JSON-Schema, das die erwartete Antwortstruktur beschreibt, und wandelt das Modellergebnis anschließend mit Jackson in das entsprechende Java-Objekt um.
🔍 Frequently Asked Questions (FAQ)
1. Wird AI Softwareentwickler:innen ersetzen?
Nach Venkat Subramaniam macht ein leistungsfähigeres Werkzeug Softwareentwickler:innen nicht überflüssig. Er verweist auf Offshoring und die Automatisierung von Tests als Beispiele dafür, dass neue Technologien Aufgaben verändern und erweitern, statt ganze Berufsbilder verschwinden zu lassen. AI verändert daher die Art, wie Software entwickelt wird, während technisches Urteilsvermögen und Erfahrung weiterhin entscheidend bleiben.
2. Welche Rolle spielt AI in der Softwareentwicklung?
AI kann Aufgaben wie das Schreiben von Code oder das Erstellen von Prototypen deutlich beschleunigen. Subramaniam zufolge liefert AI vor allem Geschwindigkeit, während Entwickler:innen weiterhin entscheiden müssen, was gebaut werden soll, wie Ergebnisse zu bewerten sind und ob eine Lösung den technischen Anforderungen entspricht.
3. Warum ist Disziplin bei AI-gestützter Softwareentwicklung wichtig?
Subramaniam bringt es auf die Formel: Geschwindigkeit plus Disziplin ist Agilität, Geschwindigkeit ohne Disziplin kann zur Katastrophe werden. Weil AI Software sehr schnell erzeugen kann, müssen Entwickler:innen umso stärker darauf achten, dass Lösungen zuverlässig, sicher, performant und nachhaltig sind.
4. Welche Fähigkeiten brauchen Softwareentwickler:innen im Zeitalter von AI?
Für Subramaniam sind vor allem Grundlagen und kritisches Denken entscheidend. Entwickler:innen müssen verstehen, was produktive Software in Bezug auf Performance, Sicherheit, Zuverlässigkeit und Resilienz benötigt, und gleichzeitig beurteilen können, ob ein von AI erzeugtes Ergebnis tatsächlich sinnvoll ist oder ob es einen besseren Ansatz gibt.
5. Wie kann AI technische Entscheidungen und Prototyping verbessern?
AI ermöglicht es, Ideen wesentlich schneller als früher in funktionierende Prototypen zu überführen. Subramaniam beschreibt im Interview, wie er eine Kundenidee innerhalb von zehn Minuten mit AI umsetzte, sodass beide Seiten die Lösung konkret beurteilen und anschließend schnell verwerfen konnten. So können technische Diskussionen stärker auf funktionierenden Modellen statt auf theoretischen Argumenten basieren.
6. Warum müssen Entwickler:innen AI-generierten Code kritisch prüfen?
Subramaniam zufolge ersetzt AI die Ausführung bestimmter Aufgaben, nicht aber das notwendige Wissen und die Verantwortung der Entwickler:innen. Sie müssen weiterhin erkennen können, wann eine Lösung fehlerhaft ist, technische Anforderungen nicht erfüllt oder ein besserer Ansatz möglich wäre. Deshalb plädiert er dafür, AI-Ergebnisse konsequent und besonders kritisch zu überprüfen.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist AOT-Caching mit Project Leyden?
Project Leyden verlagert wiederholbare JVM-Arbeit aus dem Startpfad in einen kontrollierten Trainings- und Build-Kontext. Dabei werden Informationen über geladene und gelinkte Klassen sowie, ab JDK 25, Profiling-Daten heißer Methoden in einem AOT-Cache gespeichert. Beim späteren Start kann die JVM diese Informationen wiederverwenden, ohne ihre dynamischen Eigenschaften aufzugeben.
2. Wie beschleunigt Project Leyden den Start von Java-Anwendungen?
Der AOT-Cache reduziert Arbeit, die sonst bei jedem JVM-Start erneut ausgeführt werden müsste, beispielsweise beim Laden und Linken von Klassen. Dadurch können sowohl die Zeit bis zur Betriebsbereitschaft (t_ready) als auch der anschließende Warm-up bis zum stabilen Lastzustand (t_steady) sinken. Für Spring PetClinic beschreibt der Artikel beispielsweise eine Reduktion der Startzeit von rund drei auf etwa eine Sekunde durch CDS und AOT-Cache.
3. Wie unterscheidet sich Project Leyden von GraalVM Native Image und CRaC?
Project Leyden optimiert den Start innerhalb der klassischen JVM und behält deren dynamisches Verhalten bei. GraalVM Native Image erzeugt dagegen ein natives Binary mit sehr schnellem Kaltstart, verwendet dafür aber eine Closed-World-Annahme und benötigt zusätzliche Konfiguration für dynamische Java-Features. CRaC erreicht schnelle Restores über Prozess-Snapshots, bringt jedoch zusätzliche Linux-, CRIU- und Snapshot-Komplexität mit sich.
4. Wie funktioniert AOT-Caching mit Spring Boot?
Für Spring Boot sollte die Anwendung zunächst in ein extrahiertes Layout überführt werden, da ein klassisches Fat JAR für den AOT-Cache-Pfad ungünstig ist. Ein reproduzierbarer Trainingslauf kann anschließend mit spring.context.exit=onRefresh und -XX:AOTCacheOutput bis zum Context Refresh ausgeführt werden. In der Runtime wird der erzeugte Cache mit -XX:AOTCache=... geladen, ohne dass dafür Cache-spezifischer Anwendungscode erforderlich ist.
5. Welche Bedingungen müssen AOT-Training und Runtime erfüllen?
AOT-Caches sind eng an ihre technische Umgebung gebunden. Training und Runtime müssen unter anderem hinsichtlich JDK, Hardware-Architektur und Artefaktstruktur konsistent sein; außerdem sollten reproduzierbare JAR-Inhalte und Timestamps verwendet werden. Änderungen an Code, Dependencies, JDK oder Build-Artefakten erfordern deshalb einen neuen Cache.
6. Wann lohnt sich AOT-Caching für Java nicht?
AOT-Caching lohnt sich vor allem dann, wenn der Start-up-Pfad reproduzierbar und im Verhältnis zur Lebensdauer einer Instanz relevant ist. Sehr kurzlebige CLI- oder Batch-Anwendungen profitieren häufig zu wenig, während bei selten gestarteten, langlebigen Monolithen CDS ausreichen kann. Für Serverless-Anwendungen mit extremen Sub-Sekunden-Anforderungen nennt der Artikel GraalVM Native Image als passendere Alternative.
Author
🔍 Frequently Asked Questions (FAQ)
1. Warum wird taktisches DDD durch KI-Coding-Agents wichtiger?
KI-Coding-Agents können in kurzer Zeit syntaktisch korrekten und lauffähigen Code erzeugen. Bei ungenauen Spezifikationen schließen sie fachliche Lücken jedoch möglicherweise auf statistisch plausible, aber fachlich falsche Weise. Taktisches DDD verankert Geschäftsregeln und Invarianten deshalb direkt in der Struktur des Codes.
2. Welche Rolle übernehmen Entwickler bei KI-gestützter Softwareentwicklung?
Entwickler schreiben zunehmend weniger einzelne Codezeilen und übernehmen stärker die Rolle von Architekten und Prüfern. Sie müssen Spezifikationen präzisieren und bewerten, ob generierter Code fachlich korrekt, architektonisch konsistent und langfristig wartbar ist. Dafür wird ein tiefes Verständnis der Domäne und des Softwaredesigns wichtiger als die reine Beherrschung der Programmiersyntax.
3. Warum reicht eine hohe Testabdeckung für KI-generierten Code nicht aus?
Eine hohe Testabdeckung kann Fehler sichtbar machen, aber kein schlechtes Softwaredesign reparieren. Ein fehlgeschlagener Test zeigt zunächst nur ein Symptom und beantwortet nicht, ob ein technisches Detail oder das zugrunde liegende fachliche Modell fehlerhaft ist. Ohne eine nachvollziehbare Code-Struktur bleiben strukturelle Erosion und logische Inkonsistenzen schwer erkennbar.
4. Warum bleibt der Code die stabilere Source of Truth als die Spezifikation?
Die Spezifikation beschreibt die beabsichtigte Funktionsweise eines Systems, während der Code die tatsächlich ausgeführte Laufzeitrealität bestimmt. Spezifikationen können mehrdeutig oder veraltet sein, und generative Modelle liefern nicht vollständig deterministische Ergebnisse. Typisierter und kompilierter Code kann fachliche Regeln dagegen durch Value Objects, Aggregates, Assertions und Invarianten verbindlich durchsetzen.
5. Wie unterstützt taktisches DDD die Arbeit von Coding-Agents?
Taktisches DDD definiert klare Verantwortungsgrenzen und kapselt Fachlogik in Bausteinen wie Aggregates, Value Objects und Domain Services. Ubiquitous Language und Intention-Revealing Interfaces geben dem Coding-Agent semantisch eindeutige Vorgaben. Gleichzeitig reduzieren kleine, klar abgegrenzte Kontexte die Gefahr von Kontextverlust und unnötigen Agenten- und Werkzeugzyklen.
6. Für welche Softwareprojekte eignet sich taktisches DDD besonders?
Taktisches DDD eignet sich besonders für komplexe, langlebige oder kritische Systeme, deren Geschäftsregeln und Datenintegrität dauerhaft geschützt werden müssen. Dazu gehören beispielsweise Finanzsysteme, Logistik-Plattformen, Versicherungsanwendungen, E-Government-Systeme und Lösungen für den Energiesektor. Für einfache Webanwendungen, Daten-Pipelines oder kurzlebige Prototypen kann der zusätzliche Modellierungsaufwand dagegen unverhältnismäßig sein.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was bedeutet „Design before Implementation“ in der Softwareentwicklung?
„Design before Implementation“ beschreibt den Ansatz, fachliche Abläufe und Systemverhalten zunächst präzise zu spezifizieren, bevor Code geschrieben wird. Ziel ist es, Missverständnisse zu vermeiden und eine belastbare Grundlage für Entwicklung, Tests und spätere Änderungen zu schaffen.
2. Warum werden Spezifikationen durch KI wichtiger statt überflüssig?
Große Sprachmodelle können Code generieren, benötigen dafür jedoch klare und strukturierte Vorgaben. Je komplexer ein Softwaresystem ist, desto wichtiger werden präzise Spezifikationen, damit KI-Systeme konsistente und fachlich korrekte Ergebnisse liefern.
3. Was ist Spec-driven Development?
Spec-driven Development ist ein Entwicklungsansatz, bei dem Spezifikationen die zentrale Grundlage für Implementierung, Tests und Wartung bilden. Anstatt direkt aus Anforderungen zu programmieren, werden Abläufe und Geschäftsregeln zunächst in strukturierter Form beschrieben und anschließend umgesetzt.
4. Welche Vorteile bieten detaillierte Spezifikationen für Enterprise-AI-Projekte?
Detaillierte Spezifikationen schaffen ein gemeinsames Verständnis zwischen Fachbereichen, Entwicklern und Testern. Sie reduzieren Fehlinterpretationen, ermöglichen frühzeitiges Feedback und liefern sowohl Menschen als auch KI-Systemen eine zuverlässige Basis für die Implementierung.
5. Was sind Aktogramme und wofür werden sie eingesetzt?
Aktogramme sind eine Weiterentwicklung klassischer Struktogramme für die Spezifikation von Softwareabläufen. Sie verbinden gute Lesbarkeit für Menschen mit einer klaren Struktur, die auch von KI-Systemen maschinell ausgewertet werden kann.
6. Kann KI selbst Softwarearchitektur und Spezifikationen erstellen?
KI kann bei der Analyse, Validierung und Überarbeitung von Entwürfen unterstützen. Die eigentliche Entwurfsarbeit erfordert jedoch fachliches Verständnis, analytisches Denken und die Abstimmung zwischen Stakeholdern. Deshalb bleiben Menschen für Architekturentscheidungen und Spezifikationen zentral.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was ist Golden Master Testing und woher kommt der Name?
Der Begriff „Golden Master" stammt aus der Softwareverteilung – die finale, freigegebene Version eines Produkts. Im Testing-Kontext bezeichnet er einen Snapshot des aktuellen Systemverhaltens: Für definierte Eingaben wird die Ausgabe aufgezeichnet und als Referenz für zukünftige Vergleiche genutzt.
2. Wann sollte ich Golden Master Testing einsetzen?
Immer dann, wenn ein System migriert oder refaktoriert werden muss, aber fachliches Wissen fehlt – weil Dokumentation veraltet ist, Domänenexperten das Unternehmen verlassen haben oder Tests kaum vorhanden sind.
3. Wie unterscheidet sich Golden Master Testing von klassischen Unit- oder Integrationstests?
Klassische Tests prüfen, ob ein Ergebnis fachlich korrekt ist. Golden-Master-Tests prüfen nur, ob sich das Ergebnis verändert hat. Sie setzen kein fachliches Verständnis voraus – das System wird als Blackbox behandelt.
4. Wo setze ich Golden-Master-Tests am besten an?
An öffentlich sichtbaren Schnittstellen: externe APIs, Batch-Programme, Dateischnittstellen oder fachliche Services. Interne Hilfsfunktionen sind ungeeignet – sie ändern sich bei Refactorings zwangsläufig und machen Tests fragil.
5. Was tue ich, wenn mein System nichtdeterministisches Verhalten zeigt?
Instabile Ausgaben wie Zeitstempel, zufällige IDs oder schwankende Sortierungen müssen aktiv neutralisiert werden – zum Beispiel durch Maskierung oder feste Referenzwerte. Ein instabiler Golden Master ist gefährlicher als keiner, weil er falsche Sicherheit vermittelt.
6. Kann KI beim Aufbau von Golden-Master-Tests helfen?
Ja, sehr effektiv. KI kann Legacy-Code und Schnittstellen analysieren, typische Eingaben ableiten und Testfälle skaliert generieren – auch für selten genutzte, aber kritische Ablaufpfade. Die fachliche Bewertung von Abweichungen bleibt jedoch Aufgabe des Teams.
7. Wann kann ich Golden-Master-Tests wieder abschaffen?
Sobald fachliche Regeln explizit verstanden, modelliert und durch gezielte Unit- oder Integrationstests abgesichert sind. Golden-Master-Tests sollten schrittweise ersetzt werden – ihr größter Erfolg ist, dass sie sich selbst überflüssig machen.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was bedeutet Observability im Kontext von LLM-Anwendungen?
Observability beschreibt die Fähigkeit, den internen Zustand eines Systems allein durch seine externen Ausgaben zu verstehen. Für LLM-Anwendungen ist sie entscheidend, um Fehlerquellen sichtbar zu machen und das Verhalten komplexer, nichtdeterministischer Systeme nachvollziehen zu können.
2. Welche drei Säulen umfasst klassische Observability?
Die klassischen drei Säulen sind Metriken, Logs und Traces. Metriken geben aggregierte Zustandsdaten, Logs liefern detailreiche Ereignisinformationen, und Traces verfolgen Abläufe systemübergreifend von Anfang bis Ende.
3. Was ist OpenTelemetry und warum ist es für LLMs wichtig?
OpenTelemetry ist ein CNCF-Projekt zur Standardisierung von Telemetrie-Daten (Metriken, Logs, Traces). Es bietet eine einheitliche Instrumentierung und unterstützt mittlerweile spezifische Attribute für GenAI-Operationen wie Modellnamen, Tokenverbrauch und Operationstyp.
4. Welche LLM-Architekturen profitieren besonders von Observability?
Alle gängigen LLM-Architekturen – One-Shot, RAG, Function Calling und Agentic Workflows – profitieren von Observability. Je komplexer die Architektur, desto wichtiger wird die Nachvollziehbarkeit von Promptübergaben und verteilten Workflows.
5. Was leistet Langfuse als OTEL-Empfänger für LLM-Anwendungen?
Langfuse bietet LLM-spezifische Aufbereitung von Traces, unterstützt verschiedene LLM-Architekturen und ermöglicht eine Session-Übersicht. Es lässt sich einfach in Spring AI integrieren und visualisiert u.a. Promptdetails und Tool-Calls.
6. Was ist Promptfoo und wie unterstützt es LLM-Testing?
Promptfoo ist ein LLM-Testframework, das sowohl synthetische als auch realweltliche Prompts prüft. Es unterstützt deterministische und LLM-basierte Tests, ermöglicht Red Teaming und lässt sich via GitHub Actions in CI/CD-Pipelines integrieren.
7. Welche Tools helfen bei der PII-Anonymisierung im Tracing?
Für DSGVO-konformes Tracing eignen sich Tools wie DataFog oder Microsoft Presidio. Diese lassen sich via REST API integrieren und anonymisieren personenbezogene Daten vor dem Speichern.
Author
🔍 Frequently Asked Questions (FAQ)
1. Was sind Mixed Teams in IT-Projekten?
Mixed Teams bestehen aus Mitarbeitenden von Kunden- und Dienstleisterseite, die gemeinsam in einem Projektteam arbeiten. Ziel ist eine enge, interdisziplinäre Zusammenarbeit ohne künstliche organisatorische Trennung.
2. Welche Vorteile bieten Mixed Teams in agilen IT-Projekten?
Sie ermöglichen schnellere Entscheidungen, direkten Nutzerkontakt und fördern ein gemeinsames Verantwortungsgefühl. Diese Zusammenarbeit verbessert die Produktqualität und steigert die Motivation durch höhere Identifikation mit dem Projektziel.
3. Wie unterstützen Mixed Teams eine bessere Kommunikation?
Durch die direkte Zusammenarbeit können Entwickler:innen und Fachexperten schneller Feedback erhalten und auf Nutzerbedürfnisse reagieren. Das reduziert Missverständnisse und verkürzt Feedbackzyklen.
4. Welche rechtlichen Risiken bestehen bei Mixed Teams?
Es besteht das Risiko der Scheinselbstständigkeit oder illegalen Arbeitnehmerüberlassung. Um das zu vermeiden, müssen Rollen klar definiert, Weisungen an Externe vermieden und vertragliche Rahmenbedingungen rechtssicher gestaltet werden.
5. Wie kann ein Mixed Team effektiv gesteuert werden?
Durch klare Kommunikationsstrukturen, Rollenverteilungen (z. B. mittels RACI-Matrix) und regelmäßige Abstimmungen können Mixed Teams effizient arbeiten. Frühzeitig abgestimmte Prozesse sichern Transparenz und fördern das gemeinsame Projektverständnis.
