Fragen Sie ein Team, was es greifen würde, wenn das Gebäude brennt — siebzig Jahre lang lautete die Antwort: den Quellcode. Ihn zu verlieren hieß, die angesammelten Entscheidungen des Unternehmens zu verlieren, die tausend kleinen Urteile, die ein System zu seinem Geschäft passend machen. Diese Antwort ändert sich gerade leise. Wenn Agenten aus einer präzisen Aussage darüber, was das System tun muss, eine funktionierende Implementierung neu generieren können, ist der Code nicht mehr das Kronjuwel. Die Aussage ist es. Die Praxis, die daraus folgt, wenn man das ernst nimmt, nennen wir Intent-Driven Development: die Disziplin, den Intent — nicht den Code — 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 obsolet wäre. Es heißt 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 — und Teams sollten 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. Es klingt nach etwas, das sich mit einem Leitbild und einem Moodboard erfüllen ließe. In der Praxis ist Intent, der Entwicklung tragen kann, eine Menge verifizierbarer Aussagen über Verhalten — Aussagen, gegen die eine Maschine oder eine Kollegin ein System prüfen und mit Bestanden oder Durchgefallen antworten kann. „Kunden sollen einen reibungslosen Checkout haben“ ist ein Gefühl. „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 selbst dann unmöglich, wenn der Bestätigen-Button zweimal geklickt wird“ ist Intent. Der Unterschied ist Prüfbarkeit, und er ist der ganze Unterschied.
Intent schichtet sich in drei Ebenen. Ganz oben sitzt der Produkt-Intent: welches Ergebnis das System erzeugen soll, für wen, gemessen woran. Darunter leben die Systeminvarianten: 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 sitzen Abnahmetests und Evals: die ausführbare Form, die Ebene, die eine Pipeline tatsächlich laufen lassen kann. Jede Ebene rechtfertigt die darunter; jede darunter macht die darüber prüfbar. Ein Team, das alle drei pflegt, kann die Implementierung an einen Agenten übergeben, wie ein Bauherr den Bau an einen Generalunternehmer übergibt — gegen Zeichnungen, nicht gegen Adjektive.
Wenn das wie ein naher Verwandter der Praxis klingt, Verträge für KI-Agenten zu schreiben — das ist es. Spec-Driven Development ist die Disziplin pro Aufgabe: ein Stück Arbeit, ein Vertrag, eine Verifikationsschleife. Intent-Driven Development ist das, was aus der Codebasis wird, wenn diese Disziplin sich aufzinst — wenn 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 Konsequenz ist eine Verschiebung dessen, was „die Quelle“ bedeutet. In einer kompilierten Sprache patcht niemand das Binary; man ändert den Quellcode und baut neu. Intent-getriebene Teams beginnen, Implementierungscode genauso zu behandeln: Wenn sich Verhalten ändern muss, landet die erste Änderung in der Intent-Schicht — ein neuer Abnahmetest, eine geänderte Invariante, eine geschärfte Produktaussage — und die Implementierung wird neu generiert oder überarbeitet, bis sie sie erfüllt. Der Code bleibt lesbar, reviewt und tragend. Was sich ändert, ist sein Status: Er ist abgeleitet, und das, wovon er abgeleitet ist, ist das, worüber Sie streiten.
Das Review verlagert entsprechend sein Ziel. Dreitausend generierte Zeilen in Lesegeschwindigkeit zu reviewen ist Theater; der Reviewer genehmigt etwas, das er gar nicht im Kopf halten kann. Das Intent-Diff zu reviewen ist machbar: Welches neue Verhalten wurde versprochen, welche Invarianten wurden berührt, nageln die neuen Tests das Versprechen wirklich fest, und geht irgendetwas im Implementierungs-Diff über das hinaus, was der Intent erklärt? Die Aufmerksamkeit der Senior Engineers rückt 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. Es ist Engineering-Urteil, angewandt dort, wo es sich jetzt am meisten auszahlt.
Der Code ist abgeleitet. Der Intent ist die Quelle. Teams, die über die Quelle streiten, liefern schneller als Teams, die über die Kompilierung streiten.
Wo handgeschriebener Code weiterhin gewinnt
Ehrlichkeit über die Grenze bewahrt das Ganze davor, Ideologie zu werden. Mancher Code sollte weiterhin von Hand geschrieben werden, und die Kategorien sind konsistent. Der heiße Kern — die Pricing-Engine, der Matching-Algorithmus, das Risikomodell — wo jeder Zweig eine Geschäftsentscheidung verkörpert und das Verständnis des Teams für den Code selbst ein Vermögenswert ist. Neuartige algorithmische Arbeit, bei der sich der Intent nicht präziser formulieren lässt als die Implementierung, weil das Entdecken der Implementierung die eigentliche Arbeit ist. Sicherheitskritische Grenzen — Authentifizierung, Kryptografie, Zahlungsauslösung — wo Review-Tiefe mehr zählt als Produktionsgeschwindigkeit und man auf jeder Zeile die Fingerabdrücke eines Menschen haben will. Und die Intent-Schicht selbst: Tests, Invarianten, Evals und Schemas verdienen menschliche Autorschaft, gerade weil alles andere gegen sie geprüft wird.
Die nützliche Frage für ein konkretes Stück Arbeit ist nicht „kann ein Agent das schreiben?“ — zunehmend kann er es —, sondern „was verlieren wir, wenn kein Mensch es schreibt?“. Wo die Antwort „nichts, solange der Intent durchgesetzt wird“ lautet, ist Generierung der rationale Standard. Wo die Antwort „unser Verständnis der Sache, mit der wir Geld verdienen“ lautet, tippen Sie selbst.
Wie es verrottet
Intent-Fäulnis ist der erste Fehlermodus. Die Intent-Schicht ist nur so lange die Quelle der Wahrheit, wie sie wie Quellcode gepflegt wird. In dem Moment, in dem ein Team beginnt, Verhalten direkt zu patchen — hier ein Hotfix, dort eine schnelle manuelle Änderung —, ohne die Änderung zurück in Tests und Invarianten zu propagieren, beginnt der Intent ein System zu beschreiben, das nicht mehr existiert. Die nächste Regenerierung, treu aus veraltetem Intent kompiliert, löscht dann 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 gegen denselben Intent erzeugen unterschiedlichen Code mit unterschiedlichem beiläufigem Verhalten, und alles, was die Intent-Schicht nicht festnagelt, darf sich frei ändern. Teams verbrennen sich, wenn sie annehmen, die grüne Pipeline von gestern bürge für die Regenerierung von heute. Tut sie nicht. Jede Regenerierung ist eine neue Implementierung und verdient den vollen Verifikationsdurchlauf — Tests, Evals, Invariantenprüfungen — jedes Mal. Ist das pro Regenerierung zu teuer, lautet die Lösung, die Verifikation billiger zu machen, nicht seltener.
Generierten Code als Wegwerfware zu behandeln, obwohl er tragend ist, ist der dritte und subtilste. Ein Team verinnerlicht „der Code ist nur ein Build-Produkt“ und hört ganz auf, ihn zu lesen — kein Review, kein Profiling, keine operative Vertrautheit. Dann kommt ein Incident um zwei Uhr nachts, und die Menschen in der Rufbereitschaft debuggen ein System, das nie jemand gelesen hat, geleitet allein vom Intent, den es erfüllen sollte. Abgeleitet heißt nicht ignorierbar. Produktionscode verlangt operative Verantwortung, egal wer ihn getippt hat; die Intent-Schicht sagt Ihnen, was das System tun soll, aber Incident Response findet weiterhin in dem statt, was es tatsächlich tut. Teams, die das gut handhaben, benennen für jede generierte Komponente einen Verantwortlichen, genau wie für eine handgeschriebene — jemanden, der sie gelesen hat, profiliert hat und sich unter Druck durch sie hindurcharbeiten kann.
Ein pragmatischer Einführungspfad
Nichts davon erfordert eine Revolution, und Teams, die eine versuchen, produzieren meist ein Manifest und keine Veränderung. Der funktionierende Pfad ist inkrementell. Beginnen Sie damit, den Intent für das System explizit zu machen, das Sie bereits haben: Schreiben Sie die Invarianten auf, von denen Sie glauben, dass sie gelten, verwandeln Sie das Stammeswissen in Abnahmetests, und werden Sie ehrlich darüber, wo Tests und System sich widersprechen. Dieser Schritt zahlt sich selbst dann aus, wenn nie ein Agent die Codebasis berührt — es ist schlicht die Dokumentation und Testabdeckung, die Sie sich ohnehin schuldig waren.
Wählen Sie dann eine abgegrenzte, gut verstandene Komponente und fahren Sie die volle Schleife darauf: Intent geschrieben und reviewt, Implementierung dagegen generiert, Verifikation mechanisch, menschliches Review auf das Intent-Diff gerichtet. Messen Sie ehrlich — Durchlaufzeit, Fehlerrate, Review-Aufwand — gegen die handgeschriebene Basislinie. Expandieren Sie entlang der Grenzen, an denen die Schleife gewinnt; 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 konzentriert sich auf die Ebene, auf der sie sich aufzinst: präzise und prüfbar zu entscheiden, was die Software tun muss.
Die Branche war 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 tun muss — und beweisen zu können, dass er es tut —, wird zum Beruf.