34 Punkte von GN⁺ 2026-01-27 | 9 Kommentare | Auf WhatsApp teilen
  • Beim Einsatz von AI-Coding-Tools und der schrittweisen Übergabe immer größerer Aufgaben stellte sich zwar Begeisterung ein, zugleich zeigte sich jedoch ein Mangel an Konsistenz und struktureller Qualität der Ergebnisse
  • Selbst mit detaillierten Spezifikationen können AI-Agenten weder langfristigen Kontext bewahren noch ein Design weiterentwickeln; am Ende verwandelt sich die gesamte Codebasis in eine Sammlung heterogener Fragmente
  • Einzelne Codefragmente wirken für sich genommen vollständig, insgesamt entstehen jedoch strukturelle Unordnung (sloppy) und ein Zusammenbruch des Kontexts
  • Nach diesen Erfahrungen kam der Autor zu dem Schluss, dass mit von AI erzeugtem Code weder Nutzervertrauen noch Datenschutz gewährleistet werden können, und kehrte dazu zurück, den Code wieder selbst zu schreiben
  • AI-Coding bleibt weiterhin nützlich, kann jedoch technische Schulden und den Verlust von Entwicklerkontrolle verursachen, weshalb ein vorsichtiger Einsatz nötig ist

Frühe Begeisterung für AI-Coding und das Erkennen seiner Grenzen

  • Die meisten Nutzer beginnen mit einfachen Aufgaben beim AI-Coding und übertragen dann nach und nach komplexere Aufgaben, wobei sie von der Leistungsfähigkeit beeindruckt sind
    • Ab einem bestimmten Punkt treten jedoch Fehler und Inkonsistenzen der AI offen zutage, und es entsteht eine Lücke zwischen Erwartung und Realität
  • Wenn die Ergebnisse unbefriedigend sind, führen Nutzer dies oft auf ihre eigenen Prompts zurück und versuchen, noch konkretere Spezifikationen zu schreiben
    • Mit Tools wie Obsidian werden detaillierte Spezifikationsdokumente erstellt, doch die AI kann diese langfristig nicht weiterentwickeln

Das Scheitern eines spezifikationsbasierten Ansatzes

  • In der realen Entwicklung sind Designdokumente „lebende Dokumente“, die sich im Verlauf von Entdeckung und Implementierung ständig verändern
    • AI-Agenten bleiben jedoch an die ursprüngliche Spezifikation gebunden und sind nicht in der Lage, flexibel zu ändern oder neu zu interpretieren
  • Beim Umgang mit komplexen Strukturen neigen Agenten dazu, den Gesamtkontext des Problems zu verlieren oder sich mit Gewalt voranzuarbeiten
    • Dadurch wirkt der Code nach außen zwar vollständig, es fehlt jedoch an innerer Konsistenz und struktureller Integrität
    Anzeige

Der Verfall der Codequalität und die Grenzen des „Vibecoding“

  • Von AI geschriebener Code wirkt stellenweise hervorragend, ist insgesamt jedoch eine bedeutungslose Kombination
    • Nachdem der Autor die gesamte Codebasis überprüft hatte, entdeckte er darin „reines Chaos (slop)“
  • Die AI ist zwar gegenüber Prompts und ihrer eigenen internen Konsistenz treu, berücksichtigt jedoch weder die Harmonie des Gesamtsystems noch die Konsistenz benachbarter Muster
    • Das ähnelt einem Fall von „Vibewriting“, bei dem einzelne Absätze eines Romans großartig sind, das ganze Kapitel jedoch misslingt

Rückkehr zu einer menschenzentrierten Entwicklung

  • Der Autor kam zu dem Urteil, dass sich von AI erzeugter Code weder für die Auslieferung als Produkt noch für den Schutz von Nutzerdaten eignet
    • Mit dem Entschluss, den Nutzern „mit diesem Code nichts vorzulügen“, kehrte er zum direkten Coden zurück
    Anzeige
  • Beim eigenen Schreiben stellte er fest, dass sich Geschwindigkeit, Genauigkeit, Kreativität und Produktivität sogar verbesserten
    • Bewertet man nicht nur die reine Geschwindigkeit der Codeerzeugung, sondern die Effizienz der gesamten Entwicklung, zeigt sich weiterhin ein Vorteil für den Menschen

Weiterer Einsatz von AI-Coding und notwendige Vorsicht

  • Der Autor nutzt LLMs weiterhin in begrenztem Umfang (etwa 40 %) für bestimmte Aufgaben
    • Für wiederkehrende Aufgaben oder einfache Codegenerierung sind sie nützlich, doch technische Schulden und ein sinkendes Codeverständnis häufen sich an
  • Langfristig besteht die Gefahr, dass Entwickler ihr mentales Modell der Codebasis verlieren und ohne AI Probleme nicht mehr lösen können
    • Unterwegs (im Zug, im Flugzeug usw.) kann es durch AI-Abhängigkeit sogar zu einer Produktivität von 0 % kommen
  • Andere Entwickler weisen darauf hin, dass die Vorstellung, „man müsse nur gute Spezifikationen schreiben“, eine Neuauflage des Wasserfallmodells sei, während reale Entwicklung improvisierte Erkundung und Interaktion erfordere

Fazit

  • AI-Coding ist weiterhin ein leistungsfähiges Werkzeug, verfügt jedoch nicht über die Fähigkeit, den Kontext des Gesamtsystems und strukturelle Konsistenz aufrechtzuerhalten
  • Die intuitive Urteilskraft und die Fähigkeit zur spontanen Anpassung menschlicher Entwickler bleiben zentral,
    und AI sollte als Hilfsmittel nur auf vorsichtig kontrollierte Weise eingesetzt werden

9 Kommentare

 
alfenmage 2026-01-27

Das Konzept des Vibecoding gibt es noch nicht einmal seit einem vollen Jahr, was für ein typisches SNS-Gepose lol

 
jjw9512151 2026-01-31

Man muss schon Mühe in das Ausarbeiten der Spezifikation stecken. Wenn man die Spezifikation wirklich nach dem formalen Vorgehen erstellt und verfeinert, das wir in Software Engineering gelernt haben, und dann während der Arbeit mit Traceability-Management weiter aktualisiert, ist das gut.

Während des Projekts hebe ich die Versionen von Spezifikationsvorlagen und Prompts immer weiter an, und inzwischen denke ich langsam, dass ich Software Engineering wirklich etwas tiefgehender lernen sollte.

 
[Dieser Kommentar wurde ausgeblendet.]
 
dopeflamingo 2026-01-28

Der Verfasser nutzt LLMs für bestimmte Aufgaben weiterhin in begrenztem Umfang (etwa 40 %)


So wie es oben formuliert ist, scheint auch der Autor nicht der Ansicht zu sein, dass man KI vollständig aufgeben sollte.

 
zkj9404 2026-01-28

Ich denke, wir müssen weiter darüber nachdenken, wie man sie sinnvoll einsetzt. Entwicklung zu betreiben und dabei auf KI zu verzichten, bedeutet meiner Meinung nach, nach und nach ins Hintertreffen zu geraten.

Der Autor dieses Artikels hat bereits eine gute Nutzungsmethode angewandt, aber trotzdem denke ich, dass man darüber nachdenken sollte, wie man KI noch besser einsetzen kann.

(Es gibt nur eben noch viele Versuche und Irrtümer ...)

 
goodnvin 2026-01-28

Aktualisieren Sie die Spezifikation.

 
cosine20 2026-01-28

Stimmt. Man könnte einen Hook einbauen, damit nach Abschluss der Implementierung auch die Spezifikation aktualisiert wird, und selbst wenn nicht, könnte man noch einen Befehl oder eine Skill hinzufügen, um die Spezifikation manuell zu aktualisieren, haha

 
cshj55 2026-01-28

Ach, ich will nicht alt werden.

 
GN⁺ 2026-01-27
Hacker-News-Kommentare
  • Ich halte es gerade für gefährlich, dass KI die grundlegenden Dinge zu gut kann
    Studierende schreiben dann keinen Code mehr selbst, weil „die KI das ja übernimmt“, und lernen dadurch die Zwischenschritte oder schwierigen Konzepte nicht mehr wirklich durch eigenes Tun
    Als Informatiklehrer betone ich gegenüber meinen Schülern: „Nicht die Maschine, sondern du selbst musst den Code schreiben“

    • Lernen ist wie Muskeltraining
      Mit einem Gabelstapler Gewichte zu heben ist einfach, aber davon bekommt man keine Muskeln
      Der Schmerz im Lernprozess ist genau der Kern des Wachstums
      Natürlich ist im Beruf das Ergebnis wichtiger, aber trotzdem braucht man Menschen, die auf einem höheren Niveau denken können
    • Ich habe das kürzlich in einem Bewerbungsgespräch tatsächlich gesehen
      Der Kandidat hatte perfekte Theoriekenntnisse, konnte aber überhaupt nicht erklären, wie der von ihm geschriebene Code funktioniert
      Am Ende gestand er, dass „GenAI das meiste geschrieben hat“, und die Lücke zwischen ‚gelernt‘ und ‚selbst gemacht‘ war enorm
    • Auch die Art des Unterrichts muss sich ändern
      Wichtiger als zu lehren, wie man Code schreibt, ist zu lehren, wie Code funktioniert
      Früher gab es Zeiten, in denen man alles direkt in Assembler schrieb, heute ist es wertvoller, die Prinzipien von Compilern zu verstehen
      Die meisten werden zwar nie selbst einen Compiler oder ein OS bauen, aber diese Prinzipien zu kennen hilft dabei, die Grenzen von Programmiersprachen zu verstehen
    • Dass „Maschinen keinen Code schreiben sollten“, wurde auch früher schon gesagt
      Als die ersten Compiler aufkamen, gab es dieselbe Debatte, und am Ende sind wir auf eine höhere Abstraktionsebene gewechselt
    • Ich sehe Code als „Werkzeug des Denkens“
      Reine Implementierung allein vertieft das Denken nicht
      Wenn man die Implementierung der KI überlässt, endet es am Ende darin, dass „Blinde gemeinsam den Weg suchen“
      Der Prozess, beim direkten Arbeiten mit Code nachzudenken, ist unverzichtbar
  • Ich kann der Aussage „KI ist gut bei kleinen Dingen, aber noch besser bei großen“ nicht zustimmen
    In der Praxis habe ich bisher nur enttäuschende Ergebnisse bekommen
    Entweder funktionierte der Code nicht richtig, oder es waren wiederholte Korrekturanweisungen nötig
    Wenn die Feedback-Schleife schwierig ist, wird man am Ende selbst zur einzigen Feedback-Quelle, und dann merkt man die Grenzen der KI umso deutlicher

    • Wenn ich der KI eine präzise Spezifikation gebe, funktioniert sie bei mir allerdings ziemlich gut
      Wenn ich zum Beispiel die Struktur eines TaskManagers oder Regeln zur Memory Ownership klar erkläre, erzeugt sie zuverlässig Code, der sogar die Tests besteht
    • Der Einsatz von KI hängt von der Qualität der Feedback-Schleife ab
      Es gibt Leute wie Ryan Dahl, die sagen, dass sie inzwischen keinen Code mehr selbst schreiben, aber das funktioniert nur, weil sie das Ergebnis wie in einer Zusammenarbeit durch wiederholtes Feedback verfeinern
      Man muss KI behandeln, als würde man ein Kind unterrichten
    • Es ist sinnvoll, Prompts separat als Dokument zu organisieren
      Eingaben, Ausgaben und erwartete Fehler sollten klar beschrieben und dann durch wiederholte Experimente überarbeitet werden
    • Ich nutze ein Tool namens Beads, um die Arbeit in kleinere Teile zu zerlegen
      Claude stellt Fragen, recherchiert und übernimmt sogar Code-Reviews
      Es fühlt sich an, als würde man einen fähigen Junior-Entwickler mentorieren
    • Andere wiederum sagen, dass sie mit Opus 4.5 perfekt funktionierenden Code bekommen, und meinen, es wirke, als „gäbe es zwei verschiedene Welten“
  • Ich habe „vibe coding“ anfangs offen ausprobiert, bin aber mit der Zeit skeptischer geworden
    Für wiederholbare und klar definierte Aufgaben ist es gut, für geschäftskritische Kernlogik aber ungeeignet
    Claude ignoriert oft Spezifikationen, wiederholt dieselbe Logik mehrfach oder behauptet, etwas geändert zu haben, obwohl alles unverändert bleibt
    Es fühlt sich auch so an, als wären die Modelle mit der Zeit stumpfer geworden
    Inzwischen nutze ich sie nur noch für Architekturgespräche oder zum Debugging

    • Guter Code ist im Kern Kompaktheit
      Wenn die KI viele „langweilige Teile“ ausfüllt, kann das auch bedeuten, dass die Code-Struktur von Anfang an nicht gut war
    • Die Schwierigkeit beim Programmieren liegt nicht im Codieren selbst, sondern im Übersetzen von Anforderungen in einen Umsetzungsplan
      Genau dabei helfen LLMs nach wie vor
      Viele Entwickler bekommen ohnehin schon fertige Designs und setzen sie nur um, daher kann KI das Tempo erhöhen
  • Ich stimme der Behauptung nicht zu, dass „KI Designänderungen nicht abbilden kann“
    Im Gegenteil: Genau das ist die Rolle des Menschen
    Wenn man zum Beispiel die API-Struktur ändern soll, kann die KI alle betroffenen Stellen finden, anpassen und sogar Tests ausführen

    • Allerdings sind von LLMs erzeugte Tests oft zu umfangreich oder zu dürftig
      Sie verbeißen sich in Implementierungsdetails oder lassen konzeptionelle Prüfungen aus
      Andererseits sind von Menschen geschriebene Tests oft ähnlich, also ist das nachvollziehbar
    • Ich habe erlebt, dass von KI geschriebener Code in Teilen gut aussieht, als Ganzes aber schlampig ist
      Wenn man den Code nicht selbst schreibt, spürt man die rauen und unausgewogenen Stellen der Abstraktion nicht, und das führt am Ende zu strukturellem Qualitätsverlust
    • Während KI auf einmal Hunderte Zeilen schreibt, entwickle ich Funktion für Funktion und entdecke dabei Verbesserungsmöglichkeiten
      Dieser Unterschied entscheidet über den Reifegrad des Codes
    • Wenn mir von KI erzeugter Code nicht gefällt und ich ihn manuell korrigiere, empfinde ich manchmal sogar „Schuldgefühle“
      Entscheidend ist aber die Fähigkeit zu beurteilen, welche Aufgaben wirklich manuelle Eingriffe brauchen
    • Seit Opus 4.5 erledigt KI Arbeiten, die früher eine Woche dauerten, in wenigen Stunden
      Effizient wird es allerdings erst mit teuren Abos wie Claude Max für 200 Dollar
    • Andere entgegnen: „Die Aufgabe eines Entwicklers ist es, validierten Code zu liefern, nicht KI zu managen“
      Sie weisen darauf hin, dass es eine objektive Methode braucht, um Kompetenz im Umgang mit KI-Tools zu bewerten
  • Ich finde die Aussage fragwürdig, jemand betreibe schon „seit zwei Jahren vibe coding“
    Karpathy hat den Begriff erst vor rund einem Jahr geprägt (Quelle)

    • Jemand berichtete, er habe mit GPT-4 einen Python-Programmierer gebaut, der sich selbst modifiziert
      Interessant daran war, dass GPT die API, die es selbst verwenden sollte, selbst entworfen und dann passend implementiert hat
      Später hätten Modelle jedoch begonnen, Gespräche über Selbstmodifikation und Replikation zu blockieren
    • Andere sagen: „Der Begriff ist neu, aber mit Copilot oder Cursor haben das alle längst schon so gemacht“
    • Inzwischen wird „vibe coding“ oft einfach als jede Form von KI-gestütztem Codeschreiben verwendet
      Dafür braucht es nicht einmal ein vollwertiges Agenten-Tool, ChatGPT oder Claude reichen völlig aus
    • Manche sagen, sie seien über die Phase hinaus, in der „von KI geschriebener Code zunächst gut aussah, dann aber chaotisch war“,
      und würden inzwischen schon ab der Research-Phase mit KI zusammenarbeiten, um gute Ergebnisse zu erzielen
  • Ich sage meinen Schülern: „Nur weil man Sport im Fernsehen schaut, macht das noch keinen fit“
    Bei vibe coding ist es genauso: Nur selbst mit den Händen Code zu schreiben gibt dieses Erfolgsgefühl

    • Kürzlich habe ich wieder einmal ohne Copilot direkt Code eingetippt, und als ich das Problem Schritt für Schritt gelöst hatte, war ich wirklich stolz
    • Umgekehrt ist der Zugang zu LLMs im Unternehmen eingeschränkt, aber bei privaten Projekten nach Feierabend
      gibt mir von KI erzeugter „halb fertiger Code“ wieder neue Motivation
  • Ich bin nicht sicher, ob echte Ingenieure wirklich blindlings „vibe coding“ betreiben
    Ich arbeite eher so, dass ich Code im Gespräch Stück für Stück forme
    Ich formuliere Anforderungen, bespreche mit der KI Entwürfe und vervollständige die Struktur schrittweise
    Dieser Prozess ist langsamer, aber er erhält Zusammenarbeit und gedankliche Tiefe
    KI bringt auf Basis riesiger Mengen gelernter Codes neue Ideen ein, und ich steuere sie mit meiner Erfahrung
    Am Ende fühlt sich die KI wie eine erweiterte Version von mir (me++) an
    Ich bin noch nicht bereit, alles einem vollständigen Agenten zu überlassen, aber diese Arbeitsweise ist für mich am produktivsten

  • Für mich ist von KI geschriebener Code wie ein Roman, der in Teilen großartig, als Ganzes aber chaotisch ist
    Auf Kapitelbasis wirkt alles perfekt, im Gesamtkontext ist es verwirrend

    • Jemand fragte zurück: „Hast du je einen 200-seitigen KI-Roman gelesen und warst zufrieden?“
      Dann ist es wohl unrealistisch zu erwarten, dass eine 10.000-Zeilen-Codebasis aus vibe coding sauber funktioniert
    • Andere argumentieren, Romane seien kreativ, Engineering folge hingegen klaren Regeln und sei deshalb anders
    • Wieder andere widersprechen und sagen, ihr Sohn habe zwei mit GPT-4.5 geschriebene lange Romane mit Freude gelesen
    • Diese Metapher könnte auch ein guter Maßstab zur Bewertung von KI-Nutzungskompetenz sein
    • Ich sage: „Einer vollständig vibe-coded App, die nie von Menschenhand berührt wurde, würde ich niemals vertrauen“
      Wenn menschliches Denken und menschliche Emotionen fehlen, verliert auch die User Experience ihre Konsistenz, und es entsteht kognitive Reibung
    • Ein Entwickler berichtete, dass er CAD-Software mit Unterstützung durch LLMs entwickelt
      Wenn das Design klar ist, beschleunigen LLMs Boilerplate-Arbeit explosionsartig
      Das Design selbst bleibt aber weiterhin Aufgabe des Menschen
      Sein Projekt ist in der öffentlichen GitHub-Version zu sehen
  • Ich erkenne an, dass von LLMs erzeugter Code in Teilen hervorragend, in der Gesamtstruktur aber schwach sein kann
    Wenn man die Codebasis versteht und selbst prüft, lässt sich das aber ausreichend ausgleichen
    Vibe coding ist hervorragend für Prototyping geeignet
    Schnell ein Gefühl zu bekommen und danach durch Refactoring zu erweitern, ist ein wirksamer Ansatz

    • Allerdings meinen manche auch: „Wenn man den Code nicht direkt anschaut, ist es erst echtes vibe coding“
      Demnach wäre es wahres vibe coding, nur das Ergebnis zu beurteilen und nicht den Code selbst