14 Punkte von GN⁺ 2025-12-10 | 4 Kommentare | Auf WhatsApp teilen
  • Vibe Coding funktioniert in der Praxis tatsächlich gut, verringert aber das wesentliche Vergnügen am Programmieren, weil dabei Code entsteht, den die Autorin oder der Autor selbst nicht versteht
  • Alle Programmiersprachen sind Werkzeuge, die nicht für Maschinen, sondern für die Bequemlichkeit des Menschen entworfen wurden; Vorteile wie Sicherheit, Abstraktion und Lesbarkeit sind letztlich Strukturen für menschliches Denken
  • Daraus folgt die Frage: Braucht von KI geschriebener Code überhaupt noch menschenfreundliche Sprachen? Vorgeschlagen wird eine neue, maschinenfreundliche und KI-zentrierte Sprache: VOPL (Vibe-Oriented Programming Language)
  • Diese Sprache könnte viele Formen annehmen, etwa als ausführbarer Pseudocode, als Erweiterung des Literate Programming oder als natürliche Sprache mit einer spezifischen Grammatik
  • Wie schon in den frühen Tagen des Rechners mit gespeichertem Programm gilt: Widerstand gegen neue Rechenparadigmen wiederholt sich historisch, und Vibe Coding könnte der nächste Schritt in dieser Entwicklung sein

Die Spannung zwischen Programmierung und Vibe Coding

  • Programmieren ist für mich keine Arbeit, sondern Freude und seit den späten 1990er Jahren ein bleibender Gegenstand meiner Leidenschaft
    • Seit 25 Jahren unterrichte ich Programmierung, und worauf ich am meisten stolz bin, ist, Menschen ohne fachlichen Hintergrund zu Programmiererinnen und Programmierern gemacht zu haben
  • Beim Programmieren ist mir die Freude wichtig, Probleme zu lösen und sie selbst zu verstehen
  • Vibe Coding hingegen ist ein Prozess, bei dem KI den Code schreibt und die schreibende Person das Ergebnis nicht vollständig versteht
    • Es fühlt sich irgendwie nach „Schummeln“ an (wenn auch nicht nur so), aber auf eine schwer genau zu beschreibende Weise unangenehm
    • Es scheint einen großen Teil des eigentlichen Spaßes am Coden zu nehmen
  • Trotzdem funktioniert Vibe Coding gut genug, um reale Systeme hoher Qualität hervorzubringen
    • Es geht längst über bloßen Suchmaschinen-Ersatz hinaus und löst auch Probleme präzise, die man selbst zu mühsam findet
    • KI ist bei Fehlersuche und Speicherverwaltung oft geschickter als Menschen, und es ist immer wieder erstaunlich, was entsteht, wenn man einer KI nur eine Programmidee hinwirft

Sprache war ursprünglich ein Werkzeug für Menschen

  • Wie in Abelson & Sussmans Structure and Interpretation of Computer Programs sind Programmiersprachen Ausdrucksmittel für Menschen
    • Code ist „zum Lesen durch Menschen“ da; Maschinen brauchen keine Lesbarkeit
  • Alle Programmiersprachen werden als Medium entworfen, das menschliches Denken und Ausdrücken unterstützt
    • Sicherheit in Rust, Abstraktion in C++, Nebenläufigkeit in Go sind Funktionen für den Menschen, nicht für die Maschine
    • Speicherverwaltung, Nebenläufigkeit und Typsicherheit sind letztlich nur Abstraktionen, die menschliche Denkstrukturen unterstützen
  • Daher könnte in einer Zeit, in der KI Code schreibt, ein menschenzentriertes Sprachdesign überflüssig werden

Braucht KI dann überhaupt solche Sprachen? : Die Bedeutung des Vorschlags „Mach Vibe Coding in C“

  • Beim Vibe Coding schreibt der Mensch Programme bereits in einem Zustand, in dem er den gesamten Code nicht mehr vollständig versteht
    • In so einer Situation gibt es weniger Gründe, menschenfreundliche Syntax beizubehalten
    • Statt menschenfreundlicher Sprachen könnte es vernünftiger sein, direkt maschinenfreundliche Sprachen (C oder Assembler) zu verwenden
  • KI kann undefined behavior, Speicherfreigabe und Off-by-one-Fehler in C präziser handhaben als Menschen
    • Ähnlich wie ein Compiler besser optimiert, zeigt sie eine genauere Kontrolle über die korrekte Ausführung von Code als Menschen
  • Daraus ergibt sich die Frage: Brauchen wir nicht eine Sprache, die für KI besser geeignet ist?
    • Warum sollte man Vibe Coding überhaupt in „menschenzentrierten“ Sprachen wie Python, Rust oder C++ betreiben?

Vorschlag für VOPL (Vibe-Oriented Programming Language)

  • Wenn man eine Sprache unter der Annahme von Vibe Coding entwirft, lassen sich unter anderem folgende Möglichkeiten vorstellen
    • Eine ultrahohe Abstraktionsebene, die ausführbarem Pseudocode nahekommt
    • Wie eine vollständige Form des Literate Programming, bei der der Mensch nur beschreibt und die KI den Maschinencode erzeugt
    • Eine Struktur, die wie natürliche Sprache aussieht, aber bestimmte „idiomatische Ausdrücke“ besitzt
    • Konzepte wie alltagsnahe Ausdrücke für Nebenläufigkeit, also eine Art Slang, statt Begriffen wie „goroutine“
  • Die Richtung wäre, ein maschinenzentriertes Ausdruckssystem zu entwerfen, mit dem KI Probleme präzise versteht und schnell ausführbaren Code erzeugen kann
  • Zwar gibt es das Problem, eine neue Sprache in KI-Systeme einzuprägen, doch schon heute werfen viele Entwickler der KI Pseudocode zu und erzeugen im Dialog Code
    Es ist also gut möglich, dass irgendeine Form von VOPL bereits gelernt wird

Der Wandel der Tätigkeit des Programmierens

  • „Von Hand zu coden“ könnte in der Ausbildung künftiger Vibe Coder eine Rolle ähnlich einer Montessori-Grundausbildung spielen
    • So wie das Zeichnen von Hand vor Photoshop oder das Lösen von Gleichungen auf Papier auch im Zeitalter elektronischer Rechner als Teil der Ausbildung bestehen blieb
  • Widerstand gegen das Aufkommen neuer Paradigmen hat sich historisch immer wiederholt
    • Beispiele sind die anfänglichen Gegenreaktionen bei der Einführung von Rechnern mit gespeichertem Programm (ENIAC → EDVAC)
    • Selbst Grace Hopper musste gegen die Kritik kämpfen, Maschinen könnten keine Maschinenbefehle schreiben

Abschließende Botschaft

  • Vibe Coding ist bereits Realität, und die Entwicklung der Zukunft könnte eine Neugestaltung der Sprache selbst verlangen
  • Nach dem Zeitalter menschenzentrierter Sprachen ist nun der Zeitpunkt gekommen, die Möglichkeit eines Übergangs zu KI-zentrierten Sprachen ernsthaft zu diskutieren

“Same vibe, as the kids say.” — Wie man heute sagen würde: derselbe Vibe eben.

4 Kommentare

 
youknowone 2025-12-12

Beim Coden mit einem Sprachmodell zu glauben, es würde von selbst wie durch Magie maschinennahe Ausdrücke erzeugen, ist schon eine ziemlich dreiste Erwartung.
Je mehr Einschränkungen es gibt, desto besser arbeitet es innerhalb dieser Einschränkungen.

 
aer0700 2025-12-12

Auch wenn eine KI den Code schreibt, muss doch der Entwickler die Verantwortung für den Service tragen. Ich bezweifle, dass man Verantwortung für Code übernehmen kann, den man selbst nicht versteht.

 
dooboo 2025-12-11

„Selbst wenn man vibe coding betreibt, sollte man es in einer Sprache tun, die man gut kennt, damit man das Ergebnis überprüfen kann.“

In den Kommentaren steht ein sehr wichtiger Satz.

 
GN⁺ 2025-12-10
Hacker-News-Kommentare
  • Mir ist wieder bewusst geworden, wie vielfältig der Beruf der Softwareentwicklung wirklich ist
    Ich arbeite im Backend, besonders an APIs, und der größte Engpass für die Produktivität ist, dass die meisten Leute Anforderungen nicht richtig definieren können
    Fragt man den PM, weicht er aus, und die Frontend-Entwickler warten darauf, dass das Backend die API liefert
    Am Ende ist das Schwierigste nicht das Coden, sondern der Denkprozess, Anforderungen zu entdecken und zu interpretieren

    • Das Problem, das du erlebst, ist kein Problem des Programmierens selbst, sondern Folge einer ineffizienten Organisationsstruktur
      Echtes Programmieren bedeutet, ein selbst entworfenes System zu implementieren und ihm Leben einzuhauchen
      Wenn man das bloße Schreiben von Code im Unternehmen mit „Programming“ verwechselt, entstehen Missverständnisse
    • Ich bin Professor für englische Literatur und unterrichte Studierende aus den Geisteswissenschaften in Programmierung; der Werdegang des Autors ist sehr interessant
      Allerdings hat er vermutlich nicht viel Erfahrung mit der Entwicklung großer kommerzieller Software
      Seine Prognosen über die „Zukunft des Programmierens“ sind faszinierend, könnten im industriellen Kontext aber gewisse Grenzen haben
      (Siehe: Über Stephen Ramsay)
    • Ich habe alles gemacht: Backend, Frontend, Full-Stack, QA-Automatisierung und DevOps
      Am Ende zählen Mindset und wie stark man technischer Praxis ausgesetzt ist
      LLMs haben meine Produktivität stark erhöht — besonders für mich mit meinem architektonischen Denken
      Dinge, die früher Monate dauerten, baue ich jetzt in ein paar Stunden
      Zurzeit nutze ich LLMs, um alten Shockwave-Lingo-Code in moderne Sprachen zu übersetzen und damit Legacy-Spiele zu restaurieren
    • Wenn KI klug genug wäre, Anforderungen selbst zu definieren, dann wäre vibe coding an diesem Punkt selbst überflüssig
      Wenn vibe coding also die Zukunft sein soll, steckt darin bereits die Annahme, dass KI nicht vollständig ist
      Sobald man Fähigkeiten und Grenzen einer vorgestellten KI beliebig festlegt, wird die Diskussion selbst unscharf
    • Jira-Tickets sind so vage in den Anforderungen, dass ich sie einem LLM nicht einfach übergeben kann
      Erst nach vier oder fünf Meetings mit Stakeholdern wird es klar
  • Ich habe vibe coding in C ausprobiert und mag C immer noch nicht
    Die KI vergisst wie ein Mensch, Speicher freizugeben, und korrigiert es erst später
    Mit Rust hat es deutlich mehr Spaß gemacht, und die eigentliche Kompetenz liegt darin, das Abhängigkeits-Ökosystem einer Sprache zu verstehen
    KI hilft dabei, dieses „Buchwissen“ schnell zu durchforsten

    • Rust-Code-Reviews sind deutlich klarer
      In C musste ich jedes Mal prüfen, ob Speicher freigegeben wurde, aber in Rust fällt diese Sorge fast weg
      Selbst beim vibe coding ist Rust mit den Sicherheitsmechanismen der Sprache meiner Meinung nach viel besser geeignet
    • KI schreibt Python und JavaScript gut, macht in C/C++ aber immer noch menschliche Fehler
      Die menschenfreundlichen Eigenschaften von Python helfen offenbar auch der KI
      Dank KI ist es jetzt leichter geworden, selbst neue UIs oder Utilities zu bauen,
      und nur die performancekritischen Teile in C++ zu implementieren ist ebenfalls unkompliziert
    • Ich habe auch vibe coding in C ausprobiert, und die KI hat sich um das Speichermanagement ziemlich gut gekümmert
      Wenn ich direkt mit GDB hätte debuggen müssen, hätte es viel länger gedauert
      Dass sie mir die unangenehmen Teile wie String-Verarbeitung oder Pointer-Verwaltung abnimmt, finde ich sehr zufriedenstellend
    • Zurzeit lerne ich Assembler und lasse die KI dieselben Probleme lösen, um zu vergleichen
      Der vom Compiler erzeugte Code ist zwar immer effizienter, aber ich nutze die Fehler der KI als Lerngelegenheit
    • Ich würde empfehlen, zu lernen, wie man Agenten selbst baut
      Auch mit einem lokalen LLM kann man Prüfungen wie Speicherfreigabe automatisieren
  • Vor Kurzem gab es eine Diskussion mit dem Titel „Why AI Needs Hard Rules, Not Vibe Checks“
    (Link)
    Rust eignet sich für vibe coding, weil es kostenlose Prüfmechanismen wie Typ- und Lebenszeitgarantien mitbringt
    Ohne solche Prüfungen erzeugen LLMs leicht unsicheren Code
    Abstraktion ist nicht nur für Menschen, sondern auch für LLMs notwendig

    • Ich stelle mir eine Sprache vor, die für LLMs entworfen wurde
      Eine Sprache, in der jede Funktion, Variable, jeder Typ und jede Ausnahme streng spezifiziert werden muss
      Sie wäre unbequem zu schreiben, aber leicht zu lesen und zu verifizieren
    • Auch der ACM-Artikel Automatically Translating C to Rust ist interessant
      Er behandelt die Schwierigkeit einer Übersetzung, die nicht nur Ausführungspfade, sondern die Intention des Codes bewahrt
    • Wenn man so viele Regeln braucht, warum sollte man dann überhaupt KI einsetzen?
      Werkzeuge wie Shellcheck machen Einsteiger ebenfalls deutlich kompetenter
    • Für LLMs sind Sprachen mit einfacher statischer Analyse wichtiger
      Wenn man sie per RL verbessern will, muss man die Korrektheit von Code automatisch bewerten können
      Sprachen auf Logikbasis wie Prolog verdienen vielleicht neue Aufmerksamkeit
    • Auch Rust verhindert keine Logikfehler
      Wenn ein LLM stark fehlerhaften Code ausgibt, ist das Ergebnis unabhängig von der Sprache ähnlich
  • Anfangs war vibe coding erstaunlich, aber bald hat mich die ständige Korrekturschleife mental ausgelaugt
    Es raubt einem die Konzentration wie das Scrollen durch einen algorithmischen Feed
    Jetzt code ich wieder selbst und überlasse ChatGPT nur die langweiligen Teile

    • Es fühlt sich wirklich an, als würde einem die Seele ausgesaugt
      Außerdem lernt man nichts dabei
    • Ich habe ausprobiert, das LLM zuerst eine Spezifikation (spec) schreiben zu lassen und diese dann zu überarbeiten
      So werden Anforderungen klarer, und man kann leichter zu einer anderen KI wechseln
    • Am wirkungsvollsten war es, Probleme in kleine Einheiten zu zerlegen und zu verifizieren
  • Ich bezweifle, dass ein LLM C-Code ohne Memory Leaks erzeugen kann
    Schon menschliche Entwickler machen in diesem Bereich Fehler; für LLMs mit minderwertigen Trainingsdaten ist es noch riskanter
    Wenn man ein Programm mit Segfaults per vibe coding baut, ist das schlicht Zeitverschwendung

    • Ich arbeite schon lange mit Rust und LLMs, und dank cargo check ist die Codequalität sehr hoch
      Es bricht fast nie und kompiliert praktisch immer
    • Man kann LLMs auch Ressourcen dafür geben, Fehler selbst zu erkennen
      Menschen werden müde, LLMs nicht
    • LLMs werden zunehmend mit hochwertigen Daten feinabgestimmt
      Wenn man sie mit gutem C-Code nachtrainiert, gibt es Spielraum für Verbesserungen
  • KI soll in C undefined behavior vermeiden? Das fällt mir schwer zu glauben
    Wenn ein Modell darauf trainiert ist, wie Menschen Fehler zu machen, wird es wahrscheinlich ähnliche Bugs erzeugen

    • Neuere Modelle verstärken guten Code jedoch mit Reinforcement Learning und synthetischen Daten
      Da sie die wahrscheinlichsten Tokens vorhersagen, machen sie häufige Fehler seltener
    • Sonnet in Copilot Chat hat mir auf Anhieb C++-Code ohne Speicherfehler erzeugt
      Es hat auch die Ursache eines Crashes gut gefunden
    • Man sollte sie nicht darauf trainieren, Menschen zu imitieren, sondern Compiler zu imitieren
    • Deshalb halte ich Rust für geeigneter zur Codegenerierung durch LLMs
    • Wenn man mit Claude C-Code schreibt, entstehen mit wachsendem Umfang pthread- oder Speicherbugs
      Moderne Sprachen wie Zig oder Rust sind deutlich besser
  • Der Grund, warum mich vibe coding unbehaglich macht, ist nicht einfach, dass es sich wie „Cheating“ anfühlt
    Programmieren ist eine Kunst mit Seele
    Jeder Mensch löst Probleme auf seine eigene Weise, und genau das ist Kreativität
    vibe coding fühlt sich an, als würde die Maschine sich diese Kreativität einverleiben
    Am Ende übernimmt die Maschine Denken, Entscheidungen und sogar Fehler vollständig

  • Es gab den Vorschlag, eine „vibe-oriented programming language (VOP)“ zu bauen
    Aber wenn es eine Sprache für LLMs sein soll, müsste sie eher streng und ausführlich sein
    Sie dürfte nicht kompilieren, wenn nicht alle Bedingungen und Ausnahmen explizit angegeben sind
    Für Menschen wäre das unbequem, für LLMs hätte es aber den Vorteil, Verwirrung zu reduzieren

    • Tatsächlich ist wichtiger als die Ausgabesprache die Eingabesprache (Prompt)
      Man braucht eine Struktur, in der Menschen Konzepte erklären und die KI sie in Code übersetzt
    • Diese Beschreibung erinnert mich an die Programmiersprache Ada
      Wenn sie einmal kompiliert hatte, funktionierte sie fast immer korrekt
  • Selbst wenn man vibe coding betreibt, sollte man es in einer Sprache tun, die man gut kennt, damit man das Ergebnis noch prüfen kann
    Sonst kann man auch gleich mit brainfuck experimentieren

  • Auf die Frage „Warum dann nicht mit x86-Assembler?“ lautete die Antwort,
    dass ich es selbst überprüfen und erweitern können muss
    Reines vibe coding ist nur ein Gedankenexperiment, kein realistisches Ziel
    Vielleicht kann KI irgendwann sogar QA übernehmen, aber derzeit sind sichere Sprachen und menschliche Prüfung unverzichtbar

    • Über die Bemerkung „Wenn du es selbst erweiterst, ist es ohnehin kein reines vibe coding mehr“ musste ich lachen
      Ich bin inzwischen Entwickler lange genug, dass mich solche Debatten eher ermüden