15 Punkte von GN⁺ 2026-02-09 | 14 Kommentare | Auf WhatsApp teilen
  • Nach wiederholter Nutzung von LLM-basierten Codegenerierungs-Tools entdeckte der Autor das Gefühl von Flow und Freude beim eigenen Schreiben von Code wieder
  • Code zu schreiben ist nicht nur ein Akt der Produktion, sondern ein Prozess des Verstehens des Problemraums und der Schärfung des Denkens – automatische Generierung stört genau das
  • Die Korrektheit von Code, den man nicht selbst geschrieben hat, ist schwer zu verifizieren; nur beim eigenen Schreiben wird der Kontext wirklich verinnerlicht
  • Indem man LLMs nur begrenzt nutzt – Kontext manuell bereitstellt und sie nur für Teiländerungen am Code oder zum Erzeugen von Tests einsetzt – behält man die Kontrolle über das eigene Denken
  • Statt Produktivität zu maximieren, sollte man Denktiefe und Glücksgefühl priorisieren und wachsam sein, wenn Werkzeuge das Denken behindern

Erfahrungen mit LLM-Codegenerierung und wachsende Skepsis

  • Der Autor hat claude-code mehrfach verwendet, fühlte sich danach aber jedes Mal niedergeschlagen und antriebslos und löschte es schließlich wieder
    • Der automatisch generierte Code wirkte zwar „plausibel“, ließ ihn aber den Sinn seiner eigenen Arbeit verlieren
    • Jedes Mal, wenn er das Tool nicht mehr nutzte, fand er die Freude am Programmieren wieder
  • Programmieren ist nicht bloß Implementierung, sondern ein Prozess des Erkundens des Problemraums und des Lernens durch Scheitern
    • Um eine API wirklich zu verstehen, muss man sie selbst benutzen; nur die Dokumentation zu lesen reicht nicht aus
    • Der Akt des Codierens selbst ist ein Mittel, Gedanken zu konkretisieren

Der Zusammenhang zwischen Denken und Korrektheit

"Wenn man nicht schreibt, sondern nur denkt, dann täuscht man sich nur darüber, dass man denkt." - Leslie Lamport

  • Die Korrektheit von Code, den man nicht selbst geschrieben hat, zu überprüfen, ist deutlich schwieriger
  • Beim eigenen Schreiben wird der Problemkontext verinnerlicht, und das ist entscheidend, um die Qualität des Codes zu verstehen
  • Wer sich auf LLMs verlässt, überspringt diesen Prozess und schwächt damit das Verständnis der Problemdomäne

Die Suchtwirkung und Nebenfolgen von „Vibe coding“

  • LLM-Codegenerierung hat eine süchtig machende Eigenschaft durch sofortige Dopamin-Belohnung
    • Sie erzeugt die Illusion: „Wenn ich den Prompt nur noch ein bisschen anpasse, wird es schon richtig sein“
  • Diese Arbeitsweise fördert eine Trägheit des Denkens, macht das Gehirn passiv und führt dazu, dass man selbst für einfache Aufgaben vom LLM abhängig wird
    • Als Beispiel nennt der Autor, dass er sogar ein simples find-and-replace dem LLM überließ und dadurch mehr Zeit verlor
  • Auch wenn viel Code generiert wird, liegt die Verantwortung für Review und Verständnis am Ende weiterhin beim Menschen – das kann sogar zum Engpass werden

Wie Werkzeuge das Denken formen

  • Aus der Perspektive, dass „Werkzeuge nicht neutral sind“, gilt: Werkzeuge, die das Denken behindern, sind schlechte Werkzeuge
    • Die Kernkompetenz von Wissensarbeitern ist die Fähigkeit, tief nachzudenken; Technologien, die das behindern, sollten kritisch betrachtet werden
  • Dennoch schließt der Autor LLMs nicht vollständig aus, sondern nutzt sie bewusst und begrenzt
    • Er kopiert nur die nötigen Dateien hinein, um Kontext zu geben, und verwendet sie nur für partielle Codeänderungen oder das Schreiben von Tests
    • So bleibt der Umfang der generierten Änderungen klein, und die Gesamtstruktur der Codebasis kann er selbst erfassen
    • Dadurch wird aus passiver Generierung eine „durchdachte Generierung“, die geistige Aktivität und den Flow-Zustand erhalten kann

Das Gleichgewicht zwischen Glück und Produktivität

  • Das Leben ist kurz, und Glück sollte Priorität haben
    • Das automatische Generieren kompletter Features kann die Produktivität steigern, doch wenn es existenzielle Unruhe und Niedergeschlagenheit auslöst, ist es langfristig unproduktiv
  • Der Autor räumt ein, dass man seine Gefühle teilen kann oder auch nicht,
    „Habt keine Angst davor, euch anders zu entscheiden“

14 Kommentare

 
naruchingu 2026-02-10

Wir leben in einer Welt, in der man mit einem einzigen Schnappschuss auf dem Handy ein Foto machen kann, und trotzdem leben wir auch in einer Welt, in der jemand noch immer stundenlang ein Bild zeichnen kann. Es sind lediglich unterschiedliche Prozesse und Ausrichtungen; ich glaube nicht, dass es dabei um richtig oder falsch geht.

 
nimgnos 2026-02-09

Es gibt eben auch Menschen, die trotz Taschenrechner lieber von Hand oder im Kopf rechnen.

 
su79eu7k 2026-02-09

Ich glaube vorsichtig, dass es der Produktivität helfen könnte, wenn man sehr komplexe und für die Business-Logik zentrale Teile einmal selbst von Hand schreibt, sich dabei Gedanken macht und diesen Prozess dann an AI-Ingenieure weitergibt. Auch Mathematiker nutzen Werkzeuge wie Taschenrechner, aber wenn sie über die Kernideen nachdenken, machen sie sich ja ebenfalls viele Notizen.

 
wkdehf555 2026-02-09

Für mich klingt das nur so, als wolle man frontal mit der Richtung kollidieren, die Unternehmen verfolgen..

 
dolsangodkimchi 2026-02-09

Ich respektiere das Ideal von persönlichem Glück und Zufriedenheit, aber aus der Perspektive eines Berufs, in dem man Arbeit leistet und dafür bezahlt wird, scheint mir das eine ungeeignete Haltung zu sein.

 
foriequal0 2026-02-09

Wenn jemand langfristige Metriken ignoriert und nur kurzfristigen Metriken hinterherläuft, bekommt man vermutlich selbst als völlig Unbeteiligter im Vorbeigehen das Bedürfnis, ihm ungefragt einen Ratschlag zu geben nach dem Motto: „So macht man das nicht, tsk tsk.“
Aber wenn man ein Programmierer ist, der glaubt, mit dem Unternehmen durch dick und dünn zu gehen, einen großen Beitrag zu leisten und in der Firma eine wichtige Rolle zu erfüllen, wie viel stärker muss dieses Gefühl dann erst sein.

 
geeksk553 2026-02-09

Gerade die wirklich guten und fähigen Entwickler, die wirklich stark entwickeln, haben offenbar Spaß an Vibe Coding ...

Nicht meine Worte (sondern die von Linus Torvalds oder Robert Martin)

 
dieafterwork 2026-02-10

Ich habe es nur für Python-Skripte verwendet. Ich weiß nicht, ob man sagen kann, dass ich es wirklich genossen habe.

 
cocofather 2026-02-10

Wenn ich nach Artikeln über Linus Torvalds suche, scheint es so zu sein, dass er es als Hobby nutzt und es für die Linux-Entwicklung noch nicht verwendet.

 
GN⁺ 2026-02-09
Hacker-News-Kommentare
  • Coding wird mit Holzverarbeitung verglichen. Auch wenn Maschinen Möbel herstellen können, gibt es immer noch Menschen, die sie von Hand bauen. Hand-Coding könne ähnlich aus Freude daran weiterbestehen, werde beruflich aber künftig schwierig sein

    • Dieser Vergleich passe nicht gut. Eine Motorsäge sei eine vom Menschen geführte Zentauren-Technologie, während GenAI umgekehrt eine umgekehrte Zentauren-Technologie sei, bei der der Mensch assistiert. Die Motorsäge ersetzt den Menschen nicht, AI könnte aber die Hälfte eines Teams überflüssig machen
    • In der Holzverarbeitung werden identische Produkte wiederholt gefertigt, aber Code wiederholt sich nicht. In den meisten Projekten sind Anforderungserhebung oder Design der Engpass, daher ist der Produktivitätsunterschied zwischen Hand-Coding und AI-Coding begrenzt
    • Es wird gefragt, ob der Übergang von natürlicher Sprache zu Code dem Übergang von Hochsprachen zu Assembler ähnelt. Brooks’ „essenzielle Komplexität“ verschwinde, und dank standardisierter Muster komme eine Zeit, in der AI vage Absichten in ausführbaren Code verwandelt. Am Ende steigt der Wert von Experten, aber die Nachfrage nach Standard-Ingenieuren sinkt
    • Es wird die Frage gestellt: „Wenn wir Hand-Coding beruflich nicht mehr machen können, wofür werden wir dann bezahlt?“ Es wird bezweifelt, ob man auf Kundenkontakt oder zum LLM-Prompt-Schreiber reduziert wird
    • Es wäre traurig, wenn Hand-Coding nicht mehr als wertvoll angesehen würde. Es macht weiterhin Freude, aber der Wertverlust schmerzt
  • Ich wähle langfristig die Methode, die die schnellsten und besten Ergebnisse liefert. Im Moment sind das neovim und Hand-Coding. Wenn man selbst tippt und ein Projekt tief versteht, kann man langfristig schneller Features liefern. Arbeit, die nichts zum Lernen beiträgt, überlasse ich dem LLM, und davon gibt es genug, daher nutze ich LLMs oft

    • Die Sichtweise „Tiefes Verständnis macht auf lange Sicht schneller“ ist eindrucksvoll
    • Ich arbeite genauso. Ich sage meinem Team, dass wir nicht auf 6 Monate, sondern auf 2 Jahre optimieren sollten
    • Ich mache nur die Bereiche selbst, in denen es etwas zu lernen gibt, und versuche den Rest so weit wie möglich zu automatisieren
    • Wenn man mehrere Agenten nutzt, gibt es viel Kontextwechsel, und man hat eher das Gefühl, den Gesamtkontext zu verlieren
  • Das Problem mit vibecoding ist, dass das Gefühl, „es fühlt sich gut an“, die tatsächlichen Ergebnisse verschleiert

    • Für manche fühlt es sich nur gut an, ich selbst ziehe Freude aus dem tiefen Verständnis des Problems und des Codes
    • „Vibe-Doku lesen“ ist gut, aber Vibe Coding erzeugt wortreichen Code mit zu viel Abstraktion, der schwer zu verstehen ist und unter den ich meinen Namen nur ungern setzen würde
    • Selbst mit Planung muss man am Ende oft wieder ganz von vorne anfangen, was frustrierend ist
    • Es ist schwer zu unterscheiden, ob die Produktivität wirklich gestiegen ist oder ob es sich nur so anfühlt
    • Ich habe mit Windows Copilot experimentiert, aber es war langsam und die Qualität schlecht, also hat es keinen Spaß gemacht
  • Es wird die zynische Frage gestellt: „Steigt die produzierte Code-Menge nur weil man glücklich ist um das 200-Fache?“

  • AI hat klaren Wert. Wenn man zum Beispiel eine DB-Tabelle mit 300 Spalten in ein Rust-struct umwandelt, erzeugt ein Prompt mit 15 Wörtern 900 Zeilen Code. Für solche Wiederholungsarbeiten ist AI perfekt. Aber ich will ihr nicht alles überlassen. Ich nutze sie nur auf einem angenehmen Nutzungsniveau

    • So ein Ansatz könnte verhindern, dass man ein schlechtes Schema oder Design verbessert
    • Es erscheint besser, in Python ein Codegenerierungs-Skript zu schreiben. Bei AI gibt es Zuverlässigkeitsprobleme, etwa wenn Feldnamen subtil verändert werden
    • Der Energieaufwand dafür, dass ein Mensch Kaffee trinkt und codet, ist viel höher als bei AI
    • Die Nutzung von AI fühlt sich wie Dopamin-Sucht an
  • Die Kernfrage ist: „Was mache ich, während das LLM den Code für mich schreibt?“ Man kann es nicht vollständig machen lassen, es fühlt sich eher an, als müsse man daneben aufpassen. Junior-Entwickler wachsen, aber ein LLM lernt nicht. Deshalb fühlt es sich an, als sei die Erfüllung durch Mentoring verschwunden

    • Ich lasse gleichzeitig mehrere Agenten laufen und entwickle Features, behebe Bugs und aktualisiere Dokumentation parallel. Zu tun gibt es immer noch genug, es ist kein Doomscrolling
  • Ich frage mich, wie sich Developer Hiring in letzter Zeit verändert hat. Ist die Nutzung von LLMs erlaubt, oder wird weiterhin Hand-Coding verlangt?

    • Große Unternehmen verändern sich noch langsam. Wegen rechtlicher Eigentumsfragen zögern sie beim Einsatz von AI-generiertem Code
    • Künftig werden wohl sowohl Hand-Coding als auch AI-Coding verlangt. Beim Hiring kommt einfach noch eine weitere Hürde dazu, wie immer
    • Mittelgroße Unternehmen stoppen das Hiring oder stellen nur noch Entwickler ein, die AI nutzen. Große Unternehmen verlangen weiterhin Leetcode und Systemdesign
    • Die meisten Unternehmen erkennen den Umfang von LLM-bedingtem Schummeln noch nicht
  • Schon vor LLMs habe ich mit modellbasierter Entwicklung (MDD) in einem Tempo auf Vibecoding-Niveau entwickelt. Das Datenmodell ist die Anwendung, und das LLM schreibt darauf nur prozedurale Teile etwas schneller. Die Richtung des Datenmodells bestimme weiterhin ich

  • AI-Coding lässt sich in drei Arten einteilen

    1. Suche nach bereits online vorhandenem Code
    2. Vollständig neuer Code, bei dem AI nur beim Tippen hilft
    3. Erzeugung von repetitivem, Boilerplate-lastigem Code — das ist ein Scheitern des Frameworks
    • Was AI gut kann, ist vielleicht genau das, was wir gar nicht tun sollten. Die eigentliche Herausforderung ist, eine Sprache zu finden, die das, was wir wollen, schön ausdrückt
    • Frameworks haben sich nicht weiterentwickelt, und LLMs sind zu einem Werkzeug geworden, das jedes Problem wie einen Hammer sieht
  • Die moderne Gesellschaft entwickelt sich zu einer Struktur, in der man durch Button-Klicks Dopamin bekommt. Deshalb fühlt sich alles chaotisch an

    • Es wird die Realität gespottet, in der der Spielautomat zur ultimativen UX geworden ist
 
redline2151 2026-02-09

In letzter Zeit tauchen ständig Artikel von geistig siegreichen, abgehängten Entwicklern auf. Den Lauf der Zeit kann man ohnehin nicht aufhalten.

 
cjm01115 2026-02-09

Das geht wirklich viel zu weit.

 
geeksk553 2026-02-09

Ich stimme dieser Meinung auch zu: Selbst wenn jemand darauf besteht, von Hand zu coden, wird er oder sie letztlich ersetzt werden, solange man nicht allein ein Geschäft betreibt
aber ich glaube, dass einem das nicht bewusst ist.

 
hmmhmmhm 2026-02-09

Uff, das ist schon ziemlich hart gesagt :'(