Mikkel Freltoft Krogsholm
Menü

A mind, not a brand.

AI · mennesker · fremtidKøbenhavn · Danmark
Essay
13 Min. Lesezeit

Wenn Code nicht mehr die Sprache des Menschen ist

KI könnte bald mehr Code schreiben, als Menschen prüfen können. Deshalb brauchen wir eine neue Sprache, die Maschinenarbeit verständlich und kontrollierbar macht.

Mikkel Krogsholm betragter fire gennemsigtige lag, hvor et tæt netværk bliver til én sporbar messinglinje.

Vor Kurzem habe ich eine Änderung für Graphify vorgeschlagen, ein Softwareprojekt, dessen Code offenliegt, sodass andere ihn lesen und dazu beitragen können.

In der Softwarewelt wird ein solcher Vorschlag oft als Pull Request eingereicht. Das ist ein Paket aus neuem Code, einer Erklärung und einem Überblick über die Änderungen. Andere können das Paket lesen, Fragen stellen und es genehmigen, bevor die Änderung Teil des Programms wird.

Normalerweise begegnet man zuerst dem Code selbst. Entfernte Zeilen stehen in Rot, hinzugefügte in Grün. Bei einer großen Änderung können es Tausende sein.

Mein Vorschlag für Graphify sollte dem Leser einen anderen Einstieg geben.

Statt mit all den roten und grünen Zeilen zu beginnen, sollte man mit einigen gewöhnlichen Fragen anfangen können: Was ist jetzt anders? Welche Teile des Programms sind betroffen? Worauf könnte sich die Änderung auswirken? Und wo kann ich den Beleg sehen?

Der Vorschlag erstellt deshalb einen Bericht in mehreren Schichten. Zuerst eine kurze Geschichte der Änderung. Dann ein Bild der Programmteile, die miteinander verbunden sind. Danach eine einfache Schritt-für-Schritt-Beschreibung der wichtigsten Logik. Ganz unten liegt der tatsächliche Code.

Programmierer nennen eine solche einfache Schritt-für-Schritt-Beschreibung manchmal Pseudocode. Das ist kein Code, den der Computer ausführen kann. Er ähnelt eher einem Rezept:

  1. Eine Bestellung empfangen.
  2. Prüfen, ob der Artikel auf Lager ist.
  3. Den Artikel vom Bestand abziehen.
  4. Eine Bestätigung senden.

Der echte Code enthält alle genauen Regeln, Formate und Ausnahmen, die der Computer benötigt. Der Pseudocode versucht, den Gedankengang zu zeigen, ohne dass der Leser die Programmiersprache kennen muss.

Ich habe dieses Experiment nicht gebaut, weil der echte Code unwichtig geworden wäre. Im Gegenteil. Ich habe es gebaut, weil Code zu wichtig geworden ist, als dass menschliche Kontrolle davon abhängen dürfte, wie schnell ein Mensch Tausende Zeilen in einer Sprache lesen kann, die nie unsere Muttersprache war.

Dieses Problem wächst, wenn KI einen immer größeren Teil des Codes schreibt.

Die Maschine produziert immer schneller. Der Mensch soll anschließend noch immer lesen.

Das könnte zum nächsten großen Engpass der Softwareentwicklung werden.

Von Nullen und Einsen zu Python

Etwas Ähnliches haben wir schon einmal versucht.

Die ersten Programmierer arbeiteten sehr nah an der eigenen Sprache des Computers. Sie mussten die Arbeit als Zahlen und sehr konkrete, kleine Operationen beschreiben. Das war umständlich, langsam und nur sehr wenigen Menschen vorbehalten.

Später bekamen die kleinen Operationen Namen. Danach kamen Sprachen wie Fortran, in denen ein Mensch eine mathematische Formel in erkennbarer Form schreiben konnte. Ein anderes Programm übersetzte die Formel dann in die vielen kleinen Anweisungen, die der Computer ausführen konnte.

Ein solches Übersetzungsprogramm heißt Compiler. Der Name ist nicht wichtig. Entscheidend ist die Arbeitsteilung: Der Mensch beschreibt die Aufgabe auf einer Ebene, die für einen Menschen sinnvoll ist. Das Werkzeug übersetzt sie auf eine Ebene, die für die Maschine sinnvoll ist.

IBM beschreibt, wie eine Aufgabe, die zuvor tausend Maschinenanweisungen erforderte, mit 47 Zeilen Fortran ausgedrückt werden konnte. Viele bezweifelten, dass automatisch übersetzter Code ebenso effizient werden könnte wie direkt für die Maschine geschriebener Code. Beinahe war er es.

Seitdem haben wir diese Bewegung immer wieder vollzogen.

Neue Programmiersprachen entfernten den Entwickler ein Stück weiter vom physischen Inneren des Computers. Python machte es möglich, mit vergleichsweise wenigen, lesbaren Zeilen viel auszudrücken. Fertige Bausteine machten es unnötig, alles von Grund auf neu zu erfinden.

Python wird oft als höhere Programmiersprache bezeichnet. Höher bedeutet nicht feiner oder besser. Es bedeutet weiter entfernt von den einzelnen Operationen des Computers und näher an dem Problem, das der Mensch lösen möchte.

Jedes Mal, wenn wir eine Ebene höher gegangen sind, hat der Mensch etwas direkten Kontakt zur unteren Schicht verloren. Dafür konnten mehr Menschen komplexere Dinge bauen.

Wir haben den Ort verschoben, an dem der Mensch seine Absicht formuliert.

KI setzt diese Bewegung fort. Heute kann ich eine gewünschte Änderung mit gewöhnlichen Worten beschreiben. Ein digitaler Kollege kann die relevanten Dateien finden, neuen Code vorschlagen und prüfen, ob die bekannten Teile des Programms weiterhin funktionieren.

In Als die Benutzeroberfläche optional wurde habe ich genau über diese Übersetzung geschrieben. KI kann zwischen dem Wunsch eines Menschen und dem technischen Material des Systems stehen. Wir müssen nicht mehr selbst alle Schaltflächen, Dateien und Befehle kennen, damit etwas geschieht.

Doch wenn die Übersetzung hinunter zur Maschine so gut wird, entsteht in der Gegenrichtung ein neues Problem.

Wie übersetzen wir die Arbeit der Maschine zurück in menschliches Verständnis?

Code hatte zwei Leser

Quellcode sind die geschriebenen Anweisungen, die bestimmen, was ein Programm tut.

Er hatte lange zwei verschiedene Leser.

Der Computer muss die Anweisungen in Handlungen umsetzen können. Aber auch ein Mensch muss sie lesen können, um das Programm zu verstehen, Fehler zu finden und zu entscheiden, ob eine Änderung vertretbar ist.

Deshalb nehmen sich Programmierer Zeit für gute Namen und teilen die Arbeit in verständliche Teile auf. Dem Computer ist gleichgültig, ob der Name eines Programmteils sinnvoll ist. Dem nächsten Programmierer nicht.

Vielleicht hat nur der nächste Programmierer seine Gestalt verändert.

Wenn Code zunehmend von KI-Programmen geschrieben, geändert und gepflegt wird, die Aufgaben selbst lösen können, kann Quellcode zu einem Zwischenprodukt zwischen Maschinen werden. Er bleibt entscheidend. Dort liegen weiterhin die genauen Anweisungen. Aber er muss nicht der Ort sein, an dem die meisten Menschen einer Änderung zuerst begegnen.

Nur wenige Python-Programmierer lesen heute die grundlegenden Maschinenanweisungen, in die ihr Programm am Ende übersetzt wird. Sie arbeiten auf einer höheren Ebene, weil die Verbindung zwischen den Ebenen zuverlässig genug ist.

Die Frage ist, ob etwas Ähnliches geschehen kann, wenn wir neuen Code prüfen.

Nicht indem wir den Code entfernen, sondern indem wir dem Menschen darüber eine verständlichere Leseschicht geben.

Bei einer kleinen Änderung kann eine rezeptartige Erklärung dicht am Code bleiben. Bei einer sehr großen Änderung kann selbst diese Erklärung lang werden. Dann kann man mit einem kurzen Überblick beginnen und bei Bedarf weitere Details öffnen.

Der Mensch beginnt mit der Bedeutung und bewegt sich hinunter zu den technischen Anweisungen, wenn etwas unklar, riskant oder wichtig ist.

Wir haben Jahrzehnte damit verbracht, Schichten zu bauen, die menschliche Wünsche in Maschinenanweisungen übersetzen. Vielleicht ist nun die Zeit für eine Schicht gekommen, die die Arbeit der Maschine hinauf in menschliche Bedeutung übersetzt.

Mehr Code ist nicht dasselbe wie mehr Fortschritt

Es ist verlockend, daraus eine einfache Geschichte über Geschwindigkeit zu machen.

KI schreibt den Code schneller. Also bekommen wir schneller bessere Software.

So einfach sieht die Wirklichkeit nicht aus.

DORA ist ein großes Forschungsprogramm, das untersucht, wie Software in realen Organisationen entwickelt wird. Im Bericht von 2025 gaben mehr als 80 Prozent der Teilnehmer an, KI habe ihre Produktivität erhöht. Gleichzeitig hatten 30 Prozent wenig oder gar kein Vertrauen in von KI geschriebenen Code.

Organisationen mit mehr KI brachten mehr Änderungen durch ihre Systeme. Der Bericht fand jedoch weiterhin einen Zusammenhang mit geringerer Stabilität — also mehr Schwierigkeiten, die Software funktionsfähig zu halten, während sie verändert wurde.

Andere Untersuchungen machen das Bild noch weniger eindeutig.

GitHub stellte in einem kontrollierten Versuch fest, dass Entwickler mit KI-Unterstützung eine bestimmte Aufgabe schneller lösten. Die Forschungsorganisation METR fand dagegen, dass erfahrene Entwickler Anfang 2025 für reale Aufgaben 19 Prozent mehr Zeit benötigten, wenn sie die damaligen KI-Werkzeuge verwenden durften. Die Entwickler selbst glaubten, schneller geworden zu sein.

Die Werkzeuge haben sich seitdem bereits verändert. Die Aufgaben waren unterschiedlich, und METR hat selbst erklärt, wie schwer es ist, Zeit zu messen, wenn mehrere KI-Programme gleichzeitig arbeiten. Die Zahlen können deshalb nicht entscheiden, ob KI Entwickler immer schneller macht.

Sie zeigen etwas Interessanteres:

Mehr Code zu produzieren ist nicht zwangsläufig dasselbe wie mehr Fortschritt zu schaffen.

Wenn ein weiterer Änderungsvorschlag billig wird, verschiebt sich der langsame Teil. Er liegt dann im Verstehen, Erproben, Koordinieren und Verantworten.

Google hat neun Millionen vorgeschlagene Codeänderungen untersucht. Die Studie zeigte einen Arbeitsablauf, der auf kleinen Änderungen und schneller Rückmeldung beruhte. Bei der Prüfung ging es nicht nur darum, Fehler zu finden. Es ging auch darum, dass mehr Menschen das Programm verstanden und Wissen darüber teilten.

Das ist bemerkenswert. Schon vor den heutigen KI-Programmen war menschliches Verständnis eine knappe Ressource.

Wenn KI nun mehr und größere Änderungen gleichzeitig produzieren kann, verschwindet der Bedarf nicht. Er wächst.

In Agententeams verändern meinen Softwareprozess habe ich beschrieben, wie mehrere KI-Programme parallel untersuchen, bauen und kontrollieren können. Das ist ein echter Gewinn. Aber zehn davon können auch schneller schreiben, als ein Mensch ihre gemeinsame Arbeit verstehen kann.

Irgendwann hilft es nicht mehr, den Menschen zum schnelleren Lesen aufzufordern.

Wir müssen verändern, was der Mensch liest.

Auch eine Zusammenfassung kann verbergen

Die naheliegende Lösung ist, eine weitere KI eine kurze Zusammenfassung des Codes schreiben zu lassen.

Das ist zugleich die gefährliche Lösung.

Eine KI kann eine ruhige und überzeugende Erklärung für eine Änderung verfassen, die sie missverstanden hat. Sie kann hervorheben, was der Entwickler bauen wollte, und übersehen, was das Programm tatsächlich tut. Sie kann fünftausend geänderte Zeilen wie drei einfache Punkte erscheinen lassen.

Je leichter die Zusammenfassung zu lesen ist, desto leichter kann man vergessen, wie viel ausgelassen wurde.

GitHub selbst empfiehlt, dass KI-basierte Codeprüfung die menschliche Prüfung ergänzt und nicht ersetzt. Das Werkzeug kann Probleme übersehen, besonders bei großen und komplizierten Änderungen. Es kann auch Kritik vorschlagen, die richtig klingt, ohne richtig zu sein.

Doch dieser Rat enthält ein Paradox.

Wenn KI die Menge des Codes erhöht, kann die Antwort nicht immer lauten, der Mensch solle einfach alles mit derselben Gründlichkeit wie früher lesen. Dann haben wir die Produktion automatisiert und die Kontrolle als Handarbeit bewahrt.

Die verständliche Schicht darf deshalb nicht nur eine Zusammenfassung sein. Sie muss einen Weg hinunter zum Beleg bieten.

Die kurze Erklärung muss sich öffnen lassen und das ausführlichere Rezept zeigen. Das Rezept muss auf die Programmteile verweisen können, die es beschreibt. Wenn der Bericht sagt, eine Änderung könne die Bezahlung beeinflussen, muss er zeigen, warum. Wenn er sagt, alles funktioniere, muss er die automatischen Prüfungen und die genaue Programmversion zeigen, an der sie ausgeführt wurden.

In meinem Graphify-Experiment werden deshalb drei Dinge unterschieden:

  • Was das Programm mit Sicherheit aus der Struktur ablesen kann.
  • Was eine KI daraus geschlossen hat.
  • Was weiterhin unklar ist.

Das ist kein kleines technisches Detail. Es ist der Unterschied zwischen dem, was wir wissen, und dem, was wir vermuten.

Eine menschliche Leseschicht darf die Unsicherheit nicht verbergen. Sie muss sie sichtbar machen.

Eine Karte zum Hineinzoomen

Ich stelle mir die künftige Prüfung von Software wie eine Karte mit mehreren Zoomstufen vor.

Ganz oben steht die Absicht: Was sollte die Änderung erreichen?

Die nächste Schicht zeigt das Verhalten: Was tut das Programm vorher und nachher anders?

Darunter liegen die Verbindungen: Welche anderen Teile könnten betroffen sein?

Dann folgt das Rezept: Wie funktioniert die wichtigste Logik, erklärt ohne die vielen Einzelheiten der Programmiersprache?

Ganz unten liegen der tatsächliche Code, die automatischen Prüfungen und die Geschichte der Änderung.

Nicht jeder Mensch muss jedes Mal alle Schichten lesen. Die Korrektur eines Tippfehlers verlangt nicht dieselbe Aufmerksamkeit wie eine Änderung daran, wer auf ein Bankkonto oder eine Patientenakte zugreifen darf.

Bei einer gefährlichen Änderung muss ein Spezialist vielleicht ganz bis zum Code hinuntergehen. Eine bekannte und klar begrenzte Änderung könnte anhand des sichtbaren Verhaltens, der automatischen Prüfungen und eines klaren Weges zurück zu den Einzelheiten genehmigt werden.

Entscheidend ist nicht, dass die oberste Schicht alles enthält. Dann wäre sie so schwer wie der Code. Entscheidend ist, dass sich jede wichtige Aussage in der darunterliegenden Schicht überprüfen lässt.

Es muss eine Verkürzung mit einem Weg zurück sein.

Das kann mehr tun, als den Programmierer zu entlasten. Es kann andere Fachrichtungen in die Prüfung einbeziehen.

Ein Jurist muss nicht jedes Zeichen im Code verstehen, um zu beurteilen, ob eine Regel richtig ausgelegt wurde. Eine Ärztin kann leichter erkennen, ob ein digitaler Patientenablauf der tatsächlichen Arbeit entspricht. Ein Redakteur kann die Regeln für Veröffentlichungen beurteilen, ohne zuerst das Werkzeug zu erlernen, mit dem die Website gebaut wurde.

Heute werden viele solcher Beurteilungen durch einen Entwickler übersetzt. Die Fachperson beschreibt die Absicht. Der Entwickler liest den Code. Gemeinsam versuchen sie festzustellen, ob sie über dasselbe sprechen.

Eine gute Leseschicht kann das tatsächliche Verhalten des Programms zum Gegenstand eines direkteren Gesprächs machen.

Darin liegt die positive Möglichkeit. Höhere Programmiersprachen ermöglichten mehr Menschen, Software zu bauen. Eine höhere Sprache für die Prüfung kann mehr Menschen ermöglichen, Verantwortung für sie zu übernehmen.

Auf Digital Medarbejder habe ich geschrieben, dass menschliche Kontrolle nicht bedeutet, dass ein Mensch jeden einzelnen Schritt genehmigen muss. Kontrolle betrifft Rollen, Berechtigungen, Dokumentation, klare Haltepunkte und die Frage, wann ein Mensch übernehmen muss.

Dasselbe gilt hier.

Menschliche Kontrolle über KI-produzierte Software muss nicht bedeuten, dass ein Mensch mechanisch jede Zeile liest. Sie kann bedeuten, dass der Mensch die Absicht, die Risikobewertung und die Entscheidung darüber besitzt, wie tief er in die Einzelheiten gehen muss.

Das kann ehrlichere Kontrolle sein als ein schnelles Häkchen von jemandem, der die Änderung formal gesehen, aber nicht wirklich verstanden hat.

Was müssen Menschen weiterhin können?

Gegen den ganzen Gedanken gibt es einen starken Einwand.

Wenn Menschen aufhören, Code zu lesen, verlieren wir dann nicht die Fähigkeit zu erkennen, wann die Übersetzung falsch ist? Werden wir nicht zu Piloten, die nur noch das Armaturenbrett lesen können und den Motor nicht mehr verstehen?

Ja, dieses Risiko ist real.

Ein Fach kann ausgehöhlt werden, wenn niemand mehr die untere Schicht lernt. Wir werden weiterhin Menschen brauchen, die Code lesen und schreiben, das Innere des Computers verstehen und Fehler in den Übersetzungen entdecken können, die der Rest von uns nutzt.

Höhere Ebenen haben die unteren nie wertlos gemacht. Sie haben sie stärker spezialisiert.

Die meisten Python-Programmierer schreiben im Alltag nicht die grundlegendsten Anweisungen des Computers. Das bedeutet nicht, dass diese Anweisungen nicht mehr existieren oder dass niemand sie verstehen muss. Es bedeutet, dass das Verständnis anders verteilt wurde.

Dasselbe kann mit der Prüfung von Software geschehen.

Einige Menschen werden ganz bis zum Code hinuntergehen. Mehr Menschen werden das Programm über sein Verhalten, die automatischen Prüfungen, die Verbindungen zu anderen Teilen und überprüfbare Erklärungen kontrollieren.

Die wichtige Aufgabe wird darin bestehen, zu entscheiden, wann die oberste Schicht genügt und wann das Risiko verlangt, tiefer hinunterzugehen.

Das ist keine Frage, die Technologie allein beantworten kann. Es ist eine Frage der Verantwortung.

Eine KI kann vorschlagen, dass eine Änderung klein ist. Sie kann die Folgen nicht übernehmen, wenn diese Einschätzung falsch ist. Eine automatische Prüfung kann zeigen, dass die bekannten Situationen funktionieren. Sie kann nicht entscheiden, ob wir das Richtige geprüft haben. Ein einfaches Rezept kann die Logik erklären. Es kann nicht allein entscheiden, ob diese Logik überhaupt existieren sollte.

Die wichtigste Sprache des Menschen ist deshalb vielleicht nicht Code, sondern Zweck.

Was versuchen wir zu erreichen? Welches Verhalten akzeptieren wir? Wer könnte betroffen sein? Mit welcher Unsicherheit können wir leben? Wann muss die Maschine anhalten?

Diese Fragen standen schon immer hinter guter Software. KI macht es nur schwerer, sie zwischen den Zeilen zu verstecken.

Die nächste Schicht

Wir haben ungefähr 70 Jahre damit verbracht, die Programmierung von der eigenen Sprache der Maschine wegzuheben.

Jede neue Schicht ermöglichte Menschen, mehr auszudrücken, ohne alle Einzelheiten darunter zu beschreiben. Sie brachte uns mehr Software, komplexere Systeme und mehr Menschen, die daran mitbauen konnten.

Nun beginnt die Maschine selbst, in den Sprachen zu schreiben, die wir für Menschen geschaffen haben.

Das bedeutet nicht, dass die Entwicklung abgeschlossen ist. Es bedeutet, dass wir eine weitere Schicht brauchen — diesmal in der Gegenrichtung.

Wir brauchen eine Sprache, in der die Maschine ihre Arbeit in einer für Menschen verständlichen Form zeigen kann. Eine Sprache für Absicht, Verhalten, Verbindungen, Risiko und Belege. Der rezeptartige Pseudocode kann ein Teil davon sein. Übersichten, automatische Prüfungen und durchgespielte Beispiele können weitere Teile sein.

Der Quellcode verschwindet nicht. Aber er muss vielleicht nicht mehr die Eingangstür sein, durch die jeder Mensch gehen muss, um Kontrolle auszuüben.

Als wir höhere Programmiersprachen erfanden, akzeptierten wir, dass Menschen nicht wie Maschinen denken müssen, um Maschinen arbeiten zu lassen.

Nun sollten wir die umgekehrte Forderung stellen.

Menschen sollten nicht lernen müssen, mit der Geschwindigkeit einer Maschine zu lesen, um die Arbeit der Maschine kontrollieren zu können.

Die Maschine muss lernen, sich in menschlicher Sprache zu erklären — und die Belege vorzulegen.

Quellen und weiterführende Lektüre