Die Entstehung der „Vibe-Coding-Hölle“ als Ersatz für die „Tutorial-Hölle“

• In der aktuellen Coding-Ausbildungslandschaft tritt an die Stelle der „Tutorial-Hölle“ zunehmend die „Vibe-Coding-Hölle“ als neues Problem
• Wenn die Tutorial-Hölle ein Zustand war, in dem man „ohne Tutorial nichts bauen kann“, dann bedeutet die Vibe-Coding-Hölle einen Zustand, in dem man „ohne AI nicht coden kann und nicht versteht, wie der von AI erzeugte Code funktioniert“
• Die übermäßige Nutzung von AI-Tools senkt die Lernmotivation, und paradoxerweise nutzen Menschen mit geringer AI-Kompetenz AI oft noch stärker
• Richtig eingesetzt können AI-Tools eine große Hilfe beim Lernen sein, doch die bloße Nutzung nach dem Muster „einfach nur die Antwort bekommen“ behindert den Aufbau eines konstruktiven Verständnisses
• Entscheidend ist die eigene Anstrengung im Lernprozess, selbst nachzudenken und Probleme eigenständig zu lösen; wichtig ist eine Haltung, in der man Erfahrung beim Lösen von Problemen ohne Tutorials oder AI-Hilfe sammelt

---

Hintergrund des Problems: von der Tutorial-Hölle zur Vibe-Coding-Hölle

• 2019 war das Hauptproblem in der Coding-Ausbildung die „Tutorial-Hölle“
  • Man schafft es zwar, Tutorials nachzumachen, kann aber allein nichts bauen
  • Man verbringt mehr Zeit mit dem Anschauen von Programmiervideos als mit dem eigentlichen Programmieren und versteht die Kernkonzepte nicht
  • Am Ende sammelt man nur oberflächliches Wissen und kann in der Praxis keinen Code selbst schreiben, weil man die internen Funktionsweisen nicht versteht
• Boot.dev konzentrierte sich zur Lösung auf drei Dinge
  • Tiefgehendes Curriculum: Betonung der Notwendigkeit, auch außerhalb klassischer Hochschulen die CS-Grundlagen zu lernen
  • Praxisorientierter Ansatz: Zu jedem Konzept wird auch direkt selbst Code geschrieben
  • Stärkung von Rich Text statt Video: Videos bergen das Risiko, bei passivem Konsum stehenzubleiben
• Lange YouTube-Kurse, die 2019 noch Millionen Aufrufe erzielten, haben heute oft Schwierigkeiten, überhaupt 50.000 Aufrufe zu erreichen
  • Kanäle wie FreeCodeCamp, Traversy Media und Web Dev Simplified zeigen diesen Trend
• Die Google-Trends-Daten zu „learn to code“ zeigen jedoch weiterhin ein hohes Interesse
• Bei Boot.dev registrieren sich täglich rund 1.300 neue Nutzer, und in den letzten 18 Monaten gingen Beschwerden über die Tutorial-Hölle zwar zurück, doch eine neue Form von Schwierigkeiten ist entstanden

Definition der Vibe-Coding-Hölle

• Merkmale der Tutorial-Hölle
  • „Ohne Tutorial kann ich nichts bauen“
  • „Ich verstehe die Dokumentation nicht, also brauche ich Videos“
  • „Selbst für einfache Aufgaben brauche ich ein komplexes Framework“
• Merkmale der Vibe-Coding-Hölle
  • „Ohne die Hilfe von Cursor kann ich nichts machen“
  • „Ich habe ein cooles Tower-Defense-Spiel gebaut. Hier ist der Link: http://localhost:3000“
  • „Ich weiß nicht, warum Claude 6.379 Zeilen hinzugefügt hat, um Lazy-Loading für Bilder zu machen“
• Heutige Selbstlerner bauen zwar viele Dinge, entwickeln dabei aber keine Mental Models dafür, wie Software funktioniert
• Sie kämpfen mit Halluzinationen von AI, ringen mit Bots, die nur auf das Bestehen von Tests fokussiert sind, und vertrauen blind dem von AI erzeugten Code, statt reale Probleme selbst zu lösen

Zukunft und Realität des AI-Codings

• Kurzfristig bin ich eher der Ansicht, dass AI Entwickler nicht vollständig ersetzen wird
  • Seit drei Jahren hört man schon „noch 6 Monate, bis AI die Jobs übernimmt“, und trotzdem werden weiterhin Entwickler eingestellt
• GPT-5 ist erschienen, blieb gegenüber GPT-4 aber bei einer schrittweisen Verbesserung, was als Hinweis gelesen werden kann, dass AGI nicht unmittelbar bevorsteht
• Ich nutze täglich AI-Tools, bin mir aber nicht sicher, wie sehr meine Produktivität dadurch tatsächlich steigt
  • Es ist unklar, ob AI produktiver macht oder nur bequemer
• Forschungsergebnis von 2025: Entwickler gingen davon aus, dass AI die Produktivität um 20–25 % steigert, tatsächlich wurden sie aber um 19 % langsamer
  • Ein enttäuschendes Ergebnis gemessen an Investitionen von 7 Billionen Dollar

Risiken von AI und sinkender Lernmotivation

• Eine Kultur intensiver AI-Nutzung kann sich negativ auf die Motivation von Lernenden auswirken
• Das größte Problem am AI-Hype (an der Blase?) ist die mögliche Entstehung einer Generation mit der Haltung: „Warum sollte ich das lernen? AI weiß doch schon alles.“
• Wenn AI tatsächlich nicht alle White-Collar-Jobs ersetzt, droht nicht nur eine Blase am Aktienmarkt, sondern auch eine Dürre an gut ausgebildeten Fachkräften
• Investoren ohne technischen Hintergrund missverstehen oft, dass „AI bereits das ganze Coding ersetzt hat“, während Senior-Entwickler weiterhin keine wirklich nützliche Methode gefunden haben, AI-Tools in den Arbeitsalltag zu integrieren
• Besonders besorgniserregend ist die Tendenz, dass Menschen mit geringer AI-Literacy AI noch stärker nutzen
  • Das wirkt wie die ultimative Dunning-Kruger-Falle – also das Phänomen, dass Menschen mit wenig Wissen fälschlich glauben, sie wüssten besonders viel
  • Lernende kommen zu dem Schluss, dass Selbstentwicklung sinnlos sei, „weil AI es ohnehin schon weiß“

Ist AI nützlich fürs Lernen?

• Das gesellschaftliche Interesse daran, coden zu lernen, ist weiterhin hoch
• AI kann fürs Lernen nützlich sein, aber es gibt zwei strukturelle Probleme

• Erstens: das Problem der Schmeichelei (sycophant)

  • AI-Chatbots neigen dazu, der Meinung des Fragenden übermäßig zuzustimmen
  • Wenn man über „ROAS (Return on Ad Spend)“ chattet, kommen bei denselben Daten je nach Richtung der Frage komplett gegensätzliche Schlussfolgerungen heraus, beide mit sicherem Expertenton vorgetragen
  • Dadurch wird Lernenden die Möglichkeit genommen, Verifikation, kritisches Denken und das Korrigieren von Fehlern zu erleben
    • Man fragt Experten schließlich, damit sie einem sagen, wenn man falschliegt
    • IRC-Chats oder Stack Overflow konnten das gut (vielleicht sogar zu gut)
    • LLM-Chatbots (Large Language Models) neigen stark dazu, grundlegende Missverständnisse bestehender Lernender nicht zu korrigieren
    • Studierende führen heute angenehme Gespräche mit LLMs und hören dadurch eher das, was sie hören wollen, statt das, was sie hören müssen

• Zweites Problem: Lernende wollen echte „Meinungen“

  • AI präsentiert eine übermäßig ausgewogene Position
    • „Manche Leute denken X und manche Leute denken Y“
    • Für Lernende wird es dadurch schwieriger zu entscheiden, welcher Seite sie zustimmen sollen
  • Es wurde versucht, sie mit Prompts wie „spiele einen Kapitalisten“ oder „spiele einen marxistischen Revolutionär“ zu steuern, doch das Ergebnis war nicht zufriedenstellend
  • Lernende möchten Meinungen und Kommentare aus echter Erfahrung hören
    • DHHs Gründe für das Entfernen von TypeScript aus Turbo
    • Was TypeScript laut Anders Hejlsberg für JavaScript-Entwickler löst
    • Gerade durch echte Positionen, in denen Vorurteile und Kontext der Autoren klar hervortreten, entstehen nuancierte Mental Models
  • Die für LLMs typische neutrale und vorsichtige Antwortweise behindert die echte Internalisierung von Wissen

Wann AI beim Lernen wirklich hilft

• Richtig eingesetzt ist AI ein erstaunliches Werkzeug zum Lernen
• Es gab nie eine einfachere Zeit, um Programmieren zu lernen
• Das Beispiel Boots von Boot.dev (AI-Lernhilfe)
  • Studierende nutzen den Chat mit dem AI-Tutor Boots fast viermal so häufig wie das Anzeigen der Instructor Solution (der idealen Musterlösung)
  • Anders als ein allgemeiner Chatbot unterstützt Boots das Lernen auf folgende Weise
    • Es ist vorab so gepromptet, dass es die Antwort nicht direkt verrät
    • Es nutzt die sokratische Methode, um Studierende dazu zu bringen, tiefer über das Problem nachzudenken
    • Es hat Zugriff auf die Lösung des Lehrenden, wodurch Halluzinationen über die richtige Antwort viel unwahrscheinlicher sind
    • Es hat eine unterhaltsame Charakterisierung (ein Zauberer-Bär)

So entkommt man der Vibe-Coding-Hölle

• Letztlich gilt: Ob Tutorial-Hölle oder Vibe-Hölle – entscheidend ist die Erfahrung, Dinge nicht an andere auszulagern, sondern selbst zu tun
  • Tutorial-Hölle: Video ausschalten und selbst Code schreiben
  • Vibe-Hölle: AI-Autovervollständigung wie Copilot abschalten und selbst Erfahrungen beim Lösen von Problemen sammeln
• Was man vermeiden sollte:
  • AI-Autovervollständigung im Editor
  • Projekte per Agent Mode und AI-Automatisierungstools abwickeln
• Was man nutzen kann:
  • Chatbots, die Fragen beantworten, Konzepte erklären und Beispiele liefern
  • System Prompts, die zur sokratischen Fragetechnik anhalten, um tieferes Denken zu fördern
  • System Prompts, die verlangen, Behauptungen mit Quellen zu belegen und auf Dokumentation zu verlinken, um die Verlässlichkeit von Informationen zu sichern

Kernprinzip

• Lernen muss unbequem sein
  • Die Tutorial-Hölle erlaubt es, Unbehagen zu vermeiden, indem man anderen beim Coden zusieht
  • Die Vibe-Coding-Hölle erlaubt es, Unbehagen zu vermeiden, indem man AI den Code schreiben lässt
• Echtes Lernen geschieht, wenn man hängenbleibt, frustriert ist und – vor allem – gezwungen wird, Probleme zu lösen
  • So verdrahtet sich das menschliche neuronale Netz neu
• Wenn man das Konzept „Lernen muss schwer sein“ überdehnt, kann es zur Ausrede für schlechtes Unterrichtsdesign werden
  • Der Autor verteidigt das nicht
  • Selbst wenn ein Konzept bestmöglich erklärt wurde, versteht ein Lernender es erst wirklich, wenn er damit ringt und es in einem neuen Kontext selbst anwendet
• Echtes Lernen vollendet sich dadurch, dass man selbst steckenbleibt, frustriert ist und den Durchbruch aus eigener Kraft schafft

[aer0700]

Das ist zwar ein etwas anderer Kontext, aber dass die Tutorial-Hölle entsteht, liegt auch daran, dass Framework-Tutorials nicht als grundlegende Lehrmaterialien für Informatik verwendet werden.
Ein Anfänger, der sich das Django-Tutorial angesehen und eine Poll-App gebaut hat, kann nicht allein einen Blog erstellen, weil das Django-Tutorial ein Text ist, der Django für Menschen erklärt, die bereits wissen, was HTTP ist, was Templates sind, was WS ist, was eine DB ist usw. — es ist kein Text, der das Web erklärt. Im Django-Tutorial wird sehr viel Kontext ausgelassen, und ich denke, das ist vielleicht die Ursache dafür, dass die Tutorial-Hölle entsteht.
Es wäre vielleicht auch eine gute Aufgabe, das Django-Tutorial einmal für Menschen neu zu schreiben, die heute zum ersten Mal programmieren. Zum Beispiel so, dass man zuerst die Struktur von HTTP erklärt und dann erläutert, wie Django die einzelnen Elemente handhabt.

[gudrb963]

Das ist eine wirklich großartige Meinung!

[GN⁺]

Hacker-News-Kommentare

• Der Begriff „Tutorial Hell“ trifft es so gut: Man schaut sich einen sechsstündigen Kurs an und codet alles nach, aber sobald man etwas von Grund auf selbst bauen soll, ist man komplett blockiert. Genau das ist typische Tutorial Hell. Deshalb war historisch gesehen das Handwerk mit Lehrlingen die effektivste Lernmethode: Juniors laufen Seniors hinterher, und ein Meister führt das Ganze von oben. Der Handwerker übernimmt gleichzeitig Projektmanagement und Anleitung. Schade, dass unsere Entwicklergemeinschaft nie lange wie eine Gilde organisiert war. Ich finde, spätestens seit Ende der 1980er hätte das anders laufen sollen. Mit einer Gilde hätte es vermutlich deutlich weniger Entwickler gegeben, und die Entwicklung der Branche wäre vielleicht ganz anders verlaufen.

  • Nicht nur Einsteiger, auch erfahrene Entwickler tun sich schwer, wenn man ihnen sagt, sie sollen ein Projekt aus dem Nichts starten. Meist arbeitet man auf einer bestehenden Codebasis, und selbst wenn eine neue App gebraucht wird, fängt man in der Regel mit Templates oder Copy-and-Paste an. Etwas wirklich komplett Neues von Grund auf zu bauen, ist selten. So wie ein Elektriker in einem Neubau Leitungen verlegt, setzen Entwickler in Unternehmen nur selten tatsächlich etwas völlig von Anfang an auf. Auch ein Lehrlingssystem würde diese Grundstruktur nicht wesentlich verändern.

  • Meiner Erfahrung nach trainieren gute Universitäten ihre Studenten mit schrittweisen und praxisnahen Aufgaben. Zuerst löst man einfache Datenstrukturen, Algorithmen oder Rätsel, später baut man Betriebssysteme, Datenbanken, persistente Datenstrukturen, Compiler, CPUs, Simulationen und Machine-Learning-Modelle. Man wächst von einer einzelnen Funktion hin zum eigenständigen Bau größerer Systeme, und ich bin für dieses Training wirklich dankbar. Siehe dieser Link.

  • Ich nutze LLMs beim Programmierenlernen wie eine Art Meister-Lehrling-Beziehung. Das LLM geht nur dann weiter, wenn ich es dazu auffordere, und gibt nur Erklärungen und Anleitung, während ich selbst schreibe. Das ist viel besser, als neue Kurse oder Tutorials zu suchen. Tutorial Hell ist letztlich ein Phänomen, das von Leuten erzeugt wurde, die sich selbst für Lehrer halten. Auch unzählige Bücher und Kurse schaffen es am Ende nicht, einem wirklich etwas beizubringen. Ich halte das aktuelle Modell der Programmierausbildung für grundsätzlich falsch. Heute bevorzuge ich, dass LLMs aktuelle Dokumentation zu neuen Sprachen oder Bibliotheken zusammenfassen oder dass ich meine Planung selbst mache. Etwas unzufrieden bin ich nur damit, dass ich nie ganz sicher bin, ob ein LLM halluziniert.

  • Ich habe die Schule sehr früh verlassen, vor allem wegen Langeweile und altmodischer Lehrmethoden, und bin als Software-Engineering-Lehrling direkt in die Praxis gegangen. Der Schulstoff war völlig nutzlos. Ende der 90er war alles ein ständiger Prozess aus Fehlern und Versuch und Irrtum, und ich, mein Meister und sogar dessen Meister haben alle durch direktes Ausprobieren gelernt. Wir haben mit Linux ISDN-Router gebaut, Webserver eingerichtet und mit HTML, Perl und PHP gearbeitet und dabei echtes DevOps und echtes Engineering erlebt, auch wenn es diese Begriffe damals noch gar nicht gab. Es war eine Zeit, in der man mit kaum vorhandener Dokumentation, aber viel Kreativität und Entdeckergeist die Grenzen erweitert hat. In mancher Hinsicht fühlt sich das ähnlich an wie das heutige Vibe Coding im AI-Zeitalter, nur mit viel mehr Druck, aber es sind großartige Erinnerungen.

  • In der Tech-Branche wird Gatekeeping im Beruf negativ gesehen. Das liegt am Hochmut innerhalb der Branche, aber auch daran, dass Kapitalinteressen das Arbeitskräfteangebot ausweiten wollen, um Löhne zu drücken. Dadurch sind echte Berufsstandards verschwunden, und demütigende Interviews wie LeetCode sind zu Gatekeepern für den Beruf geworden, obwohl sie mit dem eigentlichen Job wenig zu tun haben.

• Als jemand, der Zed Pro und GPT täglich beim Codieren nutzt, sehe ich in der Weiterentwicklung solcher Tools vor allem einen Hinweis darauf, wie ineffizient modernes Programmieren geworden ist. Das moderne Web ist gleichzeitig erstaunlich und schrecklich. Wenn Bürokratie bedeutet, in ein Geflecht komplizierter Regeln eingespannt zu sein, dann ist moderne Entwicklung ihr Paradebeispiel. Wenn selbst die einfachsten Dinge die Anleitung probabilistischer Automatisierungstools brauchen, ist das schon traurig. Früher habe ich Junioren immer gesagt: „Wichtig ist nicht, eine bestimmte Sprache zu kennen, sondern die Fähigkeit, ständig Neues zu lernen.“ Manche Trends bleiben länger, aber am Ende muss man immer wieder neue Tools und Sprachen lernen. Vielleicht liegt es an meinem Alter, aber irgendwann hatte ich das Gefühl, dass diese Komplexität überhandnimmt. Früher wirkte Programmierung zu sehr wie Elektrotechnik oder Mathematik, heute hat sich einfach eine andere Art von Komplexität darübergelegt.

  • Dieses Gefühl kenne ich auch. Wie in Science-Fiction-Filmen wünschte ich mir oft eine Computing-Umgebung, in der man sagen kann „Mehr Energie nach vorn!“, und Komponenten oder Systeme lassen sich jederzeit mühelos austauschen und wiederverwenden. In der Realität ist schon der Austausch der Kamera eines Android-Handys in ein iPhone fast ein unmögliches Unterfangen.

  • Ich verstehe nicht ganz genau, worauf du hinauswillst, aber der Gebrauch von „Bürokratie“ wirkt merkwürdig. Eigentlich ist Suchkompetenz die entscheidende Fähigkeit, und wer Dinge zuverlässig findet, kann so ziemlich alles machen. Automatisierungstools unterscheiden sich im Kern nicht wirklich von Büchern oder Lehrern. Dass manche Leute diese Fähigkeit nicht haben, ist eher eine Konstante menschlicher Natur, nicht die Schuld besserer Tools.

  • Ein großes Problem ist, dass es wirklich schwer ist, Dokumentation gut zu schreiben, zu durchsuchen und zu lesen. Deshalb ist Lernen so schwierig, aber dank AI ist es leichter geworden. Zum Beispiel versteht AI so etwas wie die Unreal Engine erstaunlich gut.

  • Viele der Probleme, die wir mit uns herumschleppen, sind genau die akzidentelle Komplexität aus Brooks’ „No Silver Bullet“. LLMs helfen dabei, sich durch diese Komplexität zu arbeiten und sogar die Wissenssilos aufzubrechen, die sich rund um einzelne Sprachen und Frameworks gebildet haben.

  • Wenn diese spekulative Branche noch ein wenig länger so weiterläuft, könnten wir am Ende in einer Welt landen, in der Programmieren selbst verschwindet.

• Heute kann im Prinzip jeder Code schreiben, deshalb verzehnfacht sich auf Organisationsebene die Menge an Code, aber die Zahl der Reviewer bleibt gleich, und das ist nicht mehr zu bewältigen. Wenn man nicht einmal einen LLM-Code-Sanity-Check nutzen kann, was soll man dann überhaupt noch tun? Gestern hat tatsächlich ein Nichtfachmann mit Codex einen Optimierungsalgorithmus gebaut, und ich wurde gebeten, ihn zu verbessern. Das Problem war nur, dass der Code völliger Mist war: eine naive Suche durch Tausende von Ganzzahlkombinationen, mit schlecht eingehaltenen Nebenbedingungen und entsprechend unzuverlässigen Ergebnissen. Am Ende habe ich den ganzen Tag damit verbracht, den Code zu prüfen, und musste den Führungskräften sogar noch präsentieren, dass das Ganze im Kern unbrauchbar ist.

  • Die Antwort auf „LLM-Code-Sanity-Check“ lautet Unit-Tests. LLMs erzeugen auf Anfrage auch Testcode und testbaren Code sehr gut. Wenn die Tests den Code wirklich aufrufen und auch Edge Cases gründlich prüfen, geht das viel schneller als ein Code-Review. Man kann auch Performance-Tests einbeziehen. Künftig werden wir wohl stärker über Definitionen und Tests arbeiten, während die konkrete Implementierung innerhalb von Funktionen immer weniger wichtig wird. Das ist ein großer Perspektivwechsel.

  • Man muss sich nur das Excel-Programmier-Chaos anschauen. Erst ignorieren es alle, und wenn es dann explodiert, werden plötzlich zigtausend Euro ausgegeben, damit das Unternehmen nicht daran zugrunde geht.

  • Zu dem Punkt „die Zahl der Reviewer bleibt gleich“: LLMs können auch beim Code-Review helfen. Selbst GPT-5 ist gut darin, lokale Fehler wie Off-by-One-Probleme oder fehlende Rückgabewerte zu erkennen. Bei Problemen, die ein höheres Verständnis der Gesamtstruktur verlangen, gibt es aber noch Grenzen. In Zukunft könnte man große Codebasen vielleicht regelmäßig auf LLMs feinabstimmen und sie dann als Erst-Reviewer für jede Änderung einsetzen.

  • OR-Probleme (kombinatorische Optimierung) entstehen oft daraus, dass Leute, die improvisiert coden, nicht merken, dass sie in einem grundsätzlich speziellen Algorithmusgebiet gelandet sind. Selbst wenn man sie darauf hinweist, verstehen sie die mathematische Theorie nicht und versuchen trotzdem einfach weiter ihren eigenen Ansatz.

  • In solchen Situationen ist es möglicherweise tatsächlich die einzige sinnvolle Reaktion, den Unternehmensleitern mit technischen Präsentationen ein korrektes Bild der Lage zu vermitteln.

• Ich dachte schon, jetzt kommt wieder die übliche Geschichte, dass AI Junior-Entwickler ruiniert und dadurch später eine Krise entsteht, weil Senior-Ersatz fehlt. Dieser Text deutet das indirekt zwar auch an, und insgesamt stimme ich zu, aber besonders eindrücklich fand ich den Teil über Sycophancy. Früher dachte ich, Interfaces wie ChatGPT seien fürs Lernen hilfreich, aber das YouTube-ROAS-Beispiel hat mich getroffen. Wenn die Schlussfolgerung des Lehrers je nach Fragestellung beliebig vom Schüler verzerrt werden kann, dann ist es unvermeidlich, dass zahllose Anfängerentwickler in die falsche Richtung geführt werden. Ich weiß nicht einmal, ob das ganze Prompting, das auf AI „Boot“ angewendet wurde, ausreicht. Am Ende braucht man auch im AI-Zeitalter „jemanden“, der die eigenen PRs immer wieder ablehnt, damit man wachsen kann. Und dieser „jemand“ kann AI noch nicht sein.

  • Meiner Erfahrung nach mischt sich selbst dann, wenn man um vernichtende Kritik bittet, bei AI noch ein gewisser Wunsch hinein, einen gut fühlen zu lassen. Das gilt sowohl für alte GPT-Versionen als auch für neue. Es fühlt sich irgendwie vage an. Letztlich bleibt das Werkzeug am nützlichsten für Leute, die wissen, wobei sie Hilfe wollen, und die sich der speziellen Probleme von LLMs bewusst sind.

  • Um dem Schmeicheln entgegenzuwirken, frage ich immer zweimal mit gegensätzlicher Voreinstellung. Aber ich kann nicht wissen, ob die AI damit nicht doch noch meine versteckten Vorurteile verstärkt.

• Ich bin kein Anfänger, aber weil ich ständig neue Frameworks, Sprachen und Algorithmen lerne, halte ich AI-Autocomplete nicht für schlecht. Früher haben mir IntelliSense oder ReSharper-Autocomplete beim Lernen neuer Bibliotheken oder Sprachfeatures sehr geholfen. Wenn ReSharper merkte, dass ich nach alter Art code, schlug es neue Features vor, und so habe ich oft Neues gelernt. AI-basiertes Autocomplete wirkt wie eine viel weiterentwickelte Version davon. Es macht auf natürliche Weise Vorschläge, die man annehmen oder ablehnen kann, und das hilft auch beim Lernen. Solange man neugierig genug ist, die Vorschläge zu lesen und zu verstehen, macht AI das Lernen einfacher. Früher war es einfach nur Copy-and-Paste von Stack Overflow.

  • Traditionelles Autocomplete zeigt alle Methoden, Variablen und Konstanten im jeweiligen Scope und verlinkt auch die Dokumentation. Man kann selbst beurteilen, welche Optionen es gibt, und deshalb ist das wirklich gut zum Lernen. AI-Autocomplete ist eher so, als würde man eine Stack-Overflow-Antwort ohne Kontext direkt eingefügt bekommen. Wenn man lernen will, ist es besser, selbst auf Stack Overflow zu suchen oder notfalls einen Chatbot zu prompten und sich erklären zu lassen, warum dieser Code so aussieht.

  • Ich finde, da gibt es einen kleinen Unterschied. Wenn man schon etwas Erfahrung hat, fühlt sich Autocomplete in einer neuen Sprache ganz natürlich an. Aber für Anfänger ohne Grundlagen ist es etwas anderes, wenn sie gerade erst ihre erste for-Schleife lernen.

  • Ich mag AI-Agentic-Programming. Dinge zu bauen macht mich glücklich und ist Teil davon, Ideen auszuprobieren. Ich deploye den Code nicht in Produktion, also ist mir egal, was andere davon halten. Wenn ich mit technisch hervorragenden Leuten sprechen will, muss ich es selbst ausprobieren und dabei lernen. Ich programmiere seit meinem zehnten Lebensjahr gern, bin aber kein beruflicher Entwickler. Im AI-Zeitalter ist meine Liebe zum Coden und Experimentieren wieder erwacht. Zukunftige Webtechnologien wie WASM, verschiedene Systeme, Bugs finden und Dinge auf meine eigene Weise machen, all das macht großen Spaß. Tools wie Cursor AI automatisieren sogar mein git-Setup, sodass selbst Pushes per ssh bequem sind. Natürlich könnte ich das alles selbst tun, aber ich lasse es gern von AI erledigen. Ich habe zwar Gewohnheiten aus der Zeit, als ich mit C-Syntax angefangen habe, aber es macht mir großen Spaß, mit Python-Backends, Flask-Webservern und JavaScript-Frontends zu arbeiten. WASM Python ist noch ziemlich unausgereift, aber ich experimentiere weiter damit. Grundlagen zu festigen und auf meine eigene Weise zu lernen, liegt mir. Und ich habe oft das Gefühl, dass Ingenieure die Dinge unnötig kompliziert machen.

  • AI-Autocomplete ist das beste Tool überhaupt. Man bekommt die gewünschten Codevorschläge ohne Dokumentation, und weil es nur ein paar Zeilen sind, lassen sie sich leicht prüfen. Es erzeugt keine großen Blöcke automatisch und schadet dem Lernen daher auch nicht.

• Ich bin kein Anfänger, aber dank Copilot war es eindeutig leichter, Rust zu lernen. In Kombination mit Intellisense senkt es die Hürde der Syntax, sodass man sich auf die wichtigen Teile der Sprache konzentrieren kann. Ausgehend von einem Rust-Buch konnte ich innerhalb einer Woche ein funktionierendes Tool bauen. Natürlich bin ich dadurch kein Senior Engineer geworden, aber die Hürde von „0 auf 1“ wird definitiv kleiner. Ich lasse Copilot nicht Code für mich schreiben, sondern nutze es wie ein besseres Autocomplete: Es macht Vorschläge, und ich entscheide selbst, ob ich sie annehme.

  • Das wiederkehrende Thema hier ist, dass erfahrene Seniors auch ohne Kenntnisse einer neuen Sprache wissen, „wie man programmiert“, und deshalb aus solchen Tools Wert ziehen können. Code Smells bleiben dieselben, auch wenn sich die Sprache ändert. Anfänger kennen oft nicht einmal das Konzept von „Code Smells“.

  • Ich dachte früher auch, Copilot würde mir beim Lernen von Rust enorm helfen, aber als ich es dann ohne AI selbst versucht habe, war es wirklich schwer. Erst wenn man AI ausschaltet und lernt, merkt man, dass man sich vorher nur eingebildet hat, es wirklich zu können.

• Das gleiche Problem gibt es bei allen möglichen Abkürzungen im Bildungsbereich. Schüler lassen sich etwa in der Nachhilfe die Hausaufgaben abnehmen oder hören sich Erklärungen an und glauben danach, sie seien für die Prüfung bereit. In Wirklichkeit sieht etwas beim Zuhören einfach aus, aber es wirklich selbst zu können, ist eine ganz andere Fähigkeit.

• Wenn AI nicht in wenigen Jahren tatsächlich alle White-Collar-Jobs ersetzt, steuern wir wohl nicht nur auf eine Aktienmarktblase zu, sondern auch auf einen Mangel an qualifizierten Arbeitskräften. Für mich fühlt es sich an wie der Schock, der darin liegt, zuzusehen, wie sich die besten Köpfe meiner Generation so verstreuen.

• Ich habe versucht, für den Artikeltitel eine allgemein brauchbare Formulierung zu finden, aber nichts Passendes entdeckt und deshalb einfach mein Bestes gegeben. Wenn jemand einen genaueren und neutraleren Titelvorschlag hat, kann er ihn gern ändern. Siehe Hinweis.

• Mit dem Punkt „Ich habe es verstanden, aber wenn ich es von Grund auf schreiben soll, bin ich völlig blockiert“ kann ich mich sehr identifizieren. Das Schmerzhafteste und Schwierigste war immer, erst Tutorials nachzubauen und dann bei dem Versuch hängen zu bleiben, etwas Ähnliches selbst zu machen. Aber genau dieser schmerzhafte Prozess war zugleich die dichteste und effizienteste Lernerfahrung. Später habe ich viel komplexere und unterschiedlichere Dinge gelernt, aber nie wieder Lernen mit dieser Intensität erlebt. Es erinnert mich an das dumpfe Kopfweh und den Stress, den ich in Schulmathe hatte. Wahrscheinlich ist das keine Erfahrung, die jeder macht.