Autor: Dr. Cassian Holt · Senior Architect & Programming Language Theorist
Veröffentlicht auf: java-developer.online

Lucid Programming

Es gibt einen neuen Begriff, der gerade durch die Entwickler-Szene geistert: Vibe Coding.

Die Idee: Du beschreibst grob, was du willst. Die KI generiert Code. Du schaust drauf, sagst „sieht gut aus“ — und machst weiter. Kein tiefes Verständnis nötig. Kein Debugging im klassischen Sinne. Du „vibest“ dich durch die Entwicklung.

Klingt nach Zukunft. Fühlt sich nach Produktivität an.

Aber als jemand, der seit 20 Jahren Muster in der Evolution von Programmiersprachen untersucht, erkenne ich dieses Muster. Und es ist nicht neu.

Die Illusion der mühelosen Produktivität

Jede Technologie-Generation hatte ihre Version von „es funktioniert, also ist es gut“:

In den 90ern waren es die visuellen RAD-Tools. Delphi, Visual Basic — du hast Buttons auf Formulare gezogen, und die IDE hat den Code generiert. Es funktionierte. Bis du verstehen musstest, warum es funktionierte. Oder warum es plötzlich nicht mehr funktionierte.

In den 2000ern kamen die Code-Generatoren. Enterprise-Frameworks, die aus XML-Konfigurationen ganze Anwendungsschichten erzeugten. „Niemand muss das verstehen, es generiert sich selbst.“ Bis jemand ein Custom-Feature brauchte, das nicht im Generator vorgesehen war.

In den 2010ern: Low-Code-Plattformen. „Jeder kann programmieren!“ Ja — bis die Anforderungen über das hinausgehen, was die Plattform erlaubt.

Und jetzt, 2026: Vibe Coding. Die KI schreibt den Code. Du steuerst per Prompt. Alles fühlt sich mühelos an.

Das Muster wiederholt sich seit 30 Jahren. Nur die Werkzeuge ändern sich.

Wie Detective Miller in The Expanse sagen würde: „The pattern never changes. Just the names.“

Was bei Vibe Coding tatsächlich passiert

Ich war letzte Woche in einem Code-Review. Ein Kollege hatte ein Feature gebaut — schnell, mit KI-Unterstützung. Sah sauber aus. Hat kompiliert. Tests liefen durch.

Dann habe ich gefragt: „Warum hast du hier ein Strategy-Pattern verwendet statt einer einfachen Switch-Expression?“

Stille.

„Das hat die KI so vorgeschlagen. Sah vernünftig aus.“

Das ist Vibe Coding in der Praxis. Es ist nicht Programmieren. Es ist Delegieren ohne Briefing.

Wenn du einem Kollegen sagst „Bau mir mal irgendwas, das so ungefähr das macht“, würdest du das Ergebnis nicht ungeprüft in Produktion nehmen. Aber genau das passiert beim Vibe Coding. Täglich. In echten Projekten. Bei Leuten, die es besser wissen.

Und ich rede nicht von Junioren. Ich habe das in den letzten Monaten in mehreren Unternehmen gesehen. Ein Senior-Entwickler, der Spring-Security-Konfigurationen durch die KI jagt — ohne dem Modell die bestehende Security-Architektur mitzugeben. Eine Projektleiterin, die Anforderungsdokumente analysieren lässt — mit einem Prompt, der in drei Wörter passt. Ein Team-Lead, der Code-Reviews beschleunigt, indem er den gesamten Merge Request in die KI kopiert und fragt: „Irgendwas auffällig?“

Keiner von denen ist dumm. Keiner ist faul. Sie alle stehen unter Druck, und die KI liefert. Schnell. Plausibel. Verlockend.

Das Problem ist nicht die KI. Die KI ist ein Werkzeug — und ein beeindruckendes.

Das Problem ist die Haltung dahinter. Und die lässt sich auf drei Punkte reduzieren:

1. Keine klaren Anforderungen. Wer vibed, weiß oft nicht genau, was er eigentlich will. Der Prompt ist vage, weil die Anforderung vage ist. Die KI liefert etwas — und weil es kompiliert, wird es akzeptiert. Ich sage das ohne Überheblichkeit: Mir passiert das auch. Der Unterschied ist, ob du es bemerkst.

2. Kein Plan. Vibe Coding ist reaktiv. Du promptest, schaust was kommt, promptest nochmal. Es gibt keinen Entwurf, kein Ziel, keine Architektur-Entscheidung vor dem ersten Prompt. Du lässt die KI die Richtung bestimmen — und wunderst dich, wenn du am falschen Ort landest.

3. Keine Prüfung. Wer den Code nicht versteht, kann ihn nicht verantworten. Nicht gegenüber dem Team. Nicht gegenüber dem Kunden. Nicht in sechs Monaten, wenn jemand fragt: „Warum ist das so gelöst?“ — und die einzige ehrliche Antwort wäre: „Keine Ahnung, hat die KI so gemacht.“

Und generischer KI-Code in einem spezifischen Projekt — das ist wie eine Organtransplantation ohne Blutgruppentest. Es kann funktionieren. Aber du willst nicht darauf wetten.

Die Alternative: Lucid Programming

Wir brauchen einen Gegenbegriff. Nicht weil Begriffe die Welt verändern — sondern weil sie helfen, anders zu denken.

Ich habe lange nach dem richtigen Wort gesucht. „Conscious Coding“? Klingt nach Yoga-Retreat. „Deliberate Programming“? Zu sperrig. „Clean Prompting“? Trifft es nicht.

Dann fiel mir Lucid Dreaming ein — luzides Träumen. Du träumst, aber du bist dir bewusst, dass du träumst. Du hast die Kontrolle. Du entscheidest, was passiert.

Lucid Programming ist das bewusste Gegenteil von Vibe Coding.

Und die Abgrenzung ist einfacher als man denkt:

Vibe Coding: Du promptest und hoffst. Die KI liefert. Du akzeptierst. Es fühlt sich gut an.

Lucid Programming: Du planst, bevor du promptest. Du weißt, was du fragst und warum. Du prüfst, was zurückkommt. Es ist korrekt und verlässlich.

Oder kürzer: Vibest du noch — oder planst du schon?

Der Unterschied ist nicht, ob du KI nutzt. Natürlich nutzt du KI. Wer das 2026 noch leugnet, belügt sich selbst. Der Unterschied ist auch nicht, welche KI du nutzt — ob ChatGPT, Copilot, Claude oder ein lokales Modell.

Der Unterschied ist deine Haltung.

Gleiche Technologie. Fundamental anderer Ansatz.

Die vier Prinzipien von Lucid Programming

1. Erst denken, dann prompten.
Bevor du die KI öffnest: Was genau brauchst du? Was ist das Problem — nicht die Lösung? Was sind die Randbedingungen? Welche Architektur-Entscheidung steht dahinter?

Mal ehrlich: Die meisten schlechten KI-Ergebnisse sind keine KI-Fehler. Sie sind Briefing-Fehler. Die KI ist so gut wie der Mensch, der sie benutzt. Wer seine Anforderungen nicht formulieren kann, wird auch mit GPT-5 keine guten Ergebnisse bekommen.

Das ist im Grunde Requirements Engineering — die Disziplin, die schon vor der KI die meisten Projekte zum Scheitern gebracht hat, wenn man sie ignoriert hat. Die KI hat das Problem nicht geschaffen. Sie hat es nur sichtbar gemacht.

2. Kontext ist König.
Die Qualität der KI-Antwort hängt direkt von der Qualität des Kontexts ab. Wer der KI nichts über sein Projekt erzählt, bekommt generische Antworten. Wer seine Architektur-Entscheidungen, Code-Konventionen und Projektstruktur mitliefert, bekommt Antworten, die tatsächlich passen.

Ich habe das bei einem Kunden erlebt: Ein Entwickler hat drei Tage lang mit der KI an einem Service gearbeitet — und jedes Mal sah das Ergebnis anders aus. Anderes Pattern, andere Fehlerbehandlung, andere Namenskonventionen. Weil er jedes Mal ohne Kontext gestartet hat. Jeder Prompt war ein Neuanfang. Kein Wunder, dass nichts zusammenpasste.

Relevanz schlägt Intelligenz. Immer.

3. Verstehen, was du übernimmst.
KI-generierter Code ist dein Code. Punkt. Dein Name steht im Commit. Du bist verantwortlich für das, was in Produktion geht. Das heißt: verstehen, prüfen, entscheiden. Nicht absegnen, weil es kompiliert.

Ich weiß, das ist unbequem. Es ist viel verführerischer, die KI den Code schreiben zu lassen und „Sieht gut aus“ zu sagen. Aber wir sind Entwickler. Nicht Abnicker.

Das heißt nicht, dass du jede Zeile manuell nachvollziehen musst. Aber du musst die Entscheidungen verstehen. Warum dieses Pattern? Warum diese Datenstruktur? Was passiert bei Edge Cases? Wenn du diese Fragen nicht beantworten kannst, hast du den Code nicht übernommen — du hast ihn nur kopiert.

4. Ergebnisse validieren.
Lucid Programming heißt: Du vertraust dem Ergebnis nicht blind. Du testest. Du reviewst. Du hinterfragst. Nicht weil die KI schlecht ist — sondern weil professionelle Softwareentwicklung genau das verlangt. Von jedem Code. Egal wer ihn geschrieben hat.

Ein Senior-Entwickler, dessen Code ohne Review in Produktion geht? Gibt es nicht. Warum sollte KI-generierter Code diese Prüfung überspringen dürfen?

Das klingt nach mehr Aufwand. Ist es auch — am Anfang. Aber der Entwickler, der seinen halben Sprint mit Vibe Coding verbringt und die andere Hälfte damit, die Ergebnisse zu reparieren, spart keine Zeit. Er verschiebt sie nur. Das ist keine Produktivität. Das ist Selbstbetrug mit schöner Oberfläche.

(Und wer seine Daten zusätzlich schützen will, kann mit lokalen Modellen arbeiten — dann bleibt der gesamte Kontext im eigenen Netzwerk. Das ist die Königsklasse von Lucid Programming. Aber das Prinzip gilt unabhängig davon.)

Die Küchendiskussion: „Hauptsache es funktioniert“

Wer Java Fleet kennt, kennt unsere Küchengespräche. Die besten technischen Diskussionen entstehen nicht im Meeting-Raum, sondern an der Kaffeemaschine. Dieses Thema hat eine besonders lebhafte Runde ausgelöst.

Cassian: Ich arbeite gerade an diesem Artikel über Vibe Coding — diesen Trend, dass Entwickler einfach prompten und das Ergebnis übernehmen, ohne wirklich zu planen. Und ich suche nach dem richtigen Gegenbegriff.

Franz-Martin (lehnt am Tresen, Kaffeetasse in der Hand): Vibe Coding. Netter Name für etwas, das ich seit 40 Jahren kenne.

Cassian: Wie meinst du das?

Franz-Martin: In den 80ern und 90ern war „Hauptsache es funktioniert“ keine schlechte Angewohnheit. Das war die Firmenphilosophie. Die offizielle. Der Chef hat nicht gefragt, ob dein Code wartbar ist. Der hat gefragt: „Läuft es?“ Wenn ja — nächstes Projekt. Wenn nein — Überstunden.

Nova (setzt sich dazu): Ernsthaft? Das war akzeptiert?

Franz-Martin: Akzeptiert? Das war gewünscht. Versteh den Kontext: Es gab kein Stack Overflow. Kein Google. Keine IDE, die dir Fehler anzeigt. Du hattest ein Handbuch, einen Compiler und eine Deadline. Wenn dein COBOL-Programm den Batch-Lauf überlebt hat, warst du der Held. Niemand hat nach Clean Code gefragt — den Begriff gab es noch nicht.

Cassian: Und was ist passiert mit dem Code, der „funktioniert“ hat?

Franz-Martin (grinst): Frag Elyndra. Die gräbt ihn heute aus.

Elyndra (kommt mit Tee dazu): Oh, danke für die Steilvorlage. Ich refactore gerade ein System für einen Mittelständler. Java 8, migriert von Java 6, davor war es teilweise noch J2EE. Und da drin steckt genau diese Philosophie. Klassen mit 3.000 Zeilen. Keine Tests. Kommentare wie „// funktioniert, nicht anfassen“ — und das steht da seit 2009.

Franz-Martin: Siehst du. „Hauptsache es funktioniert“ ist nie ein Endpunkt. Es ist ein Kredit. Du kaufst dir Geschwindigkeit auf Kosten der Zukunft. Und irgendwann kommt die Rechnung.

Elyndra: Die Rechnung komme ich gerade bezahlen. Jeden Tag. Und wisst ihr, was das Schlimme ist? Vibe Coding produziert genau den gleichen Typ von Code. Nur schneller. In den 90ern hat es Monate gedauert, ein unwartbares System zu bauen. Mit KI schaffst du das in einer Woche.

Code Sentinel (hat zugehört, stellt seine Tasse ab): Ich komme mal aus der Security-Ecke dazu. „Hauptsache es funktioniert“ — wisst ihr, was das in meiner Welt bedeutet?

Nova: Sicherheitslücken?

Code Sentinel: Nicht nur Lücken. Blindheit. Wenn du Code übernimmst, den du nicht verstanden hast, dann weißt du nicht, was er tut. Du weißt, was er sichtbar tut. Aber nicht, was er nebenbei tut. Welche Daten loggt er? Welche Ports öffnet er? Welche Dependencies zieht er rein? Welche Berechtigungen erwartet er?

Cassian: Und bei KI-generiertem Code?

Code Sentinel: Noch schlimmer. Weil die KI aus Millionen von Code-Snippets trainiert ist — inklusive Code mit bekannten Schwachstellen. Ich habe letzte Woche einen KI-generierten REST-Endpoint reviewt. Sah sauber aus. Funktionierte perfekt. Aber die Input-Validierung hatte eine SQL-Injection-Lücke, die so subtil war, dass sie in einem normalen Review fast durchgegangen wäre. Die KI hat ein Pattern aus dem Training übernommen, das seit 2019 als unsicher gilt. Das Modell weiß das nicht. Und der Entwickler, der es übernommen hat, wusste es auch nicht. Weil er nicht gefragt hat.

Franz-Martin: „Hauptsache es funktioniert“ hat in den 80ern zu Legacy-Code geführt, der 30 Jahre später Millionen kostet. Wenn „Hauptsache es funktioniert“ heute zu KI-generiertem Code mit Sicherheitslücken führt, reden wir nicht mehr über technische Schulden. Dann reden wir über Haftung.

Nova (nachdenklich): Aber mal ehrlich — ich kenne es nicht anders. In meinem Studium haben wir vom ersten Semester an mit Copilot gearbeitet. Die Hälfte meiner Kommilitonen schreibt keinen Code mehr ohne KI. Für die ist Vibe Coding nicht ein Trend. Das ist einfach… Arbeiten.

Elyndra: Und genau das ist das Problem, Nova. Nicht dass du KI nutzt. Sondern dass eine ganze Generation gar nicht mehr lernt, ohne KI zu denken. Wenn du nicht weißt, was ein Strategy-Pattern ist — woher weißt du dann, ob die KI das richtige vorgeschlagen hat?

Nova: Das ist fair. Ich frage tatsächlich jedes Mal nach: Warum hat die KI das so gelöst? Aber ich merke, dass ich damit in der Minderheit bin. Die meisten aus meinem Jahrgang fragen nicht. Die nehmen es.

Cassian: Und genau das ist der Unterschied, den ich beschreiben will. Es geht nicht darum, ob du KI nutzt — natürlich nutzt du KI. Es geht darum, ob du dabei wach bist. Ob du planst, bevor du promptest. Ob du verstehst, was du übernimmst.

Franz-Martin: Luzid. Wie luzides Träumen. Du bist im Traum, aber du hast die Kontrolle.

Cassian: Genau. Lucid Programming.

Code Sentinel: Gefällt mir. Und für mich heißt Lucid Programming auch: Ich weiß, was der Code tut — bevor er in Produktion geht. Nicht nachdem der Penetration-Test schiefgelaufen ist.

Elyndra: Und für mich heißt es: Der Code, den wir heute schreiben — egal ob mit oder ohne KI — muss in fünf Jahren noch wartbar sein. Sonst sitzt die nächste Elyndra vor dem gleichen Problem. Nur diesmal mit dem Kommentar: „// KI-generiert, nicht anfassen.“

(Alle lachen)

Franz-Martin (wird ernster): Wisst ihr, was ich in 35 Jahren gelernt habe? „Hauptsache es funktioniert“ war nie ein guter Grundsatz. Es war eine Notwendigkeit. Wir hatten keine besseren Werkzeuge, keine besseren Methoden. Heute haben wir beides. KI gibt uns unglaubliche Möglichkeiten. Aber wenn wir sie mit der gleichen Mentalität nutzen, die schon in den 80ern der falsche Ansatz war — dann haben wir nichts gelernt.

Cassian: Dann ist Lucid Programming im Grunde das, was wir immer hätten tun sollen — nur mit besseren Werkzeugen.

Franz-Martin: Genau. Nur dass die Werkzeuge jetzt so mächtig sind, dass die Konsequenzen von „Hauptsache es funktioniert“ auch mächtiger werden. In beide Richtungen.

Nova: Also — vibest du noch oder planst du schon?

Franz-Martin (hebt die Kaffeetasse): Ich habe nie gevibed. Aber ich habe „Hauptsache es funktioniert“ überlebt. Und glaub mir — das ist kein Kompliment an den Ansatz.

Die Küchengespräche bei Java Fleet sind echt. Wir veröffentlichen sie, weil die besten Einsichten nicht aus Vorträgen kommen — sondern aus ehrlichen Diskussionen zwischen Menschen mit verschiedenen Erfahrungen. Mehr Perspektiven von der Crew findet ihr auf unserer Team-Seite.

Der Praxistest: Zwei Entwickler, eine Aufgabe

Um den Unterschied greifbar zu machen — ein Szenario aus der Praxis:

Aufgabe: REST-Endpoint für eine Benutzer-Registrierung. Spring Boot, mit Validierung und Error-Handling.

Der Vibe Coder: Öffnet ChatGPT. Tippt: „Spring Boot registration endpoint with validation.“ Bekommt 40 Zeilen Code. Kompiliert. Funktioniert. Kopiert es ins Projekt. Weiter zum nächsten Ticket.

Drei Wochen später: Das Team stellt fest, dass die Validierung bei Umlauten in E-Mail-Adressen crasht. Dass das Error-Handling HTTP 500 zurückgibt statt sinnvoller Fehlermeldungen. Dass die Passwort-Validierung nur clientseitig stattfindet.

Niemand im Team kann erklären, warum der Code so aufgebaut ist. Weil niemand es je geplant hat.

Der Lucid Programmer: Macht sich zuerst klar: Was brauche ich? Validierung nach welchen Regeln? Welche Error-Responses erwartet das Frontend? Gibt es bestehende Patterns im Projekt für Exception-Handling?

Dann promptet er — mit Kontext: „Ich brauche einen Registration-Endpoint in Spring Boot. Wir nutzen @ControllerAdvice für zentrales Error-Handling. Validierung über Bean Validation mit Custom-Constraints für deutsche Sonderzeichen. Error-Responses als ProblemDetail nach RFC 9457. Hier ist unser bestehendes Pattern: [Code-Ausschnitt].“

Das Ergebnis? Passt ins Projekt. Ist nachvollziehbar. Hält drei Wochen später immer noch.

Gleiche KI. Gleiche Aufgabe. Fundamental anderes Ergebnis.

Der Unterschied war nicht das Modell. Der Unterschied war der Mensch davor.

5 Minuten Prompt → 2 Stunden Reparatur. Oder: 45 Minuten solider Code. Du entscheidest.

Warum die Unterscheidung jetzt wichtig ist

Wir stehen an einem Wendepunkt. KI wird sich nicht zurückentwickeln. Die Modelle werden besser. Die Integration in Entwicklungsumgebungen wird tiefer. In zwei Jahren wird es normal sein, dass jeder Entwickler täglich mit KI-Assistenten arbeitet.

Die Frage, die sich jetzt entscheidet: Wird das eine Generation von Entwicklern, die wissen was sie tun? Oder eine Generation, die gut darin ist, Dinge zu akzeptieren, die sie nicht verstehen?

Vibe Coding ist kein Verbrechen. Für Prototypen, für Experimente, für den schnellen Proof-of-Concept am Freitagabend — warum nicht. Ich mache es selbst. Jeder macht es.

Aber für professionelle Softwareentwicklung? Für Code, der in Produktion geht? Für Systeme, die echte Daten verarbeiten?

Da reicht „es fühlt sich gut an“ nicht. Da braucht es einen Plan. Klarheit. Verlässlichkeit.

Da braucht es Lucid Programming.

Fazit: Nicht das Werkzeug ist das Problem

Jede Generation hatte ihre Version der mühelosen Produktivität. RAD-Tools. Code-Generatoren. Low-Code. KI-Assistenten. Das Werkzeug ändert sich. Die Versuchung bleibt gleich: Geschwindigkeit über Verständnis zu stellen.

Und jede Generation musste die gleiche Lektion lernen: Es funktioniert ist nicht dasselbe wie es ist richtig.

KI ist das mächtigste Werkzeug, das Entwickler je hatten. Vibe Coding ist die schnellste Art, es falsch einzusetzen. Lucid Programming ist der Vorschlag, es richtig einzusetzen.

Nicht langsamer. Nicht ohne KI. Sondern mit Plan. Mit Verständnis. Mit Verantwortung.

Die Wahl liegt — wie immer — beim Entwickler.

Nicht beim Modell.

Ursprung „Vibe Coding“:

Karpathy sagt selbst: Vibe Coding ist passé (brandaktuell, 10.02.2026):

Security-Studien zu KI-generiertem Code:

Simon Willison (differenzierte Sicht):

Dr. Cassian Holt ist Senior Architect bei Java Fleet Systems Consulting in Essen-Rüttenscheid. Er promovierte an der ETH Zürich in Computer Science und forschte drei Jahre bei Microsoft Research Cambridge. Seine Leidenschaft gilt der Evolution von Programmiersprachen und der Frage, warum „neue“ Konzepte oft alte Ideen in modernem Gewand sind.

Sein Motto: „Nichts ist wirklich neu — alles kehrt in moderner Form zurück.“

Weiterführende Links:

Tags: #LucidProgramming #VibeCoding #KI #Softwareentwicklung #CleanCode #JavaFleet

© 2026 Java Fleet Systems Consulting Ltd. — java-developer.online

Autor

  • Cassian Holt

    43 Jahre alt, promovierter Informatiker mit Spezialisierung auf Programming Language Theory. Cassian arbeitet als Senior Architect bei Java Fleet Systems Consulting und bringt eine einzigartige wissenschaftliche Perspektive in praktische Entwicklungsprojekte. Seine Leidenschaft: Die Evolution von Programmiersprachen und warum "neue" Features oft alte Konzepte sind.

Tags:

AIgolangJavKI
← Vorheriger Artikel Die Fingerabdrücke der KI – So erkennst du generierten Content
Nächster Artikel → Fahrplan statt Drehbuch – Wie du KI für deine Bewerbung richtig nutzt