Wenn KI den Code schreibt, muss ihn dann noch jemand verstehen?
Ein pragmatisches Framework, um zu entscheiden, wann menschliches Verständnis noch wichtig ist
Eine Frage taucht immer wieder auf — in Gesprächen mit Entwicklern, CTOs und Tech-Leads: Wenn KI mittlerweile den Großteil des Codes schreibt, warum sollten Menschen sich dann noch die Mühe machen, ihn zu verstehen?
Keine dumme Frage, ehrlich gesagt. Die Zahlen sind beeindruckend: 41% des gesamten Codes ist mittlerweile KI-generiert oder KI-unterstützt. Microsoft und Google berichten, dass etwa ein Viertel ihres Codes von KI stammt. Anthropics CEO hat prognostiziert, dass bis Ende 2025 ganze 90% des Codes von KI geschrieben werden. Tools wie Cursor, Copilot und Claude Code sind längst keine Spielerei mehr — sie gehören zum täglichen Workflow der meisten Entwickler.
Das Versprechen klingt verlockend: Beschreib einfach auf Deutsch, was du willst, lass die KI die Implementierung schreiben, und ab damit in die Produktion. Wozu jahrelang Syntax lernen, wenn du einfach fragen kannst, was du brauchst?
Bei Skelpo setzen wir KI intensiv ein. Sie hat komplett verändert, wie schnell wir von einer Idee zu funktionierender Software kommen. Aber wir bauen auch Finanzanwendungen. Und es gibt Code in diesen Systemen, den keine KI anfasst, ohne dass ein Mensch exakt versteht, was der Code macht — und warum.
Diese Spannung — zwischen Geschwindigkeit und Sorgfalt — ist das, worum es in diesem Artikel geht. Keine pauschale Antwort, sondern ein Framework, um zu entscheiden, wann menschliches Code-Verständnis noch wichtig ist und wann vielleicht nicht.
Die 70-jährige Reise zu lesbarem Code
Programmiersprachen existieren, weil Menschen nicht mit Maschinencode arbeiten konnten.
In den 1940ern wurden frühe Computer wie ENIAC in Binärcode programmiert — rohe Sequenzen aus Einsen und Nullen, die der Prozessor direkt ausführen konnte. Technisch hat das funktioniert. Aber von Hand Binärcode zu schreiben war mühsam, fehleranfällig und quasi unmöglich zu debuggen. Eine einzige falsche Ziffer konnte alles kaputtmachen, und den Fehler zu finden bedeutete, Wände voller Zahlen zu scannen.
Assemblersprache hat die Sache etwas verbessert. Statt rohem Binärcode konnten Programmierer Kürzel wie ADD oder MOV verwenden — immer noch eng an die Hardware gekoppelt, aber wenigstens halbwegs lesbar. Ein Schritt in Richtung menschliches Verständnis, aber nur ein kleiner.
Der echte Umbruch kam Ende der 1950er. FORTRAN, COBOL und LISP führten etwas Radikales ein: Code, der mehr nach Sprache aussah als nach Mathematik. Man konnte etwas schreiben, das Logik ähnelte, statt Hardware-Anweisungen. Ein Programmierer, der den Code las, konnte die Absicht verstehen, nicht nur die Mechanik.
Jede große Sprachinnovation seitdem folgte der gleichen Richtung. C abstrahierte Speicheradressen weg. Python priorisierte Lesbarkeit so stark, dass Whitespace syntaktisch relevant wurde. Die gesamte Geschichte der Programmiersprachen ist ein 70-jähriges Projekt, um Code für Menschen verständlicher zu machen.
Aber hier ist der entscheidende Punkt: Lesbarkeit ging nie nur ums Schreiben von Code. Es ging ums Warten.
Software überlebt die Leute, die sie schreiben. Der Entwickler, der 2019 ein System gebaut hat, ist vielleicht 2024 längst bei einer anderen Firma. Die Person, die um 2 Uhr nachts einen Produktions-Incident debuggt, hat den Code, der gerade kaputtgeht, wahrscheinlich nicht geschrieben. Lesbarer Code war eine Investition in die Zukunft — die Erkenntnis, dass irgendwann jemand anders diesen Code verstehen, modifizieren und fixen muss.
Jetzt stellen wir diese gesamte Prämisse in Frage.
Was die Daten wirklich zeigen
Bevor wir beantworten können, ob Menschen Code verstehen müssen, sollten wir uns anschauen, was tatsächlich passiert — nicht die Schlagzeilen, sondern die Zahlen.
Die Behauptung, dass KI "80-90% des Codes" schreibt, wird oft wiederholt, meistens von Leuten, die KI-Tools verkaufen. Die Realität ist bescheidener. Stand 2025 sind 41% des gesamten Codes KI-generiert oder KI-unterstützt. Das ist signifikant, aber nicht die Revolution, die das Marketing suggeriert.
Aufschlussreicher ist, was passiert, nachdem KI Code generiert hat. Unter Entwicklern, die täglich KI-Tools nutzen, sind nur etwa 24% ihres gemergten Codes vollständig KI-verfasst — das heißt, er wurde ohne größere menschliche Überarbeitungen eingecheckt. Der Rest wird modifiziert, korrigiert oder komplett verworfen. GitHub Copilot macht 46% der Zeit Vorschläge, aber Entwickler akzeptieren nur etwa 30% davon. Die Mehrheit wird abgelehnt.
Dann ist da die Qualitätsfrage. Eine aktuelle Analyse von Hunderten GitHub Pull Requests hat ergeben, dass KI-generierter Code 1,7-mal mehr Probleme enthält als von Menschen geschriebener Code. Die Aufschlüsselung ist ernüchternd:
- 75% mehr Logik- und Korrektheitsfehler
- 64% mehr Probleme mit Code-Qualität und Wartbarkeit
- 57% mehr Sicherheitslücken
- 42% mehr Performance-Probleme
Eine andere Studie fand heraus, dass 62% des KI-generierten Codes Sicherheitsmängel oder Design-Probleme enthält — selbst bei Verwendung der neuesten Modelle. Häufige Probleme sind fehlende Input-Validierung, unsachgemäße Passwort-Handhabung und unsichere Authentifizierungsmuster. KI versteht dein Bedrohungsmodell nicht. Sie matched Muster aus Trainingsdaten, und diese Trainingsdaten enthalten jede Menge unsicheren Code.
Vielleicht am auffälligsten: Nur 3,8% der Entwickler berichten sowohl von niedrigen Halluzinationsraten als auch von hohem Vertrauen, KI-Code ohne menschliches Review zu shippen. Das ist kein Vertrauensproblem einiger Skeptiker. Das ist eine branchenweite Erkenntnis, dass KI-Output Aufsicht braucht.
Die Lücke zwischen Wahrnehmung und Realität ist hier wichtig. Wenn du glaubst, KI schreibt 90% des produktionsreifen Codes, baust du Prozesse, die minimales menschliches Review voraussetzen. Wenn du verstehst, dass KI erste Entwürfe produziert, die häufig Korrekturen brauchen — besonders bei Sicherheit und Logik — baust du ganz andere Prozesse.
Die Vibe-Coding-Falle
Anfang 2025 prägte Andrej Karpathy — OpenAI-Mitgründer und ehemaliger Tesla-KI-Direktor — den Begriff "Vibe Coding". Die Idee: Beschreib in natürlicher Sprache, was du willst, lass die KI den Code schreiben, und iteriere basierend darauf, ob es funktioniert. Lies dir die Implementierung nicht durch. Versuch nicht, sie zu verstehen. Akzeptier einfach den Output und mach weiter.
Klingt effizient. Für bestimmte Anwendungsfälle ist es das auch. Aber unter Entwicklern, die sich zu sehr auf diesen Ansatz verlassen, hat sich ein Muster entwickelt.
Ein Entwickler beschrieb es so: "Eine Weile lang hab ich mir kaum die Mühe gemacht zu checken, was Claude da tut, weil der generierte Code meistens beim ersten Mal funktionierte. Aber jetzt merke ich, dass ich aufgehört habe, meine eigene Codebase zu verstehen."
Das ist die Vibe-Coding-Falle. Sie funktioniert prima — bis sie es nicht mehr tut. Und wenn sie scheitert, scheitert sie auf eine Art, die besonders schwer zu beheben ist.
Die Failure-Modes sind vorhersehbar. Wenn KI-generierter Code in Produktion kaputtgeht, können Entwickler, die ihn nie verstanden haben, ihn nicht debuggen. Sie sitzen fest und prompten die KI nach Fixes, in der Hoffnung, dass sie ein Problem lösen kann, ohne sich daran zu erinnern, warum sie die ursprünglichen Entscheidungen getroffen hat. Wenn Security-Researcher Schwachstellen finden — und das tun sie regelmäßig — kann niemand im Team die Schwere einschätzen oder einen ordentlichen Fix implementieren, weil niemand weiß, wie das System tatsächlich funktioniert.
Der Skill-Verfall ist schleichend und unsichtbar. Entwickler berichten, dass sie nach Monaten starker KI-Abhängigkeit mit Aufgaben kämpfen, die früher selbstverständlich waren. Die Grundlagen werden rostig. Mustererkennung verblasst. Wenn sie schließlich auf ein Problem stoßen, das KI nicht lösen kann, stellen sie fest, dass ihre eigenen Fähigkeiten nachgelassen haben.
Für Junior-Entwickler ist die Falle besonders gefährlich. Sie bauen Karrieren auf einem Fundament aus Code, den sie nie wirklich verstanden haben. Sie können Output generieren, aber sie können ihn nicht bewerten. Sie können sicheren Code nicht von Code unterscheiden, der nur sicher aussieht. Sie sammeln jahrelange Erfahrung an, ohne das zugrundeliegende Urteilsvermögen zu entwickeln, das Erfahrung wertvoll macht.
Die unangenehmsten Fälle sind öffentlich. Ein Startup-Gründer, der sein gesamtes Produkt mit KI gebaut hatte — "null handgeschriebener Code" — postete stolz darüber in Social Media. Innerhalb von Tagen hatten Angreifer sein Bezahlsystem umgangen, seine API ausgenutzt und seine Datenbank mit Müll gefüllt. Er hatte Code geshippt, den er nicht absichern konnte, weil er ihn nie verstanden hatte.
Vibe Coding ist nicht per se falsch. Für Wegwerf-Scripts, persönliche Tools und schnelle Prototypen ist es echt nützlich. Die Falle ist, es für einen Universalansatz zu halten — zu glauben, dass es für alles funktioniert, nur weil es bei Low-Stakes-Projekten funktioniert.
Ein pragmatisches Framework — Wann Verständnis wichtig ist
Die ehrliche Antwort auf "Sollten Menschen den Code verstehen?" ist: Es kommt drauf an. Aber "es kommt drauf an" ist ohne Framework zur Entscheidung nicht hilfreich.
Bei Skelpo haben wir ein einfaches mentales Modell entwickelt. Je höher die Einsätze, desto tiefer muss das menschliche Verständnis sein. Das klingt offensichtlich, aber die Praxis erfordert, spezifisch zu werden, was "Einsätze" tatsächlich bedeutet.
Weniger Prüfung: KI-unterstützt, von Menschen reviewed
Mancher Code braucht wirklich kein tiefes menschliches Verständnis. Nicht alles ist kritische Infrastruktur.
Interne Tools und Admin-Scripts fallen in diese Kategorie. Wenn ein Script, das Log-Dateien reformatiert, einen Bug hat, wird das jemand bemerken und fixen. Der Blast-Radius ist klein. Prototypen und Proof of Concepts sind ähnlich — sie existieren, um Ideen zu testen, nicht um in Produktion zu laufen. Das Ziel ist Geschwindigkeit, nicht Langlebigkeit.
Boilerplate und Scaffolding brauchen selten zeilenweises Verständnis. Eine Standard-Projektstruktur aufsetzen, Config-Dateien generieren, repetitive CRUD-Operationen schreiben — KI macht das gut, und die Muster sind vertraut genug, dass ein schnelles Review offensichtliche Probleme findet.
Gut isolierte Komponenten mit klaren Grenzen sind auch gute Kandidaten. Wenn eine Funktion definierte Inputs nimmt, definierte Outputs produziert und solide Testabdeckung hat, ist das Verstehen ihrer Interna weniger wichtig. Die Tests verifizieren das Verhalten. Die Isolation begrenzt den Schaden, wenn etwas falsch ist.
Der gemeinsame Nenner: Das sind Situationen, in denen Fehler sichtbar, behebbar und in ihrem Umfang begrenzt sind.
Mehr Prüfung: von Menschen verstanden, KI höchstens unterstützend
Anderer Code erfordert echtes Verständnis. KI kann beim Entwurf helfen, aber ein Mensch muss verstehen, was geshippt wurde und warum.
Authentifizierung und Autorisierung stehen ganz oben auf dieser Liste. Login-Flows, Berechtigungsprüfungen oder Session-Handling falsch zu machen, verursacht nicht nur Bugs — es schafft Sicherheitslücken, nach denen Angreifer aktiv suchen. KI-generierter Auth-Code hat eine 88% höhere Wahrscheinlichkeit, unsachgemäße Passwort-Handhabung zu enthalten als von Menschen geschriebener Code. Das ist kein Tippfehler.
Zahlungsabwicklung und Finanzberechnungen erfordern die gleiche Sorgfalt. Ein subtiler Rundungsfehler oder Währungsumrechnungs-Bug bringt vielleicht nichts zum Absturz. Er wird nur still und leise Geld verlieren — deins oder das deiner Kunden. Das sind Systeme, bei denen "scheint zu funktionieren" bei weitem nicht gut genug ist. Du musst wissen, warum es funktioniert und welche Annahmen es macht.
Datenverarbeitung in regulierten Kontexten — Gesundheitswesen, Finanzen, Recht — hat Compliance-Implikationen jenseits von bloßer Funktionalität. Prüfer akzeptieren "Die KI hat's geschrieben und die Tests sind grün" nicht als Dokumentation. Jemand muss die Datenflüsse verstehen und erklären können.
Sicherheitskritische Pfade brauchen menschliche Augen, egal was die KI entworfen hat. Input-Validierung, SQL-Queries, Dateihandhabung, alles was User-Daten berührt — das sind die Stellen, an denen KI am zuverlässigsten unsichere Muster aus ihren Trainingsdaten reproduziert.
Kerngeschäftslogik, die jahrelang leben wird, verdient Verständnis, weil sie irgendwann jemand modifizieren muss. Die Person, die diesen Code 2028 wartet, hat vielleicht keinen Zugang zur KI-Konversation, die ihn generiert hat. Sie hat nur den Code selbst. Wenn ihn nie jemand verstanden hat, wird er am ersten Tag zu Legacy-Code.
Die Frage, die du dir stellen solltest
Wenn wir entscheiden, wie viel menschliches Verständnis ein Stück Code erfordert, fragen wir uns:
"Wenn das um 2 Uhr nachts kaputtgeht und die KI, die es geschrieben hat, sich an den Kontext nicht erinnert, kann jemand in unserem Team das diagnostizieren und fixen?"
Wenn die Antwort nein ist — wenn wir festsitzen würden und eine KI prompten müssten, ihren eigenen mysteriösen Output zu fixen — dann muss ein Mensch diesen Code verstehen, bevor er geshippt wird.
Welche Skills jetzt wichtig sind
Wenn KI die Syntax übernimmt, was bleibt für Menschen?
Diese Frage hält Junior-Entwickler nachts wach. Es lohnt sich, sie klar zu beantworten: Die Skills, die wichtig sind, verschieben sich, sie verschwinden nicht. Und in mancher Hinsicht werden sie anspruchsvoller, nicht weniger.
Architektur-Urteilsvermögen ist das große Ding. Zu verstehen, wie Systeme zusammenpassen — wo man Grenzen zieht, wie Komponenten kommunizieren, was passiert wenn ein Teil ausfällt — erfordert die Art von ganzheitlichem Denken, die KI derzeit fehlt. KI kann eine Funktion generieren. Sie tut sich schwer, ein System zu designen. Die Entwickler, die das ganze Spielfeld sehen können, nicht nur den nächsten Zug, werden wertvoller, während KI die einzelnen Teile erledigt.
Sicherheits-Intuition wird wichtiger, wenn du Code reviewst, den du nicht geschrieben hast. Du musst Red Flags erkennen: User-Input, der in SQL-Queries fließt, Authentifizierungsprüfungen, die umgangen werden können, Daten, die geloggt werden, obwohl sie es nicht sollten. KI reproduziert ständig unsichere Muster, weil ihre Trainingsdaten voll davon sind. Der menschliche Reviewer muss wissen, wie "falsch" aussieht, selbst wenn der Code ohne Fehler läuft.
Debugging-Fähigkeit wird kritisch in einer KI-unterstützten Welt. Wenn etwas kaputtgeht, tracest du oft durch Code, den du nicht geschrieben hast, auf der Suche nach Logik, die du nicht designt hast. Das erfordert, Code sorgfältig zu lesen, Ausführungsflüsse zu verstehen, Hypothesen zu bilden, was falsch sein könnte. Entwickler, die das nie geübt haben — die sich immer nur zu Lösungen durchgepromptet haben — sind hilflos, wenn die Prompts nicht mehr funktionieren.
Spezifikations-Präzision ist der neue Flaschenhals. Die Qualität von KI-Output hängt stark davon ab, wie klar du beschreibst, was du brauchst. Vage Prompts produzieren vagen Code. Entwickler, die Business-Anforderungen in präzise technische Spezifikationen übersetzen können — inklusive Edge Cases, Fehlerbehandlung und Sicherheits-Constraints — bekommen dramatisch bessere Ergebnisse von KI-Tools als die, die das nicht können.
Bewertungs-Skill bindet alles zusammen. Kannst du auf ein Stück Code schauen und beurteilen, ob es gut ist? Nicht nur ob es läuft, sondern ob es wartbar, sicher, performant und an den Rändern korrekt ist? Dieser Skill erfordert, genug Code geschrieben zu haben, um Muster zu erkennen, genug Bugs begegnet zu sein, um zu wissen, wo sie sich verstecken, und genug Pull Requests reviewed zu haben, um Geschmack zu entwickeln.
Hier ist das unbequeme Paradox: KI-Coding-Tools sind in den Händen derer am mächtigsten, die sie am wenigsten brauchen. Erfahrene Entwickler nutzen KI, um Arbeit zu beschleunigen, die sie bereits können. Sie fangen Fehler, weil sie sie erkennen. Sie lenken die KI zu besseren Lösungen, weil sie wissen, wie besser aussieht.
Anfänger bekommen etwas anderes. Sie bekommen plausibel aussehenden Output, den sie nicht bewerten können, selbstsicher klingende Vorschläge, die sie nicht verifizieren können, und eine wachsende Codebase, die sie nicht verstehen. Das Tool verstärkt Fähigkeiten bei denen, die sie haben, und maskiert das Fehlen von Fähigkeiten bei denen, die sie nicht haben.
Der Weg nach vorn ist nicht, KI-Tools zu vermeiden. Es ist, das Urteilsvermögen aufzubauen, um sie gut zu nutzen.
Unser Ansatz bei Skelpo
Wir sind keine KI-Skeptiker. Jeder, der in letzter Zeit mit uns gearbeitet hat, weiß, dass KI-Tools Teil unseres täglichen Workflows sind. Sie haben echt verändert, wie schnell wir von Konzept zu funktionierender Software kommen, und wir wären dumm, das zu ignorieren.
Aber wir sind auch nicht naiv.
Wir bauen Finanzanwendungen. Systeme, bei denen ein subtiler Bug in einer Berechnung echtes Geld bedeuten könnte — das Geld unserer Kunden. Wo eine Sicherheitslücke sensible Finanzdaten exponieren könnte. Wo regulatorische Compliance keine Option ist. In diesen Kontexten ist "scheint zu funktionieren" kein akzeptabler Standard.
Also haben wir uns auf ein einfaches Prinzip geeinigt: Je höher die Einsätze, desto tiefer muss das menschliche Verständnis sein.
Für internes Tooling, Prototypen und isolierte Utilities lassen wir KI die schwere Arbeit machen. Ein Entwickler reviewed den Output, prüft ob er sich korrekt verhält, und macht weiter. Wir sind nicht übertrieben pingelig damit, jede Zeile eines Scripts zu verstehen, das Daten für eine einmalige Migration reformatiert.
Für alles, was Geld, Authentifizierung oder sensible Daten berührt, ändert sich die Rechnung komplett. KI kann den Code entwerfen. KI kann Ansätze vorschlagen. Aber bevor er geshippt wird, versteht ein Mensch, was dieser Code tut — nicht nur dass er Tests besteht, sondern warum er funktioniert, welche Annahmen er macht und wie er scheitern könnte.
Das ist kein Misstrauen gegenüber KI. Es geht darum, ihre aktuellen Grenzen zu verstehen und Prozesse um sie herum zu bauen. KI kennt unser Bedrohungsmodell nicht. Sie versteht unsere Compliance-Anforderungen nicht. Sie kann die geschäftlichen Konsequenzen eines subtilen Bugs in Zahlungslogik nicht abwägen. Diese Urteile erfordern Menschen, die den Code und den Kontext verstehen, in dem er operiert.
Wir sind auch bewusst bei der Skill-Entwicklung. Es wäre einfach, KI alles machen zu lassen und zuzusehen, wie die Grundlagen unseres Teams erodieren. Stattdessen behandeln wir KI als Tool, das die langweiligen Teile erledigt, während Menschen sich auf die harten Teile konzentrieren — Architektur-Entscheidungen, Security-Review, komplexe Probleme debuggen, die Systeme verstehen, für die wir verantwortlich sind.
Das Ziel ist nicht, KI weniger zu nutzen. Es ist, sie gut zu nutzen, was bedeutet zu wissen, wann man ihr vertraut und wann man verifiziert.
Die Ära des Urteilsvermögens
Die Frage, mit der wir angefangen haben — wenn KI den Code schreibt, muss ihn dann noch jemand verstehen? — stellt sich als die falsche Frage heraus.
Die richtige Frage ist: Welche Menschen müssen welchen Code verstehen, und wie treffen wir diese Entscheidung gut?
Die Ära, in der jeder Entwickler jede Zeile versteht, geht wahrscheinlich zu Ende. Codebases sind zu groß, Entwicklung ist zu schnell, und KI ist zu nützlich für Routinearbeit. Das ist kein Verlust, dem man nachtrauern müsste.
Aber die Ära, in der niemand den Code versteht, ist nichts, worauf man hinarbeiten sollte. Das ist ein Rezept für Systeme, die nicht debuggt werden können, Sicherheitslücken, die nicht bewertet werden können, und Technical Debt, die sich still ansammelt, bis sie unbeherrschbar wird.
Für Menschen lesbarer Code wird nicht obsolet. Was sich ändert, ist wer ihn lesen muss, wann und warum. Das 70-jährige Projekt, Code für Menschen verständlich zu machen, ist immer noch wichtig — nur nicht gleichmäßig, und nicht aus den gleichen Gründen wie früher.
Der Skill, der jetzt zählt, ist nicht Syntax-Auswendiglernen. Es ist Urteilsvermögen. Zu wissen, wann man KI-Output vertraut und wann man ihn verifiziert. Zu wissen, welcher Code tiefes Verständnis erfordert und welcher nicht. Zu wissen, wie man bewertet, was man nicht selbst geschrieben hat.
Dieses Urteilsvermögen ist es, das Teams, die KI effektiv nutzen, von Teams trennt, die nur einen Produktions-Incident davon entfernt sind zu entdecken, dass sie Systeme gebaut haben, die niemand versteht.
Der Code wird immer einfacher zu generieren sein. Das Urteilsvermögen, ihn gut zu nutzen, nicht.