Wie du deine Coding-Skills fit hältst, wenn KI den Code schreibt

Deine Coding-Skills bleiben fit, wenn du genau die Teile der Arbeit, die dir die KI inzwischen abnimmt, bewusst und ohne Assistenten übst. Für die meisten Engineers heißt das: ein Problem erst selbst debuggen, bevor du um Hilfe bittest, Code lesen, den du nicht geschrieben hast, ein kleines Problem in einer leeren Datei lösen und Tests selbst schreiben. Ich würde mit ein bis zwei Stunden pro Woche anfangen und dranbleiben. Den Rest der Woche kannst du die KI so viel nutzen, wie du willst.

Kurzfassung

• Denkfähigkeiten verkümmern stärker als praktische Handgriffe. Piloten, die gewohnt waren, mit Automatik zu fliegen, konnten das Flugzeug weiterhin gut von Hand steuern, hatten aber mehr Mühe mit Navigation und Fehlererkennung (Casner et al., Human Factors, 2014). Beim Programmieren entsprechen dem am ehesten Debugging und das Lesen von Code.
• Der Verlust kann sich schon nach Monaten zeigen. In einer Beobachtungsstudie fanden Ärzte, die bei Darmspiegelungen KI nutzten, weniger Krebsvorstufen, sobald die KI abgeschaltet war: 22,4 % statt vorher 28,4 % (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025).
• Teste dich regelmäßig. Kannst du den letzten Diff erklären, den du gemergt hast? Kannst du einen fehlschlagenden Test 20 Minuten lang debuggen, ohne zu prompten? Wenn nicht, sind das die Skills, die du üben solltest.
• Eine wöchentliche Routine reicht. Lös ein kleines Problem von Hand, debugge vor dem Prompten, reviewe KI-Diffs, als hätte sie ein Junior geschrieben, lies Quellcode der Standardbibliothek und schreib die Tests selbst.
• Frag die KI nach dem „Warum“, nicht nach einem „Fix“. Sag die Antwort zuerst selbst voraus und vergleiche dann. Engineers, die eine neue Library lernten und der KI dabei Fragen stellten, lernten sie ungefähr so gut wie die, die von Hand programmierten. Wer der KI das Problem komplett übergab, lernte am wenigsten (Anthropic, 2026).

Welche Skills verkümmern zuerst, wenn KI deinen Code schreibt?

Zuerst verkümmern die Skills, bei denen du dir etwas erarbeiten musst, etwa Debugging, Code lesen und Trade-offs abwägen. Syntax tippen verlernst du viel langsamer.

Ein guter Vergleich kommt aus der Luftfahrt. In einer Studie von 2014 flogen 16 Linienpiloten einen Simulator der Boeing 747-400 und wurden beim Fliegen von Hand getestet. Ihre praktischen Flugfähigkeiten waren „größtenteils intakt“. Die Probleme zeigten sich bei den Denkaufgaben: die Position des Flugzeugs ohne Kartendarstellung im Blick behalten, den nächsten Schritt festlegen und bemerken, wenn ein Instrument ausgefallen war (Casner et al., Human Factors, 2014). Die Forscher empfahlen, dass Piloten diese Fähigkeiten erhalten, indem sie die Automatik aktiv überwachen.

Die Medizin kam 2025 zu einem ähnlichen Ergebnis. In vier Endoskopiezentren in Polen wurden Ärzte, die ein KI-Erkennungstool genutzt hatten, bei Darmspiegelungen ohne dieses Tool gemessen. Ihre Adenom-Detektionsrate fiel von 28,4 % vor der Einführung der KI auf 22,4 % danach (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025). Es war eine Beobachtungsstudie und keine randomisierte Studie, aber der Rückgang trat innerhalb weniger Monate auf.

In der Softwareentwicklung betrifft das vor allem fünf Skills.

Debugging

Auf Debugging solltest du am genauesten achten. In der Studie von Anthropic von 2026 stieß die Gruppe, die von Hand programmierte, auf mehr Fehler als die KI-Gruppe, und die Forscher vermuten, dass gerade das Durcharbeiten dieser Fehler ihre Debugging-Fähigkeit aufgebaut hat (Anthropic, 2026). Wenn ein Assistent jeden Fehler für dich behebt, bekommst du diese Übung nie.

Fremden Code lesen

Wenn dir ein Agent eine Codebase erklärt, baust du dir keine eigene Landkarte davon auf. Das geht gut, bis die Erklärung falsch ist oder der Agent während eines Incidents nicht verfügbar ist. GitClear hat 623 Millionen Codeänderungen analysiert und festgestellt, dass Aufrufe in bestehenden Code zwischen 2023 und 2026 von 343 auf 223 pro tausend geänderte Zeilen gesunken sind (GitClear, 2026). Weniger Wiederverwendung passt dazu, dass weniger von dem gelesen wird, was schon da ist.

APIs aus dem Gedächtnis kennen

Das Abrufen aus dem Gedächtnis ist hier weniger wichtig als die anderen Skills, ein bisschen davon brauchst du aber trotzdem. Du musst nicht jede Funktion in strings auswendig kennen. Du musst aber wissen, dass context.WithTimeout eine cancel-Funktion zurückgibt, die du aufrufen musst, und dass http.Error nicht aus deinem Handler zurückkehrt. Ohne dieses Wissen erkennst du nicht, wann ein Vorschlag falsch ist.

Systemdesign und Trade-offs

Die KI schlägt dir ein Design vor, wenn du fragst. Zwischen zwei vernünftigen Designs zu wählen, erfordert aber Urteilsvermögen, und das baust du auf, indem du Entscheidungen triffst und mit den Folgen lebst. Wenn der Agent die Queue, das Schema und die Retry-Policy auswählt, erfährst du nie, welche deiner Instinkte richtig lagen.

Schätzen

Wenn ein Assistent einen Teil der Arbeit erledigt, kann dein Gefühl dafür verrutschen, wie lange Dinge dauern. In der Studie von METR von 2025 brauchten erfahrene Entwickler mit KI 19 % länger, glaubten hinterher aber, dass sie 20 % schneller gewesen waren (METR, 2025). Wenn dein Gefühl für deine eigene Geschwindigkeit so weit danebenliegen kann, gilt das auch für deine Schätzungen.

Woran merkst du, dass deine Skills nachlassen?

Du findest es heraus, indem du dich ohne Assistenten testest, denn während du mit ihm arbeitest, fällt es kaum auf. Microsoft Research und die Carnegie Mellon University haben festgestellt, dass Wissensarbeiter, die der KI mehr vertrauten, nach eigener Aussage weniger kritisch über ihre Ergebnisse nachdachten (Lee et al., CHI, 2025).

Mach diese Checks einmal im Monat:

1. Erklär deinen letzten gemergten Diff. Nimm einen aktuellen Pull Request, den größtenteils die KI geschrieben hat. Erklär einer Kollegin, einem Kollegen oder laut dir selbst, warum jede Änderung da ist. Wenn du eine Änderung nicht erklären kannst, verstehst du sie nicht wirklich.
2. Debugge 20 Minuten lang, ohne zu prompten. Nimm den nächsten fehlschlagenden Test oder Bug-Report und arbeite nur mit Logs, einem Debugger und dem Quellcode daran. Achte darauf, ob du schon in den ersten zwei Minuten zum Assistenten greifst.
3. Schreib eine kleine Funktion in einer leeren Datei. Parse eine Konfigurationsdatei, wiederhole einen HTTP-Aufruf mit Backoff oder entferne Duplikate aus einem slice, ohne die Reihenfolge zu ändern. Prüfe, ob du die Aufrufe der Standardbibliothek noch im Kopf hast oder jeden einzelnen nachschlagen musst.
4. Sag das Ergebnis voraus, bevor du etwas ausführst. Schreib vor einem Testlauf auf, ob der Test durchläuft. Wenn er fehlschlägt, schreib auf, was in der Fehlermeldung stehen wird. Liegst du oft daneben, hat sich dein mentales Modell vom Code entfernt.
5. Erst schätzen, dann messen. Schätze, wie lange eine Aufgabe dauern wird, und vergleiche das mit der tatsächlichen Dauer. Wird die Lücke größer, hast du vermutlich den Überblick verloren, wo die Zeit hingeht.

Keiner dieser Checks dauert lange. Der, der sich am unangenehmsten anfühlt, zeigt dir, was du üben solltest.

Was ist der Unterschied zwischen Auslagern und Abgeben des Denkens?

Auslagern heißt, der KI Arbeit zu geben, die du schon verstehst, damit du deine Aufmerksamkeit woanders einsetzen kannst. Abgeben heißt, ihr Arbeit zu geben, die du nicht verstehst, damit du sie nie verstehen musst. Das Erste ist normales Engineering. Beim Zweiten verkümmern die Skills.

Die Studie von Anthropic ergab, dass es mehr darauf ankam, wie die Leute den Assistenten nutzten, als ob sie ihn nutzten. Die Forscher folgerten, dass kognitive Anstrengung, „und sogar schmerzhaftes Feststecken“, für echtes Können wahrscheinlich wichtig ist (Anthropic, 2026). Solltest du Code noch von Hand schreiben? zeigt, welche Nutzungsmuster gut abgeschnitten haben.

Die Lernforschung erklärt, warum. Robert und Elizabeth Bjork nennen diese Art von Anstrengung eine „erwünschte Erschwernis“ (desirable difficulty): Sie fühlt sich im Moment langsamer an, führt aber langfristig zu besserem Lernen (Bjork & Bjork, 2011). Eines ihrer Beispiele ist verteiltes Lernen. Übung, die über Wochen verteilt ist, bleibt besser hängen als dieselbe Menge in einer einzigen Session, und deshalb ist die Routine unten wöchentlich angelegt. Etwas aus dem Gedächtnis abzurufen, bringt außerdem mehr, als es noch einmal zu lesen (APS Observer zu Roediger & Karpicke, 2006). Diese Studie bespricht Solltest du Code noch von Hand schreiben? ausführlicher.

Um zu prüfen, was von beidem du getan hast, frag dich eine Woche später: Könnte ich diesen Code neu schreiben, ohne hinzusehen? Wenn ja, hast du Arbeit ausgelagert, die du verstehst. Wenn nicht, geh zurück und lern ihn, bevor du darauf aufbaust.

Eine wöchentliche Routine zum Üben ohne KI

Die folgende Routine dauert ein bis zwei Stunden pro Woche. Du kannst sie über die Woche verteilen oder am Stück machen. Schwierig ist, sie über Monate durchzuhalten.

Ein kleines Problem von Hand lösen

Öffne einmal pro Woche eine leere Datei, schalte den Assistenten ab und lös ein kleines, echtes Problem. Nimm etwas, das nah an deiner Arbeit ist: einen Rate Limiter, einen CSV-Parser, der Felder in Anführungszeichen verarbeitet, einen Worker-Pool, der beim ersten Fehler stoppt. Bleib bei 30 bis 45 Minuten. Du übst den Schritt von der leeren Datei zu funktionierendem Code, das Problem darf also ruhig klein sein.

Wenn du Aufgaben mit fertigen Tests willst, findest du im Training Ground von LevelUpGo einzelne Go-Übungen genau dafür.

Debuggen vor dem Prompten

Wenn etwas kaputtgeht, gib dir ein festes Zeitbudget, zum Beispiel 20 Minuten, bevor du den Assistenten fragst. Stell eine Hypothese auf, reproduziere den Bug, miss nach und frag erst dann.

Hier ist ein Bug, an dem sich das Üben lohnt. Ein Service holt Wechselkurse von einer langsamen Upstream-API und gibt nach 10 Millisekunden auf:

example.gogo
package main

import (
	"context"
	"errors"
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
	"time"
)

type Rate struct {
	Currency string
	Value    float64
}

func fetchRate(currency string) Rate {
	time.Sleep(50 * time.Millisecond) // a slow upstream API
	return Rate{Currency: currency, Value: 1.08}
}

func rateWithTimeout(ctx context.Context, currency string) (Rate, error) {
	ctx, cancel := context.WithTimeout(ctx, 10*time.Millisecond)
	defer cancel()

	result := make(chan Rate)
	go func() {
		result <- fetchRate(currency)
	}()

	select {
	case r := <-result:
		return r, nil
	case <-ctx.Done():
		return Rate{}, errors.New("rate lookup timed out")
	}
}

func main() {
	timeouts := 0
	for range 100 {
		if _, err := rateWithTimeout(context.Background(), "EUR"); err != nil {
			timeouts++
		}
	}
	fmt.Println("timeouts:", timeouts)
	time.Sleep(100 * time.Millisecond)
	runtime.GC()
	fmt.Println("goroutines:", runtime.NumGoroutine())
	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
}

In Produktion stürzt dabei nichts ab, der Speicherverbrauch wächst nur langsam. Miss als Erstes die Zahl der goroutines. Mit Go 1.27 ist das Profil goroutineleak allgemein verfügbar (Go 1.27 Release Notes), sodass die Runtime dir das Leak direkt zeigen kann. Unter Go 1.27 gibt das Programm Folgendes aus:

example.texttext
timeouts: 100
goroutines: 101
goroutineleak profile: total 100
100 @ 0x1048c59a8 0x10485e854 0x10485e468 0x10491c5ac 0x1048cbc74
#	0x10491c5ab	main.rateWithTimeout.func1+0x5b	./main.go:29

Alle 100 Abfragen sind in den Timeout gelaufen, und neben main leben noch 100 goroutines. Zeile 29 ist result <- fetchRate(currency). Jede Abfrage mit Timeout hinterlässt eine goroutine, die bei einem Send blockiert, den nie jemand empfangen wird, weil rateWithTimeout schon zurückgekehrt ist. Die Lösung ist ein Puffer der Größe eins, damit der Send immer gelingt:

example.gogo
result := make(chan Rate, 1)

Mit dieser Änderung gibt dasselbe Programm goroutines: 1 und goroutineleak profile: total 0 aus. Ein Assistent würde diesen Bug vermutlich schnell finden. Du übst trotzdem, ihn selbst zu finden, denn das nächste Leak steckt vielleicht in einer Library, die der Assistent nie gesehen hat, während eines Incidents, bei dem du auf dich allein gestellt bist. Das Go-Keyword chan: Channels, Richtungen und Deadlocks erklärt die Channel-Regeln hinter diesem Bug ausführlicher.

Den Diff der KI reviewen, als hätte ihn ein Junior geschrieben

Wenn ein Agent einen Pull Request öffnet, lies ihn so, wie du einen von einem neuen Teammitglied lesen würdest, das klug ist, dein System aber nicht kennt. Frag nicht nur, ob er richtig aussieht. Frag, was er voraussetzt. Prüf Fehlerpfade, den Umgang mit Context, Locking und was beim zweiten Aufruf passiert.

Viel Vertrauen haben Entwickler in diese Tools ohnehin nicht. In der Umfrage von Stack Overflow 2025 nutzten 84 % der Befragten KI-Tools oder planten es, aber nur 3,1 % vertrauten ihrer Genauigkeit stark (Stack Overflow, 2025). Das DORA-Team von Google stellte fest, dass KI ein Team nicht repariert. Sie „verstärkt, was schon da ist“ (DORA 2025, 2025). Was passiert, wenn das Review versagt, zeigt Die Schattenseite von KI-Coding-Tools anhand der Daten aus 2026.

Quellcode der Standardbibliothek lesen

Lies einmal pro Woche eine Funktion aus der Standardbibliothek von Go. Sie ist sorgfältig geschrieben, und die Doc-Kommentare erklären oft die Designentscheidungen. Installieren musst du dafür nichts:

example.bashbash
go doc -src net/http.Error

example.gogo
// Error replies to the request with the specified error message and HTTP code.
// It does not otherwise end the request; the caller should ensure no further
// writes are done to w.
// The error message should be plain text.
//
// Error deletes the Content-Length header,
// sets Content-Type to “text/plain; charset=utf-8”,
// and sets X-Content-Type-Options to “nosniff”.
// This configures the header properly for the error message,
// in case the caller had set it up expecting a successful output.
func Error(w ResponseWriter, error string, code int) {
	h := w.Header()
	// ...
	h.Del("Content-Length")
	h.Set("Content-Type", "text/plain; charset=utf-8")
	h.Set("X-Content-Type-Options", "nosniff")
	w.WriteHeader(code)
	fmt.Fprintln(w, error)
}

Die zweite Zeile des Kommentars erklärt einen häufigen Bug: http.Error schreibt eine Antwort, beendet deinen Handler aber nicht. Wenn du das return danach weglässt, läuft der Handler weiter. Hier ist ein Handler mit genau diesem Fehler im Zweig für das JSON-Decoding:

example.gogo
type Order struct {
	ID       string `json:"id"`
	Quantity int    `json:"quantity"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
	var o Order
	if err := json.NewDecoder(r.Body).Decode(&o); err != nil {
		http.Error(w, "invalid JSON", http.StatusBadRequest)
	}
	if o.Quantity <= 0 {
		http.Error(w, "quantity must be positive", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(o)
}

Solche Vorschläge kommen durch ein schnelles Review, weil der zweite Zweig korrekt aussieht. Wenn du den Quellcode gelesen hast, fällt dir das fehlende return sofort auf. Gute nächste Kandidaten zum Lesen sind sync.Once.Do, errors.Is, context.WithCancel und http.MaxBytesReader.

Die Tests selbst schreiben

Lass den Assistenten ruhig die Implementierung schreiben, aber schreib die Testfälle selbst. Festzulegen, was als korrekt gilt, ist der Teil der Arbeit, den du nicht abgeben solltest. Hier ist ein table-driven Test für den Handler oben:

example.gogo
func TestCreateOrder(t *testing.T) {
	tests := []struct {
		name     string
		body     string
		wantCode int
		wantBody string
	}{
		{"valid order", `{"id":"A1","quantity":2}`, http.StatusCreated, `{"id":"A1","quantity":2}` + "\n"},
		{"zero quantity", `{"id":"A1","quantity":0}`, http.StatusBadRequest, "quantity must be positive\n"},
		{"malformed JSON", `{"id":`, http.StatusBadRequest, "invalid JSON\n"},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(tt.body))
			rec := httptest.NewRecorder()

			createOrder(rec, req)

			res := rec.Result()
			body, _ := io.ReadAll(res.Body)
			if res.StatusCode != tt.wantCode {
				t.Errorf("status = %d, want %d", res.StatusCode, tt.wantCode)
			}
			if string(body) != tt.wantBody {
				t.Errorf("body = %q, want %q", body, tt.wantBody)
			}
		})
	}
}

example.texttext
--- FAIL: TestCreateOrder (0.00s)
    --- FAIL: TestCreateOrder/malformed_JSON (0.00s)
        handler_test.go:35: body = "invalid JSON\nquantity must be positive\n", want "invalid JSON\n"
FAIL

Die Prüfung des Statuscodes besteht, weil der erste Aufruf von WriteHeader gewinnt und die Antwort weiterhin ein 400 ist. Nur die Prüfung des Body fängt den Bug. Ein echter Server würde zusätzlich http: superfluous response.WriteHeader call loggen, aber das nützt nur, wenn jemand die Logs liest. Auf die Idee, den Body zu prüfen, kommst du nur, wenn du einschätzt, was schiefgehen könnte. Genau das übst du hier. Mit dem ergänzten return bestehen alle drei Fälle.

Wie nutzt du KI so, dass sie dir etwas beibringt, statt dich zu ersetzen?

Nutze KI, um dein Denken zu prüfen und zu erklären, und mach das Denken vorher selbst. Dabei helfen fünf Gewohnheiten:

• Erst voraussagen, dann vergleichen. Bevor du nach einer Lösung fragst, schreib deinen eigenen Ansatz in ein, zwei Sätzen auf oder skizziere den Code. Frag dann den Assistenten und vergleiche. An den Unterschieden siehst du, was du nicht wusstest.
• Nach dem „Warum“ fragen statt nach einem „Fix“. Auf „Warum wird diese goroutine nie beendet?“ bekommst du eine Erklärung, die du überprüfen kannst. Auf „Fix das“ bekommst du einen Patch, den du übernimmst, ohne etwas zu lernen.
• Um Hinweise bitten. Sag dem Assistenten, dass du übst und immer nur einen Hinweis willst. Die meisten Assistenten machen das mit.
• Dich abfragen lassen. Bitte ihn nach einer Session um drei Fragen zu dem Code, den du gerade geändert hast. Wenn du sie nicht beantworten kannst, lies den Code noch einmal.
• Aus dem Gedächtnis neu schreiben. Wenn du generierten Code übernimmst, den du nicht ganz verstanden hast, schließ ihn und schreib ihn später am selben Tag neu. Die Stellen, an denen du hängen bleibst, sind die Teile, die du nicht gelernt hast.

Dasselbe gilt, wenn du ganz von vorn lernst. Programmieren lernen 2026 (ohne dein erstes Jahr zu verschwenden) zeigt, wie Anfänger KI als Tutor nutzen.

Welche Skills werden jetzt wichtiger statt unwichtiger?

Die Skills, mit denen du KI steuerst und ihre Arbeit prüfst, sind heute mehr wert als vorher.

Am offensichtlichsten ist das Reviewen. Agents können Pull Requests schneller öffnen, als ein Team sie lesen kann, und trotzdem muss jemand jeden einzelnen reviewen und entscheiden, welcher gemergt wird.

Dazu kommt das Schreiben von Spezifikationen. Eine klare Beschreibung des Problems, der Rahmenbedingungen und der Edge Cases bringt dir bessere Ergebnisse von einem Agent, und beim Schreiben musst du das Problem selbst durchdenken.

Testen wird wichtiger, wenn du den Code nicht selbst geschrieben hast. Mit Tests sagst du einem Agent, was korrekt bedeutet, und merkst, wenn er falschliegt. Table-driven Tests, Fuzzing (Go-Tutorial zu Fuzzing) und der Race Detector kommen deshalb öfter zum Einsatz.

Bleibt die Architektur. Agents arbeiten gut innerhalb klarer Grenzen, aber wo diese Grenzen verlaufen, welches Package wofür zuständig ist und welche interfaces stabil bleiben, entscheidest weiterhin du.

Die Wahl der Sprache hilft bei allen vier Punkten. Der strenge Compiler von Go, die kleine Sprache und das eingebaute Tooling fangen viele generierte Fehler schon vor dem Review ab. Das erklärt Warum Go die beste Sprache für KI-geschriebenen Code ist im Detail. Lohnt es sich, 2026 Go zu lernen? behandelt die Karriereseite dieser Entscheidung.

Wo LevelUpGo ins Spiel kommt

LevelUpGo ist ein Ort für den KI-freien Teil der Routine. Jede Lektion zeigt links das Konzept und rechts einen echten Editor ohne Autovervollständigung, und du kommst erst weiter, wenn dein Go-Code kompiliert und die Tests besteht. Der Kurs Go Basics, kostenlos zum Einstieg, fängt bei den Grundlagen an. In Professional Go Testing übst du, table-driven Tests selbst zu schreiben, und Concurrency Fundamentals behandelt goroutines, channels und Abbruch, also genau den Code, den du am ehesten von Hand debuggen können solltest.

Häufig gestellte Fragen

Wie viel Zeit sollte ich pro Woche ohne KI programmieren?

Ich würde mit ein bis zwei Stunden pro Woche anfangen und das über Monate beibehalten. Die Lernforschung spricht für kurze, verteilte Einheiten statt gelegentlicher langer Sessions (Bjork & Bjork, 2011). Ein kleines Problem von Hand gelöst, ein Bug vor dem Prompten debuggt und eine Funktion der Standardbibliothek gelesen, jede Woche, deckt die am stärksten gefährdeten Skills ab.

Wie übe ich, wenn mein Team Output im KI-Tempo erwartet?

Übe abseits des kritischen Pfads. Nimm für die Gewohnheit, zuerst selbst zu debuggen, Bugs und Tickets, die niemanden blockieren, und löse das Problem von Hand in deiner eigenen Zeit oder über ein Weiterbildungsbudget, falls deine Firma eins hat. Diffs reviewen und Tests selbst schreiben passt in die normale Arbeit und bremst dich kaum. Wenn dein Team nur Output misst, sprich mit deiner Teamleitung über Review-Qualität und Einsatzbereitschaft in der Rufbereitschaft. Beides hängt an denselben Skills.

Verlieren auch Senior Engineers Skills durch KI?

Ja. Erfahrung schützt dich nicht. Die Piloten in der Luftfahrtstudie und die Ärzte in der Studie zu Darmspiegelungen waren erfahrene Profis, und beide Gruppen zeigten schwächere Fähigkeiten dort, wo die Automatik einen Teil der Arbeit übernommen hatte (Casner et al., 2014, Budzyń et al., 2025). Seniors haben anfangs mehr Können, das sie verlieren können, und auf die Denkfähigkeiten solltest du besonders achten.

Reicht es, KI-Code zu reviewen, um meine Skills zu erhalten?

Allein nicht. Beim Reviewen nutzt du Wiedererkennen, und das ist leichter, als selbst eine Lösung zu erarbeiten. Eine richtige Antwort erkennst du noch lange, nachdem du sie selbst nicht mehr schreiben könntest. Kombiniere das Reviewen mit regelmäßiger Übung, bei der du Code von Grund auf schreibst und debuggst.

Kommen Skills zurück, die man durch KI verloren hat?

Die Forschung dazu ist dünn, deshalb kann das niemand versprechen. Die Studien oben haben die Fähigkeiten zu einem einzigen Zeitpunkt gemessen, nicht die Erholung. Sie zeigen aber, dass Fähigkeiten, die die Leute weiter nutzten, erhalten blieben, etwa das Fliegen von Hand bei den Piloten (Casner et al., 2014). Praktisch heißt das: Fang mit den Selbsttests oben an, finde deinen schwächsten Skill und übe den zuerst.

Quellen

• Anthropic, „How AI assistance impacts the formation of coding skills“ (2026): https://www.anthropic.com/research/AI-assistance-coding-skills
• Casner, Geven, Recker & Schooler, „The retention of manual flying skills in the automated cockpit“, Human Factors (2014): https://labs.psych.ucsb.edu/schooler/jonathan/sites/labs.psych.ucsb.edu.schooler.jonathan/files/pubs/the_retention_of_manual_flying_skills_in_the_automated_cockpit.pdf
• Budzyń et al., „Endoscopist deskilling after exposure to artificial intelligence in colonoscopy“, Lancet Gastroenterology & Hepatology (2025): https://doi.org/10.1016/S2468-1253(25)00133-5
• GitClear, „The Maintainability Gap: 2026 AI Code Quality Research“ (2026): https://www.gitclear.com/the_ai_code_quality_maintainability_gap
• 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/
• Lee et al., „The Impact of Generative AI on Critical Thinking“, CHI (2025): https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/
• APS Observer, „Test-enhanced Learning“, zu Roediger & Karpicke (2006): https://www.psychologicalscience.org/observer/test-enhanced-learning
• Bjork & Bjork, „Making Things Hard on Yourself, But in a Good Way: Creating Desirable Difficulties to Enhance Learning“ (2011): https://bjorklab.psych.ucla.edu/wp-content/uploads/sites/13/2016/04/EBjork_RBjork_2011.pdf
• Stack Overflow Developer Survey 2025, Abschnitt zu KI: https://survey.stackoverflow.co/2025/ai
• Google Cloud, „Announcing the 2025 DORA Report“ (2025): https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• Go 1.27 Release Notes: https://go.dev/doc/go1.27
• Go-Tutorial zu Fuzzing: https://go.dev/doc/tutorial/fuzz