- KI-Coding-Tools automatisieren das einfache Schreiben von Code, wodurch für Entwickler strukturell nur noch die schwierigen Aufgaben wie Recherche, Kontextverständnis und Verifikation übrig bleiben
- Die Formulierung, dass die „KI es erledigt hat“, ist ein Warnsignal wie früher das Kopieren und Einfügen aus Stack Overflow, wenn Entwickler die KI-Ausgabe nicht selbst verstehen
- Vibe Coding ist für Prototyping nützlich, kann in echten Produktionsumgebungen mit KI jedoch mehr Zeit kosten statt Zeit zu sparen
- Wenn dank KI einmal schnell deployt wird, wird das zur neuen Baseline und führt zu dauerhaftem Sprint-Druck und Burnout als Managementproblem
- Entscheidend ist, KI nicht als Lösungsgeber, sondern als Recherche-Tool zu nutzen und dass Entwickler die Verantwortung für den gesamten Code behalten
Das Problem mit der Aussage „Die KI hat es erledigt“
- Früher lasen Entwickler Antworten auf Stack Overflow, Artikel oder GitHub-Issues und zogen erst nach eigener Kontextprüfung Schlüsse
- Niemand sagte, „Google hat den Code geschrieben“ oder „Das erste Suchergebnis wird schon stimmen“
- In letzter Zeit taucht zunehmend die Formulierung auf: „Die KI hat es erledigt“
- Das übertreibt entweder, was tatsächlich passiert ist, oder bedeutet, dass der Entwickler nicht selbst zu einer Schlussfolgerung gekommen ist
- Beides ist problematisch und führt zu denselben Bedenken wie beim Copy-and-Paste von StackOverflow-Code: Wurde der eingefügte Code wirklich verstanden?
Die Grenzen von Vibe Coding
- Vibe Coding macht anfangs Spaß und ist für Prototyping oder risikoarme persönliche Projekte nützlich
- In der realen Arbeit hat aber jede Codezeile Konsequenzen
- In einem Privatprojekt wurde ein KI-Agent gebeten, Tests für eine bestimmte Datei hinzuzufügen, woraufhin sich die 500 Zeilen lange Datei auf 100 Zeilen verkleinerte
- Die KI behauptete, nichts anderes gelöscht zu haben, und behauptete später sogar, die Datei habe ursprünglich nicht existiert
- Als ihr die git-Historie gezeigt wurde, entschuldigte sie sich und räumte ein, sie hätte zuerst prüfen müssen, ob die Datei existiert
- In diesem Fall hat die KI-Unterstützung mehr Zeit gekostet, statt Zeit zu sparen
- Die Diskussion mit dem Agenten und das Wiederherstellen der Datei dauerten länger, als die Tests direkt selbst zu schreiben
- Würde dasselbe in einer Umgebung wie einer Healthcare-Codebase passieren, könnte das schwerwiegende Folgen haben
- Wichtig ist, KI nicht als Lösungsgeber, sondern als Recherche-Tool zu nutzen; zu erkennen, wann KI falschliegt, erfordert Übung
Eine Struktur, in der die schwierigen Teile noch schwieriger werden
- Das Schreiben von Code war in der Entwicklungsarbeit ursprünglich der einfache Teil
- Die schwierigen Teile sind Recherche, Kontextverständnis, das Prüfen von Annahmen und zu wissen, warum ein bestimmter Ansatz richtig ist
- Wenn der einfache Teil an die KI abgegeben wird, wird die Arbeit nicht weniger, sondern es bleiben nur noch die schwierigen Aufgaben übrig
- Wenn Recherche übersprungen wird, weil die KI angeblich schon die Antwort geliefert hat, fehlt genau der Kontext, der nötig wäre, um die KI-Ergebnisse überhaupt zu bewerten
- Fremden Code zu lesen und zu verstehen ist deutlich schwieriger, als Code selbst zu schreiben
- KI-generierter Code ist seinem Wesen nach Code von jemand anderem
- Entwickler geben also den Teil ab, den sie gut können (Schreiben), und behalten nur den schwierigeren Teil (Lesen und Review)
- Dann müssen sie nur noch reviewen, ohne den Kontext aufgebaut zu haben, der beim eigenen Schreiben entsteht
Sprint-Erwartungen und Burnout
- Wenn mit KI-Hilfe einmal schnell deployt wird, wird das zur neuen Baseline, und plötzlich wird dieses Tempo immer erwartet
- Das Gespräch verschiebt sich von „Wie hast du das geschafft?“ zu „Warum schaffst du das nicht jedes Mal?“
- Das ist kein Engineering-, sondern ein Managementproblem
- Erschöpfte Engineers übersehen Edge Cases, lassen Tests weg und releasen Bugs
- Mehr Incidents → mehr Druck → mehr Sprints: ein Teufelskreis
- Auf die Behauptung „KI macht uns 10x produktiver“ bezogen, könnte es in Wirklichkeit eher so sein, dass ein 0,1x-Engineer zu einem 1x-Engineer geworden ist
- Technisch ist das 10x, aber die entscheidende Frage ist, ob das wirklich Produktivität ist oder nur offenlegt, wie wenig Recherche vorher betrieben wurde
- Burnout und Releases mit schlechter Codequalität neutralisieren die Produktivitätsgewinne durch KI
Senior-Skills, Junior-Vertrauen
- KI-Coding-Agenten haben beim Schreiben von Code Fähigkeiten auf Senior-Niveau, beim Vertrauen in ihre Ergebnisse sollte man aber auf dem Niveau eines Junior-Engineers ansetzen
- Der Code sieht gut aus und funktioniert vermutlich, aber mangels Erfahrung muss er gründlicher geprüft werden
- Als Bild gesprochen ist ein KI-Coding-Agent so, als wäre plötzlich jemand mit außergewöhnlich hoher Lesegeschwindigkeit ins Team gekommen
- Diese Person kann bei der Recherche helfen und Code schreiben, war aber nicht in dem Meeting dabei, in dem letzte Woche wichtige Hintergründe und Kontext besprochen wurden
Warum Code-Eigentümerschaft wichtig ist
- Entwickler müssen nicht nur für selbst geschriebenen Code, sondern auch für von KI erzeugten Code verantwortliche Ownership übernehmen
- Wenn KI-Ausgaben wegen unrealistischer Geschwindigkeitsziele einfach kopiert und eingefügt werden, entstehen Probleme, wenn ein neues Teammitglied den Code sechs Monate später verstehen will oder wenn es um 2 Uhr morgens einen Ausfall gibt
- „Die KI hat es geschrieben“ hilft in keiner Situation weiter
Wie KI bei den schwierigen Teilen helfen kann
- Beispiel aus einem Produktionsbug: Direkt nach einem großen Release meldeten Nutzer einen Bug in einem Edge Case bei der Anzeige von Zeitzonen
- Der zuständige Entwickler musste 30 Minuten später zum Unterricht, und alle anderen waren bereits im Feierabend
- Mithilfe von KI wurde die Untersuchung durchgeführt; sie stellte fest, dass der Bug auf jüngste Änderungen zurückging, und erklärte, wie er reproduziert werden kann
- Die Ursache war, dass einige deprecated Methoden Vorrang vor den aktuellen timezone-sensitiven Methoden bekamen, wodurch die Zeitzonenumwandlung nicht korrekt ablief
- Innerhalb von 15 Minuten wurden Root Cause, Lösungsideen und Recherche-Notizen in einem GitHub-Issue dokumentiert
- Der zuständige Entwickler prüfte den Fix, und ein anderes Teammitglied übernahm Test und Deployment
- Das Problem wurde ohne Notfall und ohne Überstunden gelöst
- Der Kern dieses Falls: KI übernimmt die wiederholbaren Teile der Recherche, während Menschen Kontext liefern und validieren
- KI sollte so eingesetzt werden, dass sie Recherche, Verifikation und Kontextverständnis stärkt; sonst verfestigt sich eine Struktur, in der die einfachen Dinge einfacher und die schwierigen Dinge schwieriger werden
3 Kommentare
Meiner Ansicht nach kopieren und fügen Entwickler, die ohnehin nur Copy-and-Paste betrieben haben, das auch mit LLMs einfach weiter,
während Entwickler, die schon immer viel auf Qualität geachtet haben, jetzt noch mehr darauf achten.
Hacker-News-Kommentare
Mit KI-Assistenz zu programmieren ist eine völlig andere neue Fähigkeit als herkömmliches, menschenzentriertes Coding.
Die Sprachen, Frameworks und Entwicklungsprinzipien, die wir haben, dienen dazu, menschliche Grenzen zu überwinden, aber KI hat andere Grenzen.
Beim Lösen komplexer Probleme war es nützlich, den Problemraum nicht einfach nur per Prompt und Ergebnis abzuarbeiten, sondern ihn durch Dialog und iteratives Design zu erkunden.
Fehler oder Halluzinationen der KI fungieren eher als Signal dafür, ob ich das Problem selbst wirklich richtig verstehe.
Ich habe im vibe-coding-Stil einen Retro-Emulator und einen Assembler gebaut und mit wenigen Prompts gute Ergebnisse bekommen.
Als ich aber den proprietären Teil einer speziellen Industrie-App ausprobiert habe, waren die Resultate miserabel, egal wie viele Prompts ich gegeben habe.
Auf GitHub gibt es tausende Emulator-Beispiele, aber für das, was ich machen wollte, gab es überhaupt keine Beispiele.
Die Schlussfolgerung ist einfach — manches ist leicht, manches geht überhaupt nicht.
Wenn es viele Beispiele auf GitHub gibt, existiert es auch im latenten Raum des LLM und kann jederzeit hervorgeholt werden.
Was du versucht hast, hatte einfach keine solchen Beispiele.
Industriespezifische Frameworks sind mit vibe coding schwer zu handhaben, aber wenn man das Problem vereinfacht, kann die KI viel schneller helfen.
Wenn man vibe coding vollständig akzeptiert, kann man beeindruckende Ergebnisse erzielen, aber die technischen Schulden werden so groß, dass man am Ende das Gefühl hat, ein Sklave der Maschine zu sein.
Wenn die KI tausende Zeilen Code schreibt, ist es sehr schwer, die Struktur zu verstehen oder sie zu reviewen.
Am Ende wird es wohl mehr Wegwerfcode und Wegwerfsoftware geben — Apps für ein bestimmtes Problem lassen sich leicht bauen, aber für nachhaltiges SaaS ist das ein großes Risiko.
KI ist ein Tool mit starkem Hebeleffekt (force multiplier).
Wenn das Fundament einer Codebase schlecht ist, kopiert die KI genau diesen Stil.
Ist die Basis dagegen sauber und konsistent, hält die KI dieses Qualitätsniveau und arbeitet erstaunlich gut.
Entscheidend ist letztlich das Fundament (foundation).
Die meisten Codebases sind schwer wartbar und schwer erweiterbar, und KI macht diese Probleme nur sichtbarer.
Wie in der Architektur gilt: Wenn das Fundament schwach ist, stößt auch das beste Werkzeug an Grenzen.
Dadurch konnten auch nachfolgende Entwickler den Kontext des Projekts vollständig verstehen.
Letztlich muss man zuerst die Kernabstraktionen korrigieren, damit die KI richtig funktioniert.
Anforderungen ändern sich ständig, und aus Effizienzgründen entstehen Kompromisse.
Letztlich haben Zeit und Opportunitätskosten Vorrang vor Qualität — weil Menschen sich nicht perfekt an Pläne halten können.
KI macht die lästigen Teile weniger lästig.
Aber mit einem LLM zu streiten ist Zeitverschwendung.
Effizienter ist es, Änderungen in kleinen Einheiten zu machen, bei Erfolg zu committen und sie andernfalls zu verwerfen und neu anzufangen.
KI ist kein Allheilmittel, und die Wahl des richtigen Werkzeugs ist wichtig.
Wenn man mit einem Kind spielt, das eine Waffe in der Hand hat, sollte man eine kugelsichere Weste tragen.
Oft hört man, fremden Code zu lesen sei schwieriger, als ihn zu schreiben, aber ich finde das seltsam.
Für eine Funktion, die einen halben Tag zum Schreiben braucht, reichen zum Lesen und Reviewen 10 bis 15 Minuten.
Korrekte Software zu verifizieren ist viel einfacher, als sie zu erstellen.
Einfach nur zu lesen ist leicht, aber beim Editieren, also die Struktur zu verstehen und Verbesserungen zu finden, ist der Aufwand viel größer.
Das liegt daran, dass der Kontext aus dem Moment des Schreibens verloren gegangen ist.
Tatsächlich ist Lesen nicht unbedingt schwieriger, sondern die Leute schreiben lieber neu.
Die richtige Denkweise ist: „KI macht zwar vieles einfacher, ist aber selbst eine neue Fähigkeit und schwer zu lernen.“
Wir befinden uns gerade im ENIAC-Zeitalter der KI, in dem Konzepte entsprechend höheren Programmiersprachen oder Betriebssystemen noch fehlen.
In Zukunft wird wohl ein Fachgebiet namens Context Engineering entstehen, und die heutige Arbeitsweise wird dann primitiv wirken.
Wenn die Struktur gut ist, wirken die Fähigkeiten der KI praktisch unbegrenzt.
„Mit KI gemacht“ bedeutet im Grunde: „in großem Maßstab CPU-Ressourcen eines externen Unternehmens verbraucht“.
Bis ich einen vollständig von mir besessenen KI-Agenten habe, halte ich das eher für Ressourcendiebstahl im planetaren Maßstab als für echten Fortschritt.
KI macht Entwicklung nicht schwieriger.
Im Gegenteil: Sie legt die wirklich schwierigen Teile offen, die Menschen bisher ignoriert haben.
In den letzten 15 Jahren haben Entwickler bereits „die menschliche Version von vibe coding“ betrieben — Copy-and-paste von Stack Overflow, Refactoring ohne Plan und Arbeiten nach dem Motto „solange es auf meinem Laptop läuft“.
Jetzt, da KI das übernimmt, wollen plötzlich alle planen und Tests schreiben.
Wenn sich dadurch die Qualität verbessert, selbst auf Kosten von Tempo, dann ist das echter Fortschritt.
Die heutige Kultur des „Sprintens im Marathon“ wird durch KI noch weiter beschleunigt.
Aber ohne Aufsicht gerät KI schnell vom Weg ab, und von anderen geschriebener Code zu lesen ist viel ermüdender, als den eigenen zu reparieren.
Ich habe die KI gebeten: „Füge in diese Datei Tests ein“, und plötzlich wurde eine 500-Zeilen-Datei zu einer 100-Zeilen-Datei.
Auf die Frage nach dem Grund antwortete sie: „Die ursprüngliche Datei existierte nicht.“
Als ich den git-Verlauf zeigte, entschuldigte sie sich und sagte, sie hätte „zuerst prüfen sollen, ob sie existiert“.
Gestern sagte ich: „Vergiss diese Datei“, und sie hat die Datei tatsächlich gelöscht.
Ein gewisser Rollback-Aufwand ist im Vergleich zum Nutzen der KI akzeptabel.