Application Flavour Modelling

Im Jahr 1986 schrieb Fred Brooks einen Aufsatz, der für zwei Generationen von Software-Architekten zur Pflichtlektüre wurde: „No Silver Bullet — Essence and Accident in Software Engineering". Seine These war nüchtern und sehr wirkungsvoll: Es gibt keine Wundertüte, die uns von der wesentlichen Komplexität der Software-Entwicklung befreit. Werkzeuge, Sprachen, Methoden — sie alle haben uns nur dort geholfen, wo die Komplexität zufällig war. Die essentielle Komplexität blieb. Daran haben wir uns gewöhnt.

Jetzt klopft die Agentic-Coding-Ära an die Tür und flüstert eine sehr verführerische Gegenthese: „Beschreibe dem Modell deine Fachlichkeit. Den Rest macht die KI." Schöne Vorstellung — und es wäre eine Silver Bullet, wenn sie funktionierte. Sie funktioniert nicht. Brooks hatte recht: ohne eine a priori-Entscheidung über die technische Architektur (und bei eingebetteten Systemen sogar über Mechanik und Energie) verläuft sich jede Bemühung im Sumpf. Ein Lager-Inventarsystem ist nicht dasselbe wie ein Suchmaschinen-Spider, auch wenn beide irgendwie mit „Daten" zu tun haben. Reine Fachlichkeit auskippen ist naiv.

Und trotzdem behaupte ich in diesem Artikel: vielleicht hat Brooks recht und unrecht zugleich. Technologie allein ist tatsächlich keine Silver Bullet. Aber ein konzeptionelles Framework, das der Technologie ihren Korridor vorgibt — vielleicht doch. Ich nenne dieses Framework Application Flavour Modelling. Der Rest dieses Textes ist eine Beschreibung, eine Begründung — und eine ehrliche Selbstkritik.

Im Frühjahr 2026 hat Google ein Paper von Addy Osmani et al. veröffentlicht — The New SDLC With Vibe Coding —, das aus industrieller Sicht überraschend nah an die hier vertretene Position rückt. Ich komme darauf zurück, sobald die Begriffe dafür stehen.

Application Flavour Modelling — die Begriffe

Drei verbundene Begriffe, die ich auseinanderhalten möchte.

Ein Application Flavour ist eine Familie von Software-Systemen mit ähnlichem Charakter — gleiche Grundsubstanz, anderer Geschmack. Wer schon einmal mit Linux-Distros zu tun hatte, kennt das Wort: „Ubuntu Server", „Ubuntu MATE", „Ubuntu Studio" sind verschiedene Flavours derselben Familie. Cloud-Anbieter sprechen analog von „Instance Flavours". Das Wort sagt freundlich, was es meint: die Sippe ist dieselbe, der Charakter unterscheidet sich.

Ein Application Flavour Template (AFT) ist der Bauplan für eine solche Familie. Es bündelt die generischen Konstrukte, die für diese Sippe typisch sind — sowohl technisch (welche Sprachen, welche Frameworks, welche Persistenzschicht, welche Kommunikationsmuster) als auch konzeptionell (welche Begriffe gehören ins Vokabular, welche Strukturen wiederholen sich überall). Ein AFT ist nicht etwa ein Source-Code-Generator. Es ist näher dran an einem Vokabular plus Spielregeln: es legt fest, worüber gesprochen werden kann, und nicht was am Ende gebaut wird.

Application Flavour Modelling (AFM) ist schließlich die Methode: jedes neue Software-Vorhaben zuerst gegen das passende AFT zu lehnen und erst danach die fachlichen Details darauf zu projizieren. AFM ist der Verzicht auf das fröhliche „Wir fangen einfach mal an" — und das Eingeständnis, dass jede ernsthafte Anwendung ein Skelett braucht, bevor man Fleisch und Haut anbringt. Bewusst wählte ich Flavour gegen die trockeneren Alternativen Type, Class, Kind — der Marken-Anker soll im Gedächtnis bleiben.

AFT ist kein Harness — und doch eine Antwort auf dieselbe Sorge

Eine zweite Abgrenzung verdient eigene Aufmerksamkeit, weil sie sonst missverstanden wird. Im aktuellen Agentic-Coding-Diskurs flottiert der Begriff Harness zwischen drei Bedeutungen. Eng verstanden bezeichnet er ein Test-Bett für die Evaluierung von Sprachmodellen — SWE-Bench, HumanEval und Verwandte. In einer zweiten Lesart steht er für eine defensive Sandbox — Permissions-Schicht, Audit-Trail, Code-Execution-Container, die den Schaden begrenzen, den ein außer Kontrolle geratener Agent anrichten kann. In der dritten und sich derzeit durchsetzenden Lesart meint Harness den operativen Rahmen, in dem ein Agent arbeitet: die Werkzeuge (Datei-Editieren, Shell-Ausführen, Web-Recherche), das Memory, die Skills, die Hooks, das Layout des Arbeitsverzeichnisses. Claude Code ist in diesem Sinn ein Harness. Aider ein anderer. OpenHands ein dritter.

So unterschiedlich diese drei Lesarten technisch wirken — sie haben ein gemeinsames Grundmotiv. Es ist die Sorge, die in jeder vorsichtigen Diskussion über Agentic Coding mitläuft und auf der Ebene der IT-Verantwortlichen oft die zentrale ist: dass eine KI unkontrollierbare Änderungen an einem Software-System einbaut, dass sie Funktionen umschreibt, deren Folgen sie nicht überblickt, dass sie Sicherheits-, Datenschutz- oder Compliance-Annahmen still verletzt. Test-Betten, Sandboxes und kontrollierte Werkzeug-Surfaces antworten auf diese Sorge alle auf dieselbe Weise: defensiv. Sie umgrenzen den Möglichkeitsraum, in dem die KI Schaden anrichten kann. Das ist legitim und nötig — aber es ist die negative Seite einer Antwort.

AFT und AFM antworten auf dieselbe Sorge — aber gestaltend positiv. Statt zu sagen, was die KI nicht tun darf, sagt das AFT, was die KI tun soll und in welchen Begriffen. Statt einen Käfig um den Möglichkeitsraum zu ziehen, gibt es dem Möglichkeitsraum eine Form. Eine RAP-Anwendung wächst in den vom AFT vorgegebenen Konstrukten (TABLE, ENTITY, VIEW, ACTION, PROCESS), nicht weil die KI nichts anderes könnte, sondern weil ihr nichts anderes zu tun bleibt. Wer die Sorge der IT-Verantwortlichen ernst nimmt, kommt ohne beide Seiten nicht aus: die defensive Schicht, die das Schlimmste verhindert, und die gestaltende Schicht, die das Beste wahrscheinlich macht.

Wenn man das Bild zu Ende denkt, ordnen sich die Schichten so:

Schicht	Was	Beispiele
5	Konkrete Anwendung	Schul-Bibliothek
4	Agent Guidelines	CLAUDE.md / AGENTS.md (Anteile aus RAP und dem Projekt)
3	AFT / AFM	RAP (Vokabular der Familie)
2	Harness	Claude Code, Aider, OpenHands
1	Foundation Model	Claude, GPT, Gemini
0	Souveränität, Datenstandort, Egress	Cloud-Region, On-Premise-Hosting, Firewall-Policy, Audit-Trail beim Egress

Die Agent Guidelines auf Schicht 4 sind der jüngste Zugang: kuratierte Leitlinien (CLAUDE.md / AGENTS.md), die den Agenten zielgerichtet ausrichten — sie projizieren den User-Prompt, zusammen mit dem Weltwissen des Modells, in die Konstrukte des AFT. Ein Teil dieser Leitlinien ist generisch und gehört zum AFT (RAP), ein Teil ist projektspezifisch; deshalb liegen sie über dem AFT (Schicht 3, was gebaut wird) und unter der konkreten Anwendung (Schicht 5, das Ziel).

Die nullte Schicht ist die Frage, der in jedem ernsthaften Enterprise-Gespräch zuerst gestellt wird: Auf welchem Kontinent steht der Server, der unsere Prompts entgegennimmt? Welche unserer Geschäfts­daten verlassen das Haus, und wohin? Welche Modelle dürfen wir überhaupt nutzen? Diese Sorgen sind real und sie sind orthogonal zu den Sorgen, die die Schichten 2 und 3 abdecken. Ein perfektes AFT auf Schicht 3 schützt nicht vor einer falschen Antwort auf Schicht 0. Und umgekehrt: ein hervorragend kuratierter Datenstandort schützt nicht vor einer wuchernden Architektur ohne Korridor. AFM ist deshalb deployment-agnostisch — es macht keine Aussage darüber, wo das Foundation-Modell läuft. Das ist eine Stärke: ein RAP-Setup funktioniert in der EU-Cloud, im On-Premise-Rechenzentrum und im Self-Hosting-Edge-Stack gleichermaßen. Schicht 0 darf entscheiden, was sie für richtig hält. Schicht 3 stört dabei nicht.

Das Harness ist generisch über alle Anwendungs-Domänen und gibt dem Agenten Werkzeuge. Das AFT ist spezifisch für eine Anwendungsfamilie und gibt ihm das Vokabular dieser Familie. Beides braucht es, und sie verschmelzen nicht: ein RAP-Spezifikator könnte morgen sein Harness wechseln — von Claude Code zu Aider —, das AFT bliebe unverändert gültig. Umgekehrt könnte derselbe Architekt im selben Harness an einem Batch-System arbeiten: anderes AFT, gleiche Werkzeuge.

Die Brücke zwischen den Schichten — und das ist eine der zentralen Thesen dieses Artikels, mehr dazu im übernächsten Abschnitt — ist Markdown. Repo-Artefakte wie CLAUDE.md und die Spezifikationsdateien einer RAP-Anwendung gehören semantisch in die Schichten 3 und 4 (AFT-Substrat und projektspezifische Regeln). Sie werden aber vom Harness der Schicht 2 zur Laufzeit gelesen und entfalten ihre Wirkung schichtübergreifend. Das ist der Punkt, an dem die Trennung der Schichten nicht dazu führt, dass jede für sich allein wirkt. Sie ist sortierend, nicht trennend.

Ich positioniere AFM und AFT deshalb klar auf Schicht 3 — nicht als Konkurrenz zu den Schichten darunter, sondern als deren positiv-gestaltende Vervollständigung. Wer mit Harness und Sandbox allein operiert, hat den Schaden begrenzt, aber den Wirkungsraum nicht geformt — und beobachtet, wie sich Funktionen, Module und Architekturen mit jedem Schritt ein Stück weiter von der erwarteten Form entfernen. Wer mit AFT ohne Harness und Sandbox operiert, hat den Wirkungsraum geformt, aber das Schlimmste nicht abgesichert. Erst beide zusammen — defensive Begrenzung und gestaltende Form — ergeben den produktiven Arbeitsraum, den dieser Artikel zu beschreiben versucht. Und nur beide zusammen sind eine Antwort auf die Sorge, die in jedem ernsthaften Gespräch über KI-gestützte Software-Entwicklung mitläuft.

Eine industrielle Bestätigung — und ihre Leerstelle

Dass dieses Bild nicht nur die Privatlogik eines Solo-Architekten ist, zeigt das eingangs erwähnte Google-Paper. Es buchstabiert genau das Harness aus, das ich von der zweiten Schicht erwarte — und kommt dabei verblüffend nah: das „Factory-Model" („the developer's primary output is not code — it's the system that produces code"), die Gleichung Agent = Model + Harness mit der Faustzahl „90 % harness, 10 % model", das Konfigurieren des Rahmens vor der ersten Zeile Code, Regel-Dateien „versioned and reviewed like code", bis hin zur Ökonomie („3–10× more per feature" fürs Vibe-Coding). Eine große, unabhängige Quelle, die zu denselben Schlüssen kommt wie die Schichten 1, 2 und 4 dieses Textes — mehr Bestätigung kann man sich kaum wünschen.

Und doch bleibt ihr Bild genau an der entscheidenden Stelle leer. Ihr Harness ist generisch — Werkzeuge, Sandboxes, Guardrails, Evals, über alle Domänen gleich. Ein anwendungsfamilien-spezifisches Vokabular, das den Lösungsraum einer Software-Sippe kollabiert, kommt darin nicht vor; sie umkreisen die Idee („build the harness once and refine it many times"), ohne sie je zur eigenen Schicht zu erheben. Das ist genau die dritte Schicht, die in ihrem „90 %-Harness" als undifferenzierter Klumpen steckt — und die ich AFT nenne. Und wo ihr Instrumentarium den Möglichkeitsraum begrenzt und prüft, gebe ich ihm zusätzlich eine Form: nicht nur einfangen, was schiefläuft, sondern vorbeugen, dass es entsteht.

Vier Flavours — eine kurze Galerie

Die Liste ist illustrativ, nicht erschöpfend. Aber sie reicht, um den Punkt zu machen: vier verschiedene Software-Familien, vier völlig verschiedene a-priori-Architekturen.

Flavour	Beispiele	Schwerpunkt	A-priori-Architektur
Algorithmenlastiges Batch-System	AlphaFold, Such­maschinen-Spider, wissen­schaftliche Pipelines	Rechenlast, Parallelisierung, reproduzierbare Pipelines	GPU-Cluster oder Map-Reduce, kein UI nötig, Artefakt-Storage, deterministische Wiederholbarkeit
Social Media	Facebook, X, Mastodon	User-Generated Content, Push, hohe Concurrency, Moderation	Mikroservices, Caching-Layer, Push-Channels, Feed-Algorithmen, Anti-Missbrauch
Database Business Application	ERP-, Asset-Management-, Verwaltungs-Software	Stammdaten, Workflows, Reports, Auditierbarkeit	Relationale DB, REST-API, formularbasierte UI, RBAC, Audit Trail
Embedded System	Bridge-Tracker, Smart-Home-Aktoren, Medizingeräte	Sensor/Aktor, Echtzeit, Energiebudget, physisches Gehäuse	Mikrocontroller, USB/Serial/WiFi plus Mechanik, Power, BOM

Bei den ersten dreien ist die Architektur rein technisch. Beim Embedded-System kommt eine zweite Architekturdimension hinzu, die in den ersten Generationen Software-Entwicklung gern vergessen wurde: die Mechanik. Welches Gehäuse? Welche Stromversorgung? Welche Sensoren? Welche Tasten? Welche LEDs? Wer ein Embedded-Projekt beginnt, ohne diese Fragen vor der ersten Zeile Code zu beantworten, baut implizit eine Antwort hinein — und stabilisiert dann jahrelang die falsche. Genauso wie bei der Technik: was als technische Nebenbemerkung im fachlichen Kontrakt abgehandelt wird, prägt das ganze System.

Wer also Software baut, sollte sich vor der ersten Spezifikationszeile fragen: Welcher Flavour ist das eigentlich? Eine Antwort gibt dem nächsten Tag Struktur. Keine Antwort lässt das System implizit wachsen — meist in die falsche Form.

Ein AFT im Detail — das Beispiel RAP

Die Rapid Application Platform ist genau ein solches AFT: ein Bauplan für Database Business Applications. Wer wissen will, wie sie technisch funktioniert, geht zu jenem Artikel. Hier interessiert mich nur die Sicht als AFT.

Die technische Architektur liegt fest: Node.js für den Server, SQLite für die Persistenz, Server-Sent Events für den Push-Kanal, schlanke Plain-HTML-PWA für den Browser. Bewusst minimalistisch — eine RAP-Anwendung läuft auf einem Raspberry Pi, ohne zusätzliche Container-Orchestrierung, ohne Cloud-Abhängigkeit. Dieselbe Architektur trägt jede RAP-Anwendung — vom kleinen Hobby-Projekt bis zum produktiven Kunden-System mit sehr großen Datenmengen.

Die generischen Konstrukte sind ein kurzes, präzises Vokabular: TABLE, ENTITY, VIEW, ACTION, PROCESS, IMPORT, API — plus zwei Quer-Konzepte (SELECT, TREE). Sieben Substantive und ein paar Adjektive — mehr braucht es nicht, um die meisten Datenbank-Geschäftsanwendungen vollständig zu beschreiben. Jede neue RAP-Anwendung kombiniert diese Bausteine in immer wieder anderer Weise. Aber die Bausteine selbst ändern sich nicht. Sie sind das Vokabular der Familie.

Die Leitplanken schließlich sind die unausgesprochenen Selbstverständlichkeiten: jedes RAP-System hat dieselbe Verzeichnisstruktur, dieselbe REST-API-Form, dieselbe Audit-Logik, dieselbe doppelschichtige Validierung (Client und Server). Wer ein neues System anfängt, weiß a priori, was er hat — und kann sich von Tag eins an auf das Fachliche konzentrieren, weil das Technische bereits entschieden ist.

Ein kleiner, aber wichtiger Hinweis zur Methode: RAP zu bauen war kein AFM. Die Plattform ist das Ergebnis mehrerer Jahrzehnte konkreter Arbeit an konkreten Systemen, in denen ich immer wieder dasselbe Muster gebaut, verworfen und wieder gebaut habe. RAP als AFT zu erkennen und es bewusst als Bauplan für neue Systeme zu verwenden — das ist AFM. Und derselbe Schritt steht für jede andere Software-Familie aus: irgendwann benennt jemand die Konstanten ihrer Praxis und macht aus impliziter Erfahrung ein explizites Template. Für Suchmaschinen-Spider ist das vor langer Zeit geschehen. Für Embedded-Steuerungen auch. Für ein paar andere Familien steht es noch aus.

Für die Embedded-Welt habe ich begonnen, genau diesen Schritt zu tun — Arbeitsname REP — Rapid Embedded Productivity. Stand: Konzeptphase, Absichtserklärung.

Dokumenten-zentrierte Entwicklung mit MD++

Die methodische Brücke zwischen der menschlichen Architektur-Entscheidung und der KI-Code-Erzeugung ist das Markdown-Dokument. Und genau hier liegt die Kern-These dieses Artikels:

Markdown-Dokumente sind nicht „ganz nett am Anfang und leicht obsolet am Ende" eines Projekts. Sie sind die dauerhafte Wahrheit. Sie sind gleichberechtigt zum Source-Code. Sie sind integraler Bestandteil des Systems auch zum Ausführungszeitpunkt.

Vier Beobachtungen begründen diese These, die im Kern von dokumenten-zentrierter Entwicklung spricht — als bewusster Gegenpol zur code-zentrierten Sicht, die jahrzehntelang das Selbstverständnis der Disziplin geprägt hat.

Erstens: Markdown ist Input vom Menschen. Die Spezifikation, die Anforderungen, die fachlichen Konzepte stehen in MD — präzise genug, dass die KI sie direkt umsetzen kann, und gleichzeitig lesbar genug, dass der Architekt sie noch in fünf Jahren versteht. Zweitens: Markdown ist auch Output der KI. Befunde, Zusammenfassungen, neue Spezifikations-Abschnitte werden von der KI als MD geschrieben — in derselben Form und mit derselben Qualitäts-Schwelle, wie sie für Code gilt. Drittens: Markdown wird damit zur zweiten Sprachebene, auf der beide Parteien gemeinsam arbeiten. Weder muss der Mensch noch Code lesen, noch muss die KI raten, was der Mensch eigentlich meinte. Viertens — und das ist mir wichtig: die KI profitiert davon. In Markdown-Dokumenten hat sehr viel mehr Platz als in einem einzelnen Kontextfenster einer Arbeitssitzung. Was nicht ins Context Window passt, holt sie aus den Dokumenten. Die Doku ist nicht trotz der KI ein Wert — sie ist für sie ein Werkzeug.

Daraus folgt: MD-Dateien sind versioniert wie Code, reviewed wie Code, zur Laufzeit verfügbar wie Code. RAP demonstriert das im Extrem — die Markdown-Spezifikation ist das laufende System, sie wird zur Laufzeit gelesen und interpretiert. Aber selbst dort, wo das nicht so extrem ist, gilt das Prinzip: Doku ist nicht das Beiwerk eines Systems, sie ist sein Skelett — die zweite Seite der Code-Medaille.

MD++ — Markdown in drei Schichten

Das Markdown, mit dem ein AFT arbeitet, ist allerdings nicht vanilla. Es ist MD++ — weiterhin gültiges Markdown, das in jedem Standard-Renderer sauber dargestellt wird, aber angereichert um semantische Add-Ons. Drei Schichten lassen sich klar voneinander trennen:

Schicht	Was sie tut	Beispiele
Standard MD	gewöhnliches Markdown — bleibt in jedem Viewer lesbar	Überschriften, Listen, Tabellen, Code-Blöcke, Links
+ Syntax	strukturelle Erweiterungen, AFT-unabhängig	YAML-Frontmatter, Inline-Annotationen [KEY: value], Kapitel-Konventionen (## Step N), getypte Code-Blöcke (mermaid, json, sql), Verzeichnis- und Pfad-Konventionen
+ Semantik (AFT-spezifisch)	wie ein AFT das Syntax-Vokabular interpretiert	für RAP: Entity-Definitionen, Computed Columns, ACTION-Links, VIEW-Deklarationen, PROCESS-Schritte, IMPORT-Mappings

Die ersten beiden Schichten sind wiederverwendbar zwischen AFTs. RAP und REP und alle künftigen Familien teilen sich denselben Markdown-Kern und dieselben Syntax-Mechanismen — Frontmatter, Annotations, Konventionen. Nur die dritte Schicht ist familienspezifisch: jedes AFT prägt sein eigenes Semantik-Vokabular auf das gleiche Substrat.

Das ist der ganze Punkt von MD++: das Branding einer Erweiterungs-Architektur, die in jedem Markdown-Editor weiterhin funktioniert — Mermaid ist das vertraute Beispiel, das jeder schon kennt —, aber die der AFT-spezifischen Verarbeitung eine klare semantische Andockstelle bietet.

Was AFM gegen die typischen KI-Defizite leistet — der Lackmus-Test

Wer eine Weile mit einem KI-Coding-Assistenten gearbeitet hat, kennt die Litanei der typischen Defizite. Sie sind real und sie sind nervig. Hier eine ehrliche Aufzählung — und für jeden Punkt die Stelle, an der AFM, das Markdown-Substrat oder das versionierte Regelwerk (in meiner Praxis: eine pro Projekt gepflegte CLAUDE.md) eingreift. Keine Heilsversprechen, sondern systematische Eindämmung.

Beobachtetes KI-Defizit	Wo AFM / Markdown / Regelwerk eingreift
Lange Würste, Gott-Funktionen pro Feature — am Ende ein „Götterhimmel wie im Alten Griechenland"	Das AFT gibt Modul- und Datei-Grenzen a priori vor; jede neue Logik findet ihren vorgesehenen Platz. Die KI muss das Vokabular der Familie sprechen, nicht ihr eigenes erfinden.
Halluzinieren als Energie­optimierung — sie fantasiert, weil es billiger ist als nachzuschauen (denselben Mechanismus zeigt der Mensch mit seinen Vorurteilen, von denen sie das ja wohl übernommen hat)	Das Markdown-Substrat ist die Quelle der Wahrheit. Statt zu fantasieren, schlägt die KI im Vokabular nach, das im AFT festgelegt ist. Eine ausdrückliche Regel verlangt: keine ungeprüften Behauptungen über Code oder Verhalten.
Zu viel Code — Error-Handling im Kleinen, kein Plan im Großen	Das AFT skizziert die Architektur im Großen. Fehler­behandlung folgt dem Plan, nicht der zufälligen Stelle. Technical Contract zuerst.
Copy-Paste statt Modulari­sierung — REUSE als Anstrengung	Eine harte Regel: die dritte Kopie ist das Signal. Einmal duplizieren ist erlaubt, zweimal nicht mehr. Plus: gemeinsame Daten­erzeugung gehört in einen Helper, nicht in zwei Stellen. Der Architekt schreibt diese Regeln einmal; die KI hält sie jedes Mal ein.
Sycophancy — die KI redet dem Menschen nach dem Mund (sie ist auf Gefallen trainiert)	Ein rigides Wertesystem im Projekt-Regelwerk macht aus „nett sein" eine normative Verletzung. Anstelle des unter­würfigen „gute Idee" steht das diszipliniert-höfliche „push back", wenn eine Regel verletzt wird.
Kontext-Drift über Sessions — sie vergisst Ent­scheidungen vom Vortag, baut die gleiche Lösung anders, schafft Drift mit dem Bestehenden	Drei Planungs-Horizonte: persistente Issues für Monate, Memory für Tage, Pläne für die laufende Stunde. Die Wahrheit lebt in Dokumenten, nicht im Context Window. Jede neue Session liest sich zurück in den Stand der Dinge.
Symptom-Patching statt Root-Cause — „ich hab's gefixt!" obwohl der Fix nur die spezifische Manifestation kaschiert	Eine ausdrückliche Reihenfolge: erst die Fehlerklasse sichtbar machen (Detektor), dann beheben. Der Detektor muss am echten Fehler ansprechen, bevor irgendwas geändert wird.
Silent Omission — die KI schluckt einen Fehler still und liefert ein unvollständiges Ergebnis	Eine Zeile aus dem Regelwerk: „Lieber ein harter Absturz als ein falsches Ergebnis."
Premature Generalization — Frameworks und Abstraktionen für Probleme, die noch nicht existieren	Start naive, extract on time. Die zweite Kopie ist erlaubt, die dritte ist das Signal. Nicht früher.
Doku-Versprechen ohne Doku-Pflege — „ich update das gleich", und der Doku-Eintrag kommt nie	Doku ist Commit-Voraussetzung, nicht „Aufgabe für später". Kein Feature-Commit ohne Doku-Update im selben Commit.

Das sind keine Wundermittel. Jede dieser Regeln ist ein stiller Vertrag zwischen Architekt und KI, kein automatischer Schutzwall. Aber genau weil die Regeln einmal aufgeschrieben sind — versioniert, gelesen, eingehalten — entfaltet sich ihr Schutz millionenfach, nicht einmal. Die Regeln sind das Echo eines erfahrenen Architekten, das die KI in jede einzelne Entscheidung trägt.

Der Korridor — und warum er beide Parteien produktiv macht

Damit kommt die Synthese der vorigen Abschnitte. Ein AFT engt den Spielraum für Mensch und Maschine ein — und genau das macht die Zusammenarbeit produktiv. Im Korridor sind die Begriffe bekannt, die Abläufe vorhergesehen, die Architektur stabil. Was bleibt, ist die fachliche Projektion: was sind meine konkreten Entitäten, meine konkreten Workflows, meine konkrete Hardware? Diese Projektion ist die eigentliche Wertschöpfung der Software-Entwicklung. Alles andere ist Boilerplate, der ohnehin schon hundertmal anderswo geschrieben wurde.

An dieser Stelle muss auch eine ehrliche Beobachtung Platz haben — die mir wichtig ist, weil sie weder Marketing-Slogan noch Übertreibung ist. Wir können auf einmal Qualität bezahlen, die wir uns immer gewünscht haben, aber nie selbst leisten konnten. Die fünfte Refactor-Runde, die saubere Testabdeckung, die selbstdokumentierende Benennung, die mitgepflegte Doku in jedem Commit — Dinge, vor denen jeder erfahrene Entwickler gelegentlich ein stilles „gut genug" murmelt, weil das Vollkommene zu teuer wäre. Der KI-Partner verschiebt diese Kalkulation. Das Niveau, das die Regeln des Handwerks vorsehen, ist auf einmal das Niveau, das an einem ganz gewöhnlichen Arbeitstag erreichbar wird.

Das macht die KI nicht überflüssig zur Architektur — sie verschiebt nur die Schwelle, ab der gute Architektur wirtschaftlich wird. Und ich behaupte: das ist tatsächlich eine kleine Revolution.

Im Tandem lesen — und warum ich einen vierten Reifegrad reklamiere

Spec-driven Development (SDD) — die strukturierte Gegenbewegung zum „Vibe Coding" — kennt in der Fachliteratur drei Reifegrade (so der iX/heise-Überblick von Mainczyk & Oberhagemann, Juni 2026). Ich möchte einen vierten dazustellen — und sage gleich dazu: der vierte ist meine eigene Ergänzung, nicht Teil der publizierten Einteilung.

Reifegrad	Die Spec wird…	Die eine Wahrheit liegt in…
Spec-first	einmalig vor dem Feature geschrieben	danach: dem Code
Spec-anchored	während der Entwicklung weiter gepflegt	Spec und Code (parallel)
Spec-as-Source	zum primären Artefakt	allein der Spec — der Code wird daraus erzeugt
Continuous Spec Alignment (mein vierter)	fortlaufend geschärft als Nebenprodukt des Bauens	allein der Spec — und sie gewinnt an Präzision

Die ersten drei Grade beantworten, wo die Wahrheit wohnt (Code → beide → Spec). RAP erreicht den dritten: die MD++-Spec ist die Anwendung, der Code materialisiert sich aus ihr — Spec-Drift entfällt strukturell, weil es keine zweite, handgepflegte Code-Wahrheit gibt.

Aber Spec-as-Source garantiert nur, dass die Spec die Quelle bleibt — nicht, dass sie präzise bleibt. Genau dort setzt der vierte Grad an, und er wird erst auf dem dritten möglich: eine Spec laufend zu verfeinern lohnt nur, wenn die Spec das ist, was läuft.

Continuous Spec Alignment heißt: Während der KI-Partner arbeitet, liest er beide Ebenen zugleich — die MD++-Spec (das Warum, die gewollte Form) und den Code bzw. das laufende System (die Grundwahrheit). Wo beide auseinandergehen, ist das ein freies Signal: eine Präzisionslücke der Spec, aufgedeckt als Nebenprodukt des Bauens. Die Disziplin ist, sie nicht still zu umgehen, sondern zu benennen und im Dialog zu schließen. So wächst die Spec an Präzision, statt zu verrotten, während der Code wächst.

Ein Wort zur Sicherheit, denn der Mechanismus hat eine Kehrseite: Der KI-Partner wird darin schnell — schnell genug, den Menschen innerlich abzuhängen und heimlich zur eigentlichen Autorin der Spec zu werden. Dagegen steht eine Vorlagepflicht: die KI erkennt Lücken und legt sie vor, sie schreibt die kanonische Spec nie im Alleingang um. Der Mensch bleibt die Autorität — „human periodically in the loop", angewandt auf die Single Source of Truth.

Den Modus, in dem das geschieht, nenne ich Tandem Mode, mit dem Leitsatz: „Im Tandem lesen, im Dialog heilen." Das Tandem ist dabei doppelt gemeint — zwei Ebenen (Spec und Code) zugleich gelesen, und zwei Köpfe (Mensch und KI), die sich das Lesen teilen.

Was ist mit Teams? — die offene Frage

Bevor andere sie stellen, stelle ich diese Frage lieber selbst. Die hier beschriebene Praxis ist die eines einzelnen Senior-Architekten mit KI-Partner. Etwas böse charakterisiert wäre das ein „Titanen-Approach" — ein einzelner überlegener Mensch macht Arbeit, die früher Teams brauchten. Solange dieser eine Mensch alle Fäden hält, mag das funktionieren. Aber wie skaliert es auf ein klassisches Team? Die ehrliche Antwort: das wissen wir noch nicht. Ich biete drei Hypothesen an — keine Antworten, sondern Diskussionsanker.

Rollen-Spezialisierung im Team. AFM könnte Team-Rollen neu schneiden. Ein Architekt pflegt das AFT, mehrere „Spezifikatoren" formulieren Anforderungen in Markdown, alle gemeinsam reviewen den KI-Output. Klingt traditionell — „Senior plus Junioren" — aber mit einer anderen Mechanik darunter: der Senior tippt keinen Code mehr, sondern hütet das konzeptionelle Framework. Die Junioren arbeiten in der zweiten Sprachebene, nicht in der Tastatur.

Konvergenz-Problem. Diese Aufgabenteilung funktioniert nur, wenn das Team sich auf ein AFT einigt. In gewachsenen Organisationen mit Stil-Vielfalt — wo schon der Streit über Klammern-Style ein halbes Jahr kostet — ist gerade das die Hürde. Konsequenz: AFM eignet sich besonders für Greenfield-Projekte, weniger für Brownfield mit etablierter Diversität. Wer eine neue Sparte gründet, hat es leichter als wer eine bestehende migrieren will.

Doku-Disziplin im Team. Beim Solo-Architekten trägt die Disziplin sich selbst — wer morgen wieder in sein Markdown reinschaut, schreibt heute ordentlich. Im Team wird MD-Pflege schnell zur Latrinenpflicht, die jeder dem anderen aufdrücken will. Möglich, dass gerade hier die KI die Brücke ist — nicht nur als Code-Erzeuger, sondern als Doku-Wächter, der jede Abweichung zwischen Markdown und Code sichtbar macht und im Daily-Stand-up vorhält. Wer das in einem realen Team praktiziert hat — bitte melden.

Anti-Taylorismus durch KI. Wenn das Spektrum des einzelnen Menschen sich an beiden Enden ausdehnt — zum konzeptionell-Kreativen einerseits, zum Detail-Debugging andererseits — könnten Teams künftig mit weniger Arbeitsteilung auskommen. Mehr überlappende Kompetenzen heißt: weniger Brüche an Rollenschnittstellen, weniger Übersetzungsverluste, mehr ganzheitliches Verständnis für ein Vorhaben. Eine sehr vorsichtige Hypothese: das könnte den klassischen Taylorismus der Wissensarbeit relativieren — und Teams entstehen lassen, deren Mitglieder sich eher als egalitäre Partner verstehen denn als arbeitsteilige Funktionseinheiten. Und Teams, die sich so verstehen, sind möglicherweise gerade die, mit denen die Zusammenarbeit mit der KI am produktivsten wird.

Schluss — Silver Bullet, aber mit Bedingung

Zurück zum Aufhänger. Brooks hatte recht: Technologie allein ist keine Silver Bullet. Aber AFM plus KI plus dokumenten-zentrierte Entwicklung ist vielleicht eine — unter der Bedingung, dass ein erfahrener Architekt das Framework hütet.

Das ist keine vollständige Lösung. Es ist eine starke Hypothese. Sie funktioniert nachweislich für den Solo-Architekten — ich kann das selbst bezeugen, als praktisches Beispiel ebenso wie als persönliche Erfahrung. Sie wartet auf ihre Bewährung im größeren Team. Aber dass der Spielraum für Wundertüten in der Software-Entwicklung endlich nicht mehr ganz so leer ist wie 1986 — das darf man festhalten.

Vielleicht haben wir nicht die Silver Bullet gefunden. Aber wir haben gelernt, dass ein guter Korridor und ein guter Schreibtisch zusammen schon ziemlich nahe daran kommen.