Vibe-Coding: Abkürzung oder Lernbooster?

Mit „Vibe-Coding“ meine ich eine Art zu programmieren, bei der du dich stark auf das Gefühl verlässt: Du beschreibst eine Aufgabe in natürlicher Sprache, eine KI liefert Code, und du übernimmst ihn, weil er plausibel aussieht und schnelle Ergebnisse bringt. Das kann von „schreib mir eine Utility-Methode“ bis hin zu „baue mir einen REST-Endpunkt mit Validierung“ reichen. Der Vorteil liegt auf der Hand: Du kommst zügig in Bewegung, bekommst Beispiele, Formulierungen und Strukturen, die du sonst erst mühsam zusammensuchen würdest.

Gerade im Java-Umfeld gibt es viele wiederkehrende Bausteine. DTOs, Mapper, REST-Controller, JPA-Queries, kleine Refactorings, Tests - das sind Themen, bei denen sich eine KI als Ideengeber und als Generator für Grundgerüste bewähren kann. Und ja: Auch beim Lernen kann das funktionieren, wenn du die KI nicht nur als „Code-Drucker“ nutzt, sondern als Gesprächspartner, der dir Alternativen erklärt und dich auf typische Stolpersteine hinweist.

Der kritische Punkt ist nicht, dass Code generiert wird. Der kritische Punkt ist Ownership. Sobald du Code in dein Repository eincheckst, bist du verantwortlich: für Lesbarkeit, Sicherheit, Wartbarkeit und dafür, dass du im Zweifel erklären kannst, warum du es so gelöst hast. Vibe-Coding ist dann hilfreich, wenn es dich zu dieser Verantwortung hinführt - und schädlich, wenn es dich davon wegschiebt.

Warum der Ruf so schlecht ist

Der schlechte Ruf kommt meistens daher, dass KI-Code oft „gut genug“ wirkt, aber im Detail danebenliegt. KI ist stark darin, Muster zu imitieren, und schwächer darin, deinen konkreten Kontext zu kennen: Framework-Versionen, Projektkonventionen, Transaktionsgrenzen, Security-Setup, Datenmodell, Edge Cases. In JavaEE-Setups mit WildFly ist das besonders spürbar, weil dort viel über Container-Services läuft. Ein Stück Code kann lokal im Unit-Test funktionieren und im Deployment wegen Classloading, CDI-Scopes oder Konfigurationsdetails plötzlich kippen.

Ein weiteres Problem: KI generiert gern glatten Code, der Fehlerfälle unterschlägt. Es werden Exceptions pauschal geschluckt, Timeouts ignoriert oder null nicht sauber behandelt. Das Ergebnis ist weniger „kaputt“, sondern eher „unklar“. Und unklarer Code ist der, der dich später im Debugger am meisten Zeit kostet.

Ein kleines Beispiel aus der Praxis: Eine Query, die auf den ersten Blick ok ist, aber schlechte Gewohnheiten einschleust.

public User loadUser(EntityManager em, Long id) {
    return em.createQuery("select u from User u where u.id=" + id, User.class)
             .getSingleResult();
}

Das funktioniert oft, aber es ist eine schlechte Basis. String-Konkatenation in Queries ist wartungsfeindlich und öffnet bei komplexeren Parametern schnell die Tür für Sicherheitsprobleme. In JPA willst du Parameter binden, damit Typen, Escaping und Caching sauber bleiben.

public User loadUser(EntityManager em, Long id) {
    return em.createQuery("select u from User u where u.id = :id", User.class)
             .setParameter("id", id)
             .getSingleResult();
}

Solche Details wirken klein, sind aber genau die Dinge, die Vibe-Coding riskant machen: Wenn du den Unterschied nicht kennst, übernimmst du das „plausible“ und importierst nebenbei technische Schulden. Und da sind wir beim Kern: Der Ruf ist schlecht, weil zu viele Ergebnisse entstehen, die niemand wirklich verstanden hat.

Wann Vibe-Coding sinnvoll ist und wann nicht

Sinnvoll ist Vibe-Coding dann, wenn du die Ausgabe schnell und zuverlässig verifizieren kannst. Das klappt gut bei klar abgegrenzten Aufgaben: eine Methode, die Strings normalisiert; ein einfacher Mapper; ein Test, der ein bestimmtes Verhalten abdeckt; ein Vorschlag für eine bessere API; ein Refactoring, das IntelliJ ohnehin ähnlich anbietet. Auch ein erster Entwurf für eine Klasse kann helfen, solange du ihn als Rohmaterial siehst und nicht als fertige Lösung.

Fürs Lernen wird es interessant, wenn du die KI aktiv auf Verständnis festnagelst. Statt „schreib mir das“ bringt dich oft weiter: „Erkläre mir, warum du das so gemacht hast“, „Welche Alternativen gäbe es in Java?“, „Welche Risiken stecken in dieser Lösung?“, „Welche Tests würdest du dafür schreiben?“ Wenn du das konsequent machst, wird aus Vibe-Coding ein Lernmodus: Du bekommst nicht nur Code, sondern Begründungen und Gegenbeispiele. Und du merkst schneller, ob du gerade etwas wirklich verstanden hast oder nur nachbaust.

In der Praxis brauchst du dafür ein paar handwerkliche Leitplanken, ohne daraus ein Prozess-Monster zu machen. Wenn du KI-Code übernimmst, behandle ihn wie Code von einem fremden Entwickler: Du liest ihn, du verstehst ihn, du testest ihn. In IntelliJ schaust du dir den Diff an, springst per „Go to Declaration“ durch wichtige Typen, setzt Breakpoints, und schaust dir im Debugger an, welche Werte wirklich durchlaufen. In Git sind kleine, saubere Commits dein Sicherheitsnetz, weil du Änderungen isoliert nachvollziehen und bei Bedarf sauber zurückdrehen kannst. Maven hilft dir ebenfalls: Wenn Abhängigkeiten komisch wirken oder Plugins „magisch“ auftauchen, ist das ein Signal, genauer hinzuschauen.

Nicht sinnvoll ist Vibe-Coding in Bereichen, in denen „fast richtig“ gefährlich wird. Alles, was Security betrifft, gehört dazu: Authentifizierung und Autorisierung, Token-Handling, Zugriffskontrollen, Input-Validierung, sichere Fehlerausgaben, Schutz vor Injection. Auch bei Nebenläufigkeit, Transaktionen und Performance kann ein kleiner Denkfehler große Effekte haben. In solchen Themen ist KI als Sparringspartner ok, aber ich würde Ergebnisse nur übernehmen, wenn du sie wirklich erklären und testen kannst.

Ein typisches Warnsignal ist, wenn du Code übernimmst, weil er lang ist und „professionell aussieht“. Länge ist kein Qualitätsmerkmal. Gerade am Anfang neigt man dazu, sich von viel Struktur beruhigen zu lassen: viele Klassen, viele Patterns, viele Abstraktionen. Das fühlt sich nach Enterprise an, ist aber oft Overengineering. Wenn du beim Lesen merkst, dass du gerade nicht mehr folgen kannst, ist das kein persönlicher Makel, sondern ein Stoppschild. Dann ist der richtige Schritt nicht „noch mehr generieren“, sondern „vereinfachen, runterbrechen, verstehen“.

Ein weiteres Risiko ist Gewöhnung. Wenn du dir früh jede Kleinigkeit generieren lässt, trainierst du dir ein Muster an: Problem formulieren, Lösung kopieren, weiter. Du überspringst dabei den Teil, in dem du dein mentales Modell aufbaust. Und dieses Modell brauchst du später beim Debugging. Der Moment, in dem ein Fehler im Log auftaucht oder ein Endpunkt sporadisch 500er wirft, entscheidet sich nicht durch „wie schnell kann ich Code erzeugen“, sondern durch „wie gut verstehe ich Ablauf, Zustand und Nebenwirkungen“.

Hier ist ein simples Beispiel, das genau das zeigt: Eine KI kann dir schnell einen Null-Check hinwerfen, aber du solltest verstehen, welche Semantik du eigentlich willst.

public String displayName(User u) {
    return u == null ? "Unbekannt" : u.getName();
}

Das ist ok, wenn „Unbekannt“ fachlich wirklich passt. Wenn aber ein fehlender User ein Fehler ist, verschleierst du damit ein Problem. Dann wäre eine klare Exception oder ein Optional die bessere Aussage. Der Code ist nicht nur Technik, sondern Kommunikation.

Fazit: KI bewusst nutzen, nicht blind folgen

Vibe-Coding ist kein moralisches Thema. Es ist ein Werkzeug, das dir Geschwindigkeit geben kann - oder dir Verständnis rauben kann. Der Unterschied liegt darin, ob du KI als Abkürzung benutzt oder als Verstärker. Wenn du dir Varianten generieren lässt, sie kritisch prüfst, sie testest und dir erklären lässt, warum etwas so und nicht anders ist, lernst du oft schneller als mit reinem Trial-and-Error. Wenn du hingegen Code übernimmst, den du nicht nachvollziehen kannst, baust du dir eine Blackbox, die du selbst warten musst.

Mein pragmatischer Maßstab ist einfach: Übernimm nur Code, den du in eigenen Worten erklären kannst. Wenn du das gerade nicht kannst, nutze die KI genau dafür: Lass dir die Logik erklären, lass dir Risiken nennen, lass dir Tests vorschlagen, und reduziere die Lösung, bis sie wieder verständlich ist. So verteufelst du KI nicht, aber du gibst ihr auch nicht das Steuer. Und genau an dieser Stelle verliert Vibe-Coding seinen schlechten Ruf: wenn du es bewusst einsetzt - und nicht, weil es gerade bequemer ist.