Guided Coding statt Vibe Coding in Java

In dieser Live-Session war Kenny Pflug zu Gast, um mit mir über eine bewusstere Art zu sprechen, mit KI in Java zu arbeiten: Guided Coding.

Was die Session nützlich machte, war ihr klarer Fokus. Es ging nicht darum, ein KI-Tool möglichst viel Code erzeugen zu lassen. Es ging darum, einen Workflow zu bauen, in dem der Mensch die Kontrolle behält, die Architektur sichtbar bleibt und das Modell als Implementierungsmaschine innerhalb klarer Grenzen eingesetzt wird.

Co-Speaker

Kenny Pflug

Autor des Guided-Coding-Frameworks

Kenny war dabei, um die Prinzipien hinter Guided Coding zu erklären und zu zeigen, wie ein strukturierter, constraint-getriebener Workflow KI-gestützte Java-Entwicklung rigoros und wartbar halten kann.

GitHubLinkedInX

Warum diese Session wichtig war

Das Kernargument war simpel: Wenn du in professioneller Softwareentwicklung gute Ergebnisse mit KI willst, brauchst du mehr als einen Prompt und Glück.

Die Session kam immer wieder auf ein paar praktische Ideen zurück:

• Planung von der Implementierung trennen
• Grenzen definieren, bevor die KI Code schreibt
• Ergebnisse gegen die Architektur prüfen, nicht nur gegen Syntax
• Feedback-Loops wie Tests, Linter und Benchmarks nutzen
• systematisch refactoren statt Probleme reaktiv zu flicken

Diese Kombination gibt dem Ansatz seine Form. Die KI wird nicht wie ein autonomer Teamkollege behandelt. Sie wird wie ein schnelles System behandelt, das Richtung, Grenzen und Verifikation braucht.

Was Guided Coding in der Praxis bedeutet

Für mich war am nützlichsten, wie konkret das Framework wurde, sobald wir den Workflow Schritt für Schritt durchgesprochen haben.

1. Planung ist eine eigene Phase

Einer der stärksten Punkte der Session war die klare Trennung von Designarbeit und Codegenerierung.

Statt das Modell sofort etwas implementieren zu lassen, beginnt Guided Coding damit, den Plan explizit zu machen. Dazu gehören die beabsichtigte Struktur, die Grenzen und die Qualitätslatte. In der Praxis schafft das eine viel bessere Grundlage, um die Ausgabe später zu beurteilen.

2. Grenzen gehören in den Prompt, nicht hinterher dazu

Ein wiederkehrendes Thema war, dass KI deutlich besser arbeitet, wenn die Betriebsgrenzen klar sind.

Das bedeutet, Dinge wie architektonische Grenzen, Erwartungen an Stil, Schnittstellen, Review-Kriterien und erlaubte Änderungen vorab festzulegen. Ohne das driftet man schnell zu lokal plausibelem Code ab, der nicht zum System passt.

3. Reviews müssen architektonisch sein

Ein weiterer wichtiger Punkt war der Unterschied zwischen Code, der okay aussieht, und Code, der wirklich ins System passt.

Die Session betonte, KI-Ausgaben mit architektonischer Absicht zu prüfen. Das heißt: Passt die Implementierung zum Plan, bleiben Verantwortlichkeiten am richtigen Ort, und bleibt das System nach der Änderung verständlich?

4. Feedback-Loops sind nicht verhandelbar

Die Diskussion über automatisierte Tests, Linter und Benchmarks war besonders relevant. Wenn du KI intensiv nutzen willst, ohne die Kontrolle zu verlieren, brauchst du enge Loops, die dir zeigen, wann die Ausgabe falsch, fragil oder fehlgeleitet ist.

Der Workflow dreht sich damit weniger um Vertrauen in das Modell und stärker um Bedingungen, unter denen Fehler schnell sichtbar werden.

AGENTS.md und explizite Leitplanken

Ein wesentlicher Teil des Talks drehte sich darum, Erwartungen über Planungsartefakte wie AGENTS.md sichtbar zu machen.

Das ist wichtig, weil gute KI-Zusammenarbeit von externalisiertem Denken lebt. Wenn Regeln, Ziele und Grenzen nur in deinem Kopf existieren, kann das Modell ihnen nicht zuverlässig folgen und andere Entwickler können den Prozess ebenfalls nicht sauber reviewen.

Das war eines der stärksten Learnings der Session: Schreibe zuerst das Betriebsmodell auf und lass die KI dann darin arbeiten.

Der Live-Coding-Teil

Der Live-Coding-Abschnitt hat die Theorie aus dem ersten Teil gut geerdet. Nachdem wir zunächst über Prinzipien und Prozess gesprochen hatten, wechselte der Stream zu einem praktischen Java-Beispiel in Visual Studio Code mit GitHub Copilot.

Diese Struktur funktionierte gut. Die Implementierung war leichter nachzuvollziehen, weil das Denken vorher schon explizit gemacht worden war. Statt zufälligem Trial-and-Error konnte man sehen, wie Planung, Grenzen und Reviews die Coding-Entscheidungen geprägt haben.

Vibe Coding, Vise Coding und Guided Coding

Die Session streifte auch verwandte Begriffe wie Vibe Coding und Vise Coding.

Der nützliche Unterschied war hier nicht Branding, sondern Kontrolle.

Guided Coding, wie Kenny es beschrieben hat, basiert auf disziplinierter Ausführung: Richtung vorgeben, den Agenten begrenzen, das Ergebnis reviewen und die Codequalität über die Zeit intakt halten. Das passt deutlich besser zu echten Softwareprojekten als ein Workflow, der sich nur auf Geschwindigkeit konzentriert.

Nützliche Links

• Präsentations-PDF
• Light.PortableResults
• Context Rot paper
• Chroma research: Context Rot
• Vaadin banking app
• David Farago post on AI coding assistants

Abschließender Gedanke

Am stärksten hängen geblieben ist bei mir, dass disziplinierter KI-Einsatz nicht in erster Linie davon lebt, den perfekten Prompt zu finden. Es geht darum, einen Prozess zu gestalten.

Diese Session hat eine konkrete Version dieses Prozesses für Java-Entwicklung gezeigt: erst planen, das Modell begrenzen, aggressiv verifizieren und die Architektur bei jedem Schritt im Blick behalten. Das ist eine deutlich stärkere Grundlage, als nur darauf zu hoffen, dass das Modell schon das Richtige tun wird.