Was würde ein Entwicklungsteam retten, wenn das Gebäude brennt? 70 Jahre lang lautete die Antwort: den Quellcode. Ihn zu verlieren hieß, die angesammelten Entscheidungen eines Unternehmens zu verlieren, also die tausend kleinen Urteile, die ein System zu seinem Geschäft passend machen. Diese Antwort ändert sich gerade, und zwar leise. Sobald Agenten aus einer präzisen Aussage darüber, was das System leisten muss, eine funktionierende Implementierung neu erzeugen können, ist nicht mehr der Code das Kronjuwel, sondern die Aussage. Die Praxis, die daraus folgt, wenn man das ernst nimmt, nennen wir Intent-Driven Development: die Disziplin, nicht den Code, sondern den Intent zu dem Artefakt zu machen, das Ihr Team schreibt, reviewt, versioniert und besitzt.
Die Behauptung im Titel braucht sofort eine Einschränkung. „Das Schreiben von Code wird optional“ heißt nicht, dass niemand mehr Code liest, dass generierter Code keine Rolle spielt oder dass Engineering-Können überflüssig wäre. Gemeint ist etwas Engeres und Interessanteres: Für eine wachsende Klasse von Arbeit ist das Tippen der Implementierung von Hand inzwischen eine Wahl und keine Notwendigkeit mehr. Teams sollten deshalb bewusst entscheiden, wo sie diese Wahl noch treffen, statt sie aus Gewohnheit überall zu treffen.
Intent ist kein Bauchgefühl
Das Wort „Intent“ lädt zum Missbrauch ein, weil es nach etwas klingt, das sich mit einem Leitbild und einem Moodboard erledigen ließe. In der Praxis ist ein Intent, der Entwicklung tragen kann, eine Menge überprüfbarer Aussagen über Verhalten, an denen eine Maschine oder eine Kollegin ein System messen und mit Bestanden oder Durchgefallen antworten kann. „Kunden sollen einen reibungslosen Checkout haben“ ist eine Stimmung. „Ein wiederkehrender Kunde schließt den Checkout in drei Schritten ab; eine fehlgeschlagene Zahlung erhält den Warenkorb und erklärt den Fehler in der Sprache des Kunden; eine doppelte Belastung ist auch dann unmöglich, wenn der Bestätigen-Button zweimal geklickt wird“ ist ein Intent. Der Unterschied heißt Prüfbarkeit, und er ist der ganze Unterschied.
Ein Intent liegt in drei Schichten. Ganz oben steht der Produkt-Intent: welches Ergebnis das System erzeugen soll, für wen und gemessen woran. Darunter stehen die Systeminvarianten, also die Eigenschaften, die unabhängig von der Implementierung gelten müssen: Geld bleibt erhalten, Audit-Trails wachsen nur an, personenbezogene Daten bleiben innerhalb der Grenze, Löschungen sind wiederherstellbar. Ganz unten stehen Abnahmetests und Evals als die ausführbare Form, also die Schicht, die eine Pipeline tatsächlich laufen lassen kann. Jede Schicht begründet die darunter, und jede darunter macht die darüber prüfbar. Ein Team, das alle drei pflegt, kann die Implementierung an einen Agenten übergeben, wie ein Bauherr die Ausführung an einen Generalunternehmer übergibt: nach Zeichnungen, nicht nach Adjektiven.
Das ist ein naher Verwandter der Praxis, Verträge für KI-Agenten zu schreiben. Spec-Driven Development greift auf Ebene der einzelnen Aufgabe: ein Stück Arbeit, ein Vertrag, eine Verifikationsschleife. Intent-Driven Development beschreibt, was aus einer Codebasis wird, wenn sich diese Disziplin summiert, wenn also die angesammelten Verträge, Invarianten und Evals zur eigentlichen Beschreibung des Systems werden und jede konkrete Implementierung nur deren aktuelle Kompilierung ist.
Code als Build-Produkt
Die praktische Folge ist eine Verschiebung dessen, was „die Quelle“ bedeutet. In einer kompilierten Sprache patcht niemand das Binary, sondern man ändert den Quellcode und kompiliert neu. Intent-getriebene Teams behandeln Implementierungscode genauso: Muss sich Verhalten ändern, landet die erste Änderung in der Intent-Schicht, sei es ein neuer Abnahmetest, eine geänderte Invariante oder eine geschärfte Produktaussage, und die Implementierung wird daraufhin neu erzeugt oder überarbeitet. Der Code bleibt lesbar, reviewt und tragend. Was sich ändert, ist sein Status: Er ist abgeleitet, und gestritten wird über das, wovon er abgeleitet ist.
Das Review verlagert entsprechend sein Ziel. 3.000 generierte Zeilen in Lesegeschwindigkeit zu prüfen ist Theater, weil der Reviewer etwas genehmigt, das er gar nicht im Kopf behalten kann. Das Intent-Diff zu prüfen ist dagegen machbar: Welches neue Verhalten wurde versprochen, welche Invarianten wurden berührt, nageln die neuen Tests das Versprechen wirklich fest, und steht im Implementierungs-Diff etwas, das der Intent nicht erklärt? Die Aufmerksamkeit der Senior-Entwickler rückt damit eine Ebene nach oben, von „ist diese Schleife korrekt“ zu „ist das das richtige Versprechen, und wird es durchgesetzt“. Das ist keine Degradierung des Engineering-Urteils, sondern Engineering-Urteil an der Stelle, an der es sich heute am meisten auszahlt.
Der Code ist abgeleitet, die Quelle ist der Intent. Wer über die Quelle streitet, liefert schneller als wer über die Kompilierung streitet.
Wo handgeschriebener Code überlegen bleibt
Ehrlichkeit über die Grenze bewahrt das Ganze davor, zur Ideologie zu werden. Mancher Code sollte weiterhin von Hand geschrieben werden, und die Kategorien wiederholen sich. Da ist der heiße Kern aus Pricing-Engine, Matching-Algorithmus und Risikomodell, wo jeder Zweig eine Geschäftsentscheidung verkörpert und das Verständnis des Teams für diesen Code selbst ein Vermögenswert ist. Da ist neuartige algorithmische Arbeit, bei der sich der Intent nicht präziser formulieren lässt als die Implementierung, weil das Finden der Implementierung die eigentliche Arbeit ist. Da sind sicherheitskritische Grenzen wie Authentifizierung, Kryptografie und Zahlungsauslösung, wo Review-Tiefe schwerer wiegt als Liefergeschwindigkeit und auf jeder Zeile die Fingerabdrücke eines Menschen liegen sollen. Und da ist die Intent-Schicht selbst: Tests, Invarianten, Evals und Schemas verdienen menschliche Autorschaft, gerade weil alles andere an ihnen gemessen wird.
Die nützliche Frage für ein konkretes Stück Arbeit lautet nicht „kann ein Agent das schreiben?“, denn zunehmend kann er es. Sie lautet: „Was verlieren wir, wenn es kein Mensch schreibt?“ Wo die Antwort „nichts, solange der Intent durchgesetzt wird“ heißt, ist Generierung der vernünftige Standard. Wo die Antwort „unser Verständnis der Sache, mit der wir Geld verdienen“ heißt, tippen Sie selbst.
Wie die Intent-Schicht verfällt
Intent-Verfall ist der erste Fehlermodus. Die Intent-Schicht bleibt nur so lange die Quelle der Wahrheit, wie sie wie Quellcode gepflegt wird. Sobald ein Team anfängt, Verhalten direkt zu patchen, hier ein Hotfix und dort eine schnelle manuelle Änderung, ohne die Änderung zurück in Tests und Invarianten zu tragen, beschreibt der Intent ein System, das so nicht mehr existiert. Die nächste Regenerierung, treu aus veraltetem Intent kompiliert, löscht dann genau die undokumentierten Fixes. Die Regel, die das verhindert, ist dieselbe, die Schemas ehrlich hält: Verhaltensänderungen landen zuerst als Intent-Änderungen, im selben Pull Request - oder sie landen gar nicht.
Regenerieren ohne erneutes Verifizieren ist der zweite. Regenerierung ist nicht idempotent: Zwei Läufe auf demselben Intent erzeugen unterschiedlichen Code mit unterschiedlichem Nebenverhalten, und alles, was die Intent-Schicht nicht festnagelt, darf sich frei ändern. Teuer wird es für Teams, die annehmen, die grüne Pipeline von gestern bürge für die Regenerierung von heute. Das tut sie nicht. Jede Regenerierung ist eine neue Implementierung und verlangt jedes Mal den vollen Verifikationsdurchlauf aus Tests, Evals und Invariantenprüfungen. Ist das pro Regenerierung zu teuer, machen Sie die Verifikation billiger und nicht seltener.
Generierten Code als Wegwerfware zu behandeln, obwohl er tragend ist, ist der dritte und subtilste Fehlermodus. Ein Team verinnerlicht, dass der Code nur ein Build-Produkt sei, und hört ganz auf, ihn zu lesen: kein Review, kein Profiling, keine operative Vertrautheit. Dann kommt der Incident um 2 Uhr nachts, und die Rufbereitschaft debuggt ein System, das nie jemand gelesen hat, geleitet allein von dem Intent, den es erfüllen sollte. Abgeleitet heißt nicht ignorierbar. Produktionscode verlangt operative Verantwortung, gleich wer ihn getippt hat; die Intent-Schicht sagt Ihnen, was das System tun soll, doch die Störungsbehebung findet in dem statt, was es tatsächlich tut. Teams, die das gut handhaben, benennen für jede generierte Komponente einen Verantwortlichen wie für eine handgeschriebene: jemanden, der sie gelesen und profiliert hat und sich unter Druck durch sie hindurcharbeiten kann.
Ein pragmatischer Einführungspfad
Nichts davon verlangt eine Revolution, und Teams, die eine versuchen, produzieren meist ein Manifest und keine Veränderung. Der Weg, der funktioniert, ist inkrementell. Machen Sie zuerst den Intent für das System explizit, das Sie bereits betreiben: Schreiben Sie die Invarianten auf, von denen Sie glauben, dass sie gelten, überführen Sie das Wissen, das nur in Köpfen steht, in Abnahmetests, und werden Sie ehrlich dort, wo Tests und System sich widersprechen. Dieser Schritt zahlt sich selbst dann aus, wenn nie ein Agent die Codebasis anfasst, denn er liefert schlicht die Dokumentation und die Testabdeckung, die Sie sich ohnehin schuldig waren.
Wählen Sie danach eine abgegrenzte, gut verstandene Komponente und fahren Sie die volle Schleife einmal durch: Intent geschrieben und reviewt, Implementierung daraufhin generiert, Verifikation mechanisch, menschliches Review auf das Intent-Diff gerichtet. Messen Sie ehrlich, also Durchlaufzeit, Fehlerrate und Review-Aufwand im Vergleich zur handgeschriebenen Basislinie. Weiten Sie die Schleife dort aus, wo sie sich auszahlt, und tippen Sie weiter, wo sie es nicht tut. Innerhalb weniger Quartale sortiert sich die Codebasis in einen handgeschriebenen Kern mit generierter Peripherie, und die knappe Senior-Aufmerksamkeit des Teams sammelt sich auf der Ebene, auf der sie sich verzinst: präzise und prüfbar zu entscheiden, was die Software leisten muss.
Die Branche stand schon einmal an diesem Punkt. Niemand trauert dem handgeschriebenen Assembler nach; wir haben die Fähigkeit behalten und die Gewohnheit abgelegt, weil eine höhere Quellebene plus ein vertrauenswürdiger Compiler schlicht das bessere Geschäft war. Intent plus Agenten plus Verifikation formt sich gerade zum selben Geschäft, eine Ebene höher. Code zu schreiben wird optional. Genau zu wissen, was der Code leisten muss, und beweisen zu können, dass er es tut, wird zur eigentlichen Arbeit.