Warum KI-Code ohne Kontextstore schnell zur Architekturfalle wird

KI kann heute sehr schnell Code ausspucken. Genau das macht den Einstieg in neue Features oft beeindruckend effizient. Das Problem beginnt dort, wo Unternehmen aus schnellerem Schreiben auf schnelleres Verstehen schliessen. Der neue InfoQ-Beitrag vom 14. Juli 2026 dreht die Perspektive deshalb bewusst weg vom Output und hin zur Frage, ob Teams noch nachvollziehen koennen, warum ein System so gebaut wurde, wie es gebaut wurde. Der vorgeschlagene Gegenentwurf heisst Context Store: ein repo-gebundener, versionierter Kontextlayer aus Spezifikation, Tests und architektonischen Leitplanken.

KI macht den Anfang schnell, nicht automatisch die Architektur besser

Die staerkste These des Artikels ist nicht, dass KI schlecht fuer Softwareentwicklung sei. Im Gegenteil: Der erste Teil einer Aenderung wird oft wirklich schneller. Scaffolding steht frueher, Tests entstehen schneller, eine Demo wirkt frueh fertig. Aber genau dadurch kann ein gefaehrlicher Eindruck entstehen: dass das System bereits verstanden sei, nur weil der Code schon da ist. Der InfoQ-Text beschreibt diese Schieflage als eine Art 80/20-Falle. Die ersten 80 Prozent fuehlen sich schnell an, waehrend die letzten 20 Prozent – Integration, Randfaelle, Architekturtreue, nicht dokumentierte Zwänge – erst spaet und dann umso teurer sichtbar werden.

Diese Beobachtung passt zu einer breiteren Evidenzlage. DORA betrachtet Softwareleistung nicht nur als Frage von Tempo, sondern auch von Stabilitaet, etwa ueber Lead Time, Deployment Frequency, Change Failure Rate und Time to Restore Service. Schon deshalb ist mehr generierter Code kein verlaesslicher Erfolgsindikator, wenn sich gleichzeitig Fehlerrisiken oder Wiederherstellungszeiten verschlechtern. Auch der aktuelle GenAI-Forschungsblick von DORA ist bewusst differenziert: Produktivitaetsgewinne koennen real sein, aber sie gehen nicht automatisch mit besserer Gesamtleistung des Systems einher.

Besonders nützlich ist hier der Kontrast zur METR-Studie vom 10. Juli 2025. Dort arbeiteten erfahrene Open-Source-Entwickler in ihren eigenen grossen Codebasen. Das Ergebnis war gerade nicht die erwartete Beschleunigung, sondern im Mittel ein Zeitnachteil mit KI-Unterstuetzung. Das beweist nicht, dass KI generell verlangsamt. Es zeigt aber sehr deutlich, warum der eigentliche Engpass in komplexen Codebasen nicht nur das Schreiben von Code ist, sondern das Einordnen in bestehende Architektur, Historie und Nebenbedingungen.

Genau an dieser Stelle wird der Artikel fuer CTOs, Architekten und Platform-Teams interessant: Wenn KI die Kopplung zwischen Code erzeugen und System verstehen lockert, dann muss dieses Verstaendnis an anderer Stelle bewusst aufgebaut und gepflegt werden. Das ist auch der Punkt, an dem der interne Beitrag zu verantwortliche KI am Ende kein Modell-, sondern ein Führungsproblem gut anschliesst: Das Risiko sitzt oft weniger im Modell selbst als in unklaren Verantwortlichkeiten, stillen Annahmen und schlecht eingefangenen Arbeitsablaeufen.

So funktioniert der Context Store aus Specs, Tests und Fitness Functions

Der Begriff Context Store klingt zunaechst nach einem Produkt. Gemeint ist hier aber eher ein Arbeits- und Architekturmodell. Die Grundidee: Alles, was spaeter erklaert, begrenzt oder prueft, warum eine Aenderung architektonisch sinnvoll ist, soll nicht lose in Koepfen, Chats oder Tickets verschwinden, sondern nah am Repository, versioniert und maschinenlesbar mitgefuehrt werden.

Praktisch besteht dieser Kontextlayer aus drei Bausteinen.

Erstens: Spezifikationen mit Designabsicht. Nicht nur „was soll die Funktion tun?“, sondern auch „welche fachlichen oder architektonischen Grenzen darf sie nicht verletzen?“. Thoughtworks beschreibt Spec-Driven Development derzeit noch als begrifflich uneinheitliches Feld. Genau deshalb ist fuer Teams weniger wichtig, welches Label sie benutzen, sondern dass Spezifikationen fuer Menschen und KI gleichermassen als verbindlicher Arbeitskontext dienen.

Zweitens: Tests als Verhaltensanker. Der Artikel setzt bewusst auf ein spec-anchored Vorgehen zusammen mit TDD-Logik: Bevor generierter Code akzeptiert wird, soll moeglichst klar sein, welches Verhalten erwartet wird und woran Fehler sichtbar werden. Das verhindert nicht jede schlechte Aenderung, aber es verschiebt die Zusammenarbeit mit KI weg von „schreib mal irgendwas Plausibles“ hin zu „erfuelle diese nachpruefbare Absicht“.

Drittens: Fitness Functions als dauerhafte Leitplanken. Martin Fowler und Thoughtworks verwenden den Begriff fuer automatisierte Regeln, mit denen Teams Qualitaets- oder Architekturmerkmale laufend ueberpruefen koennen. In diesem Artikel ist das besonders wichtig, weil erstellt Code sonst lokal korrekt, aber systemisch schaedlich sein kann. Eine Fitness Function kann zum Beispiel verhindern, dass ein Modul unerlaubt in einen fremden fachlichen Bereich greift, eine Latenzgrenze reisst oder eine Integrationsregel umgeht.

Genau hier passt auch der DDD-Gedanke des Bounded Context hinein. Wenn fachliche Grenzen schon fuer Menschen unscharf sind, wird KI sie erst recht verwischen. Ein Context Store ist deshalb kein Ersatz fuer Architekturarbeit, sondern eine Moeglichkeit, bestehende Architekturarbeit so zu hinterlegen, dass sie in AI-assisted Development ueberhaupt wirksam bleibt.

Wichtig ist zudem, was der Context Store nicht ist. Er ist kein Pre-Merge-Dokumentationsritual fuer die Schublade. Er soll vor einer Aenderung den Handlungsraum abstecken, waehrend der Aenderung Review und Rueckfragen schaerfen und nach der Aenderung Debugging, Evolution und Architekturentscheidungen besser nachvollziehbar machen. Damit wird aus verstreutem Kontext ein gemeinsam abfragbarer Referenzpunkt statt implizitem Teamwissen.

Was Geschwindigkeit ohne Kontext im Team kaputt machen kann

Wenn Teams KI vor allem als Beschleuniger fuer Ticketdurchsatz einsetzen, verschiebt sich das Problem oft nur nach hinten. Der sichtbare Gewinn liegt dann im schnelleren Erstellen von Code. Die unsichtbaren Kosten tauchen spaeter in Review, Betrieb und Weiterentwicklung auf.

Ein typisches Muster ist oberflaechlich plausibler Code. Er kompiliert, besteht Standardtests und sieht im Pull Request sauber aus. Trotzdem kann er Architekturrichtungen verletzen, die nie explizit aufgeschrieben wurden: etwa fachliche Grenzen zwischen Domänen, historische Kompromisse im Datenmodell oder Integrationsannahmen mit Altlasten. Genau diese stillen Hintergruende fehlen KI-Systemen besonders haeufig.

Daraus entstehen mehrere Betriebsfolgen.

Review wird schwerer. Reviewer muessen nicht mehr nur Code lesen, sondern implizite Annahmen rekonstruieren. Je groesser der durch KI erzeugte Change-Umfang, desto eher kippt Review von Verstehen zu Abnicken.

Wartbarkeit sinkt. Wenn Designabsicht nur im Kopf einzelner Personen existiert, wird jedes spaetere Refactoring teurer. Das Team sieht dann zwar, was geaendert wurde, aber nicht mehr verlaesslich, warum es urspruenglich so angelegt war.

Architektur driftet. Ohne maschinenpruefbare Leitplanken sammeln sich lokal sinnvolle, global aber widerspruechliche Entscheidungen. Gerade hier helfen Fitness Functions, weil sie Architektur nicht nur predigen, sondern pruefbar machen.

Wissen konzentriert sich auf wenige Menschen. Das ist paradox: KI soll Teams eigentlich entlasten, kann aber in unreifen Setups die Abhaengigkeit von Senior-Entwicklern sogar erhoehen. Sie muessen naemlich jene Architekturabsicht nachliefern, die weder im Code noch im Prompt sichtbar ist.

Delivery-Stabilitaet wird unschaerfer. DORA erinnert daran, dass gute Softwareleistung nie nur Deployment-Frequenz meint. Wenn mit mehr Aenderungstempo auch die Fehlerquote oder Wiederherstellungszeit steigt, wurde nicht geliefert, sondern nur frueher Risiko erzeugt.

Der strategische Punkt dahinter ist simpel: Unternehmen, die AI-assisted Development skalieren wollen, brauchen nicht nur bessere Modelle, sondern bessere Systemgedaechtnisse. Sonst wird aus schneller Entwicklung schleichende Architekturerosion.

Wie sich der Entwicklungsalltag mit KI und Kontextstore verändert

Ein Context Store aendert den Alltag nicht durch ein einzelnes Wunderwerkzeug, sondern durch andere Gewohnheiten. Gute Teams wuerden nicht mehr zuerst fragen: „Welchen Prompt geben wir dem Agenten?“ Sondern: „Welcher Kontext ist verbindlich genug, dass Mensch und KI dieselbe Aenderung als korrekt verstehen?“

Das fuehrt oft zu kleineren, besser begruendeten Aenderungen. Spezifikationen werden konkreter. Tests entstehen frueher. Reviewer koennen gezielter fragen, welche Annahmen durch Specs gedeckt und welche durch Fitness Functions abgesichert sind. Platform- und Architekturteams gewinnen dadurch eine wichtigere Rolle: nicht als Bremser, sondern als Lieferanten der Leitplanken, die Geschwindigkeit erst sicher machen.

Das ist auch der Punkt, an dem Port AI Builder: Was der Vibe-Coding-Ansatz für Platform Engineering wirklich ändert interessant wird. Je mehr KI in reale Entwicklungsworkflows eingebunden wird, desto wertvoller werden Organisationskontext, Freigaben und sauber definierte Grenzen. Reine Prompt-Bequemlichkeit reicht dann nicht mehr aus.

Woran Teams merken, ob ihr Projekt davon profitiert

Ein sinnvoller Pilot beginnt nicht mit einem unternehmensweiten Rollout, sondern mit einem einzelnen realen Repo, in dem KI bereits spuerbar genutzt wird und Architekturfolgen teuer werden koennen. Drei Prueffragen helfen schnell weiter.

1. Fehlt bei Pull Requests regelmaessig die Designabsicht? Wenn Reviewer oft erst im Gespraech verstehen, warum eine Aenderung so gebaut wurde, fehlt bereits heute strukturierter Kontext.

2. Gibt es kritische Architekturregeln, die nur als Teamwissen existieren? Sobald Antworten lauten wie „Das machen wir hier einfach nicht“ oder „Frag am besten Person X“, ist das ein gutes Signal fuer fehlende maschinen- und teamlesbare Leitplanken.

3. Entstehen durch KI eher groessere, schwerer pruefbare Changes? Dann sollte der erste Hebel nicht ein noch besserer Assistent sein, sondern kleinerer Scope plus sauberer Kontext.

Ein pragmatischer Einstieg kann so aussehen:

• fuer ein Feature eine knappe Spezifikation mit fachlicher Absicht direkt am Repo hinterlegen,
• vor dem Akzeptieren von generiertem Code mindestens einen failing test definieren,
• fuer die riskantesten Architekturmerkmale wenige CI-blockierende Fitness Functions bauen,
• Review nicht nur auf Codequalitaet, sondern auf Rueckverfolgbarkeit von Absicht zu Verhalten ausrichten.

Damit wird auch klar, wo der Ansatz offen bleibt. Der Markt hat noch keinen einheitlichen Standard dafuer, wie ein Context Store strukturiert, versioniert oder toolseitig integriert werden sollte. Thoughtworks weist zudem selbst darauf hin, dass Begriffe wie Spec-Driven Development noch semantisch in Bewegung sind. Teams sollten den Ansatz deshalb nicht als fertige Blaupause lesen, sondern als belastbare Richtung: Architekturwissen muss fuer KI-natives Entwickeln expliziter, repo-naher und pruefbarer werden.

Genau deshalb ist das Thema groesser als nur Coding-Produktivitaet. Wer heute AI-assisted Development skaliert, entscheidet zugleich, ob kuenftige Systeme nachvollziehbar evolvierbar bleiben oder ob sich das Architekturverstaendnis schleichend aus dem Codeprozess verabschiedet. Der Context Store ist dafuer keine Garantie. Aber er ist ein nuetzlicher Name fuer etwas, das viele Organisationen jetzt dringend brauchen: ein gemeinsames, versioniertes Systemgedaechtnis fuer schnelle Softwareaenderung.

Wer die Debatte weiterdenken will, findet in Warum offene Datenarchitekturen bei KI jetzt gewinnen einen guten Anschluss. Denn auch dort zeigt sich dieselbe Grundbewegung: Nicht geschlossene Bequemlichkeit gewinnt langfristig, sondern Architektur, Metadaten und Governance, die Kontext belastbar nutzbar machen.