Programmieren lernen mit KI: Lagere dein Gehirn nicht aus

Wenn du Programmieren lernst, ist das fertige Programm ein Nebenprodukt. Was du aufbaust, ist ein mentales Modell: ein Bild im Kopf davon, was der Code tut und warum er kaputtgeht. Den Code liefert dir eine KI in Sekunden. Dieses Bild kann sie dir nicht abnehmen. Wenn du sie beim Lernen das Denken übernehmen lässt, hast du am Ende funktionierende Programme und ein dünnes Verständnis davon. Die Lücke zeigt sich später, wenn etwas kaputtgeht.

Kurzfassung

• Funktionierender Code kann sich wie Verständnis anfühlen. Anfänger, die ohnehin schon Schwierigkeiten hatten, beendeten eine Aufgabe mit KI-Hilfe teilweise mit einer „Illusion von Kompetenz“ und hielten ihre Leistung für besser, als sie war (Prather et al., ICER, 2024).
• Was du nicht selbst erzeugt hast, behältst du schlechter. Wer Essays mit einem LLM schrieb, konnte Minuten später kaum aus dem eigenen Text zitieren. Die Studie ist noch nicht peer-reviewed (Kosmyna et al., MIT Media Lab, 2025).
• Auslagern geht mit weniger kritischem Denken einher. In einer Studie mit 666 Personen korrelierte stärkere KI-Nutzung mit schwächerem kritischem Denken, und kognitives Offloading vermittelte diesen Zusammenhang statistisch (Gerlich, Societies, 2025).
• Die Arbeit für Einsteiger verschiebt sich. Die Beschäftigung von Softwareentwicklern zwischen 22 und 25 Jahren ist bis September 2025 um fast 20 % unter ihren Höchststand von Ende 2022 gefallen (Stanford Digital Economy Lab, 2025).
• Gewohnheiten halten das Denken bei dir. Versuch es zuerst selbst, frag nach Hinweisen statt nach Antworten, erklär das Ergebnis in eigenen Worten und bau es am nächsten Tag in einer leeren Datei neu.

Was heißt es, dein Gehirn an die KI auszulagern?

Dein Gehirn auszulagern heißt, die KI die Denkarbeit machen zu lassen, für die es die Übung überhaupt gibt. Psychologen nennen das kognitives Offloading: Du nutzt ein Werkzeug für Denkarbeit, die du sonst selbst erledigen würdest. Ein Taschenrechner übernimmt das für das Rechnen, eine Karten-App für den Weg. Ein erfahrener Entwickler kann Boilerplate ohne großen Verlust auslagern, weil das Verständnis schon da ist. Für jemanden, der lernt, entsteht die Fähigkeit aber genau aus dieser Denkarbeit. Lagerst du sie aus, bleibt dir das Ergebnis und kaum etwas anderes.

Die engere Frage, wann du Code selbst tippen und wann du einen Vorschlag annehmen solltest, behandelt ein eigener Artikel: Solltest du Code noch von Hand schreiben? geht die kontrollierten Studien durch. Hier geht es darum, was in deinem Kopf passiert, wenn du mit einem Assistenten lernst, und was dich das in einem Jahr kostet.

Warum fühlt sich funktionierender Code wie Verständnis an?

Dein Gehirn beurteilt Verständnis unter anderem danach, wie glatt etwas läuft, und mit KI läuft alles glatt. Du fügst einen Prompt ein, bekommst Code, und er läuft. Diese Leichtigkeit hält man schnell für Können.

Lernforscher messen diese Lücke seit Jahrzehnten. Nicholas Soderstrom und Robert Bjork haben die Forschung dazu ausgewertet und kamen zu dem Schluss, dass die Leistung während des Übens „oft ein unzuverlässiger Indikator“ dafür ist, ob gelernt wurde. Außerdem fanden sie, dass „Menschen ihre Leistung während der Aneignung oft fälschlich als verlässlichen Hinweis auf langfristiges Lernen deuten“ (Soderstrom & Bjork, Perspectives on Psychological Science, 2015). Bedingungen, die sich im Moment schwer anfühlen, etwa Abrufen statt erneutem Lesen, führen oft zu dauerhafterem Lernen. Bjorks Labor nennt sie „wünschenswerte Erschwernisse“ (Bjork Learning and Forgetting Lab).

Studien zur KI-Nutzung aus 2024 und 2025 zeigen in dieselbe Richtung.

Schwächere Anfänger beenden die Aufgabe mit einer Illusion von Kompetenz

James Prather und seine Kollegen beobachteten Programmieranfänger, die eine Aufgabe lösten und dabei generative KI zur Verfügung hatten. Sie nutzten Beobachtung, Interviews und Eye-Tracking in 21 Laborsitzungen. 20 der 21 Studierenden lösten die Aufgabe. Wer ohnehin schon Schwierigkeiten hatte, brachte metakognitive Probleme mit, und KI „kann sie verstärken und sogar neue metakognitive Schwierigkeiten hervorbringen“. Mehrere von ihnen „glaubten, besser abgeschnitten zu haben, als es der Fall war, und beendeten die Aufgabe mit einer Illusion von Kompetenz“ (Prather et al., ICER, 2024). Studierende mit stärkeren metakognitiven Fähigkeiten setzten die KI dagegen gut ein. Daher kommt der Titel des Papers, „The Widening Gap“.

Auch erfahrene Entwickler verschätzen sich. In der Studie von METR aus 2025 brauchten sie mit KI 19 % länger und glaubten dabei, 20 % schneller zu sein (METR, 2025). Ausführlicher geht darauf Solltest du Code noch von Hand schreiben? ein. Wenn sich selbst Leute mit jahrelanger Erfahrung bei ihrem eigenen Fortschritt täuschen, hat ein Anfänger noch weniger, woran er sich halten kann.

Weniger Aufwand, weniger Erinnerung

Forscher am MIT Media Lab ließen 54 Personen Essays schreiben, entweder mit einem LLM, mit einer Suchmaschine oder ganz ohne Hilfsmittel, und zeichneten dabei ihre Hirnaktivität per EEG auf. Die Gruppe ohne Hilfsmittel zeigte die stärksten und am weitesten vernetzten Hirnnetzwerke. Die Suchmaschinen-Gruppe lag in der Mitte, die LLM-Gruppe zeigte die schwächste Vernetzung. Die LLM-Nutzer „hatten Mühe, ihre eigene Arbeit korrekt zu zitieren“, also Essays, die sie wenige Minuten zuvor geschrieben hatten (Kosmyna et al., MIT Media Lab, 2025). Die Studie ist ein Preprint und noch nicht peer-reviewed, sieh sie also als frühen Hinweis. Es ging um Essays, nicht um Code. Der Mechanismus ist aber genau der, um den es in diesem Artikel geht: Was du nicht selbst erzeugt hast, behältst du schlechter.

Eine größere Umfrage kam zu einem ähnlichen Ergebnis. Michael Gerlich untersuchte 666 Personen und fand „eine signifikante negative Korrelation zwischen häufiger Nutzung von KI-Tools und der Fähigkeit zum kritischen Denken, vermittelt durch verstärktes kognitives Offloading“. Jüngere Teilnehmer stützten sich stärker auf KI und schnitten schlechter ab (Gerlich, Societies, 2025). Die Studie ist korrelativ und beweist deshalb nicht, dass KI das Denken schwächt. Sie zeigt aber, dass Menschen, die nach eigener Angabe mehr auslagern, beim kritischen Denken auch schlechter abschneiden.

Wo rächt sich die Abkürzung?

Übersprungenes Verständnis merkst du nicht an dem Tag, an dem du es überspringst. Du merkst es später, wenn die KI nicht reicht oder nicht da ist.

Einen Panic debuggen, den du nie verstanden hast

Angenommen, ein Assistent hat den In-Memory-Cache für deinen ersten Go-Service geschrieben, mit einem Konstruktor NewCache, der alles aufsetzt, und in jedem Test hat er funktioniert. Dann legt ein neuer Codepfad das Struct direkt an:

example.gogo
type Cache struct {
	items map[string]string
}

func (c *Cache) Set(key, value string) {
	c.items[key] = value
}

func main() {
	c := &Cache{}
	c.Set("session:42", "user-1893")
}

example.texttext
panic: assignment to entry in nil map

Hättest du ein paar Dutzend Mal selbst mit Maps gearbeitet, würdest du das sofort erkennen. Der Nullwert einer Map ist nil. Lesen aus einer nil-Map funktioniert, Schreiben löst einen Panic aus. Die Lösung ist, den Nullwert mit einer nil-Prüfung in Set nutzbar zu machen (c.items = make(map[string]string)). Liegt der Cache in einem eigenen Package, kannst du items alternativ nicht exportieren und dokumentieren, dass Aufrufer NewCache verwenden müssen. var vs make in Go erklärt, warum sich der Nullwert so verhält. Hast du Map-Code bisher immer nur übernommen, starrst du auf einen Panic in einer Zeile, die völlig normal aussieht, und weißt nicht, wo du anfangen sollst.

Eine Frage im Code Review, die du nicht beantworten kannst

Jemand fragt im Review, warum dein Handler einen Pointer Receiver verwendet oder warum du einen context.Context an eine Funktion übergibst, die ihn nie liest. Wenn du den Code geschrieben hast, kannst du antworten, selbst wenn die Antwort „Da lag ich falsch“ lautet. Wenn du ihn nur übernommen hast, hast du nichts zu sagen. Dieselbe Lücke zeigt sich im Live-Coding-Interview, wo du deine Überlegungen beim Tippen erklären musst.

Eine Codebase lesen, die du nicht geschrieben hast

Ein großer Teil der Zeit neuer Entwickler geht dafür drauf, fremden Code zu lesen: einen Request durch die Middleware verfolgen, herausfinden, wo ein Konfigurationswert gesetzt wird, oder verstehen, warum ein Worker-Pool genau diese Größe hat. KI kann eine Datei zusammenfassen. Zu wissen, wo du als Nächstes nachsehen musst, kommt daher, dass du ähnlichen Code selbst geschrieben hast und dich erinnerst, wo du Dinge abgelegt hast.

Warum zählt Verständnis für Einsteiger gerade jetzt mehr?

Ein naheliegender Grund: Die Aufgaben, die KI gut erledigt, überschneiden sich mit denen, für die früher Juniors eingestellt wurden. Das Digital Economy Lab in Stanford hat festgestellt, dass die Beschäftigung von Softwareentwicklern zwischen 22 und 25 Jahren bis September 2025 um fast 20 % unter ihren Höchststand von Ende 2022 gefallen ist, während die Beschäftigung erfahrenerer Arbeitskräfte stabil blieb (Brynjolfsson, Chandar & Chen, Stanford Digital Economy Lab, 2025). Laut der Überarbeitung vom August 2026 liegt die Beschäftigung junger Arbeitskräfte in KI-exponierten Jobs 19 % unter dem Niveau, das sie sonst hätte (Brynjolfsson, Chandar & Chen, 2026).

Die Autoren weisen darauf hin, dass neben KI auch andere Faktoren eine Rolle spielen können. Ihre Erklärung lautet, dass KI „möglicherweise die kodifizierbaren, überprüfbaren Aufgaben automatisiert, die in der Vergangenheit Einstiegsstellen gerechtfertigt haben“, und dass sie „möglicherweise weniger gut darin ist, implizites Wissen zu ersetzen“. Implizites Wissen ist das Verständnis, das du nur bekommst, indem du die Arbeit selbst machst. Zu erkennen, warum generierter Code richtig oder falsch ist, gehört dazu.

Warum ist das produktive Ringen die eigentliche Arbeit?

Das mentale Modell entsteht, während du feststeckst. Du bist verwirrt, stellst eine Vermutung auf, testest sie, und oft liegst du falsch. Diese Minuten fühlen sich verschwendet an, aber genau dann lernst du.

So sieht das an einem echten Bug aus. Du schreibst eine Funktion, die mehrere URLs nebenläufig abruft und vorzeitig zurückkehrt, sobald einer der Aufrufe fehlschlägt:

example.gogo
type result struct {
	body string
	err  error
}

func fetchAll(ctx context.Context, urls []string) ([]string, error) {
	results := make(chan result)
	for _, u := range urls {
		go func() {
			body, err := fetch(ctx, u)
			results <- result{body, err}
		}()
	}

	var bodies []string
	for range urls {
		r := <-results
		if r.err != nil {
			return nil, r.err
		}
		bodies = append(bodies, r.body)
	}
	return bodies, nil
}

Die Tests laufen durch. Eine Woche später steigt der Speicherverbrauch des Services langsam an, bis er neu startet. Von Hand kommst du dem ungefähr so auf die Spur. Du prüfst runtime.NumGoroutine() und siehst, dass der Wert wächst. Du ziehst ein Goroutine-Profil und findest Hunderte goroutines, die alle in derselben Zeile hängen: results <- result{body, err}. Du fragst dich, wer aus diesem channel eigentlich empfangen soll, und die Antwort ist: niemand, denn fetchAll ist beim ersten Fehler zurückgekehrt. Der channel ist ungepuffert, also blockiert jeder verbleibende Sender für immer.

Die schnelle Lösung ist eine Zeile, results := make(chan result, len(urls)), damit jede goroutine senden und sich beenden kann, egal ob jemand liest. Eine bessere Lösung bricht zusätzlich den Context ab, damit die übrigen Requests früh aufhören. Die Suche nach dieser Zeile hat dir mehr beigebracht als die Zeile selbst: Ein Send auf einen ungepufferten channel wartet auf einen Empfänger, ein vorzeitiges return kann goroutines zurücklassen, und ein Goroutine-Profil zeigt dir, wo sie hängen. Ein Assistent hätte dir die korrigierte Version gleich beim ersten Versuch geben können, und du hättest korrekten Code gehabt, ohne irgendetwas davon zu lernen. Im Kurs Concurrency Fundamentals schreibst und reparierst du channel-Code, der genau so blockiert.

Wie lernst du Programmieren mit KI, ohne dein Gehirn auszulagern?

Behandle die KI wie einen geduldigen Senior-Kollegen. Lass dir von ihr Dinge erklären oder deine Überlegungen prüfen, wenn du feststeckst, aber die Übung selbst machst du.

Erst selbst versuchen, mit Zeitlimit

Gib dir 20 bis 30 Minuten für ein Problem, bevor du um Hilfe bittest. Schreib auf, was du versucht hast und wo du hängen geblieben bist. Diese Notiz hilft dir zweifach: Sie zwingt dich, das Problem klar zu formulieren, und sie gibt der KI genug Kontext, um dir einen Hinweis statt einer fertigen Lösung zu geben.

Frag nach Hinweisen, nicht nach Lösungen

Sag dem Assistenten, welche Rolle er spielen soll. Oft trennt ein einziger Satz einen Prompt, der dir die Arbeit abnimmt, von einem, bei dem du weiter selbst arbeitest:

In der rechten Spalte erklärt die KI oder stellt Fragen, und den Code schreibst weiterhin du.

Erklär den Code in eigenen Worten

Wenn du Code von einem Assistenten übernimmst, mach erst weiter, wenn du jede Zeile erklären kannst. Schreib die Erklärung als Kommentare oder sag sie laut. Die Zeile, die du nicht erklären kannst, ist die, die du dir als Nächstes erarbeiten solltest. Erklären ist auch der schnellste Weg herauszufinden, ob du etwas verstanden oder nur wiedererkannt hast.

Bau es am nächsten Tag in einer leeren Datei neu

Schließ die Datei, öffne morgen eine leere und schreib die Lösung noch einmal, ohne nachzusehen. Das dauert länger, und an manchen Stellen bleibst du hängen. Genau diese Stellen hattest du noch nicht gelernt. Es ist dasselbe Abrufüben, das Karteikarten wirksam macht, nur angewendet auf Code.

Halte die KI aus der Grundlagenphase heraus

Schreib in deinen ersten Wochen mit einer Sprache die Grundlagen ohne Assistenten: Variablen, Schleifen, Slices, Maps, Structs, Fehlerbehandlung und deine ersten goroutines. So früh füllt die KI-Autovervollständigung jede Zeile aus, bevor du selbst darüber nachdenken konntest. Sobald die Grundlagen sitzen, holst du die Tools für die Teile zurück, die du schon verstehst. Programmieren lernen 2026 enthält einen ausführlicheren Plan für diese erste Phase, und 13 häufige Anfängerfehler beim Programmieren behandelt die Gewohnheiten, die jeden Code schwerer debugbar machen, ob generiert oder nicht.

LevelUpGo ist darauf ausgelegt, dass du den Code selbst schreibst. Jede Übung stellt das Konzept neben einen echten Go-Editor ohne KI-Vervollständigung, und sie gilt erst als erledigt, wenn dein Code kompiliert und die Tests besteht. Fang mit den kostenlosen Lektionen in Go Basics an, dem ersten Kurs im Lernpfad Go Fundamentals. Danach hältst du die Fähigkeit mit einzelnen Übungen im Training Ground in Form.

Häufig gestellte Fragen

Ist es Schummeln, beim Programmierenlernen ChatGPT zu nutzen?

Nein, es sei denn, dein Kurs sagt etwas anderes. Das Risiko ist, dass du überspringst, was die Übung dir beibringen sollte. Eine KI zu bitten, einen Fehler oder ein Konzept zu erklären, ist wie eine Frage an einen Tutor. Lässt du sie die Lösung schreiben, trainiert die Übung nichts mehr.

Woran erkenne ich, ob ich KI-geschriebenen Code wirklich verstehe?

Versuch, ihn ohne Hilfe zu ändern. Füg ein Feature hinzu, behandle einen neuen Edge Case oder sag vorher, was passiert, wenn eine Zeile fehlt. Wenn du vorhersagen kannst, was der Code tut, bevor du ihn ausführst, verstehst du ihn. Wenn du ihn nur ausführen und schauen kannst, hast du ihn wiedererkannt. Wiedererkennen fühlt sich im Moment wie Verstehen an, und genau diese Lücke beschreiben Soderstrom und Bjork (Soderstrom & Bjork, 2015).

Was ist kognitives Offloading beim Programmieren?

Die KI entscheidet über die Struktur, den Algorithmus oder die Korrektur, statt dass du es selbst herausfindest. Sobald du die Fähigkeit hast, ist das effizient. Solange du sie noch aufbaust, ersetzt das Auslagern die Übung, und die Forschung bringt stärkeres Offloading mit schwächerem kritischem Denken in Verbindung (Gerlich, 2025).

Ab wann kann ein Anfänger KI-Coding-Tools frei nutzen?

Sobald du die Grundlagen schreiben kannst, ohne etwas nachzuschlagen: Schleifen, Funktionen, Maps, Structs, Fehlerbehandlung und einen einfachen HTTP-Handler. Ab dann macht dich die KI bei Arbeit schneller, die du schon verstehst. Geh zurück zum Schreiben von Hand, sobald du etwas Neues anfängst, etwa deinen ersten nebenläufigen Code oder deine erste Datenbankschicht.

Wird KI Junior-Entwickler ersetzen?

Die Forschung zeigt einen klaren Weg, wertvoll zu bleiben. Die Forscher in Stanford vermuten, dass KI kodifizierbare, überprüfbare Aufgaben übernimmt und sich weniger dafür eignet, implizites Wissen zu ersetzen, also das Verständnis, das du nur durch die Arbeit selbst aufbaust (Stanford Digital Economy Lab, 2025). Diesen Teil hast du selbst in der Hand. Ein Junior, der debuggen, prüfen und erklären kann, was eine KI schreibt, bringt etwas mit, das das Tool nicht hat, und wird mit KI zusätzlich schneller.

Quellen

• Prather et al., „The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers“, ICER (2024): https://arxiv.org/abs/2405.17739
• METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“ (2025): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Kosmyna et al., „Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task“, Preprint des MIT Media Lab (2025): https://arxiv.org/abs/2506.08872
• Gerlich, „AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking“, Societies 15(1) (2025): https://doi.org/10.3390/soc15010006
• Brynjolfsson, Chandar & Chen, „Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence“, Stanford Digital Economy Lab (2025, überarbeitet 2026): https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
• Soderstrom & Bjork, „Learning versus performance: An integrative review“, Perspectives on Psychological Science (2015): https://doi.org/10.1177/1745691615569000
• Bjork Learning and Forgetting Lab, Forschungsüberblick zu wünschenswerten Erschwernissen: https://bjorklab.psych.ucla.edu/research/