Die Verfassung der Software

Alle drei Monate wird die Branche neu geboren. Ein Modell erscheint, die Timelines glühen, die Benchmarks purzeln, und in tausend Meetings wird beschlossen, jetzt aber wirklich alles neu zu denken. Es ist das verlässlichste Ritual der Agenten-Ära — und ihr größtes Missverständnis. Denn je schneller die Sprünge kommen, desto weniger entscheidet der einzelne Sprung: Was alle bekommen, unterscheidet niemanden. Das Modell, um das sich alles dreht, ist inzwischen die austauschbarste Komponente im Stack — fungibler als jede Bibliothek, kurzlebiger als jedes Framework. Was dagegen nicht austauschbar ist, liegt eine Schicht tiefer und sieht verdächtig nach Hausaufgaben aus.

Wer 2026 mit Agenten konkurriert, konkurriert nicht über Modelle. Er konkurriert über Verfassungen.

Die Serviette

Ein Webformular bei Kaffee und Kuchen

Sommer 2024, Geburtstagsfeier eines befreundeten Paars — alte Studienfreunde, das Essen war phänomenal, und irgendwann saß die Runde draußen im Hof auf Bierzeltbänken, zwischen Resten, Gläsern und den Malbüchern der Kinder. Ich nahm einen ihrer Buntstifte, wischte ein paar Kuchenkrümel von einer Serviette und skizzierte grob ein Webformular: ein paar Felder, ein paar Stufen, Pfeile dazwischen; in eine der Boxen kritzelte ich einfach: „Tabelle mit Name, Vorname, Geburtsdatum, sechs Demo-Datensätze“. So erzählt man Freunden, woran man gerade baut.

Dann fotografierte ich das kleine Kunstwerk mit dem Handy und schickte das Foto an meinen Bot — einen Assistenten, der meinen ersten Entwurf eines semantischen Designsystems kannte: die Komponenten und die Instruktionen, wie ein Bot sie zu verwenden hatte. Er las die Skizze, baute daraus das Datenobjekt, reichte es in den UI-Builder weiter. Wenige Minuten später lag ein fertiges Webformular auf dem Handy-Display: mehrstufig, funktionsfähig, konform zum Designsystem. Das Handy machte die Runde, zwischen Kaffeetassen und einem angeschnittenen, wirklich guten Kuchen.

Bemerkenswert war dabei weniger die Geschwindigkeit als das, was das System ausgelassen hat: Es hat die Skizze nicht abgemalt. Vom krummen Strich bis zur Buntstift-Ästhetik fand nichts davon den Weg ins Formular. Das System hat erkannt, was es ist — ein Wizard mit diesen Schritten, Felder mit dieser Bedeutung, ein Prozess mit diesem Skelett — und es nach den Guidelines seines Designsystems neu erzeugt. Aus der hingekritzelten Box mit dem einen Satz wurde eine echte Tabelle: drei Spalten, sechs Demozeilen, genau wie notiert. Die Form blieb auf der Serviette. Der Sinn kam an.

2024 ließ das die Umstehenden staunen. Heute ist es — eine Einschätzung aus eigener Praxis, keine Branchenstatistik — der Standard unter denen, die Agentic Coding ernsthaft betreiben: Man baut ein Rahmenwerk samt Designsystem, gibt Spezifikationen hinein, und heraus kommt ein Webprodukt. „Der auswärtige Dienst“ fragte nach dem Außenrecht zwischen Agenten, nach Pässen und Beglaubigung; dieser hier schreibt das Innenrecht der Software — und beginnt dort, wo jedes Recht beginnt: bei der Frage, was gelten soll. Die Antwort des Abends im Hof steht seitdem fest: Das System bewahrte den Intent, nicht die Form.

Zwei berechtigte Skepsen

Eine Verteidigung der Augenroller

Wer an dieser Stelle die Augen verdreht, hat gute Gründe — gleich zwei Sorten davon.

Die erste Skepsis kennt jeder, der eine Designsystem-Initiative überlebt hat. Nicht, dass die Idee falsch gewesen wäre — im Gegenteil: Ich baue seit Jahren Designsysteme und halte sie für zentral, für jedes Produkt, das skalieren soll. Die Skepsis galt nie der Idee. Sie galt dem, was in der Praxis meist aus ihr wurde. Drei Wellen lang wurde diese Gattung gebaut, gefeiert und beerdigt: Styleguides, die für Audits entstanden und in Pitch-Decks glänzten; Komponenten-Bibliotheken, deren Pflege nach dem Launch niemand budgetierte; Token-Architekturen, die exakt ein Team verstand, das dann ging. Der Prachtband im Regal: gedruckt, signiert und ungelesen. (Das Wort „lebendiges Dokument“ trug in diesen Jahren eine Beweislast, die es selten eingelöst hat.) Wer da „Schaufenster-Schickimicki“ sagte, beschrieb nicht die Idee, sondern ihren Normalfall.

Die zweite Skepsis ist jünger und sitzt tiefer: der Verdacht, das Modell sei eben doch alles. Auch sie war berechtigt. Solange Modellsprünge die einzige Quelle neuer Fähigkeiten waren, war Modell-Jagd schlicht die korrekte Strategie — wer das bessere Modell hatte, gewann, und alles andere war Deko. Der Fetisch war eine Weile lang schlicht wahr.

Beide Skepsen waren also völlig richtig — bis sich etwas verschoben hat, das mit Qualität nichts zu tun hatte. Die Styleguides wurden nicht besser, die Modelle nicht bescheidener. Was sich änderte, war etwas anderes: wer liest.

Das Designsystem hatte nie ein Qualitäts-Problem. Es hatte ein Leser-Problem.

Der zweite Leser

Was sich geändert hat — und es waren nicht die Menschen

Der Leser, der all die Jahre fehlte, ist angekommen. Er ist nur kein Mensch. Vor jeder Aufgabe liest eine Maschine die Artefakte des Projekts — Designsystem, Dokumentation, Direktiven. Nicht, indem sie alles von vorne bis hinten durchpflügt; das wäre Verschwendung. Sie liest das Inhaltsverzeichnis und findet von dort ihren Weg — über Ontologien, Verweise, Links — zu genau der Stelle, die die Aufgabe verlangt. Keine Müdigkeit, keine stille Übereinkunft, dass Kapitel drei sowieso niemand braucht; aber eben auch kein blindes Durchackern. Developer Experience und Agent Experience fallen damit in eins: Was diesem zweiten Leser nicht auffindbar ist, existiert für die Produktion nicht mehr.

Gleichzeitig hat sich das Tempo-Verhältnis umgekehrt, auf das jede Engineering-Kultur gebaut war: Generieren geht inzwischen schneller als Verstehen. So entstehen riesige Software-Gebilde, die kein Mensch mehr im Detail durchdringt. An einem einzigen Nachmittag generiert, werden sie zu den digitalen Ruinen von morgen.¹

Nehmen wir als Faustregel: Die Modelle verdoppeln ihre praktische Leistungsfähigkeit gefühlt alle drei Monate. Wenn das auch nur ungefähr stimmt, folgt daraus eine unbequeme Rechnung: Wer nur Code besitzt, besitzt das Artefakt, das am schnellsten an Wert verliert — eine Momentaufnahme dessen, was die vorletzte Generation für eine gute Lösung hielt. So entsteht die eigentliche Schere dieser Ära: Der Modellsprung entwertet Code im selben Takt, in dem er Verfassungen aufwertet.

Die Verfassung

Präambel, Norm, Standanweisung, Vertrag, Fallrecht

Was also ist diese Verfassung, die den Sprung überlebt? Lesen wir sie, wie Juristen ein Grundgesetz lesen — von vorn. Sie besteht aus vier Artefakt-Klassen und einer Präambel, und keine davon ist Code. Alle fünf sind Aggregatzustände desselben Substrats: Intent.

Die Präambel — Intent

Jede Verfassung beginnt mit einem Satz, der nichts vollstreckt und alles begründet. „Wir, das Volk“ wird in der Software-Verfassung zu „Ich, der Nutzer“: Was hier festgehalten wird, ist der Zweck, dem alle Normen dienen — wortwörtlich festgehalten, nicht zusammengefasst. Das gilt in beide Richtungen desselben Mechanismus: Der Nutzer artikuliert, was er will, und die Anwendung entfaltet sich darum; der Entwickler artikuliert, was gelten soll, und die Agenten bauen danach. Wie schnell der Wortlaut verloren geht, zeigt ein Experiment im Kleinen: Sage einem Agenten „bau mir ein Quadrat“, und er baut ein Quadrat. Sage es Tage später einem zweiten, bekommst du ein Rechteck — die Viereckigkeit wurde erkannt, die eigentliche Bedingung ging unterwegs verloren. Die Präambel ist der Ort, an dem „Quadrat“ stehen bleibt, bis jemand es begründet ändert. Der Intent treibt an; was ihn haltbar macht, kommt weiter unten. Denn eine Präambel vollstreckt nichts — aber ohne sie weiß keine Norm, wozu sie da ist.

Die Norm — das Designsystem

Dann beginnt der Verfassungstext selbst. Die Norm der Software ist ihr Designsystem, verstanden als generative Quelle: Sie legt fest, was überhaupt erzeugt werden darf — mit der alten Stilvorschrift für Menschen teilt sie kaum mehr als den Namen. Auf der Serviette im Hof war genau das zu besichtigen — das System hat die Skizze gegen seine Norm gelesen und designsystemkonform neu erzeugt. Die nächste Verwandtschaft ist älter, als man denkt: WAI-ARIA gibt Screenreadern seit Jahren eine rein semantische Beschreibung dessen, was eine Oberfläche bedeutet, entkoppelt von ihrer Darstellung.² Das Designsystem der Agenten-Ära ist dasselbe Versprechen an einen neuen Adressaten. Hält man die Norm rein semantisch, lässt sich am Ende sogar ihr Renderer austauschen, ohne den Anwendungskern zu berühren. Zur Norm gehören die Legaldefinitionen: ein hierarchisches Glossar, in dem jeder Begriff in genau einer Ebene definiert wird und tiefere Ebenen nur referenzieren — „im Sinne dieser Verfassung ist ein Wizard …“. Ohne sie driften die Begriffe, und mit den Begriffen die Agenten.

Und die Norm beantwortet eine Frage, die sich früher nie stellte: Wann wird eigentlich gebaut? Drei Kadenzen stehen offen — im Pre-Build, wo Spezifikationen zu einem statischen Produkt gerinnen; zur Laufzeit, wo jeder Nutzer seine eigene Renderung bekommt; und ein Hybrid, der beides verschränkt. Pre-Build friert, On-the-Fly fließt, der Cache entscheidet den Aggregatzustand. Als Faustregel für die Zuordnung: Texte sind volatiler als Layouts, Layouts volatiler als Semantik-Verträge. Eine dieser drei Kadenzen ist allerdings mehr als eine technische Option — sie ist eine Wertentscheidung; dazu gleich. Festzuhalten bleibt die Arbeitsteilung: Die Norm legt fest, was Software werden darf. Wie sie aussieht, ist danach Auslegungssache.

Die Standanweisungen — Direktiven

Normen vollziehen sich nicht selbst. Der Vollzug gehört den Direktiven: standing instructions,³ die jeder Agent vor jeder Arbeit liest. Ihre Substanz sind Use Cases, vernetzte Dokumentation und erste Prinzipien — Material, an dem ein Agent auch dann einen Stoppgrund findet, wenn die Konversation längst in die Irre schmeichelt.

Wie man diese Disziplin lernt, kann ich an einer eigenen Narbe zeigen — keiner einzelnen, eher einem Muster, das sich über viele Projekte wiederholte. Der erste Plan eines Modells war nie der beste. Also ließ ich nachbessern: „Mach es wasserdicht.“ Das funktionierte — und kippte zuverlässig ins Gegenteil. Der Agent dichtete weiter ab, längst an der Aufgabe vorbei, und verlor Ziel und Verhältnismäßigkeit aus den Augen. Meine einseitige Wasserdicht-Direktive war eine gescheiterte Direktive: Sie kannte nur einen Pol. Daraus wurde ein Ritual in drei Prompts — erst der Plan, dann „mach ihn wasserdicht“, dann „geh noch einmal drüber und schneide alles heraus, was over-engineered ist“. Trim the Fat. Ob zwei getrennte Anweisungen wirklich besser arbeiten als eine kombinierte, habe ich nie sauber im A/B-Test geprüft. Mein Eindruck sagt ja. Die Lehre aber steht: Direktiven dürfen widersprüchliche Pole im selben Manifest halten — die Spannung ist keine Inkonsistenz, sie ist eingebaute Selbstkorrektur, die der Agent als Schleife abarbeitet.

Wie so etwas produktiv aussieht, zeigt eine einzelne Sprachguideline aus meinem Lernportal: Sie legt fest, was übersetzt wird und was nicht, wie Eigennamen behandelt werden, welcher Zeichensatz gilt, wie Fachbegriffe konsistent bleiben — einmal sauber geschrieben, von jedem Übersetzungs-Agenten vor jeder Arbeit gelesen. Inzwischen lesen stabil rund fünf Prozent der Besucher das Portal in Leichter Sprache, die es ohne diese Direktiven-Disziplin schlicht nicht gäbe. Die Narbe und das Portal lehren dasselbe: Eine Direktive mit nur einem Pol ist eine Drift mit Dienstsiegel.

Der Vertrag — Tests

Tests waren in der Softwaregeschichte das Kanarienvögelchen im Schacht: geduldet, gelegentlich gefüttert, im Zweifel zuerst gestrichen. In der Verfassung rücken sie an die Stelle des Vertrags — der einzigen Artefakt-Klasse, die einen Modellwechsel prüfbar überlebt. Die Begründung dafür ist älter als jede KI. Nietzsche ließ seinen Zarathustra wissen, dass ein Mensch den anderen höchstens beinahe versteht — Maschinen eingeschlossen. Vollständiges Verstehen ist nicht zu haben. Was zu haben ist: der exakte Wortlaut, Silbe für Silbe festgehalten — was der Nutzer sagte, was der Entwickler sagte, jedes „ich“. Aus dem Wortlaut werden Requirements, aus Requirements werden Tests. Und wenn am Ende etwas nicht passt, läuft die Kaskade rückwärts — vom roten Test über das Ticket bis zur ursprünglichen Aussage und ihrem Subtext, derselbe Mechanismus, der sich im vorigen Artikel als „Rückpropagieren“ durch die Agenten-Welt zog. Am klassischen Requirements Engineering ändert das nichts, und das ist keine Randnotiz: Anforderungen klären bleibt die Disziplin. Tests sind ihre ausführbare Endform⁴ — der Schritt, an dem Akzeptanzkriterien Maschinenform annehmen, ob als Spezifikations-Tests, Property-Tests in der Breite, Mutation-Testing oder Persona-getriebene End-to-End-Läufe. Test und Code sind dabei getrennte Instanzen — die eine hält das Ziel, die andere führt aus und berichtet zurück. Ein roter Test ist, wenn man so will, eine erfolgreiche Normenkontrollklage.

Ein Test ist die einzige Anforderung, die nicht lügen kann.Die Vertragsklausel

Das Fallrecht — Smart Caches

Bleibt die Frage, was mit den Urteilen geschieht. Smart Caches sind das Fallrecht der Verfassung: die bestmöglichen validen Lösungen, die nicht ohne Begründung geändert werden. Konserviert wird dabei das Erkannte — der Wizard-Typ, die Feld-Semantik, das Prozess-Skelett. Die Erscheinung, vom Pixel-Layout bis zur Roh-Eingabe, bleibt draußen. In den Cache kommt eine Lösung wie ein Fall vor Gericht: Erst wenn Häufigkeit, Tests und Sicherheits-Prüfung bestanden sind und eine Begründung vorliegt, wird sie zur Präzedenz erhoben — und auch wieder herabgestuft wird nur aktenkundig. Die Urteilsbegründung dazu liefern Architecture Decision Records, die neben dem Code liegen statt in einem fernen System, das nur die Volltextsuche je wiedersieht: Der Cache ist die ausführbare Hälfte der Präzedenz, das ADR die begründete — und der Agent liest beide an derselben Stelle. Warum dieser Aufwand? Weil viermal Druck auf dem Kessel ist: Ungetestetes darf nicht ausrollen, menschliche Abnahme braucht einen stabilen Stand, das mentale Modell des Nutzers braucht Wiedererkennbarkeit, und jede unnötige Neugenerierung verbrennt Geld.

Damit löst sich auch die Wertentscheidung von vorhin ein. Die Frage ist nicht, wann Sie einen Cache brauchen. Die Frage ist, an welchen Stellen Ihrer Anwendung Fluidität nichts verloren hat — wo zwei Gesichter derselben Funktion ein Vertrauensbruch wären. Der Hybrid aus dem Norm-Kapitel bekommt hier seine Mechanik: Der Cache ist Pre-Build-Material auf On-the-Fly-Substrat. Und ja, auch Vergessen will geregelt sein — sonst wird das Fallrecht zum Gedächtnis alter Fehler. Was bleibt, ist die juristische Kurzform: Ein Cache ist eine Entscheidung gegen Fluidität — getroffen, begründet, aktenkundig.

Die Löschungs-Frage

Vier Artefakt-Klassen, eine Präambel. Falls sich das nach Werkzeugkasten anfühlt, hilft ein Gedankenexperiment, das keine Werkzeuge übrig lässt.

Heute Nacht, sagen wir um drei, wird der gesamte Code Ihrer Organisation gelöscht. Jede Zeile. Die Implementierung von Monaten oder Jahren — weg. Was verbrennt, ist alles, was ein Modell der letzten Generation geschrieben hat. Was nicht verbrennt, falls es existiert: die Präambel mit dem festgehaltenen Intent, die Norm, die Standanweisungen, der Vertrag, das Fallrecht samt Begründungen.

Was bleibt von Ihrer Software, wenn Sie heute Nacht den gesamten Code löschen?Der Rebuild-Test, in einer Frage

Der Rebuild-Test

Städte brennen, Katasterämter nicht

Wer eine Verfassung hat, beantwortet die Frage erstaunlich gelassen: Er baut neu — als Vorgang mit Plan, so wie Städte nach Bränden neu entstanden sind, solange Kataster und Baurecht erhalten blieben.

Dafür gibt es einen Namen: Rebuild Affordance — die Eigenschaft eines Systems, aus seiner Verfassung heraus neu gebaut werden zu können, von jedem hinreichend guten Modell, zu jedem Zeitpunkt. Der Rebuild-Test ist der ehrlichste Reife-Maßstab, den eine Software-Organisation heute anlegen kann: Gib dem neuen Modell Norm, Direktiven, Tests und Intent — und lass dieselbe Sache neu bauen. Wenn der neue Build die Verträge hält, hast du in Tagen, was sonst eine Migrations-Roadmap über Quartale war: modernen Code, der nachweisbar dasselbe tut. Genau hier kippt ein altes Anti-Pattern. Der Big-Bang-Rewrite — das Schreckgespenst, vor dem Generationen von Architekten zu Recht gewarnt haben — wird zur Real-Option: Wenn alle drei Monate ein doppelt so gutes Modell bereitsteht und ein Rebuild Tage statt Jahre kostet, ist Neubauen plötzlich eine Entscheidung, die man treffen kann — nicht mehr ein Schicksal, das man erleidet.

Und sie reicht weiter, als es zunächst aussieht: Wenn der Rebuild für die eigene Software trivial wird, wird er es auch für die Software, die man bisher gekauft hat. Was das für die Anbieter bedeutet — für ganze Geschäftsmodelle, die auf der Mühsal des Nachbauens ruhten —, behandelt der nächste Teil dieser Serie: „Kälte auf Bestellung“. Bis dahin genügt der Maßstab selbst: Rebuildbarkeit ist der Beweis, dass eine Verfassung trägt — und der einzige, der sich ausführen lässt.

Sechs Fragen an Ihren Stack

Montagmorgen, erster Kaffee

Geprüft wird so etwas nicht in Strategie-Workshops, sondern beim Rundgang mit dem eigenen Schlüsselbund. Sechs Fragen für Montagmorgen:⁵

1. Kann ein Agent Ihr Designsystem lesen — oder nur Ihr Frontend-Team? Wenn die Norm in Figma-Screenshots⁶ und Konventions-Folklore lebt, existiert sie für den zweiten Leser nicht.
2. Überlebt Ihre Testsuite einen Modellwechsel — oder testet sie Implementierungsdetails? Verträge binden an Verhalten; wer Interna testet, hat den Vertrag mit dem falschen Partner geschlossen.
3. Liest jeder Agent Ihre letzte Direktiven-Änderung vor jeder Arbeit — oder liegt sie in einem Wiki, das niemand öffnet? Eine Standanweisung, die nicht am Arbeitsplatz hängt, ist eine Anekdote.
4. Welche Stelle Ihrer Anwendung darf nie zwei Gesichter haben — und wo ist das festgehalten? Wenn die Antwort „im Kopf des Teams“ lautet, ist sie nein.
5. Wenn morgen ein doppelt so gutes Modell erscheint: Wie viele Tage, bis Ihr Stack davon profitiert? Die Zahl ist Ihre Verfassungs-Reife in Tagen.
6. Liegen Ihre Entscheidungs-Begründungen dort, wo der Agent arbeitet — oder dort, wo das Management sucht? Präzedenz ohne auffindbare Begründung ist Aberglaube mit Versionsnummer.

Wer alle sechs mit Ja beantwortet, braucht keine Verfassung mehr — er hat längst eine.

Zinseszins

Markt, Berufsbild und eine unbequeme Eigentumsfrage

Jetzt die Kamera auf. Wenn Verfassungs-Reife entscheidet, wie viel von jedem Modellsprung ankommt, dann kompondiert sie: Dieselbe neue Modellgeneration löst beim Team mit Verfassung eine Renditewelle aus — Rebuilds, Modernisierung, frei werdende Kapazität — und beim Team ohne Verfassung eine Rework-Welle. Der Abstand zwischen beiden wächst mit jedem Sprung — und fragt nicht nach dem Talent der Beteiligten. Es ist dieselbe Schutz-Mechanik, die im „Auswärtigen Dienst“ den Menschen vor seinem Agenten schützte, nur eine Ebene tiefer eingebaut: Dort hielt ein festgehaltener Wortlaut den Proxy auf Kurs, hier hält er das Produkt auf Kurs, während der Generator darunter ausgetauscht wird. Und mit der Arbeit verschiebt sich das Berufsbild: Wer heute Software baut, schreibt immer seltener ihren Code — und immer öfter ihre Verfassung.

Womit eine Frage unangenehm konkret wird: Wem gehört eigentlich der Intent, wenn er das einzige bleibende Asset ist — dem, der ihn hatte, oder dem, der ihn festhält? Die Bilanzregel aber steht schon jetzt: Modelle werden abgeschrieben. Verfassungen verzinsen sich.

Die weggeworfene Urkunde

Die Serviette aus dem Hof gibt es übrigens nicht mehr. Sie wurde noch am selben Abend zusammengeknüllt und hat Kuchenreste in den Müll begleitet — niemandem ist es aufgefallen, mir auch nicht. Das Formular von damals ist längst Geschichte, ein Showcase von einem Abend. Geblieben ist die Art, so zu bauen. Was auf der Serviette stand, hatte das Papier längst verlassen: der Intent. Er lebt im Designsystem weiter — von dort ließe sich dasselbe Formular an jedem beliebigen Nachmittag neu bauen. Die Zeichnung war nur sein Fahrzeug für einen Abend.

Feiern Sie also ruhig den nächsten Modellsprung mit — er wird wieder beachtlich sein. Aber verwechseln Sie das Geschenk nicht mit dem Vermögen.

Ihr nächstes Modell bekommen Sie geschenkt. Ihre Verfassung schreibt Ihnen niemand.Die Bilanzregel der Agenten-Ära

Für das Schreiben und Pflegen solcher Verfassungen gibt es übrigens längst einen Namen: Code Context Engineering. Wer diese Disziplin trägt, welche Rolle daraus wird und was das für jede Laufbahn im Software-Bau bedeutet — das verhandelt „Das Stundenbuch“, der letzte Teil dieser Serie. Bis dahin bleibt sie offen, und sie ist größer, als sie aussieht: Wer schreibt diese Verfassung?

1. So habe ich es in Basiswissen Künstliche Intelligenz beschrieben (Kapitel 6: Die Kunst des Prompting).
2. W3C, Accessible Rich Internet Applications (WAI-ARIA) — seit 2014 W3C-Standard: eine semantische Beschreibungsschicht, die Screenreadern Rolle, Zustand und Bedeutung von UI-Elementen unabhängig von deren Darstellung mitteilt. Fünfundzwanzig Jahre Barrierefreiheits-Arbeit erweisen sich rückblickend als Generalprobe für maschinenlesbare Interfaces.
3. Einen Namen hat diese Gattung erst spät bekommen: Inzwischen verpacken Agenten-Frameworks solche stehenden Anweisungen als „Skills“ — wiederverwendbare Instruktionspakete, die ein Agent bei Bedarf zieht. 2024 gab es dafür weder den Begriff noch das Produkt.
4. Die hübsche Herleitung — „Test“ von lateinisch testis, der Zeuge — ist sprachgeschichtlich leider wackelig: Wahrscheinlicher stammt das Wort von testum, dem Tongefäß, in dem man Edelmetalle im Feuer auf Echtheit prüfte. Für unsere Zwecke gewinnen beide Lesarten. Ein Test ist ein Zeuge, der Ihr Gold im Feuer prüft.
5. Wer beim Lesen der sechs Fragen ein leichtes Ziehen verspürt: Das ist keine Rhetorik. Das ist Ihr Backlog.
6. Meine Überzeugung: Jede Software-Firma sollte ihr Designsystem längst über einen hauseigenen MCP-Server ausspielen — maschinenlesbar, versioniert, vom Agenten abfragbar. Figma hat das verstanden und liefert seinen eigenen MCP-Server gleich mit — was die Frage nur verschiebt: Braucht, wer direkt mit den echten Produktions-Komponenten prototypisiert, das gezeichnete Zwischending überhaupt noch?