Weniger menschliches Programmieren, mehr menschliche Architektur

Wenn KI morgen jede Zeile der Implementierung eines Systems erzeugte, was müsste die Technik dann noch entwerfen, entscheiden und verifizieren? Die Frage ist hypothetisch, aber nicht mehr müßig, und dieser Artikel argumentiert, dass die Antwort Architektur lautet, in einem bestimmten und ausführbaren Sinn. Er hält dabei drei Arten von Aussagen auseinander: was Studien gemessen haben, mit Quellenangabe; was aus diesen Messungen durch Überlegung folgt, als Schlussfolgerung gekennzeichnet; und die These selbst, eine Hypothese, die zu prüfen ist, kein Befund.

Die gemessene Leistungsfähigkeit ist real und schnell gewachsen. SWE-bench lässt ein System echte GitHub-Issues in echten Python-Repositories lösen und bewertet das Ergebnis mit den Tests der Projekte selbst; 2023 löste das beste Modell 1,96 % davon. Auf dem schwierigeren SWE-Bench Pro, gebaut aus größeren Änderungen und zum Teil aus kommerziellem Code, der nie öffentlich war, lag das beste Ergebnis in der ersten Fassung des Papiers im September 2025 bei etwa 23 %; Mitte 2026 zeigte die Rangliste, die der Betreiber des Benchmarks führt, etwa 60 % im öffentlichen und etwa 50 % im kommerziellen Teil, mit Harnesses, die sich zwischen den Einträgen unterscheiden. Der Zeithorizont von METR ist die Länge einer Aufgabe, gemessen an der Zeit einer fachkundigen Person, die ein KI-Agent in der Hälfte der Fälle erledigt. Auf seinen gut spezifizierten, automatisch bewerteten Aufgaben verdoppelte sich diese Länge zwischen 2019 und Anfang 2025 etwa alle sieben Monate, nach seiner Schätzung von 2026 seit 2023 etwa alle vier Monate.

In Organisationen zeigt sich die Verschiebung als Menge, berichtet von den Unternehmen selbst. Google berichtete im Januar 2025, dass angenommene KI-Vervollständigungen 67 % der Codezeichen ausmachten, die in den Editoren seiner Entwicklerinnen und Entwickler eingegeben wurden, eingefügter Code ausgenommen, und dass 80 % der Änderungen in einer Reihe großer interner Migrationen, einer gut spezifizierten Art von Aufgabe, vollständig von KI geschrieben wurden, jede davon geprüft wie jeder andere Code. In einer nicht anonymen Befragung von 132 eigenen Beschäftigten gaben die Entwicklerinnen und Entwickler von Anthropic an, sein Modell in etwa 59 % ihrer Arbeit zu nutzen, während mehr als die Hälfte sagte, höchstens ein Fünftel davon vollständig delegieren zu können.

Die Belege zur Produktivität sind gemischter, als die Kurve der Leistungsfähigkeit vermuten lässt. In einer randomisierten kontrollierten Studie Anfang 2025 mit 16 erfahrenen Entwicklerinnen und Entwicklern, die in reifen Projekten arbeiteten, zu denen sie seit Jahren beitrugen, stellte METR fest, dass Zugang zu KI-Werkzeugen Aufgaben um 19 % verlängerte, während die Beteiligten glaubten, um etwa 20 % schneller gewesen zu sein. Eine Folgestudie Anfang 2026 deutete auf moderate Beschleunigungen hin, mit Konfidenzintervallen, die null einschließen, und METR bezeichnete diese Daten als unzuverlässiges Signal, weil Beteiligte zunehmend ablehnten, ohne KI zu arbeiten. Feldexperimente mit 4.867 Entwicklerinnen und Entwicklern bei Microsoft, Accenture und einem dritten Unternehmen, mitverfasst von Forschenden von Microsoft und durchgeführt mit der Codevervollständigung der Jahre 2022 bis 2024, fanden 26 % mehr erledigte Aufgaben, mit größeren, aber unsicher geschätzten Zuwächsen bei weniger Erfahrenen. Eine randomisierte Studie, die Google mit 96 eigenen Entwicklern durchführte, schätzte für eine Aufgabe etwa 21 % weniger Zeit, bei einem Konfidenzintervall, das weit genug ist, um keinen Effekt einzuschließen. Die DORA-Befragung von 2024 verband jede Zunahme der KI-Nutzung um 25 % mit geschätzt 1,5 % weniger Liefer-Durchsatz und 7,2 % weniger Lieferstabilität; der Bericht von 2025 fand, dass der Durchsatz mit der Nutzung nun steigt, die Instabilität aber weiter zunimmt, und beschrieb KI als Verstärker der vorhandenen Stärken und Schwächen einer Organisation.

Zusammen gelesen zeigen diese Studien nicht, dass KI Softwareentwicklung billig macht. Sie passen zu etwas Engerem, das dieser Artikel erschließt, nicht misst: Eine Kandidatenimplementierung zu erzeugen wird schneller billiger, als festzustellen, dass ein Kandidat annehmbar ist. KI automatisiert auch Teile der Verifikation, von erzeugten Tests bis zu maschinell geprüften Beweisen. Was sie nicht von selbst klärt, ist, was die Prüfungen prüfen sollen. Diese Asymmetrie ist der Ausgangspunkt für alles Folgende.

Ein Benchmark zählt eine Aufgabe als gelöst, wenn ein Patch die vorgesehenen Tests bestehen lässt. Ein System ist angenommen, wenn die Verantwortlichen bereit sind, sich darauf zu verlassen. Der größte Teil der Schwierigkeit liegt im Abstand zwischen beidem.

Die Benchmarks selbst zeigen diesen Abstand. SWE-bench Verified gibt es, weil 2024 bei der Prüfung einer Stichprobe der ursprünglichen Aufgaben durch 93 Entwicklerinnen und Entwickler 38,3 % als unterspezifiziert und 61,1 % wegen Tests markiert wurden, die gültige Lösungen ablehnen konnten, ein Filter, den seine Autoren selbst für wahrscheinlich übereifrig halten. 2026 hörte OpenAI auf, den Benchmark zu berichten, nachdem eine Prüfung von 138 Aufgaben, ausgewählt, weil das eigene Modell an ihnen immer wieder scheiterte, bei 59,4 % wesentliche Mängel in den Tests oder Problembeschreibungen gefunden hatte und jedes getestete Spitzenmodell für einige Aufgaben den ursprünglichen Fix oder Details der Problembeschreibung wiedergeben konnte. Eine auf der ICSE 2026 vorgestellte Studie fand, dass sich 29,6 % der als plausibel gezählten Agenten-Patches anders verhielten als der Fix der Entwickler selbst, nicht alle davon falsch; zusammen mit anderen Schwächen der Tests blähte das die berichteten Lösungsraten um etwa sechs Prozentpunkte auf. Und METR bat Maintainer von scikit-learn, Sphinx und pytest, testbestehende Patches zu prüfen, ohne zu wissen, wer sie geschrieben hatte. Die Patches stammten von Agenten, die bis Ende 2025 erschienen waren, jeweils mit einem Versuch und ohne Rückmeldung, und ungefähr die Hälfte wäre nicht gemergt worden; METR betont, dass dies keine Obergrenze dessen ist, was Agenten können.

Jenseits funktionaler Tests ist das Bild ähnlich. Auf BaxBench, einem auf der ICML 2025 vorgestellten Benchmark für Backend-Anwendungen, erzeugte das beste Modell in 62 % der Fälle ein korrektes Programm, und im Durchschnitt über die Modelle gelangen Sicherheits-Exploits gegen etwa die Hälfte der korrekten Programme. In 576.000 Codebeispielen, 2024 von 16 Modellen erzeugt, existierten 19,7 % der Softwarepakete nicht, auf die die Modelle verwiesen, 5,2 % bei kommerziellen und 21,7 % bei offenen Modellen; ein Angreifer kann solche Namen registrieren. In einer Studie von 2022 mit 47 überwiegend studentischen Teilnehmenden und einem frühen Modell schrieben diejenigen mit KI-Assistenten unsichereren Code und hielten ihn häufiger für sicher. Eine quasi-experimentelle Studie öffentlicher GitHub-Projekte, die einen KI-Code-Editor, Cursor, einführten, fand einen großen, aber vorübergehenden Zuwachs an Output, während die Warnungen der statischen Analyse um 30 % und die Codekomplexität um 41,6 % stiegen und dort blieben.

Die Belege weisen auch in die andere Richtung, und das zählt. Eine präregistrierte Studie mit 151 Teilnehmenden fand keinen signifikanten Unterschied darin, wie leicht andere Entwicklerinnen und Entwickler mit KI-Unterstützung geschriebenen Code später weiterentwickeln konnten. Die meisten der genannten Sicherheitsstudien haben keine passende menschliche Vergleichsgruppe. Nichts davon zeigt, dass erzeugter Code schlechter ist als menschlicher.

Es zeigt, dass erzeugter Code als das behandelt werden sollte, was er ist: eine Kandidatenimplementierung. Eine Kandidatenänderung sollte gegen die Randbedingungen der Architektur und gegen ihre Tests, Validierungen und Regeln geprüft werden; sie sollte Nachweise darüber hinterlassen, was geprüft wurde; und sie sollte auf dieser Grundlage angenommen oder abgelehnt werden. Wo eine Entscheidung ein Risiko trägt, das keine Prüfung klären kann, sollte ein Mensch gefragt werden. Dieses Modell hängt nicht davon ab, wer den Kandidaten erzeugt hat.

Werden Kandidatenimplementierungen reichlich, wird die knappe Frage, welche davon annehmbar ist, und um sie zu beantworten, muss man wissen, was annehmbar bedeutet. Dieser Artikel argumentiert, dass mit leichter erzeugbarer Implementierung der relative Wert der Entscheidung darüber steigt, was wahr bleiben muss. Das ist eine Schlussfolgerung, keine Messung, und sie sagt nicht, dass Code keinen Wert hat.

An den Rändern gibt es stützende Belege. Mehr als ein Drittel der für SWE-bench Verified geprüften Aufgaben wurde als unterspezifiziert markiert. Modelle erkennen schlecht, wann eine Anweisung unterspezifiziert ist, und Agenten, die Rückfragen stellen, schneiden deutlich besser ab, in einer Studie der ICLR 2026 um bis zu 74 % relativ, mit einem simulierten Nutzer. Google beschreibt, wie die Autorin oder der Autor KI-gestützten Codes zunehmend zu dessen Reviewer wird, und die Entwicklerinnen und Entwickler von Anthropic beschreiben ein Paradox der Aufsicht: Das Modell gut zu nutzen erfordert, es zu beaufsichtigen, und es zu beaufsichtigen erfordert genau die Fähigkeiten, die zu viel Delegation abtragen kann. Der DORA-Bericht von 2025 hält fest, dass Reibung weniger verschwindet als wandert, von manueller Arbeit zum Entscheiden und Verifizieren. In der Stack-Overflow-Befragung von 2025 misstrauten mehr Entwicklerinnen und Entwickler der Genauigkeit von KI-Werkzeugen, als ihr vertrauten, 46 % gegen 33 %, und die häufigste Frustration waren Ergebnisse, die fast richtig sind, aber nicht ganz.

Die Verschiebung lässt sich nützlich beschreiben, indem man zwei Fragen trennt. Architektur beantwortet: Was muss wahr bleiben? Implementierung beantwortet: Wie wird es hier umgesetzt? Man nehme eine Eigenschaft: Ein probabilistisches Ergebnis darf nicht stillschweigend zu maßgeblichen Daten werden. Umsetzen lässt sie sich durch Schemavalidierung zur Laufzeit, durch eine typisierte Grenze, die nur ein Validierungsdienst erzeugen kann, durch einen Adapter in der Anwendungsschicht oder durch einen Architekturtest in der Continuous Integration, der fehlschlägt, wenn ein Modell-Client in den Kern importiert wird. Jede davon deckt einen Teil der Eigenschaft ab, unterschiedlich stark; eine Importregel etwa erzwingt die Richtung einer Abhängigkeit, nicht die Eigenschaft selbst. Die Technologie kann sich ändern. Die Eigenschaft bleibt.

Eine KI kann zunehmend die zweite Art von Antwort liefern. Die erste bleibt eine Frage von Absicht, Domänenverständnis, Risiko und Verantwortung. Die Grenze ist nicht ganz sauber: Ein Cache oder eine Wiederholungsstrategie, die in der Implementierung gewählt wird, schafft eigene Eigenschaften, deshalb braucht erzeugter Code weiterhin eine Prüfung gegen die Architektur, nicht nur gegen seine Tests.

Softwarearchitektur kennt bereits ausführbare Absicht. In Building Evolutionary Architectures definieren Ford, Parsons und Kua eine architektonische Fitnessfunktion als objektive Bewertung der Integrität eines oder mehrerer architektonischer Merkmale. Werkzeuge wie ArchUnit lassen die Abhängigkeitsregeln zwischen Schichten als gewöhnliche Unit-Tests laufen. Verträge, Schemata, Typsysteme, eigenschaftsbasierte Tests und, wo sich der Aufwand lohnt, formale Verifikation drücken dieselbe Idee in unterschiedlicher Tiefe aus.

Die hier verwendete Arbeitsdefinition ist einfach. Eine Randbedingung wird architektonisch in dem Sinn, um den es diesem Artikel geht, also durchgesetzt statt bloß festgehalten, wenn ihre Verletzung dazu führt, dass das System oder sein Auslieferungsprozess das Ergebnis ablehnt. Nach dieser Definition ist ein Prinzip, an dem kein Build, kein Deployment und keine Laufzeitprüfung scheitern kann, noch eine Beschreibung, wie sorgfältig es auch formuliert ist. Nicht alles Architektonische lässt sich so durchsetzen; wie ein System zerlegt wird oder wem welche Daten gehören, wird beurteilt, nicht geprüft.

Wird Implementierung reichlich, geht es in der Architektur weniger darum, Systemdiagramme zu zeichnen, und mehr darum, ausführbare Grenzen festzulegen: maschinell prüfbare Randbedingungen, Abnahmeeigenschaften, Nachweisanforderungen, Architekturtests, Anforderungen an Beobachtbarkeit, Regelgrenzen und festgelegtes Fehlerverhalten. Als These formuliert, nicht als Definition der Disziplin: Das Artefakt der Architektin oder des Architekten ist nicht mehr nur ein Diagramm. Es ist auch die Menge der Eigenschaften, die das System nicht stillschweigend verletzen kann.

Ausführbar heißt nicht bewiesen. Tests nehmen Stichproben des Verhaltens; sie können Fehler aufdecken, aber nicht zeigen, dass keine mehr übrig sind. Unterschiedliche Eigenschaften brauchen unterschiedliche Absicherung: Typen und Schemata für die Gestalt von Daten, statische Analyse und Architekturtests für Abhängigkeiten, eigenschaftsbasierte Tests für Verhalten über viele Eingaben, formale Verifikation, wo eine Eigenschaft kritisch ist und sich spezifizieren lässt, Laufzeitkontrollen für das, was sich nur im Betrieb beobachten lässt, und menschliche Prüfung für das, was kein Mechanismus beurteilen kann.

Forschung dazu, Spezifikationen zusammen mit Code zu erzeugen, zeigt Versprechen und Grenze zugleich. Sprachmodelle übersetzten natürlichsprachliche Absicht in Nachbedingungen, die 64 reale historische Fehler im Datensatz Defects4J fanden. Auf dem Benchmark VERINA schrieb das beste Modell für 72,6 % der Aufgaben korrekten Code, aber nur für 52,3 % eine korrekte und vollständige Spezifikation. Lahiri benennt die zugrunde liegende Grenze: Eine Implementierung gegen eine Spezifikation zu prüfen lässt sich mechanisch definieren, aber es gibt keinen algorithmischen Weg sicherzustellen, dass die Spezifikation erfasst, was die Nutzerin oder der Nutzer beabsichtigt hat. Das ist das architektonische Problem in einem Satz.

Ein System ist nicht deshalb kontrolliert, weil einem Modell gesagt wurde, was es nicht tun soll. Ein System-Prompt, eine schriftliche Richtlinie, eine Anweisung, etwas zu unterlassen, die scheinbare Bereitschaft eines Modells, einer Regel zu folgen, und ein Mensch, der hinterher alles überfliegt, beschreiben erhofftes Verhalten. Keines davon blockiert einen unannehmbaren Zustand zuverlässig, wenn das Modell nicht mitspielt; ein Mensch, der hinterher überfliegt, fängt manches ab, spät und ungleichmäßig.

Kontrolle im hier gemeinten Sinn besteht, wenn ein unannehmbarer Zustand erkannt, blockiert, abgelehnt oder eskaliert werden kann, unabhängig von der Mitwirkung des Modells. Ihre Instrumente sind vertraut: ausführbare Architekturrandbedingungen, Typgrenzen, Schemata, deterministische Validatoren, Architektur- und Vertragstests, Prüfungen in der Continuous Integration, die den Build scheitern lassen, Durchsetzung von Regeln, Zulassung beim Deployment, Herkunftsnachweis und Nachvollziehbarkeit, Abnahmetests, kontrollierte menschliche Prüfung und Veröffentlichungstore. Eine Regel, die eine KI ignorieren kann, ist noch keine architektonische Kontrolle.

Eine Folge ist, dass die Kontrollen nicht wissen müssen, wer den Code geschrieben hat. Dieselbe Grenze beschränkt eine Änderung, die ein Mensch getippt hat, eine, die ein Assistent vorgeschlagen hat, und eine, die ein Agent von Anfang bis Ende erzeugt hat. Die wichtige Frage ist nicht mehr nur, wer den Code geschrieben hat, sondern ob das entstehende System die geforderten Eigenschaften bewahrt. Das NIST-Profil für sichere Entwicklung bei Teams, die generative KI-Modelle bauen, nimmt für Schwachstellen dieselbe Position ein: Seine Praktiken unterscheiden nicht zwischen von Menschen geschriebenem und KI-erzeugtem Quellcode, weil jeder Code vor der Verwendung bewertet werden sollte. Das ist kein Kontrollregime für maschinell geschriebenen Code. Es ist Architektur, die Implementierung beschränkt, gleich woher sie stammt, einschließlich der Fehler, die Menschen machen.

Es ändert auch, was ein System hinterlassen sollte. Ein erzeugtes System, das bloß korrekt aussieht, hat keinen Nachweis darüber hinterlassen, was geprüft wurde. Wichtige Eigenschaften sollten Nachweise hinterlassen, dass sie bewertet wurden: welche Tests liefen, welche Regelversion galt, was eine Validierung ergab, wie eine Änderung mit der Anforderung verknüpft ist, der sie dient, woher ihre Eingaben stammen und was das Freigabetor entschieden hat. Frameworks für die Lieferkette behandeln solche Aufzeichnungen bereits als etwas, das ein Build erzeugt und ein Abnehmer verifiziert: SLSA spezifiziert Herkunftsnachweise darüber, wie ein Artefakt gebaut wurde, und in-toto verifiziert, dass jeder Schritt einer Lieferkette wie festgelegt ausgeführt wurde. Ein Herkunftsnachweis zeigt, wie ein Artefakt entstanden ist, nicht, dass es korrekt ist.

Zurück zur Eingangsfrage. Erzeugte KI morgen jede Zeile der Implementierung, müsste die Technik weiterhin festlegen, was die Implementierung bedeuten und tun darf, welche Eigenschaften sie nicht stillschweigend verletzen kann und welche Nachweise nötig sind, bevor man ihr vertrauen kann.

Praktisch ist das eine Liste von Verantwortlichkeiten: den Zweck des Systems festlegen, entscheiden, welche Ergebnisse unannehmbar sind, bestimmen, was als Nachweis gilt, semantische Mehrdeutigkeit auflösen, die Risikotoleranz festlegen, Invarianten definieren, Ausnahmefälle prüfen, die Architektur validieren, Restrisiken akzeptieren und rechenschaftspflichtig bleiben. Nicht jeder Punkt braucht jedes Mal einen Menschen, der ihn von Hand erledigt. Jeder braucht eine benannte Person oder Rolle, die in einem festgelegten Prozess für ihn zuständig ist. Ein System kann Arbeit automatisieren, ohne Verantwortung unbestimmt zu machen. Weniger menschliches Programmieren heißt nicht weniger menschliche Verantwortung.

Menschliche Absicht ist nicht automatisch richtig, und sie ist nicht automatisch verfügbar. Eine Anforderung, die nur in jemandes Kopf existiert, ist keine architektonische Kontrolle. Um erzeugte Implementierung zu beschränken, muss Absicht explizit gemacht werden, in einer prüfbaren Form dargestellt, geprüft, versioniert, wo sie sich ändert, und mit der Verifikation verbunden, die sie durchsetzt.

Am schwersten ist das bei der Bedeutung. Ein Generator kann ein syntaktisch fehlerfreies System erzeugen, das seine Domäne missversteht, weil Begriffe Kontext tragen: Dieselbe Bezeichnung bedeutet in zwei Organisationen Verschiedenes, die Definitionen eines Standards verschieben sich zwischen Versionen, und Daten, die eine Grenze überqueren, treten in ein anderes rechtliches Vokabular ein. Syntax zu erzeugen löst semantische Abstimmung nicht. Zu entscheiden, was ein Feld bedeutet, und diese Bedeutung stabil zu halten, während Daten zwischen Systemen, Organisationen und Rechtsordnungen wandern, ist architektonische Arbeit, die mehr Implementierung nicht ersetzt.

Menschliche Aufmerksamkeit ist außerdem eine begrenzte Ressource mit bekannten Fehlerarten. Bainbridge beobachtete 1983, dass Automatisierung den Bedienenden die Aufgaben überlässt, die ihre Entwickler nicht automatisieren konnten, und sie bittet, ein System zu überwachen, das eingebaut wurde, weil es die Aufgabe besser erledigt als sie. Eine systematische Übersicht zum Automation Bias, der Neigung, sich zu sehr auf automatisierte Ergebnisse zu verlassen, nennt die Betonung der Verantwortlichkeit der Nutzenden unter den Maßnahmen, die ihn verringern. Die Folgerung ist nicht, dass Menschen jede erzeugte Zeile lesen müssen; das skaliert nicht. Sie lautet, dass Systeme menschliche Aufmerksamkeit auf ungeklärte Urteile und Risiken lenken und dieser Aufmerksamkeit Folgen geben sollten.

Dieser Artikel argumentiert, dass man sich auf Autonomie bei der Implementierung nur in dem Maß verlassen kann, in dem sich das entstehende Verhalten unabhängig beschränken und verifizieren lässt. Als Prinzip formuliert, nicht als Formel: Die Autonomie, die einem Implementierungsagenten eingeräumt wird, sollte davon abhängen, wie unabhängig sich sein Ergebnis verifizieren lässt. Wo Eigenschaften gut spezifiziert und Prüfungen stark sind, etwa bei einer mechanischen Migration, einem Abhängigkeits-Upgrade unter einer gründlichen Testsuite oder einem Adapter hinter einer typisierten Grenze, lässt sich viel delegieren. Wo Eigenschaften vage, Prüfungen schwach oder die Kosten eines Fehlers hoch sind, sollte Autonomie langsam oder gar nicht wachsen.

Nach diesem Argument kann Implementierung zunehmend autonom werden, ohne dass Kontrolle autonom wird. Autonomie wird von den Randbedingungen gewährt, an den Nachweisen gemessen und entzogen, wenn die Nachweise sie nicht mehr stützen. Die Abnahmekriterien müssen nicht davon abhängen, wer den Code geschrieben hat; wie viel ein Erzeuger tun darf, bevor ein Mensch hinsieht, kann dennoch von seiner Bilanz abhängen.

Deshalb hängt das Argument auch nicht von einer bestimmten Sprache oder Plattform ab. Dieselbe architektonische Eigenschaft lässt sich zur Übersetzungszeit durch einen Typ in TypeScript prüfen, zur Laufzeit durch ein Schema in Python, durch eine Modulgrenze in Java oder durch eine Admission Policy in Kubernetes. Wenn sich die Implementierung ändert, auch wenn sie neu erzeugt wird, ist die Eigenschaft das, was überdauert.

COADF, das Compliance-Oriented AI Development Framework, ist eine praktische Erkundung dieser These, und nur eine. Es ist eine Entwicklungsmethode für KI-Systeme, die europäischer Regulierung standhalten müssen. Vor dem Hintergrund dieser These gelesen, fragt es, welche Eigenschaften wahr bleiben müssen, wenn probabilistische Komponenten daran mitwirken, Informationen zu erzeugen, umzuformen oder zu veröffentlichen, und wie ein Build bemerken kann, wenn sie aufhören, wahr zu sein. Es stammt aus dem Forschungs- und Entwicklungsprojekt AnyLAI, das untersucht, wie architektonische Absicht durchsetzbar bleiben kann in Systemen, die zunehmend probabilistisches und maschinell erzeugtes Verhalten enthalten.

Seine Prinzipien wenden die These auf einen engeren Fall an: was aus der Ausgabe eines Modells werden darf, während das System läuft. P-1 hält probabilistisches Verhalten innerhalb deterministischen Systemverhaltens: Ein Modell liefert einen Wert zusammen mit seiner Konfidenz und der Methode dahinter, nie einen nackten Wert. P-4 hält wichtige Umformungen nachvollziehbar, von einer veröffentlichten Ausgabe zurück zu den Nachweisen, auf denen sie ruht. P-6 macht aus Leitplanken Fences, Prüfungen, die eine Auslieferung stoppen, statt Ratschläge in einem Dokument zu sein, und verlangt von jedem Fence den Beweis, dass er anschlägt. P-7 hält externe Standards, Klassifikationssysteme und Terminologiedienste in Adaptern außerhalb des Kerns. P-8 hält Regeln explizit und versioniert als Daten, sodass eine Entscheidung die Regelversion nennt, die sie erzeugt hat. P-2 und P-3 legen fest, dass niedrige Konfidenz nie eine veröffentlichte Ausgabe erreicht und dass dort ein Mensch entscheidet, eine Tatsache nach der anderen, gegen ihre Quelle.

Erst seine Governance-Vorlagen behandeln den anderen Fall, KI-Agenten, die Produktionscode schreiben. Eine Autonomieleiter legt fest, wie viel ein Agent tun darf, bevor ein Mensch hinsieht: Auf der untersten Stufe liest ein Mensch jede Zeile; auf der obersten liest ein Mensch die Testergebnisse und die Ausgabe der Wächter, eine Stufe, die reife Fence-Abdeckung und eine Erfolgsbilanz voraussetzt und die nach dem Framework selten bleiben sollte. Eine kurze Liste von Entscheidungen, darunter Änderungen am Datenbankschema, Sicherheitskonfiguration, Schnittstellenverträge, deren Änderung Aufrufer bricht, und Änderungen am Fence-System selbst, bleibt auf jeder Stufe bei einem Menschen.

COADF macht autonomes Programmieren nicht sicher, und es stellt nicht fest, dass erzeugte Software korrekt ist. Es ist kein Framework für autonomes Programmieren. Es macht einige architektonische Annahmen explizit und prüfbar, und es ist veröffentlicht, damit diese Annahmen untersucht und bestritten werden können.

Sie behauptet nicht, dass Softwareentwicklerinnen und -entwickler nicht mehr gebraucht werden, dass menschliches Programmieren überholt ist oder dass Entwickler durch Architekten ersetzt werden. Vieles von dem, was dieser Artikel Architektur nennt, leisten Entwicklerinnen und Entwickler. Die These handelt davon, wo technischer Aufwand den größten Wert schafft, nicht von Berufsbezeichnungen.

Sie behauptet nicht, dass KI Produktionssoftware bereits autonom bauen kann, dass Architektur Halluzinationen beseitigt oder dass die richtigen Kontrollen alles sind, was eine KI braucht. Die oben zitierten Belege enthalten Maintainer, die etwa die Hälfte testbestehender Patches ablehnen, Benchmarks, die Korrektheit überschätzen, und Sicherheitsmängel in erzeugtem Code.

Und sie behauptet nicht, dass der beschriebene Übergang abgeschlossen, allgemein oder unausweichlich ist. Sie ist eine Hypothese über eine Richtung, mit einem Mechanismus, der sich untersuchen lässt: Je leichter Implementierung zu erzeugen ist, desto wichtiger wird Verifikation, und die Arbeit, zu entscheiden, was wahr bleiben muss, wird zu einem größeren Teil der Technik.

Eine These ist nur nützlich, wenn sie Fragen hervorbringt, die sich beantworten lassen. Diese erscheinen am dringendsten.

1. 01Wie viel Implementierungsdetail lässt sich delegieren, bevor Verifikation zum dominierenden Kostenfaktor wird?
2. 02Welche architektonischen Eigenschaften lassen sich automatisch prüfen, und welche erfordern weiterhin menschliches Urteil?
3. 03Wie sollte Architektur dargestellt werden, damit Menschen und Maschinen gleichermaßen über sie schlussfolgern können?
4. 04Kann architektonische Absicht maschinell verifizierbar werden, ohne an eine Implementierungstechnologie gebunden zu sein?
5. 05Wie viel Autonomie sollte eingeräumt werden, wenn Absicherungstechniken unterschiedlich stark sind?

Keine davon hat eine abschließende Antwort. Zwischen der Behauptung, KI helfe Entwicklern bloß, schneller zu programmieren, und der Behauptung, Entwickler würden nicht mehr gebraucht, liegt die Frage, um die es in dieser Forschung geht: was ein System nicht tun können darf, wer das entscheidet und wie die Entscheidung durchgesetzt wird.