Wenn AI mehr Code schreibt – warum wir ihn weiterhin verstehen müssen

Ich habe mit AI ein Produkt entwickelt, das Menschen hilft, Code zu verstehen.

Doch etwas Interessantes geschah: Je komplexer das Produkt wurde, desto weniger verstand ich selbst davon.

Ich begann etwa im Juli 2025 mit FiboCode. Vibe Coding gewann an Fahrt, und überall ging es darum, mit AI Code zu schreiben und die Kosten der Softwareentwicklung zu senken. Ein Gedanke lag nahe:

Wenn AI Menschen beim Schreiben von Code helfen kann, könnte sie ihnen dann auch beim Verstehen helfen?

Die Kosten des Schreibens sinken weiter, aber ein unbekanntes Projekt zu verstehen bleibt mühsam. Das gilt besonders für jahrelang gewachsene Codebasen mit komplexer Verzeichnisstruktur, Modulabhängigkeiten, historischen Entwurfsentscheidungen und zahlreichen Konventionen. Oft dauert es schon lange, nur den richtigen Einstieg zu finden.

FiboCode begann mit dieser einfachen Idee: AI sollte Code analysieren und passende Dokumente und Beziehungsdiagramme erzeugen; anschließend sollte man zwischen Code, Dokumenten und Diagrammen springen können.

Damals war es nur ein Werkzeug zur Codeanalyse.

Später fügte ich einen einfachen Agent hinzu, damit Fragen zum Code leichter wurden. Für ein besseres Leseerlebnis integrierte ich Monaco Editor. Mit einem Editor schienen auch Codenavigation, Symbolreferenzen und Sprachdiagnosen nötig, also kam LSP-Unterstützung hinzu.

Nachdem Lesen möglich war, war Bearbeiten der natürliche nächste Schritt.

Als FiboCode Code ändern konnte, überlegte ich, wie der Agent ein Projekt wirklich verstehen könnte, statt es anhand weniger geöffneter Dateien zu beurteilen. Nach und nach ergänzte ich MCP und Skills, damit die AI auch auf Entwurfskonventionen, Architekturkontext und Geschichte des Projekts zugreifen konnte.

Dann erkannte ich, dass viele Entwickler bereits mit Agent CLI wie Claude und Codex vertraut waren. Sie brauchten vielleicht keinen weiteren eingebauten Agent, sondern eher eine Oberfläche, die für die Prüfung seiner Arbeitsergebnisse entworfen war.

Deshalb erhielt FiboCode ein Terminal und gezielte Verbesserungen für die Ausgaben von Agent CLI. Dateiverweise, Codeänderungen und Ausführungsschritte im Terminal konnten nun mit Code, Dokumenten und Beziehungsdiagrammen verbunden werden.

So wuchs ein einfaches Analysemodul Stück für Stück zu einem immer komplexeren System.

Ich begann, mein eigenes Projekt zu vergessen

AI-gestützte Programmierung ist wirklich bequem.

Obwohl frühe Modelle weniger leistungsfähig waren, prüfte ich ihren Code sorgfältig und oft mehrfach. Ich betrachtete die Aufteilung der Module, den Datenfluss und die Gründe für den Architekturentwurf.

Das Projekt wurde während der Entwicklung oft refaktoriert, teils sehr umfangreich. Weil ich die Entwurfsdetails damals kannte, beschädigte keine dieser Änderungen das Projekt dauerhaft.

Dann wurden die Modelle leistungsfähiger, die Codegenerierung schneller und die Codebasis wuchs rasant.

Allmählich bemerkte ich, dass ich mich nicht mehr an Entwurfsdetails von Code erinnerte, den ich erst ein oder zwei Wochen zuvor geprüft hatte.

Zuerst machte mir das etwas Angst.

Es war mein eigenes Projekt. Jede Funktion stammte von mir, doch ich wusste nicht mehr, warum jedes Modul so entworfen war und wie jede Logik funktionierte.

Mit der Zeit erkannte ich, dass ich das vielleicht einfach akzeptieren musste.

Es war nicht mehr das kleine Projekt vom Anfang. In einem ausreichend komplexen System kann niemand jedes Implementierungsdetail behalten. Entscheidend ist vielleicht nicht, jede Zeile im Kopf zu haben, sondern zu wissen, wo der Kern liegt, wie Module zusammenarbeiten, welche Teile sicher der AI überlassen werden können und welche sorgfältig verstanden werden müssen.

Ich musste lernen auszuwählen.

Ich musste in der Masse des Codes die kritischen Pfade finden, ein grobes mentales Bild des Systems aufbauen und der AI präzisere Anforderungen und Grenzen geben.

Aus dieser Sicht half FiboCode mir auch dabei, FiboCode zu bauen.

Ich entwickelte das Produkt mit AI; es wurde immer nützlicher und half mir wiederum, sich selbst schneller zu verstehen und weiterzuentwickeln. Dieser positive Kreislauf war aufregend und ein wichtiger Grund, so lange daran zu arbeiten.

Doch neben der Begeisterung fragte ich mich oft:

Was blieb mir in diesem Entwicklungsprozess noch?

Als ich immer mehr Denken an die AI abgab

Über lange Zeit entwickelte ich schrittweise eine Gewohnheit.

Gab es eine Anforderung, gab ich sie zuerst der AI.

Gab es ein Problem, ließ ich zuerst die AI untersuchen.

Nach ihrem Lösungsvorschlag prüfte ich. Schlug die Prüfung fehl, gab ich das Ergebnis zurück und bat erneut um Analyse und Korrektur.

Manchmal verging ein ganzer Tag damit, Anforderungen zu beschreiben, den Stand eines Fehlers zu erklären und Testergebnisse zurückzugeben.

Es schien, als erledige die AI fast alle schwierige Denkarbeit, während meine Rolle auf das Definieren von Anforderungen und Zurückgeben von Ergebnissen schrumpfte.

In dieser Zeit hatte ich ein starkes Gefühl:

Es schien, als hätte ich kaum noch einen Wert.

Doch als ich weitermachte, stellte ich fest, dass das nicht ganz stimmte.

Bei der Entwicklung mit AI begegnete ich vielen Technologien, die ich früher nicht gewählt hätte, und zahlreichen Implementierungsansätzen. Ich begann bewusst, Entwurf und Architektur vor der konkreten Umsetzung zu betrachten.

Bei manchen Aufgaben sah ich sofort, dass der Umfang klein war und die AI sie direkt erledigen konnte.

Sobald eine Aufgabe jedoch mehrere Module berührte oder die Kernstruktur beeinflusste, wusste ich, dass sie nicht so einfach war. Die AI sah vielleicht nur die aktuelle Anforderung, verstand aber nicht den Grund für einen historischen Entwurf oder indirekte Auswirkungen.

Es gab auch Code, den ich fast vollständig verstehen musste, selbst wenn die AI ihn schreiben konnte, weil Fehler dort schwer kontrollierbare Folgen hätten.

Ich bestand nicht mehr darauf, jedes Detail zu verstehen, wurde aber empfindlicher für Grenzen, Abhängigkeiten, Risiken und Veränderungen des Systems.

Vielleicht ist menschliche Arbeit nicht verschwunden. Sie verändert sich nur.

Früher verstanden wir ein System, indem wir seinen Code selbst implementierten.

Künftig investieren wir vielleicht weniger in wiederholende Umsetzung und mehr in Architektur, Prozesse, Einschränkungen, Prüfung und langfristige Entwicklung.

Nur weil AI es schreiben kann, können wir ihm noch nicht vertrauen

Ich weiß nicht, ob AI menschliche Fachleute wirklich ersetzen und künftig alle Programmierarbeit übernehmen kann.

Das ist sicher eine technische Frage, aber meiner Ansicht nach auch eine Frage des Vertrauens.

Selbst wenn AI eines Tages allein ein hochkomplexes System erzeugt, werden wir ihm nicht zwangsläufig vorbehaltlos vertrauen.

Wenn sich das System unerwartet verhält, wissen wir warum?

Können wir den Fehler finden?

Können wir die Korrektur verifizieren?

Kann jemand anderes übernehmen?

Wer trägt die Verantwortung, wenn das System schweren Schaden verursacht?

Diese Fragen lassen sich nicht vollständig lösen, indem man die Modellgenauigkeit von 99 % auf 99,9 % steigert.

Bei risikoarmen, leicht ersetzbaren Anwendungen können wir mehr Blackbox akzeptieren. Wenn die Funktion arbeitet und die Entwicklung schnell genug ist, müssen wir vielleicht nicht jedes Detail kennen.

Bei grundlegender Software wie Betriebssystemen und Datenbanken oder Systemen in Finanzen, Stromversorgung und anderen gesellschaftlich wichtigen Bereichen ist eine nicht verstehbare, nicht prüfbare und nicht übernehmbare Blackbox jedoch schwer akzeptabel.

Diese Systeme brauchen weiterhin Menschen für ihre Wartung.

Sie müssen nicht jede Zeile selbst schreiben, aber jemand muss grob wissen, wie das System arbeitet, wo die kritischen Risiken liegen und wo eine Untersuchung bei Problemen beginnen sollte.

Deshalb glaube ich zunehmend, dass Codeverständnis mit dem Aufstieg der AI-Programmierung nicht verschwinden wird.

Es nimmt nur eine andere Form an.

Früher mussten wir Code verstehen, um ihn zu schreiben.

Künftig müssen wir ihn vielleicht verstehen, um von AI geschaffene Systeme zu prüfen, zu warten, zu übernehmen und weiterzuentwickeln.

Die Einstiegsaufgaben, die verschwinden

Codeverständnis hat noch eine weitere Bedeutung.

AI verringert manche Einstiegsrollen mit wiederholender Umsetzung und einfachen Aufgaben. Selbst wenn die Stellen bleiben, wird viel Arbeit, die früher Neulinge erhielten, zuerst durch AI automatisiert.

Das ist nicht freundlich gegenüber Einsteigern.

Der traditionelle Entwicklungsweg eines Ingenieurs beginnt mit einfachen Aufgaben: einen Fehler beheben, einen kleinen Codeabschnitt lesen, eine kleine Funktion fertigstellen und schrittweise an komplexeren Modulen und Systementwürfen teilnehmen.

Durch diese scheinbar unwichtigen Aufgaben bauen Neulinge nach und nach ihr Verständnis echter Projekte auf.

Nun kann AI diese grundlegenden Aufgaben direkt erledigen.

Wenn weniger Einstiege für die Ausbildung bleiben, woher kommen die erfahrenen Ingenieure der Zukunft?

Das war ein weiterer Grund für FiboCode.

Auch ich bin neu im Beruf. Als ich erstmals einer komplexen Legacy-Codebasis gegenüberstand, war ich oft völlig ratlos.

Es gab so viele Dateien und Verzeichnisse. Dienste riefen einander auf, Typen, Schnittstellen und Konfiguration waren verstreut. Man wusste, die Antwort musste im Code liegen, aber nicht, wo man anfangen, was wichtig oder was nur ein Detail war.

Die eigentliche Schwierigkeit war oft nicht eine bestimmte Zeile, sondern das Fehlen einer vollständigen Karte.

Ich wollte immer ein Werkzeug, das zunächst die Struktur des gesamten Projekts analysiert und zeigt, wo Kernmodule liegen, wie der Code verbunden ist und welche Bereiche eine Änderung betreffen könnte.

Dann müssten Neulinge nicht völlig von schrittweiser Anleitung abhängen und sich nicht immer wieder durch unbekannte Codebasen tasten.

Ein solches Werkzeug ersetzt den Wachstumsprozess nicht, senkt aber die Hürde für den Einstieg in ein komplexes System.

Während AI den alten Lernweg allmählich abschneidet, hoffe ich, dass FiboCode einen neuen Weg verbinden kann.

Nicht unbedingt eine Abkürzung über alle Grundlagen hinweg, sondern eher eine Karte, ein Navigationssystem und ein Pfad, der Neulingen schneller ein mentales Modell ermöglicht.

Code zeichnet nur die Gegenwart auf

Während der Entwicklung entdeckte ich ein weiteres Problem.

Eine Aufgabe direkt an die AI zu geben und sie allein das Repository erkunden zu lassen, kann zu unvollständigem Denken führen.

Die AI sieht den aktuellen Code, kennt aber möglicherweise nicht die Gründe eines Modulentwurfs oder indirekte Verbindungen zu scheinbar unabhängigen Dateien.

Code zeigt meist, wie ein System heute aussieht, erklärt aber nur schwer, warum es so wurde.

Zunächst erwog ich, all diese Informationen in Codekommentare zu schreiben.

Später entschied ich, dass das nicht passte.

Viel Entwurfskontext, historische Begründungen und Änderungserklärungen würden Dateien aufblähen und der AI viel für die aktuelle Aufgabe irrelevanten Kontext geben. Kommentare erklären lokale Logik gut, tragen aber nicht leicht die gesamte Entwicklung eines Projekts.

Deshalb entwarf ich eine Reihe von Fibo Skills.

Sie zeichnen Konventionen, Entwürfe, Implementierungsabläufe und Diff-Erklärungen auf und hinterlassen eine vollständigere Spur jeder Codeänderung.

Wenn AI künftig Code ändert, soll sie nicht nur den aktuellen Zustand sehen, sondern verstehen, was früher geschah und warum bestimmte Entwürfe erhalten blieben.

Wenn die Entwicklungsgeschichte nachvollziehbar wird, kann AI das Projekt vollständiger verstehen.

Das wurde auch eine Richtung, in die sich FiboCode entwickelte:

Ursprünglich half es Menschen, Code zu verstehen. Später begann es auch, AI beim besseren Verständnis zu helfen.

Wie FiboCode zu dem wurde, was es ist

Rückblickend wurde FiboCode nicht von Anfang an für seine heutige Form entworfen.

Es begann als einfaches Analysemodul. Später kamen Dokumente und Beziehungsdiagramme, ein Agent, ein Editor und Sprachdienste hinzu. Allmählich folgten Codebearbeitung, Terminal, MCP und Skills.

Ich wollte Agent CLI eine Cursor-ähnliche Codeprüfung geben und zugleich Dokumente und Beziehungsinformationen aus der Analyse in tatsächlich nutzbaren AI-Kontext verwandeln.

Es entwickelte sich vom einfachen Modul zum komplexen System, und dieses ständige Wachstum spiegelte leise die Ausbreitung der Fibonacci-Folge wider.

Daher stammen auch der Name FiboCode und das Bild der Schnecke.

Das Schneckenhaus trägt die mathematische Schönheit der goldenen Spirale.

Es bewegt sich nicht sehr schnell, wächst aber stetig vorwärts.

FiboCode will weder Menschen wieder jede Zeile von Hand schreiben lassen noch AI ausschließen.

Im Gegenteil. Es akzeptiert, dass AI immer mehr Code schreibt, und möchte Menschen auf dieser Grundlage helfen, ihre Systeme weiter zu verstehen, zu prüfen, zu warten und zu übernehmen.

In einer Zeit, in der alle schnellere Erzeugung verfolgen, hoffe ich weiterhin, dass wir gelegentlich langsamer werden können.

Um zu verstehen, warum Code so läuft und warum ein System zu dem wurde, was es heute ist.

Und um die Freude wiederzuentdecken, die uns zuerst zur Programmierung führte.