LiterateProgramming

Vibe Coding: Ein Nachfolger des Literate Programming?

13 Aufrufe 36 Minuten

Literate Programming und Vibe Coding sind zwei unterschiedliche Paradigmen der Softwareentwicklung, entstanden in verschiedenen Epochen und aus verschiedenen Motiven. Literate Programming führte Donald Knuth in den 1980er-Jahren ein: Programme sollten wie literarische Werke geschrieben werden, mit dem Schwerpunkt auf Erklärung und Lesbarkeit für Menschen statt auf einer maschinenorientierten Struktur (Donald Knuth). Vibe Coding dagegen ist ein Begriff, den der KI-Forscher Andrej Karpathy 2025 geprägt hat. Er beschreibt einen neuen, KI-gestützten Programmierstil: Man programmiert „nach Gefühl“, lässt per Prompt in natürlicher Sprache eine KI den Code erzeugen und „vergisst“ dabei praktisch, „dass es den Code überhaupt gibt“ (Vibe Coding is Real). Dieser Bericht vergleicht die beiden Ansätze aus philosophischer Sicht. Er untersucht ihre Grundprinzipien, ihre Art, an das Programmieren heranzugehen, und die Rolle von Dokumentation, Struktur und Intuition. Außerdem fragen wir, ob sich Vibe Coding als Nachfolger des Literate Programming verstehen lässt, und bewerten, wie beide Ansätze sich auf Kreativität, Wartbarkeit, Zusammenarbeit und die langfristige Tragfähigkeit von Softwareprojekten auswirken, in heutigen Teams ebenso wie im Open-Source-Bereich.

Grundhaltung und Vorgehen

Literate Programming: Code als Literatur

Literate Programming beruht auf der Überzeugung, dass ein Computerprogramm in erster Linie für Menschen geschrieben wird, die es lesen und verstehen sollen, und erst in zweiter Linie für Maschinen, die es ausführen (Donald Knuth). Knuth schlug vor, Programmieren nicht länger als Unterweisung eines Computers zu sehen. Stattdessen sollten wir uns vorstellen, wir erklärten einem anderen Menschen, was der Computer tun soll (Donald Knuth). In der Praxis mischt ein literarisches Programm Prosa und Quellcode und verwebt beides so, dass der Programmierer die Logik in erzählerischer Reihenfolge darstellen kann (der Reihenfolge der Erklärung) und nicht in der Reihenfolge, die der Compiler verlangt (Literate programming – Wikipedia). Anschließend wird die Quelle verarbeitet: „Tangling“ erzeugt maschinell ausführbaren Code, „Weaving“ die formatierte Dokumentation (Literate programming – Wikipedia). Der Programmierer wird so zum Essayisten. Knuth verglich einen Literate Programmer mit einem Autor, dem es um Klarheit und Stil geht, der sprechende Bezeichner wählt und die Absicht jedes Codeteils erklärt (Donald Knuth). Das Grundprinzip lautet: Dokumentation ist kein nachträglicher Zusatz, sondern fester Bestandteil des Programmierens. Die Erklärung des Programms ist das Programm. Weil Literate Programming Programmierer zwingt, ihre Gedankengänge auszuformulieren, soll es klarere Designentscheidungen und bessere Software hervorbringen (Literate programming – Wikipedia). Oft planen und strukturieren die Praktiker die Codelogik im Voraus, zerlegen das Problem und erklären es im Text Schritt für Schritt, während Codeausschnitte die Erzählung stützen. Kurz gesagt behandelt der literarische Ansatz Code als literarisches Artefakt und stellt das menschliche Verständnis, eine strenge Struktur und die Transparenz der Absicht an die erste Stelle.

Vibe Coding: Code nach Intuition und mit KI-Unterstützung

Vibe Coding hingegen ist ein zeitgenössisches Paradigma, das parallel zu leistungsfähigen KI-Programmierassistenten entstanden ist. Der Begriff bezeichnet einen Entwicklungsstil, bei dem sich der Programmierer beim intuitiven Programmieren „ganz den Vibes hingibt“ (Vibe Coding is Real). Statt jede Codezeile von Hand zu schreiben, beschreibt der Entwickler in natürlicher Sprache, was er haben möchte (den „Vibe“ oder die Idee des Features), und überlässt es einem KI-System (etwa einem LLM-basierten Werkzeug wie ChatGPT, GitHub Copilot oder Cursor), den eigentlichen Code zu erzeugen (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Andrej Karpathy hat diese Erfahrung knapp beschrieben: „Ich sehe einfach Zeug, sage Zeug, führe Zeug aus und kopiere Zeug hin und her, und meistens funktioniert es.“ (Vibe Coding is Real). Beim Vibe Coding tritt der Code selbst im Kopf des Entwicklers in den Hintergrund. Man kann sogar „vergessen, dass es den Code gibt“, während man sich auf das gewünschte Ergebnis konzentriert (Vibe Coding is Real). Der Prozess ist stark iterativ und explorativ: Der Entwickler führt den KI-generierten Code aus, beobachtet das Ergebnis und ändert bei Problemen einfach den Prompt oder übernimmt die von der KI vorgeschlagenen Korrekturen und versucht es noch einmal (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Das steht in scharfem Gegensatz zu traditionellen Programmierpraktiken, die sorgfältige Planung und das Verständnis der Implementierungsdetails vor der Ausführung betonen (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Vibe Coding setzt auf Tempo, Kreativität und eine niedrige Einstiegshürde: Eine Idee soll genügen, um mit dem Programmieren anzufangen (Vibe Coding is Real). Der Ansatz „demokratisiert“ das Programmieren, weil auch Menschen ohne Programmierkenntnisse über Beschreibungen in natürlicher Sprache funktionierenden Code hervorbringen können (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Er stützt sich stark auf Intuition und auf das Vertrauen in die Kompetenz der KI und schätzt schnelles Prototyping und freies Experimentieren höher als vorab festgelegte Struktur oder ein tiefes Verständnis des erzeugten Codes.

Dokumentation und Struktur

Besonders deutlich unterscheiden sich Literate Programming und Vibe Coding in ihrer Haltung zu Dokumentation und Programmstruktur:

  • Literate Programming: Dokumentation ist Code. Beim Literate Programming lässt sich die Dokumentation nicht vom Quellcode trennen. Der Programmierer schreibt ausführliche Erklärungen in natürlicher Sprache und fügt Codeblöcke ein, die jeden Teil der Logik veranschaulichen oder umsetzen. So entsteht eine erzählerische Struktur: Die Reihenfolge der Themen folgt der logischen Überlegung des Programmierers zum Problem und nicht unbedingt der Reihenfolge, in der der Computer die Anweisungen ausführt (Literate programming – Wikipedia). Das Ergebnis ist ein reichhaltiges Dokument, das zugleich das Programm und seine eigene Erklärung ist. Knuth argumentiert, dass diese Methode „erstklassige Dokumentation“ hervorbringt, die „im Prozess der Darstellung ganz natürlich gewachsen“ ist. Der Autor (oder jeder andere Leser) kann so nachvollziehen, wie das Programm aufgebaut ist, und beim späteren Wiederlesen des Codes sogar den eigenen Gedankengang neu starten (Literate programming – Wikipedia). Jedes Stück Code ist von einer Erklärung seines Zwecks umgeben, und übergeordnete Konzepte werden über pseudocodeartige Makros eingeführt, die sich zu konkretem Code verfeinern lassen. Das ergibt eine geschichtete Top-down-Struktur (Literate programming – Wikipedia) (Literate programming – Wikipedia). Hinter dieser Betonung von Struktur und Dokumentation steht die Überzeugung, dass klares Denken zu besseren Programmen führt: Wer seine Gedanken ausformuliert, dem fallen schlechte Designentscheidungen eher auf, und er kann sie früh korrigieren (Literate programming – Wikipedia). Der Lohn sind Wartbarkeit und Lesbarkeit. Die Dokumentation ist kein getrenntes Artefakt, sondern in den Code eingebaut, sodass sie aktuell bleibt, während sich der Code weiterentwickelt. Allerdings verlangt der Ansatz Disziplin: Es kostet erheblichen Aufwand im Voraus, den erklärenden Text zu schreiben und zu pflegen, und man muss bereit sein, das Programm didaktisch aufzubauen. Im Kern versteht Literate Programming die Programmstruktur als Abbild der logischen Erzählung und die Dokumentation als Grundelement des Programmierens.
  • Vibe Coding: Wenig Dokumentation, Struktur entsteht nebenbei. Vibe Coding stellt diese Philosophie fast auf den Kopf. Ausdrückliche Dokumentation ist hier spärlich oder fällt nur beiläufig an. Der wichtigste Beitrag des Entwicklers ist ein Prompt in natürlicher Sprache, der die gewünschte Funktion beschreibt, aber dieser Prompt richtet sich an das KI-Werkzeug und nicht unbedingt an menschliche Leser in der Zukunft (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Die „Dokumentation“ besteht beim Vibe Coding vielleicht nur aus dem Verlauf der Prompts oder ein paar Kommentaren, die die KI im Code hinterlassen hat. Im Allgemeinen entsteht dabei keine zusammenhängende erzählerische Erklärung dafür, wie der Code funktioniert. Tatsächlich versteht der Urheber das Innenleben des erzeugten Codes womöglich gar nicht vollständig (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Die Struktur des fertigen Programms bestimmen weitgehend die Interpretation und die Generierung der KI. Die Organisation des Codes kann deshalb eher emergent oder von außen auferlegt wirken als vom menschlichen Entwickler sorgfältig entworfen. In traditionellen Begriffen ist Vibe Coding aus menschlicher Sicht unstrukturiert: Man springt von einer Idee zur nächsten, erzeugt unverbundene Codestücke und verlässt sich dann darauf, dass die KI (oder weitere Prompts) sie zusammenfügt. Designdokumente oder erklärende Prosa im Voraus gibt es kaum. Struktur entsteht, wenn überhaupt, durch schrittweises Verfeinern (etwa wenn der Nutzer merkt, dass er eine Funktion braucht, und die KI per Prompt damit beauftragt). Dieser minimalistische Umgang mit Dokumentation tauscht die Klarheit und Formalität des Literate Programming gegen Tempo und Bequemlichkeit ein. Philosophisch geht Vibe Coding davon aus, dass der Code später für sich selbst sprechen kann (oder dass künftige Maintainer bei Bedarf eine KI um eine Erklärung bitten können), aber im Moment räumt es einer für Menschen lesbaren Erklärung keinen Vorrang ein. Es stützt sich auf die Vorstellung, dass funktionierender Code das Ziel ist und sich Dokumentation oder Struktur bei Bedarf nachtragen lassen (eine Haltung, die zu vielen Philosophien des schnellen Prototypings passt). Das offensichtliche Risiko: Ohne leitende Erzählung oder Struktur ist der entstandene Code für Menschen womöglich schwerer nachzuvollziehen, vor allem wenn die ursprünglichen Prompts und die Überlegungen der KI nicht festgehalten wurden. Der Mangel an eingebauter Dokumentation gefährdet daher die langfristige Lesbarkeit der Software und lädt Tests oder späteren Kommentaren die Last auf, zu erklären, warum der Code existiert und wie er aufgebaut ist.

Intuition und Programmierprozess

Intuition und Planung im Literate Programming: Der literarische Ansatz ist bedacht und methodisch, schließt Kreativität aber nicht aus. Er lenkt sie in eine geordnete Form. Oft beginnt der Prozess mit dem intuitiven Verständnis des Problems, doch diese Intuition muss in eine klare Erklärung übersetzt werden. Intuitive Sprünge werden also nachträglich in Prosa dokumentiert und begründet. Knuth betont, man solle Programme schreiben wie einen Essay oder eine Geschichte (Donald Knuth). Das heißt, Sie müssen die Darstellung planen: Sie skizzieren die Struktur des Programms, entscheiden, wie Sie die Konzepte vom Allgemeinen zum Besonderen präsentieren, und achten sorgfältig darauf, dass jeder Teil logisch zum nächsten führt. Das fördert ein tieferes Verständnis des Problems, denn der Programmierer unterrichtet im Grunde den künftigen Leser (und sich selbst) über die Lösung. Intuitiv ist daran, wie man ein Problem erklärt oder zerlegt (das ist eine kreative Entscheidung), aber insgesamt neigt Literate Programming eher zur Analyse als zur Improvisation. Das Ausformulieren kann sogar Fehler in der eigenen Intuition aufdecken, wie Knuth anmerkte: „Die Gedanken hinter dem Programm ausdrücklich zu formulieren [macht] schlecht durchdachte Designentscheidungen offensichtlicher.“ (Literate programming – Wikipedia). Ein Literate Programmer nutzt also durchaus seine Intuition, um eine Lösung zu finden, aber der Ansatz zwingt ihn, diese Intuition durch rationale Darlegung zu prüfen und zu strukturieren. Der Programmierprozess ist in diesem Paradigma oft langsamer und nachdenklicher. Man schreibt vielleicht einen Abschnitt aus Erklärung und Code, testet ihn und geht dann zurück, um die Erklärung klarer zu fassen oder den Code stimmiger zu machen. Der Programmierer fragt sich gewissermaßen laufend „Ergibt das für einen menschlichen Leser Sinn?“ ebenso wie „Funktioniert das für die Maschine?“ Die philosophische Haltung dahinter: Diese intellektuelle Disziplin spart am Ende Zeit bei Debugging und Wartung („die Zeit für die Organisation wird durch die beim Debugging gesparte Zeit mehr als wettgemacht“ (Donald Knuth)), und es entsteht eine Codebasis, die mit Absicht und Weitblick entwickelt wurde.

Intuition und Flow beim Vibe Coding: Vibe Coding baut auf Intuition und Flow. Schon das Wort „Vibe“ legt nahe, dem Bauchgefühl oder dem kreativen Impuls zu folgen. Der Entwickler führt eine Art spontanes Gespräch mit der KI, fast wie improvisiertes Pair Programming. Formale Planung im Voraus gibt es kaum. Sie beginnen mit einer groben Idee und lassen den Code Gestalt annehmen. Der Ansatz nimmt Versuch und Irrtum als natürlichen Teil der Arbeit an: Sie werfen der KI eine Idee hin, schauen, was zurückkommt, und passen dann Ihre Idee an oder bitten um Änderungen. Der Prozess ist stark interaktiv und explorativ, was sich sehr kreativ und befreiend anfühlen kann. Er ähnelt dem Skizzieren oder dem Jammen in der Musik: Sie probieren schnell etwas aus, hören, ob es richtig „klingt“, und wenn nicht, spielen Sie weiter damit herum. Karpathys Beschreibung „Zeug sehen, Zeug sagen, Zeug ausführen“ trifft die spontane, iterative Schleife des Vibe Coding (Vibe Coding is Real). Weil die KI die Schwerarbeit beim Erzeugen des Codes übernimmt, kann der menschliche Programmierer von einem Gedanken zum nächsten springen, ohne an Syntax oder Low-Level-Details hängen zu bleiben. Das kann in einen Flow führen, in dem der Entwickler intuitiv und schnell Features als Prototypen baut und darauf vertraut, dass die KI die Lücken füllt. Die Intuition ist hier das Wichtigste: Erfolg hat, wer zur richtigen Zeit das Richtige verlangt und weiß, wann sich die Ausgabe der KI akzeptabel „anfühlt“ und wann sie überarbeitet werden muss. Philosophisch verschiebt sich damit die Rolle des Programmierers: vom Autor, der jede Zeile sorgfältig ausarbeitet (wie im Literate Programming), zum Kurator oder Regisseur, der einen KI-Agenten mit allgemein gehaltenen Anweisungen führt. Dieser intuitionsgetriebene Prozess hat allerdings seine Schattenseiten. Weil kaum geplant wird, kann man in Sackgassen geraten oder uneinheitliche Codestrukturen erzeugen, die später ein Refactoring erfordern. Auch das Debugging kann darauf hinauslaufen, die KI intuitiv so lange zu bearbeiten, bis sie das Problem preisgibt oder behebt. Ein Nutzer spottete: „Vibe Coding ist ein einziger Spaß, bis man vibe-debuggen muss.“ (Vibe Coding is Real). Im Grunde behandelt Vibe Coding das Programmieren als interaktives, intuitives Erlebnis und nicht als sorgfältig konstruierten Prozess. Es holt das Maximum an kreativem Schwung und unmittelbarem Fortschritt heraus, womöglich auf Kosten des tieferen Verständnisses. Philosophisch vertraut es darauf, dass sich Probleme im Moment lösen lassen, durch wiederholtes Prompten, statt sie durch Überlegungen im Voraus zu verhindern.

Auswirkungen auf Kreativität und Ideenfindung

Literate Programming und Vibe Coding wirken sich beide stark, aber unterschiedlich auf die Kreativität in der Softwareentwicklung aus:

  • Literate Programming und Kreativität: Auf den ersten Blick scheint Literate Programming eine Struktur vorzugeben, die Spontaneität einengen könnte. Tatsächlich fördert es eine andere Art von Kreativität: die Kreativität von Kommunikation und Design. Weil man den Code klar erklären muss, denkt ein Literate Programmer oft gründlicher über das Design nach und erkundet mehrere Wege, ein Konzept darzustellen oder umzusetzen. Das kann zu neuartigen Lösungen führen, denn beim Ausformulieren von Erklärungen entstehen neue Ideen oder es fallen Ineffizienzen in der Logik auf. Literate Programming lässt Raum für Kreativität darin, wie eine Lösung entworfen und erklärt wird: Der Programmierer kann Abstraktionen einführen (über Makros oder die erzählerische Struktur), die bei linearem Programmieren nicht naheliegen würden. Es ist ein wenig wie kreatives Schreiben: Innerhalb der Grenzen der Prosa entdeckt man oft elegante Formulierungen für die eigenen Gedanken. Außerdem kann Literate Programming die Kreativität in komplexen Problembereichen stärken (etwa bei Algorithmen oder im wissenschaftlichen Rechnen), weil Sie Komplexität bewältigen, indem Sie sie Stück für Stück abstrahieren und erklären. Die Pflicht, laufend mitzudokumentieren, kann Inspirationsschübe allerdings bremsen: Sie haben vielleicht eine brillante Idee, müssen sich aber trotzdem die Zeit nehmen, sie klar zu formulieren, damit sie in die literarische Erzählung passt. Manche Entwickler empfinden das womöglich als Hemmnis für schnelles Experimentieren. Insgesamt nährt der Ansatz die Kreativität auf der Ebene von Architektur und Erklärung, lenkt kreative Energie aber eher in eine durchdachte Form als ins schnelle Prototyping. Das Ergebnis ist oft Code, der innovativ und zugleich begründet ist: Hinter kreativen Entscheidungen steht im Text eine Begründung.
  • Vibe Coding und Kreativität: Vibe Coding zielt ausdrücklich darauf ab, Kreativität und schnelle Ideenfindung zu fördern. Es senkt die Hürde, aus einer Idee funktionierenden Code zu machen, und beschleunigt damit die Prototyping-Phase der Entwicklung enorm (The Rise of Vibe Coding – Lovable Blog) (The Rise of Vibe Coding – Lovable Blog). Entwickler (und sogar Nicht-Entwickler) können beim Ausprobieren von Ideen mutiger sein, weil ein Fehlschlag wenig kostet: Sie lassen die KI einfach etwas erzeugen, und wenn es nicht funktioniert oder nicht Ihrer Vorstellung entspricht, versuchen Sie einen anderen Prompt oder ändern die Ausgabe. Durch diese Unmittelbarkeit werden mehr Ideen getestet und durchgespielt, was zu sehr kreativen Ergebnissen führen kann. Seine Stärken zeigt Vibe Coding etwa bei Spieleprototypen oder beim Skripten, wo ein spielerisches Vorgehen nach dem Prinzip von Versuch und Irrtum rasch interessante Ergebnisse liefern kann (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Es „macht Code ‘demokratischer’“ und lässt Menschen, die Ideen, aber keine fortgeschrittenen Programmierkenntnisse haben, an der Softwareentwicklung teilhaben (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). In diesem Sinn setzt es Kreativität bei einem breiteren Publikum frei: Der „Ideenmensch“ kann jetzt mit der KI als Übersetzer tatsächlich programmieren (Vibe Coding is Real). Die freie Form des Vibe Coding kann allerdings auch zu chaotischen Implementierungen führen. Weil es um sofortige Funktionalität geht, sind die erzeugten Lösungen womöglich clevere Hacks oder Standardmuster aus den Trainingsdaten der KI und keine sorgfältig ausgearbeiteten eigenen Algorithmen. Kreativität steckt darin, was Sie bauen und wie schnell Sie iterieren können, aber vielleicht weniger in der Low-Level-Implementierung (die an die KI ausgelagert ist). Hat die KI zudem Grenzen (sie kann zum Beispiel womöglich keinen wirklich neuartigen oder komplexen Code erzeugen, der über das hinausgeht, was sie gesehen hat), stoßen Sie vielleicht an eine Decke, an der die Vorstellungskraft der KI Ihre kreative Vision begrenzt. Alles in allem löst Vibe Coding einen Wirbel aus kreativer Aktivität und Brainstorming aus und schätzt Erkundung und „Vibes“ höher als strenge Analyse. Kreativ kann das enorm befreiend sein und die Softwareentwicklung in eine Art interaktive Kunstsitzung verwandeln. Die Herausforderung besteht darin, dass aus dieser Kreativität tragfähige Ergebnisse werden und nicht bloß Wegwerf-Experimente. Hier braucht es womöglich etwas Struktur (oder spätere Dokumentation), wenn aus dem kreativen Prototyp ein ausgereiftes Produkt werden soll.

Wartbarkeit und langfristige Tragfähigkeit

Die Philosophien von Literate Programming und Vibe Coding führen bei Wartbarkeit und Lebensdauer von Softwareprojekten zu unterschiedlichen Ergebnissen:

  • Wartbarkeit im Literate Programming: Wartbarkeit ist von vornherein eine Kernstärke des Literate Programming. Weil den Code eine ausführliche Erklärung begleitet, warum und wie er funktioniert, können künftige Leser (auch der ursprüngliche Autor nach einiger Zeit) die Absicht hinter jedem Teil des Programms verstehen (Literate programming – Wikipedia). Knuth beobachtete, dass der Autor beim Wiederlesen der Dokumentation „seine eigenen Gedankengänge zu jedem späteren Zeitpunkt neu starten“ kann, was es viel leichter macht, den Code korrekt zu aktualisieren oder zu ändern (Literate programming – Wikipedia). Weil die Struktur der menschlichen Logik und nicht der Reihenfolge der Maschine folgt, kann ein Maintainer bei geänderten Anforderungen außerdem die betreffende Stelle der Erzählung finden und den Code im Zusammenhang anpassen, statt die Logik aus verstreuten Implementierungsdetails zu erraten. Im Grunde baut Literate Programming eine solide Wissensbasis in den Code selbst ein, und das hilft der langfristigen Tragfähigkeit sehr. Taucht ein Bug auf, kann der Entwickler oft in der Erklärung nachsehen, ob der Code wie beabsichtigt umgesetzt wurde oder ob schon die Absicht fehlerhaft war. Ebenso kann die literarische Dokumentation Portierungen oder Optimierungen leiten, falls die Software sie braucht (Knuth merkte sogar an, dass diese übergeordnete Sicht das Portieren von TeX auf mehrere Compiler und Plattformen erleichterte) (Literate programming – Wikipedia). Das Bekenntnis zur Klarheit deckt zudem Designprobleme tendenziell früh auf, was bestimmte Klassen von Bugs gar nicht erst entstehen lassen kann (Literate programming – Wikipedia). Manche bezweifeln allerdings, dass Literate Programming in sehr großen oder schnelllebigen Projekten praktikabel ist. Es erfordert ständigen Aufwand, die Dokumentation im Gleichschritt mit dem Code zu aktualisieren. Im Team muss jeder Beteiligte im literarischen Stil schreiben und die erzählerische Struktur respektieren, was umständlich sein kann. Hält sich nicht jeder gewissenhaft daran, kann die Dokumentation aus dem Takt geraten, und das schadet der Wartbarkeit. Dazu kommt der Mehraufwand durch die nötigen Spezialwerkzeuge (Weaver, Tangler und so weiter). Richtig umgesetzt liefert Literate Programming aber Code, der sehr gut wartbar bleibt und sich sogar über Jahre selbst trägt. Projekte wie TeX (im literarischen Stil geschrieben) waren langfristig erfolgreich und angesichts ihrer Komplexität relativ leicht zu pflegen, was auch an diesem Ansatz liegt. Zusammengefasst optimiert Literate Programming für die Zukunft: Es opfert etwas unmittelbares Tempo, damit andere (oder später der Autor selbst) das Projekt mit möglichst wenig Verwirrung verstehen, ändern und weiterführen können.
  • Wartbarkeit beim Vibe Coding: Vibe Coding in Reinform tauscht Wartbarkeit gegen kurzfristige Produktivität. Weil der Code sehr ad hoc durch wiederholtes Prompten erzeugt und geändert wird, fehlen dem Ergebnis womöglich eine stimmige Struktur oder eine im Code dokumentierte klare Begründung. Zieht sich die Person zurück, die eine Software „gevibecodet“ hat, steht ein anderer Entwickler, der diesen Code erbt, womöglich vor Schwierigkeiten. Er hat dann Code vor sich, der funktioniert, dessen Designentscheidungen aber nicht offensichtlich sind: Das Wissen steckt im Kopf des ursprünglichen Entwicklers (oder im Verlauf der KI-Prompts, falls er überhaupt festgehalten wurde) und nicht in der Codebasis. Das kann Debugging oder Erweiterungen schwierig machen. Ein Kommentar merkte an, dass diese KI-gestützten Werkzeuge Code erzeugen können, in dem „Bugs bestehen bleiben und der Code schnell ‘zu groß’ werden kann“, dass die Komplexität also über das hinauswächst, was der Mensch noch gut versteht (Vibe Coding is Real). In einem per Vibe Coding entstandenen Projekt fragen sich die Maintainer vielleicht ständig „Was sollte dieser Code eigentlich tun?“ und führen mangels Dokumentation am Ende erneut KI-Prompts aus, um ihn erklären oder umbauen zu lassen. Die Absicht wird so im Nachhinein neu entdeckt. Außerdem kann KI-generierter Code subtile Probleme oder ineffiziente Muster enthalten, die in der schnellen Entwicklungsphase niemandem aufgefallen sind. Deshalb warnen viele Fachleute, dass Vibe Coding zwar stark bei Prototypen ist, ohne zusätzliche Aufsicht aber „noch nicht dafür geeignet ist, Anwendungen zu entwickeln, die in Produktion gehen“. Codequalität und menschliches Verständnis bleiben bei ernsthaften Projekten unverzichtbar (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Die langfristige Tragfähigkeit eines solchen Projekts erfordert womöglich eine spätere Phase, in der Entwickler Struktur und Dokumentation nachträglich einbringen. Hat ein Team etwa rasch einen Prototyp per Vibe Coding gebaut, muss es danach womöglich die Codebasis umbauen, Kommentare oder Designdokumente ergänzen und Tests schreiben, die das Verhalten festhalten. Vibe Coding kann also eine Art Wartungsschuld aufbauen, die zu begleichen ist, wenn das Projekt überleben und wachsen soll. Dabei darf man nicht vergessen, dass sich das Umfeld weiterentwickelt: Befürworter des Vibe Coding arbeiten an besseren KI-Werkzeugen für Dokumentation und Codequalität (zum Beispiel an KI-Assistenten, die Code nicht nur erzeugen, sondern auch erklären oder bestimmte Architekturen durchsetzen) (The Rise of Vibe Coding – Lovable Blog) (The Rise of Vibe Coding – Lovable Blog). Reifen solche Werkzeuge, könnten sie einige Wartungsprobleme entschärfen: Die KI erzeugt dann vielleicht selbstdokumentierenden Code oder liefert zumindest nachvollziehbare Überlegungen. Beim heutigen Stand hängt die Tragfähigkeit eines per Vibe Coding entstandenen Projekts aber stark von der Disziplin seiner Maintainer ab, die KI-Ausgaben prüfen, Tests schreiben und womöglich nachträglich erklärende Kommentare ergänzen müssen. Zusammengefasst stellt Vibe Coding das sofortige Erschaffen über die strukturierte Langlebigkeit. Es kann den Weg zum funktionierenden Produkt verkürzen, riskiert ohne sorgfältige Nacharbeit aber Code, der langfristig fragil oder undurchschaubar ist.

Zusammenarbeit in Teams und Open-Source-Projekten

Softwareentwicklung ist heute oft Gemeinschaftsarbeit, ob im Unternehmensteam oder in einer Open-Source-Community. Literate Programming und Vibe Coding beeinflussen die Zusammenarbeit auf ganz unterschiedliche Weise:

  • Zusammenarbeit im Team mit Literate Programming: Im Team kann Literate Programming ein zweischneidiges Schwert sein. Einerseits wird die Codebasis des Projekts extrem transparent, wenn alle im Team die literarische Philosophie mittragen. Neue Teammitglieder (oder Code-Reviewer) können die Erzählung durchlesen und rasch Zweck und Logik jedes Moduls erfassen. Das kann Onboarding und Wissensweitergabe erleichtern, weil der Code im Grunde seine eigene technische Dokumentation ist (Literate programming – Wikipedia). Wer etwas ändert, soll auch die Erklärung in Prosa aktualisieren und teilt dadurch wie von selbst mit, warum die Änderung erfolgt. Im Idealfall arbeitet ein solches Team mit einem hohen Maß an gemeinsamem Verständnis und wenig Insiderwissen, das in einzelnen Köpfen verborgen bleibt: Alles Wichtige steht im Literate-Programming-Quelltext. Das könnte Missverständnisse deutlich verringern und dafür sorgen, dass das Team eine einheitliche Vorstellung von der Software behält. Andererseits kann Literate Programming die gemeinsame Arbeit bremsen. Nicht jeder Entwickler schreibt gern zu jedem Commit ausführliche Dokumentation, und das kann sich wie ein Hemmschuh für schnelle Iteration anfühlen. In agilen Teams mit hohem Tempo gilt die Pflicht, eine verwobene Erzählung zu pflegen, womöglich als Mehraufwand. Der Ansatz verlangt außerdem Einheitlichkeit in Schreibstil und Struktur. Teams brauchen vielleicht einen Styleguide für Dokumentation, ähnlich einem Styleguide für Code. Vernachlässigen einige im Team die literarische Seite und kümmern sich nur darum, dass der Code läuft, können sie die Kette des Verstehens unterbrechen, und Teile des Codes sind dann schlechter dokumentiert als andere. Zudem braucht Literate Programming Werkzeuge, die alle im Team in ihren Arbeitsablauf einbauen müssen (Weaver, spezielle Editoren oder Notebook-Umgebungen), was eine Hürde sein kann. Außerhalb bestimmter Bereiche (etwa akademischer oder Forschungsprojekte) hat sich Literate Programming in großen kommerziellen Teams historisch nicht breit durchgesetzt, zum Teil wegen dieser praktischen Schwierigkeiten. Zusammengefasst fördert Literate Programming die Zusammenarbeit durch Klarheit und gemeinsame Dokumentation, aber nur, wenn sich das ganze Team darauf einlässt. Wenn es funktioniert, kann ein Team sehr wirksam gemeinsam über den Code nachdenken, aber es braucht dafür eine Kultur, die gründliche Dokumentation und Geduld in der Entwicklung schätzt.
  • Zusammenarbeit im Team mit Vibe Coding: Vibe Coding gehört zunehmend zum Werkzeugkasten heutiger Entwickler, seine Auswirkungen auf die Zusammenarbeit im Team werden daher gerade diskutiert. Im Team kann KI-basiertes Vibe Coding Entwicklungsaufgaben beschleunigen: Der Einzelne kann seinen Teil des Systems mit weniger Handarbeit rasch als Prototyp bauen. Das kann bei der Arbeitsteilung helfen, weil die Teammitglieder Features schneller liefern. Auch die Rollen könnten sich verschieben: Statt dass eine Person den gesamten Code für eine Komponente schreibt, könnte jemand das übergeordnete Design skizzieren, während andere den Detailcode mit KI ausarbeiten. Es gibt aber deutliche Schwierigkeiten bei der Zusammenarbeit. Erstens: Wenn jeder Entwickler für sich per „Vibe Coding“ arbeitet, ohne eine klar vereinbarte Struktur, kann die Codebasis in Stil und Vorgehen uneinheitlich werden. Der KI-generierte Code des einen verwendet womöglich andere Namenskonventionen oder Muster als der des anderen, weil sich KI-Modelle womöglich nicht an die internen Standards des Teams halten, solange man sie nicht ausdrücklich dazu anleitet. Diese Unterschiede können das Zusammenführen der einzelnen Teile schwierig machen. Auch das Code Review, eine tragende Praxis der Teamentwicklung, verändert sich. KI-generierten Code zu prüfen, kann schwieriger sein, wenn der menschliche Reviewer nicht weiß, warum der Code so geschrieben wurde (weil es womöglich keine klare Dokumentation gibt). Reviewer müssen besonders wachsam sein, um KI-Fehler oder unsinnigen Code zu finden, den der Urheber übersehen hat. Die Zusammenarbeit leidet auch, wenn sich Teammitglieder so sehr auf die KI verlassen, dass ihr eigenes Verständnis oberflächlich bleibt. Ein Entwickler committet vielleicht ein Stück Code von der KI, das „zu funktionieren schien“, doch wenn ein Kollege nachfragt oder ein Bug auftritt, kann der ursprüngliche Autor die Logik womöglich kaum erklären. Das kann Debugging-Sitzungen oder Designdiskussionen verlangsamen. Für das Projektmanagement kann Vibe Coding Unsicherheit bedeuten: Aufgaben sind vielleicht viel schneller erledigt als geschätzt (wenn die KI sie gut bewältigt), oder sie stoßen auf unvorhergesehene Hindernisse (wenn die KI-Ausgabe schlecht ist und mehrere Iterationen braucht). Teamleiter müssen diese Schwankungen womöglich einplanen. Positiv gesehen könnte gut gesteuertes Vibe Coding den Teammitgliedern Freiraum für übergeordnetes Design und Integrationsfragen verschaffen und so die Zusammenarbeit auf Architekturebene verbessern. Statt Zeit mit Boilerplate-Code zu verbringen, könnten Entwickler zum Beispiel besprechen, wie ihre Komponenten zusammenspielen, und die KI das Boilerplate erledigen lassen. Dieses Idealbild erfordert aber wohl Richtlinien: Teams könnten bewährte Verfahren für das Prompten, Erwartungen an den Codestil und verpflichtende Kommentare für KI-generierte Abschnitte festlegen (z. B. „Diese Funktion wurde auf Basis von Prompt Y erzeugt, um X zu tun“). In einem offenen Kommunikationsklima tauschen Entwickler vielleicht sogar Prompt-Techniken aus und arbeiten damit gemeinsam daran, die KI am besten zu nutzen, eine neue Form der Teamarbeit. Zusammengefasst ist Vibe Coding im Team leistungsstark, muss aber von strengen Entwicklungsstandards geleitet werden, um zu wirken. Sonst drohen Verwirrung, versteckte technische Schulden und eine schwankende Codequalität, die die Zusammenarbeit behindern.
  • Open Source und Auswirkungen auf die Community: Open-Source-Projekte bringen eine weitere Perspektive ein: Beitragende aus aller Welt, mit unterschiedlichem Engagement und Hintergrundwissen. Literate Programming ist im Open-Source-Bereich relativ selten, kann bei komplexen Projekten aber sehr nützlich sein. Ist ein Open-Source-Projekt literarisch geschrieben, senkt das die Hürde für neue Beitragende, das System zu verstehen. Knuth veröffentlichte zum Beispiel den Quellcode von TeX und METAFONT in literarischer Form (als Bücher), was anderen half, diese vielschichtigen Systeme zu begreifen. In jüngerer Zeit ist die Idee in Data-Science-Projekten wieder aufgetaucht, wo Jupyter Notebooks (ein modernes, dem Literate Programming ähnliches Werkzeug) den Code begleiten und Analysen oder Algorithmen erklären. In der Praxis bleiben die meisten Open-Source-Projekte jedoch bei traditionellem Code mit getrennter Dokumentation. Ein literarischer Stil könnte manche potenziellen Beitragenden abschrecken, die die Werkzeuge nicht kennen oder das ausführliche Format mühsam finden, wenn sie nur einen kleinen Bug beheben wollen. Er kann auch den Build-Prozess verkomplizieren (weil der Code vor dem Kompilieren „getangelt“ werden muss). Literate Programming kann ein Open-Source-Projekt also durch seine Dokumentationsqualität sehr einladend machen, verkleinert aber womöglich den Kreis der Beitragswilligen auf jene, die den Ansatz mittragen. Am besten funktioniert es bei Open-Source-Projekten, die eher Wissensressourcen sind (Lehrcode, Beispiele, Forschungscode), und weniger bei sich schnell entwickelnden Produkten. Vibe Coding im Open-Source-Bereich ist ein neues Thema. Einerseits könnte KI-Unterstützung mehr Menschen Beiträge zu Open-Source-Projekten ermöglichen, weil sie ihnen hilft, Code in unbekannten Sprachen oder Frameworks zu schreiben, ganz im Sinn der Demokratisierung des Programmierens. Ein motivierter Nutzer könnte mit Vibe-Coding-Werkzeugen ein Problem beheben oder ein Feature ergänzen und dann einen Pull Request einreichen. Das könnte die Zahl der Beiträge erhöhen. Andererseits sind die Maintainer von Open-Source-Projekten bei KI-generierten Beiträgen womöglich vorsichtig. Ohne sorgfältige Prüfung kann ein Patch, der „gut aussieht“, dessen Autor ihn aber nicht ganz verstanden hat, Bugs oder Sicherheitslücken einschleppen. Dazu kommt die Frage nach Lizenz und Eigenständigkeit: Die KI gibt womöglich Code aus den Trainingsdaten wieder, der unter einer inkompatiblen Lizenz steht, oder erzeugt unidiomatischen Code, der nicht zum Stil des Projekts passt. Manche Open-Source-Communitys diskutieren bereits Richtlinien für den KI-Einsatz, zum Beispiel die Pflicht für Beitragende zur Zusicherung, dass sie den Code verstehen, den sie einreichen, unabhängig davon, wie er entstanden ist. In einem gemeinschaftlichen Open-Source-Projekt sollte ein per Vibe Coding entstandener Beitrag idealerweise Tests und Erklärungen in der Commit-Nachricht oder der Beschreibung des Pull Requests mitbringen, um den Reviewern zu helfen. Überlegt eingesetzt könnte KI die Einstiegshürde so senken, wie sie es auch sonst tut: Auch wer einen Bugfix zwar beschreiben, aber nicht selbst programmieren kann, könnte dann mitwirken. Die langfristige Wirkung auf die Tragfähigkeit von Open Source ist ungewiss: Es könnte eine Welle neuer Maintainer entstehen, die sich auf KI stützen (was Projekte lebendiger macht), oder die Core Maintainer könnten unter dem Review vieler KI-generierter Gelegenheitspatches von schwankender Qualität leiden. Philosophisch zwingt Vibe Coding die Open-Source-Community, sich damit auseinanderzusetzen, was es heißt, „seinen Code zu kennen“, ein Wert, der im Open-Source-Bereich traditionell hochgehalten wird. Zusammengefasst kann Literate Programming Open-Source-Projekte verständlicher machen, ist wegen des Aufwands aber unüblich, während Vibe Coding die Zahl der Beiträge erhöhen könnte, aber wachsame Praktiken der Zusammenarbeit braucht, um Qualität und Stimmigkeit gemeinschaftlich entwickelter Software zu wahren.

Ist Vibe Coding ein Nachfolger des Literate Programming?

Lässt sich Vibe Coding bei allen Unterschieden als philosophischer Nachfolger des Literate Programming betrachten? Die Antwort fällt differenziert aus. In mancher Hinsicht teilen Vibe Coding und Literate Programming einen gemeinsamen Geist: Beide Paradigmen entstanden aus dem Bemühen, das Programmieren stärker an menschlichen Denkprozessen auszurichten und weniger an den Beschränkungen der Maschine. Literate Programming hob das Gespräch über Code auf eine höhere Ebene, indem es ihn mit menschlicher Sprache verschmolz. Es war ein Sprung in Richtung einer menschenfreundlicheren Softwareentwicklung und erkannte an, dass Menschen Code verstehen müssen. Auch das von KI-Fortschritten getragene Vibe Coding will eine Lücke schließen: Es nimmt dem Menschen die Last ab, Code zu erzeugen, und lässt ihn in natürlicher Sprache mit dem Computer umgehen, einer sehr menschlichen Art der Kommunikation (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). In diesem philosophischen Sinn führt Vibe Coding den Gedanken fort: „Machen wir Programmieren mehr zu einer Sache der Ideen und weniger der Mechanik.“ Beide Ansätze lassen sich als Gegenreaktion auf die maschinenzentrierte Sicht des Programmierens lesen: Knuths Ansatz sagte Schreiben Sie für Menschen, nicht für Maschinen (Donald Knuth), und Karpathys Vibe Coding sagt im Grunde Drücken Sie Ihre Absicht einfach (gegenüber einer Maschine) so aus, als sprächen Sie mit einem Menschen. Interessanterweise kehren beide die Rolle der natürlichen Sprache um: Literate Programming nutzt Englisch (Prosa), um anderen Menschen Code zu erklären, Vibe Coding nutzt Englisch (Prompts), um einer Maschine den gewünschten Code zu erklären, die ihn dann erzeugt. Sie treffen sich in der Mitte bei der Vorstellung, dass natürliche Sprache und menschliche Intuition einen zentralen Platz im Programmieren haben.

In der Praxis ist Vibe Coding jedoch kein geradliniger Nachfolger des Literate Programming. Es ist fast eine Splitterbewegung, deren Philosophie in mehreren Kernpunkten quer dazu steht. Man könnte sagen, Vibe Coding ist weniger ein Nachkomme als eine radikale Abweichung, in der sich die neuen Möglichkeiten (und Probleme) der KI-getriebenen Entwicklung spiegeln. Die Grundannahme des Literate Programming sind Verständnis und Klarheit, die des Vibe Coding Produktivität und Kreativität. Das eine schreibt Wissen in den Code hinein, das andere holt (über die KI) Code aus dem eigenen Wissen heraus. Wenn es beim Literate Programming darum geht, ein bedachter Lehrer für das eigene künftige Ich und für andere zu sein, dann geht es beim Vibe Coding darum, Entdecker oder Künstler zu sein und den Werkzeugen die Details zu überlassen. Manche könnten sogar sagen, Vibe Coding stehe den Idealen des Literate Programming philosophisch entgegen: Vibe Coding lädt Sie ein zu „vergessen, dass es den Code überhaupt gibt“ (Vibe Coding is Real) und sich um das Innenleben nicht zu kümmern, Literate Programming dagegen fordert Sie auf, jedes Detail zu untersuchen und zu erklären. Unter dem Blickwinkel von Wartbarkeit und Werten der Softwaretechnik lässt sich Vibe Coding als Gegenreaktion auf Formalität verstehen und als Hinwendung zu einem postmodernen Programmieren, bei dem die Wahrheit des Programms das ist, was im Moment funktioniert, mit der Option, es mit KI-Hilfe laufend neu zu schreiben. Literate Programming glaubt aus einer eher modernistischen Perspektive an objektives Verständnis und eine beständige Dokumentation der Absicht eines Programms.

Betrachtet man die Auswirkungen auf Kreativität, Wartbarkeit und Zusammenarbeit, dann „beerbt“ Vibe Coding das Literate Programming nicht so sehr, es gewichtet diese Faktoren vielmehr anders. Vibe Coding steigert Kreativität und schnelles Prototyping enorm (wohl stärker, als Literate Programming es je anstrebte) und passt in eine Zeit, in der KI Routineaufgaben übernehmen kann und Menschen Freiraum für kreatives Denken auf konzeptioneller Ebene erhalten (The Rise of Vibe Coding – Lovable Blog). Das Literate Programming hat bei Klarheit und Langlebigkeit jedoch hohe Maßstäbe gesetzt, die Vibe Coding derzeit nicht erreicht. Es sagt einiges, dass Fachleute heute raten, Vibe Coding vor allem für kleine oder experimentelle Projekte zu nutzen, und vor dem unkontrollierten Einsatz in kritischen Produktivsystemen warnen, solange Verständnis und Tests nicht wieder ergänzt werden (‘Vibe coding’ increasingly becoming standard for development – Techzine Global) (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Versteht man „Nachfolger“ im philosophischen Sinn als „etwas, das auf dem Vorgänger aufbaut und ihn verbessert“, dann ist Vibe Coding kein echter Nachfolger des Literate Programming, weil es das nicht verbessert, worum es dem Literate Programming am meisten ging: das ausdrückliche menschliche Verständnis. Es verschiebt den Schwerpunkt auf andere Werte: Zugänglichkeit, Tempo und die Vorstellung, dass Code vergänglich ist und sich leicht neu schreiben lässt. Möglich wird diese Verschiebung durch einen hochentwickelten KI-Vermittler, den Knuth 1984 nicht hatte. Man könnte sagen, Vibe Coding ist für das heutige KI-Zeitalter, was Literate Programming für die frühe Zeit der strukturierten Programmierung war: Beide sind Kinder ihrer Zeit und antworten auf das, was ihren Befürwortern am jeweils herrschenden Programmierparadigma fehlte.

Denkbar ist, dass künftige Entwicklungsmethoden die Stärken beider Ansätze vereinen wollen, etwa mit KI-Werkzeugen, die aus einem Prompt nicht nur Code, sondern auch für Menschen lesbare Erklärungen dieses Codes erzeugen (Auto-Literate Coding), oder mit KI-gestützten Literate-Programming-Umgebungen, die aus einer literarischen Beschreibung Vorschläge für Code-Implementierungen ableiten. Solche Hybride könnten die wahren „Nachfolger“ sein, die Intuition und Erklärung verbinden und uns das Beste aus beiden Welten geben. Derzeit ist Vibe Coding eher eine Ergänzung traditioneller Methoden als ein Ersatz für die Philosophie des gründlichen Verstehens, für die Literate Programming steht. Es trägt den Staffelstab weiter, das Programmieren stärker auf menschliche Ideen auszurichten, lässt aber den Staffelstab fallen, der dafür sorgt, dass diese Ideen für andere sorgfältig dokumentiert werden. Ob die Branche zurückgeht und diesen Stab wieder aufhebt (vielleicht durch KI-generierte Dokumentation), bleibt abzuwarten.

Fazit

Literate Programming und Vibe Coding bieten zwei überzeugende und philosophisch ergiebige Sichtweisen auf das Programmieren. Literate Programming mit seinem Leitsatz „Programme sind dazu da, von Menschen gelesen zu werden“ (Donald Knuth) versteht Programmieren als Akt des Lehrens und der Kommunikation. Sein Beharren auf Dokumentation und Struktur legt ein starkes Fundament für Wartbarkeit, Klarheit und gemeinsames Verständnis, was langfristigen Projekten und komplexen Systemen sehr zugutekommen kann. Vibe Coding, entstanden in einer Zeit, in der KI mitgestaltet, denkt Programmieren als dialogischen, intuitiven Akt neu, bei dem eine Idee und der richtige „Vibe“ genügen können, um funktionierende Software zu erzeugen. Dieser Ansatz hat die Tür für mehr Kreativität und Teilhabe in der Entwicklung geöffnet: Der Weg vom Konzept zum Code wird kürzer, und neuartige Experimente werden möglich, um den Preis von weniger eingebauter Klarheit.

In der heutigen Softwareentwicklung finden beide Ansätze ihre Nischen. Literate Programming inspiriert weiterhin Werkzeuge wie Jupyter Notebooks und dokumentationszentrierte Frameworks und zeigt seinen Wert vor allem dort, wo Reproduzierbarkeit und Erklärbarkeit zählen (etwa in wissenschaftlicher Forschung und Bildung) (Literate programming – Wikipedia) (Literate programming – Wikipedia). Vibe Coding wird rasch Teil des gängigen Werkzeugkastens, Millionen Entwickler nutzen inzwischen KI-Programmierassistenten (‘Vibe coding’ increasingly becoming standard for development – Techzine Global). Besonders nützlich ist es für schnelles Prototyping, kreatives Programmieren und Situationen, in denen Tempo vor Perfektion geht. In Teams und Open-Source-Projekten lässt sich keiner der beiden Ansätze unkritisch anwenden: Literate Programming verlangt eine Dokumentationskultur, die nicht jedes Team hat, und Vibe Coding verlangt Aufsicht, um Qualität und Zusammenhalt zu sichern. Die besten Ergebnisse entstehen womöglich, wenn man die Philosophien mischt: zum Beispiel per Vibe Coding einen Codeentwurf erstellen und ihn dann literarisch verfeinern (Erklärungen ergänzen und die Logik ordnen), oder umgekehrt einen literarischen Plan schreiben und die KI die Boilerplate-Abschnitte ausfüllen lassen.

Letztlich hängt die Wahl zwischen diesen Paradigmen (oder ihre Mischung) von den Zielen und dem Umfeld eines Projekts ab. Stehen langfristige Tragfähigkeit, Klarheit und eine solide Wissensweitergabe an erster Stelle, bietet die Haltung des Literate Programming erprobte Vorteile (Literate programming – Wikipedia) (Donald Knuth). Stehen Innovation, schnelle Entwicklung und eine niedrigere Einstiegshürde an erster Stelle, bietet Vibe Coding eine leistungsfähige neue Arbeitsweise (The Rise of Vibe Coding – Lovable Blog) (Vibe Coding is Real). Statt Vibe Coding als vollständigen Nachfolger des Literate Programming zu sehen, trifft es vielleicht eher zu, es als anderen philosophischen Zweig zu begreifen: Er glänzt in Bereichen, die dem Literate Programming weniger wichtig sind, und umgekehrt. Während sich die Softwarebranche weiterentwickelt, ist Platz für beides, den gut gegliederten Essay und die freie Improvisation. Bleibend ist die Erkenntnis, dass es beim Programmieren nicht nur darum geht, Maschinen Anweisungen zu geben, sondern Menschen zu befähigen, Technik zu gestalten. Ob in sorgfältig geschriebener Prosa oder im kreativen Dialog mit einer KI: Der Mensch bleibt der Kern des Programmierens.

Quellen:

Aus dem Englischen übersetzt: zum Originalbeitrag

Gestalten Sie die Zukunft Ihres Unternehmens mit KI

Tauchen Sie ein in unsere spannenden Workshops und rüsten Sie Ihr Team mit den Werkzeugen und dem Wissen aus, um im Zeitalter der KI führend zu sein.

Kontaktieren Sie uns
Scroll to top