Live Vibe Coding Battle: Eine Java-App mit GitHub Copilot bauen

Dieser Stream war ein simples, aber nützliches Experiment: Catherine nutzte den vordefinierten Master Prompt in einem Schritt, ich nutzte den vordefinierten Split Prompt in sechs kleineren Schritten, und am Ende verglichen wir die Ergebnisse gegen dieselben CI-Gates. Die App selbst war ein kleiner Healthcare Assistant für Symptom-Analyse, KI-generierte Ratschläge und die Suche nach passenden Spezialisten.

Co-Speaker

Catherine Edelveis

DevRel bei BellSoft

Catherine war Teil dieser Live Coding Battle, um Prompting-Strategien unter strikten CI-Qualitäts-Gates in einem realen Java-App-Workflow zu vergleichen.

GitHubXBluesky

Setup des Battles

Das Repository brachte bereits eine strikte Evaluierungspipeline mit, deshalb ging es nie darum, möglichst schnell Code zu erzeugen. Es ging darum, Code zu erzeugen, der unter Druck standhält.

Quality-Gates im Stream:

• Apache Maven PMD Plugin, um Stilprobleme, Duplikate und typische Maintainability-Probleme zu finden.
• SpotBugs Maven Plugin, um mögliche Defekte wie Null-Handling-Probleme, falsche API-Nutzung und riskante Implementierungsmuster aufzudecken.
• JaCoCo Maven Plugin, um Testabdeckung zu messen und sichtbar zu machen, wie viel des generierten Codes tatsächlich ausgeführt wurde.
• Trivy, um das Projekt auf bekannte Schwachstellen in Abhängigkeiten und Build-Artefakten zu scannen.
• OWASP ZAP Baseline Scan, um einen leichten dynamischen Sicherheitscheck gegen die laufende Anwendung auszuführen.

Genau dieses Setup machte die Session nützlich, weil Copilot-Output an objektiven Checks gemessen wurde und nicht am ersten Eindruck.

Ergebnisse aus dem Livestream

GitHub-Action-Ergebnisse von One-Shot Prompt und Split Prompt.

Das Hauptergebnis war klar:

• der One-Shot Master Prompt erzeugte eine laufende Anwendung, aber das Abrufen der Ergebnisse scheiterte an internen Fehlern
• der Split-Prompt-Ansatz erzeugte eine laufende Anwendung
• statische Analyse und testbezogene Ergebnisse fielen klar zugunsten der Split Prompts aus

Wichtiger Kontext: Das war kein Fehler von Catherine. Das eigentliche Problem war die Komplexität des Prompts. Der Master Prompt wollte in einem Schritt zu viel erledigen, was Debugging und Korrekturen schwerer machte.

Kurzer Vergleich: Master Prompt vs Split Prompt

Hier ist der praktische Unterschied zwischen den beiden Ansätzen, die wir genutzt haben.

Die Kurzfassung: Der Master Prompt optimierte auf Vollständigkeit in einem Durchgang, die Split Prompts auf inkrementelle Korrektheit.

UI-Ergebnis (unerwartet)

Ein überraschender Teil des Streams war die UI-Qualität: Beide generierten Anwendungen sahen rau aus, obwohl wir Vaadin genutzt haben und Vaadin normalerweise solide Default-Stylings mitbringt. Wir konnten während der Session nicht vollständig erklären, warum beide UIs so schlecht aussahen.

Was tatsächlich besser funktioniert hat

Der Split-Prompt-Workflow veränderte zwei Dinge, die am meisten zählten:

• jeder Schritt ließ sich sofort validieren
• wir konnten nachvollziehen und reviewen, was das Modell geändert hatte, bevor wir weitergingen

Das gab mehr architektonische Kontrolle und machte es leichter, Copilot zu korrigieren, wenn selbstbewusst falscher Output entstand.

Genau deshalb ließ sich der Split-Ansatz leichter steuern und leichter vertrauen.

Warum die Qualitäts-Gates wichtig waren

Ohne automatisierte Checks hätte dieser Stream eine Weile so wirken können, als seien beide Ansätze irgendwie "okay".

Die CI-Gates machten die Unterschiede sichtbar:

• Codequalitätsprobleme wurden schnell von PMD und SpotBugs sichtbar gemacht
• Sicherheits- und Analyse-Checks verhinderten stille Regressionen mit Trivy und OWASP ZAP Baseline
• wir konnten Prompting-Stile über messbares Feedback vergleichen

Genau hier wird Vibe Coding real: Wenn der Code deine Guardrails nicht besteht, ist er nicht fertig.

Praktische Takeaways

• vermeide übergroße One-Shot-Prompts für mehrschichtige Java-Apps
• zerlege die Arbeit in kleinere Prompts mit klaren Akzeptanzkriterien
• führe statische Analyse und Tests nach jedem sinnvollen Schritt aus
• behandle KI-Output als Entwurf, der reviewt werden muss, nicht als Wahrheit
• optimiere im Entwicklungsprozess für Erklärbarkeit, nicht nur für Geschwindigkeit

Hilfreiche Links

• XDEV IntelliJ PMD Plugin

Abschließender Gedanke

Diese Session war eine gute Erinnerung daran, dass besseres Prompting nicht bedeutet, einfach einen längeren Prompt zu schreiben. Es geht darum, einen Workflow aufzubauen, in dem jeder Schritt klein genug ist, um validiert zu werden.

Der One-Shot Master Prompt brachte die App zwar zum Starten, scheiterte aber weiterhin beim internen Abrufen der Ergebnisse. Die Split-Prompt-Strategie lieferte den stabileren End-to-End-Flow und die besseren Qualitätssignale. Für produktionsorientierte Java-Teams ist das die stärkere Standardeinstellung.