LevelUpGo
Anmelden
Zurück zum Blog
Go · Artikel13 Min. Lesezeit

Code noch von Hand schreiben? Wann du 2026 besser bist als die KI

KI kann 2026 den Großteil deines Codes schreiben. Die Forschung zeigt aber, wann du ihn trotzdem selbst tippen solltest: wenn du lernst, wenn du ihn später debuggen musst und wenn ein Fehler echtes Geld kosten würde.

Patrik Nilsson
Gründer, LevelUpGo
Veröffentlicht am 23. September 2026
Code noch von Hand schreiben? Wann du 2026 besser bist als die KI

Ja, aber nicht alles. 2026 kann ein KI-Assistent den Großteil des Codes in einem typischen Backend-Service schreiben, und bei Boilerplate, Testgerüsten und Wegwerfskripten solltest du ihn das auch machen lassen. Selbst schreiben lohnt sich aber weiterhin, wenn du etwas Neues lernst, wenn du den Code um zwei Uhr nachts selbst debuggen musst, wenn ein Bug Daten oder Geld kosten würde und wenn die Logik das ist, was dein Produkt ausmacht. Die Forschung aus 2025 und 2026 sagt ziemlich genau, warum.

Kurzfassung

  • Lernen mit KI kostet dich Verständnis. In der randomisierten Studie von Anthropic erreichten Entwickler, die eine neue Library mit KI-Hilfe lernten, im anschließenden Quiz 50 %. Wer von Hand programmierte, kam auf 67 %, und die größte Lücke gab es bei Fragen zum Debugging (Anthropic, 2026).
  • „Fast richtig“ ist der Normalfall. Für 66 % der Entwickler ist KI-Code, der fast, aber eben nicht ganz stimmt, das größte Ärgernis, und 45,2 % sagen, dass sie für KI-generierten Code länger debuggen (Stack Overflow Developer Survey, 2025).
  • Die Sicherheit hat nicht aufgeholt. KI-generierter Code besteht Sicherheitsprüfungen nur in etwa 55 % der Fälle. Der Wert pendelt seit Langem zwischen 45 % und 55 %, obwohl die Syntax inzwischen in über 95 % der Fälle stimmt (Veracode, 2026).
  • Du spürst nicht, ob die KI dir hilft. Erfahrene Entwickler brauchten in der Studie von METR 2025 mit KI 19 % länger, glaubten aber, 20 % schneller gewesen zu sein (METR, 2025).
  • Die Regel: Lass die KI Code schreiben, den du auch selbst hättest schreiben können. Alles, was du noch nicht verstehst, schreibst du von Hand.

Was sagt die Forschung zum Programmieren mit KI?

Mit KI schreibst du schneller Code und lernst weniger daraus, und beides merkst du kaum, während es passiert.

Die deutlichsten Belege liefert eine Studie von Anthropic aus dem Januar 2026. 52 überwiegend junge Engineers, die alle jede Woche mit Python arbeiteten, bekamen eine Aufgabe mit Trio, einer Async-Library, die keiner von ihnen kannte. Die Hälfte durfte einen KI-Assistenten verwenden. Danach machten alle ein Quiz zu der Library. Die KI-Gruppe kam im Schnitt auf 50 %. Die Gruppe ohne KI kam auf 67 %. Die Forscher sprechen von „fast zwei Notenstufen“ (Anthropic, 2026). Dafür war die KI-Gruppe nur etwa zwei Minuten schneller fertig, und auch das war statistisch nicht signifikant.

Am größten war der Abstand bei den Debugging-Fragen. Debugging ist der Teil der Arbeit, den die KI dir zurückgibt. Wenn der generierte Code kaputtgeht, musst du selbst herausfinden, warum.

Eine größere Studie außerhalb der Programmierung kam zum selben Ergebnis. In einem randomisierten Versuch mit etwa 1.000 Schülern weiterführender Schulen im Fach Mathematik schnitten diejenigen mit einem einfachen Assistenten im Stil von ChatGPT bei den Übungen um 48 % besser ab. In der Prüfung ohne KI schnitten sie 17 % schlechter ab als Schüler, die nie Zugang dazu hatten (Bastani et al., PNAS, 2025). Sie haben mehr Aufgaben geschafft und weniger davon gelernt.

Lernforscher überrascht nichts davon. Der Generierungseffekt, erstmals 1978 von Slamecka und Graf beschrieben, zeigt, dass Menschen sich Informationen besser merken, die sie selbst erzeugen, als solche, die sie nur lesen. Beim Abrufen ist es genauso: Studierende, die den Stoff aus dem Gedächtnis wiedergaben, schnitten in einem sofortigen Test schlechter ab als Studierende, die ihn noch einmal lasen, eine Woche später aber besser (Roediger & Karpicke, Psychological Science, 2006). Einen KI-Vorschlag zu übernehmen ähnelt dem Nochmal-Lesen. Wer die Lösung aus dem Kopf tippt, ist näher am Abrufen.

Wann solltest du Code noch von Hand schreiben?

Schreib Code von Hand, wenn es dich mehr kostet, ihn nicht zu verstehen, als du an Zeit sparen würdest. In der Praxis läuft das auf sechs Situationen hinaus.

Wenn du eine Sprache, eine Library oder ein Pattern lernst

Wenn du Go lernst, schreib die goroutines, das Error Wrapping und die interface-Definitionen selbst, auch wenn ein Assistent sie schneller erzeugen könnte. Genau diese Situation hat Anthropic untersucht, und die Gruppe ohne KI lag deutlich vorn.

Die Studie zeigte auch, dass KI-Nutzung nicht schaden muss. Teilnehmer, die sich Code geben ließen und dann so lange nachfragten, bis sie ihn verstanden hatten, oder die nur konzeptionelle Fragen stellten und ihre Fehler selbst behoben, erreichten im Quiz 65 % oder mehr (Anthropic, 2026). Schlechter schnitt ab, wer das Denken dem Assistenten überlassen hat.

Wenn du den Code selbst debuggen musst

Wenn du angepiept wirst, sobald dieser Code in Produktion ausfällt, musst du wissen, wie er funktioniert. Hast du ihn selbst geschrieben, hast du schon ein Bild davon im Kopf, wie er funktioniert. Hast du ihn nur übernommen, baust du dir dieses Bild erst während des Incidents auf. In der Stack-Overflow-Umfrage 2025 sagen schon 45,2 % der Entwickler, dass sie KI-generierten Code länger debuggen als eigenen (Stack Overflow, 2025).

Wenn der Code Geld, Auth oder Nutzerdaten absichert

Veracode hat Code von über 100 Modellen getestet. In 45 % der Samples steckte eine Schwachstelle aus den OWASP Top 10 (Veracode, 2025). Laut dem Update vom Frühjahr 2026 bestehen weiterhin nur 45 % bis 55 % der Samples die Sicherheitsprüfungen. Bei Cross-Site-Scripting waren nur 15 % der Samples sicher (Veracode, 2026). Neuere und größere Modelle schreiben sauberere Syntax, aber bei der Sicherheit hat sich nichts bewegt.

Selbstsicherheit macht es noch schlimmer. In einer Stanford-Studie schrieben Teilnehmer mit KI-Assistent weniger sicheren Code und hielten ihren Code gleichzeitig eher für sicher (Perry et al., ACM CCS, 2023). Schreib Authentifizierung, Autorisierung, Zahlungsabwicklung, Eingabevalidierung und alles, was SQL oder HTML zusammenbaut, von Hand. Oder lies zumindest jede generierte Zeile so, als wüsstest du, dass irgendwo ein Bug steckt.

Wenn die Logik das Produkt ist

Boilerplate ist in jeder Codebase gleich. Preisregeln, Scheduling-Algorithmus und das Verhalten deines Systems bei einem Teilausfall gibt es so nur bei dir. In diesem Code stecken die Designentscheidungen, und beim Schreiben stößt du auf die Edge Cases, die in der Spezifikation fehlen. Reviewst du nur eine generierte Version, siehst du, was das Modell über diese Edge Cases angenommen hat. Ob das stimmt, ist offen.

Wenn du nicht sagen kannst, ob die KI wirklich hilft

In der randomisierten Studie von METR von 2025 arbeiteten 16 erfahrene Open-Source-Entwickler an 246 echten Issues in ihren eigenen Repositories. Mit KI dauerten die Aufgaben 19 % länger. Vorher hatten sie mit 24 % Zeitersparnis gerechnet, und hinterher glaubten sie immer noch, mit KI 20 % schneller gewesen zu sein (METR, 2025).

Fairerweise: Die Folgestudie von METR vom Februar 2026 mit neueren Modellen zeigt in die andere Richtung. Nach ihrer Schätzung sind erfahrene Entwickler mit KI inzwischen wahrscheinlich schneller, auch wenn die Konfidenzintervalle weiterhin die Null einschließen (METR, 2026). Geblieben ist die Lücke zwischen Gefühl und Messung: Dass du dich schneller fühlst, sagt wenig darüber, ob du es bist. Wenn du bei einer Aufgabe immer wieder promptest und nachbesserst, hör auf und schreib sie selbst.

Wenn keine KI im Raum ist

Technische Interviews, Systemdesign am Whiteboard, ein Produktionsvorfall auf einer Maschine ohne installierten Assistenten, eine Pairing-Session, in der du deine Überlegungen erklären musst: Hier kannst du nichts abgeben. Wenn du Code nur per Prompt zustande bringst, merkt man das schnell.

Ein Go-Beispiel: die Retry-Schleife, die deine Autovervollständigung falsch macht

So sieht „fast richtig“ in der Praxis aus. Du schreibst eine Hilfsfunktion, die einen wackeligen Aufruf an einen Downstream-Service wiederholt, und dein Assistent ergänzt den Funktionsrumpf:

example.gogo
func retry(ctx context.Context, fn func() error) error {
	var err error
	for i := 0; i < 5; i++ {
		if err = fn(); err == nil {
			return nil
		}
		time.Sleep(time.Second)
	}
	return err
}

Der Code kompiliert und besteht einen Test, in dem fn zweimal fehlschlägt und dann klappt. Er ist aber an drei Stellen falsch, und die siehst du nur, wenn du weißt, wie sich Go-Services unter Last verhalten:

  1. Er nimmt einen context.Context entgegen und ignoriert ihn. Trennt der Client die Verbindung oder fährt der Server herunter, schläft die Funktion weiter und ruft fn noch bis zu vier Sekunden lang auf. Unter Last stapeln sich diese verwaisten Retries.
  2. Die Wartezeit ist fest. Wenn der Downstream-Service ohnehin schon strauchelt und alle Aufrufer im selben Sekundentakt erneut anklopfen, wird es nur schlimmer. Die Wartezeit sollte wachsen.
  3. Er schläft nach dem letzten Versuch. Das letzte time.Sleep hält den Fehler eine Sekunde lang zurück, ohne dass es etwas bringt.

So sieht die Version aus, die du schreibst, wenn du diese drei Probleme kennst:

example.gogo
func retry(ctx context.Context, fn func() error) error {
	const maxAttempts = 5
	delay := 100 * time.Millisecond

	var err error
	for attempt := range maxAttempts {
		if err = fn(); err == nil {
			return nil
		}
		if attempt == maxAttempts-1 {
			break
		}

		timer := time.NewTimer(delay)
		select {
		case <-ctx.Done():
			timer.Stop()
			return errors.Join(err, ctx.Err())
		case <-timer.C:
		}
		delay *= 2
	}
	return err
}

Auch die zweite Version kann ein Assistent erzeugen, aber nur, wenn du weißt, dass du danach fragen musst. Dieses Wissen (Context-Abbruch, Backoff, was unter Last passiert) bekommst du, indem du solche Schleifen selbst schreibst und zusiehst, wie sie scheitern. Wenn du genau das üben willst, behandelt der Go Concurrency Fundamentals Kurs select, Timer und Context-Abbruch mit Übungen, in denen echtes Go läuft.

Wann ist es in Ordnung, die KI den Code schreiben zu lassen?

Lass die KI den Code schreiben, wenn du ihn auch selbst hättest schreiben können und das Lesen schneller geht als das Tippen. Go-Entwickler kommen dabei weitgehend auf dieselbe Liste. In der Go Developer Survey 2025 setzten sie KI am häufigsten ein für Unit Tests, Boilerplate, Autovervollständigung, Refactoring und Dokumentation (Go Developer Survey, 2026).

Gute Kandidaten:

  • Table-driven Testfälle, sobald du die ersten beiden von Hand geschrieben hast
  • Struct-Tags, JSON-Mappings und andere mechanische Übersetzungsarbeit
  • Parsen von CLI-Flags, Laden von Konfiguration und ähnlicher Glue Code
  • Migration einer Codebase auf eine neue API, wenn das Muster schon klar ist
  • Wegwerfskripte, die du morgen wieder löschst
  • Erklärungen zu einer fremden Codebase oder Fehlermeldung, bevor du irgendetwas änderst

Dieselbe Umfrage zeigt auch, warum du die Ergebnisse weiter prüfen solltest. Nur 55 % der Go-Entwickler waren mit ihren KI-Tools zufrieden, und die häufigste Beschwerde (53 %) war Code, der nicht funktioniert. Ein Viertel der Befragten wollte beim Schreiben von Code am liebsten gar keine KI dabeihaben. Bei keiner anderen Aufgabe in der Umfrage war die Ablehnung so groß (Go Developer Survey, 2026).

Wenn du eine Sprache für die Arbeit mit KI auswählst, erklärt Warum Go die beste Sprache für KI-geschriebenen Code ist, warum die kleine Sprache, der strenge Compiler und die stabilen APIs von Go gut zu generiertem Code passen. Was schiefgeht, wenn Teams diesen Code nicht mehr prüfen, zeigt Die Schattenseite von KI-Coding-Tools anhand der Daten aus 2026 zu Produktionsausfällen, gelöschten Datenbanken und überlasteten Code Reviews.

Eine einfache Regel: Hättest du es selbst schreiben können?

Bevor du einen Vorschlag annimmst, stell dir eine Frage: Hätte ich das mit etwas mehr Zeit selbst schreiben können?

Wenn ja, nimm ihn an, lies ihn und mach weiter. Dann ist die KI für dich eine schnellere Tastatur, und Fehler fallen dir auf.

Wenn nein, ist das der Code, den du von Hand schreiben oder zumindest nach dem Lesen des Vorschlags aus dem Gedächtnis nachbauen solltest. Dort lernst du etwas, und dort übersiehst du am ehesten einen Bug.

Das passt zu einer Umfrage von Microsoft Research und der Carnegie Mellon University unter 319 Wissensarbeitern aus dem Jahr 2025: „Höheres Vertrauen in GenAI geht mit weniger kritischem Denken einher, während höheres Selbstvertrauen mit mehr kritischem Denken einhergeht“ (Microsoft Research, 2025). Wer weiß, dass er den Code auch selbst schreiben könnte, liest ihn kritischer. Wenn du KI schon jeden Tag nutzt und diese Fähigkeit behalten willst, beschreibt Wie du deine Coding-Skills fit hältst, wenn KI den Code schreibt eine wöchentliche Routine für Übung ohne KI.

Wo LevelUpGo ins Spiel kommt

LevelUpGo setzt genau beim Selbstschreiben an. Jede Lektion zeigt links das Konzept und rechts einen echten Editor, und du kommst erst weiter, wenn dein Go-Code kompiliert und die Tests besteht. Im Editor gibt es keine Autovervollständigung, also sind die Fehler und die Korrekturen deine eigenen. Fang mit dem kostenlosen Go Fundamentals Kurs an. Wenn du dich sicher fühlst, findest du im Training Ground einzelne Übungen, mit denen du in Übung bleibst, während die KI im Job die Boilerplate übernimmt.

Wenn du noch überlegst, wo du anfangen sollst, zeigt Programmieren lernen 2026, wie du KI als Tutor statt als Abkürzung nutzt, und 10 häufige Go-Fehler, die du vermeiden solltest listet die Bugs auf, die du in generiertem Code erkennen solltest. Was mit deinem Lernen passiert, wenn die KI für dich denkt, liest du in Lagere dein Gehirn nicht aus.

Häufig gestellte Fragen

Lohnt es sich noch, Programmieren zu lernen, wenn KI Code schreiben kann?

Ja. KI schreibt oft Code, der fast richtig ist, und 66 % der Entwickler nennen das ihr größtes Ärgernis damit (Stack Overflow, 2025). Um den falschen Teil zu finden und zu reparieren, brauchst du dasselbe Verständnis wie zum Selbstschreiben. Programmieren lernen heißt heute, Code beurteilen zu können und nicht nur, ihn zu produzieren.

Wird man durch KI ein schlechterer Programmierer?

Das kann passieren, wenn du sie nutzt, um das Denken zu überspringen. In der Studie von Anthropic von 2026 schnitten Entwickler, die beim Lernen an die KI delegierten, beim Verständnis 17 Prozentpunkte schlechter ab. Entwickler, die der KI konzeptionelle Fragen stellten und ihre Fehler selbst behoben, schnitten fast so gut ab wie die, die von Hand programmierten (Anthropic, 2026).

Sollten Anfänger KI-Coding-Assistenten nutzen?

Nutze sie als Tutor, nicht als Autovervollständigung. Lass dir von einem Assistenten einen Fehler erklären, zwei Ansätze vergleichen oder dich zu einem Konzept abfragen. Die Lösung schreibst du selbst. Schalte Inline-Vervollständigungen ab, solange du die Grundlagen lernst, denn einen Vorschlag anzunehmen fühlt sich nach Fortschritt an, überspringt aber genau den Teil, bei dem etwas hängen bleibt.

Welcher Code sollte immer Zeile für Zeile geprüft werden?

Authentifizierung, Autorisierung, Zahlungen, Eingabevalidierung und alles, was SQL-Queries, HTML oder Shell-Befehle zusammenbaut. KI-generierter Code fällt immer noch in etwa der Hälfte der Fälle durch Sicherheitsprüfungen, und Schutzmaßnahmen gegen Cross-Site-Scripting bestehen nur in 15 % der Fälle (Veracode, 2026).

Ist KI für erfahrene Entwickler wirklich schneller?

Wahrscheinlich, aber weniger, als es sich anfühlt. Die Studie von METR von 2025 maß eine Verlangsamung um 19 %, während die Entwickler glaubten, 20 % schneller geworden zu sein. Laut der Folgestudie von 2026 machen neuere Tools inzwischen etwas schneller, allerdings mit großer Unsicherheit (METR, 2026). Miss deine eigenen Aufgaben, statt dich auf das Gefühl zu verlassen.

Quellen

Schreib Go wie ein Senior Engineer

Interaktive Lektionen im Browser. Die ersten sind kostenlos.

Kostenlose Lektion testenOder kostenloses Konto erstellen