Persönliche Fallstudie über die Grenzen von KI-Codegenerierung und den Verlust menschlichen Gespürs
(github.com/jackdoe)- Eine Implementierungsbibliothek für das SWD-Protokoll zum Debuggen des RP2350 RISC-V-Kerns, aufgebaut so, dass ein Raspberry Pi Pico2 einen anderen Pico als Probe verwendet
- Etwa 80 % des Codes wurden von einer KI (Claude) erzeugt; der Autor erstellte zunächst mit Oszilloskop und Dokumentation einen grundlegenden Prototyp und ließ die KI den Code erweitern
- Im Verlauf des Projekts erlebte er starke Abneigung und Zweifel durch die sinnlose Token-Struktur von KI-Code, Verlust des Kontexts und Verlust des Gefühls von Code-Eigentum
- Dagegen machte er positive Erfahrungen, wenn er KI als Hilfswerkzeug für Dokumentenanalyse, Datendekodierung und die Erzeugung von Strukturen nutzte
- Dieser Fall macht die Probleme von Qualität, Gespür und Eigentum bei KI-generiertem Code sichtbar und wirft grundlegende Fragen nach dem Wesen des Programmierens und der Rolle des Menschen auf
0. VIBE CODE WARNING
- Rund 80 % des gesamten Codes sind KI-generiert (vibe coded), und auch der größte Teil der README wurde automatisch erzeugt
- Der Autor implementierte anhand von Oszilloskop und Dokumentation SBA, Register-Lese-/Schreibzugriffe, abstrakte Befehle, PROGBUF usw. selbst und überließ der KI anschließend die Bibliotheksumsetzung
- Als der Code von 1.000 auf 4.000 Zeilen anwuchs, gingen Code-Struktur und Bedeutung vollständig verloren; es fühlte sich nicht mehr wie sein eigener Code an
- Die KI interpretierte
dap_read_mem32falsch, wodurch Protokollfehler und unlogischer Code in großer Menge entstanden - Am Ende waren zwar in 10 Stunden fast 10.000 Zeilen Code fertig, aber es gab überhaupt kein Gefühl von Leistung oder Weiterentwicklung
Unterschiede zwischen KI-Code und menschlichem Code
- Von Menschen geschriebener Code besteht aus Token mit Absicht und Zweck und lässt sich daher verstehen, während die Token in KI-Code als bedeutungslose Kombinationen schwer lesbar sind
- Teile des KI-Codes zeigen eine bessere Qualität als menschlicher Code, doch direkt in der nächsten Zeile kann ein nur oberflächlich plausibler fehlerhafter Code folgen
- Diese Uneinheitlichkeit und der Verlust sinnlicher Verlässlichkeit lähmen das Urteilsvermögen des Programmierers
- Je größer der Code wird, desto mehr verschwindet das „Gespür“ dafür, ob es guter oder schlechter Code ist, und mentales Modell und Eigentumsgefühl brechen zusammen
Menschliche Gefühle und Zweifel
- Der Autor stellt die Frage „Ist das noch Programmierung?“ und bringt Abscheu und Scham zum Ausdruck
- In einer Zeit, in der KI den Code schreibt, schildert er eine existenzielle Verunsicherung darüber, was Menschen noch erschaffen und wie weit sie noch eingreifen sollten
- Er ist sich nicht einmal sicher, ob schon „kein Code mehr zu schreiben“ Fortschritt ist oder ob „Probleme nicht mehr zu modellieren“ überhaupt Effizienz bedeutet
- Er sagt, dass er weiterhin selbst etwas bauen möchte, der Sinn davon aber in einer KI-zentrierten Entwicklungsumgebung verblasst ist
Positive Nutzungserfahrungen mit KI
- Wenn KI für Dokumentenanalyse, Dekodierung von Oszilloskopdaten und automatische Erzeugung von C-Strukturen eingesetzt wurde, bewertete der Autor das als effizient und befriedigend
- Besonders als er das erste Register las und über SBA auf den Speicher zugriff, empfand er echte Erfüllung
- Das heißt: Wenn KI nicht als Code-Autor, sondern als Assistent eingesetzt wird, sind positive Erfahrungen möglich
Abschließende Reflexion
- KI-Codegenerierung ist schnell, führt jedoch zu einem Verlust von Bedeutung, Gespür und Eigentum
- Wenn das menschliche „Gespür“ für guten Code verschwindet, gerät auch das Wesen des Programmierens ins Wanken
- Der Autor hofft, dass dieses Phänomen nur eine vorübergehende Übergangsphase ist, und schließt damit, dass er selbst nicht sagen kann, was „bessere Programmierung“ eigentlich ist
Die technischen Abschnitte (1–20) nach dem Originaltext sind eine detaillierte Implementierungsdokumentation des RP2350-RISC-V-Debug-Protokolls und enthalten eine vollständige technische Spezifikation des gesamten Debug-Stacks, darunter SWD-Schichtstruktur, DAP-/DAPC-Register, PROGBUF-Ausführung, SBA-Zugriff, Hart-Steuerung, Tracing, Reset und Dual-Hart-Struktur.
Das Kernthema ist jedoch eine persönliche Fallstudie (Vibe Code Warning) über die „Entkopplung zwischen KI-generiertem Code und menschlichem Gespür“.
1 Kommentare
Hacker-News-Kommentare
Ich kann die Gefühle der Leute nachvollziehen, die sagen: „AI hat dem Programmieren den Spaß genommen“, aber ich halte „etwas tun“ gegenüber „etwas fertigstellen“ für weniger wichtig als das Ergebnis.
Früher verloren Gaslaternenanzünder durch die elektrische Beleuchtung ihre Arbeit, aber letztlich ging es darum, einer Stadt Licht zu geben.
Für mich ist AI ein Werkzeug, um Ideen umzusetzen und Resultate zu erzeugen. Ich investiere immer noch ähnlich viel Zeit und Mühe wie die „echten Programmierer“, nur liegt mein Fokus auf Problemdefinition, Modularisierung, Tests, Bugfixing und iterativer Verbesserung.
Wichtig ist, eine Welt zu schaffen, in der Menschen Sinn, Würde und Freude empfinden können.
Wenn ich leckeres Essen bekomme, das aber von Menschen unter Leiden hergestellt wurde, oder wenn es von böswilligen Kräften per Roboter produziert wurde, dann will ich es nicht.
Gesellschaft ist für Menschen da und nicht einfach eine Checkliste für Effizienz.
Bei persönlichen Projekten mag das in Ordnung sein, aber in Umgebungen mit Kunden, Nutzern oder Aktionären braucht man nachweisbare Ergebnisse.
Der Vergleich mit Gaslaternen passt nicht. AI ist kein physisches System wie Elektrizität, sondern Software.
Am Ende zählt Problemlösung. Wenn nichts gelöst wird, ist es nur Arbeit.
Viele schreiben Code nicht nur, um nützliche Software zu bauen, sondern wegen der Freude am Schaffen.
Auch „echte Programmierer“ verbringen ihre Zeit damit, zu denken, zu definieren, zu testen und zu korrigieren.
Ein „smarter Zahnseidespender“, ein automatischer Toilettenpapier-Besteller oder Bots wie Clippy sind Verschwendung von Zeit und Energie.
Nicht nur das Ergebnis zählt, auch der Lern- und Verstehensprozess bringt große Befriedigung.
Beim Lesen des Survival-Buchs Adrift, 76 Days at Sea hatte ich das Gefühl, dass tiefes Wissen über Leben und Tod entscheiden kann.
Das ähnelt auch der Frage, ob man seine Daten selbst hostet oder einem zentralisierten Dienst anvertraut.
Wenn ich im Internet einen Text sehe, der meine Gedanken perfekt ausdrückt, fühlt sich das wirklich tröstlich an.
Danke, dass hier von menschlicher Erfahrung gesprochen wird statt von dem üblichen Lärm à la „Passe einfach den Prompt so an“.
Um da wieder herauszukommen, muss ich erst einmal eine Nacht richtig schlafen.
Es liefert fast richtige Antworten, hat psychologisch aber eine ähnliche Sogwirkung wie Glücksspielautomaten.
Jemand sagte, er habe „mit AI in 10 Stunden 10.000 Zeilen Code geschrieben, und es war furchtbar“, aber diese Erfahrung fällt je nach Vorgehensweise völlig unterschiedlich aus.
Prompt-Strukturierung, Planung, Review, Tests, Tempokontrolle – all das ist von Person zu Person verschieden.
Viele Einsteiger scheitern mit dem improvisierten Ansatz, der als vibe coding bezeichnet wird.
Die Ermüdung ist groß, deshalb pausiere ich gerade, und irgendwann will ich eigene Agenten bauen.
So etwas Big Tech wie OpenAI, Microsoft oder Anthropic zu überlassen, erscheint mir riskant.
Für mich ist das am Ende nur ein Schlagwort ohne Substanz.
Es fühlt sich eher an, als würde man vor dem Lernen einer neuen Library ins Projektmanagement flüchten.
Auch der damals viel diskutierte Beitrag „Just Talk to It“ blieb bei den Details dünn.
Je improvisierter man arbeitet, desto gründlicher muss man planen. Ist das im Kern dein Punkt?
Öffentlich verfügbarer Code ist inzwischen oft kein von Menschen geschriebener Code mehr.
Wenn solcher Code wieder in Trainingsdaten einfließt, besteht die Gefahr, dass die Welt mit noch mehr sinnlosen Ergebnissen gefüllt wird.
Schon in der Sprachforschung gibt es Fälle, in denen maschinell erzeugter Text die Datensammlung praktisch wertlos gemacht hat.
In den meisten Fällen geben Menschen immer noch die Richtung vor.
Natürlich mache ich mir Sorgen, wenn ein Zwölfjähriger „yolo 3d game now“ eintippt, aber gleichzeitig wäre das auch irgendwie cool.
vibe-codierter Code fühlt sich beim Lesen an wie „English as She is Spoke“.
Die Grammatik stimmt, aber es ist kein Code, der sich wie menschliche Sprache anfühlt.
Ich empfinde das ähnlich.
Wenn ich normalerweise eine App entwickle, entsteht über mehrere Tage ein mentales Modell in meinem Kopf, und selbst unter der Dusche denke ich die Struktur neu durch.
Beim vibe coding verschwindet dieser innere Kontext jedoch, und das Lesen des Codes wird schmerzhaft.
Dagegen macht es Freude, Code zu lesen, den ich selbst geschrieben habe.
Ich verstehe die Verbindungen zwischen Systemen und die Datenflüsse, aber die Details der Implementierung bleiben verschwommen.
Ich habe ähnliche Erfahrungen gemacht. LLMs haben den Spaß am Programmieren reduziert.
Meine Routine besteht heute aus „Prompt schreiben → kurz warten → wiederholen → Code-Review“.
Ich verstehe die Struktur des Codes, aber weil ich ihn nicht selbst mit den Händen bearbeite, bleibt die Tiefe des Verständnisses flach.
Mit dem richtigen Training wäre das vielleicht möglich, aber ich bin noch nicht an diesem Punkt.
Für das Generieren von Tests sind sie nützlich. Einen guten Test schreibe ich selbst, den Rest lasse ich AI erledigen, um Zeit zu sparen.
So erkenne ich die Grenzen und schreibe es anschließend mit besserem Systemdesign neu.
Selbst der weitschweifige Code von LLMs wirkt auf mich noch besser als der bizarr zusammengezimmerte Code, den frühere Entwickler hinterlassen haben.
Etwas überzogen formuliert, aber ich kann es nachvollziehen.
LLMs sind nützlich für das Verstehen und Zusammenfassen vorhandenen Codes, für Autovervollständigung und fürs Prototyping durch Nicht-Entwickler, aber
zum Schreiben von Production-Code sollte man sie niemals verwenden.
Die Lösung ist, das Modell zu grounden.
Im Code ist testgetriebene Entwicklung (TDD) genau diese Methode.
Man schreibt zuerst Tests, bestätigt, dass sie fehlschlagen, prüft warum, und lässt dann den Code schreiben.
So entsteht eine Verhaltensspezifikation für den Code, die später als Dokument dient, auf das Menschen oder Agenten zurückgreifen können.
Ich habe das README auf GitHub bis zum Ende gelesen und festgestellt, dass der Autor zugibt, dass drei Viertel des Codes AI-generiert sind, während er gleichzeitig Urheberrechte beansprucht.
Für Inhalte, die nicht von Menschen geschaffen wurden, gibt es bereits Präzedenzfälle, dass sie rechtlich nicht urheberrechtlich geschützt sind.