Ist ein Engineering-Modell nicht einfach SAST mit einem neuen Namen?

Statische Analyse prüft Code gegen bekannte Fehlermuster. Sie beantwortet nicht, wer eine Änderung freigeben muss, wie tief geprüft wird und woran das hängt. Das Engineering-Modell ordnet Risiko zu Prüftiefe und erzeugt einen Beleg, der die Zuordnung nachvollziehbar macht. SAST bleibt ein Werkzeug in dieser Kette.

Lassen sich Entwicklerinnen und Entwickler solche Regeln vorschreiben?

Guardrails liegen im Repository und werden wie Code geändert: mit Pull Request, Begründung und Review. Wer eine Regel für falsch hält, widerspricht ihr mit einem Vorschlag. Was Teams stört, ist selten die Prüfung, sondern eine Prüfung, die bei jeder Kleinigkeit gleich streng ist und bei der wichtigen Änderung nicht tiefer wird.

Ist die Kennzeichnung der Herkunft von Code eine Leistungskontrolle?

Erfasst wird die Herkunft der Änderung, nicht die Leistung der Person: ob ein Modell beteiligt war, nicht wie produktiv jemand ist. Die Kennzeichnung hängt am Commit, nicht am Konto. Der Betriebsrat sollte vor der Einführung einbezogen werden, nicht danach.

Betrifft der EU AI Act Unternehmen, die KI nur zur Softwareentwicklung einsetzen?

Wer KI ausschließlich zur Entwicklung der eigenen Software einsetzt, fällt in der Regel nicht unter die Hochrisiko-Pflichten des AI Act. Der Druck zur Nachweisführung entsteht meist anderswo: durch Kundenaudits, Lieferkettenprüfungen, interne Revision und Versicherer, die nach dem Freigabeprozess fragen.

Software Engineering, wenn die KI mitschreibt

Q: Wir haben SonarQube, Dependabot und ein Vier-Augen-Prinzip. Reicht das?

Das sind die Bausteine. Was meist fehlt, ist die Verbindung: Das Vier-Augen-Prinzip gilt für alles gleich, die Werkzeuge laufen nebeneinander, und keine Instanz entscheidet, welche Änderung wie viel Aufmerksamkeit bekommt. Sobald das Volumen steigt, wird die Prüfung überall gleich dünn.

Q: Kann man ein solches Engineering-Modell intern selbst aufbauen?

Ja, und das ist das Ziel. Was intern meist fehlt, ist nicht die Fähigkeit, sondern zusammenhängende Zeit: Guardrails entstehen nebenher, bis die erste dringende Änderung kommt. Wer jemanden hat, der drei Monate am Stück daran arbeiten kann, braucht dafür keine externe Unterstützung.

Der Befund

Vier Sätze, die wir seit dem Copilot-Rollout hören.

Keiner davon handelt von einem Werkzeug. Alle vier handeln davon, dass die Erzeugung schneller geworden ist als die Prüfung – und dass niemand das Verhältnis nachgezogen hat.

„Wir sind schneller geworden. Sicherer nicht."

Die Änderungen kommen in doppelter Zahl an, geprüft wird wie vorher. Es fehlt keine weitere Richtlinie, es fehlt eine, die mitzählt.

„Der Review ist zum Durchwinken geworden."

Zwanzig Zeilen liest man. Achthundert überfliegt man. Ab einem bestimmten Volumen hört man auf, sich das einzugestehen – und der Haken im Werkzeug sieht danach genauso aus wie vorher.

„Wir wissen nicht, welcher Code aus einem Modell stammt."

Ohne diese Unterscheidung lässt sich weder die Lizenzlage klären noch begründen, welche Stellen ein zweites Paar Augen wirklich brauchen. Man behandelt dann alles gleich, was heißt: alles zu flach.

„Für den Auditor haben wir Screenshots."

Der Nachweis wird am Ende zusammengesucht, statt im Prozess zu entstehen. Das trägt genau so lange, bis jemand die zweite Frage stellt.

Das Problem

Eingeführt wurden Werkzeuge. Gebraucht wird ein Modell.

Lizenzen lassen sich in einer Woche ausrollen. Was danach fehlt, ist die Antwort auf die Frage, wie Software Engineering organisiert sein muss, wenn Code schneller entsteht, als er von Hand geprüft werden kann.

Nach dem Rollout

CopilotCursorAgentenPrompt-SammlungenShadow-ToolsEin Richtlinien-PDF

↓ mehr Volumen

Mit dem Modell

Engineering-ModellHerkunft je ÄnderungRisikoklassenGuardrails als CodeReview-BudgetNachweis im Prozess

↓ mehr Kontrolle

Die Rechnung

Code zu erzeugen ist billig geworden. Ihn zu lesen nicht.

Das ist der ganze Umbruch in einem Satz. Solange Schreiben teuer war, war Lesen die günstigere Kontrolle. Dieses Verhältnis hat sich umgedreht – und damit ist der zeilenweise Review nicht schlechter geworden, sondern schlicht zu langsam für die Menge, die auf ihn zuläuft.

Zeilen lesen

Prüft, ob der Code so aussieht, wie ein erfahrener Mensch ihn geschrieben hätte
Die Tiefe hängt daran, wer gerade Reviewer ist und wie voll der Tag war
Der Aufwand wächst mit jeder Zeile – linear, ohne Ausweg
Sicherheit und Lizenzen als Stichprobe, weil mehr nicht zu schaffen ist
Am Ende steht ein Haken im Werkzeug, kein Beleg

Eigenschaften prüfen

Prüft, ob die Software tut, was sie soll: fachlich richtig, sicher, schnell genug
Dieselben Kriterien für jede Änderung, unabhängig von Tagesform und Person
Der Aufwand wächst mit der Zahl der Eigenschaften, nicht der Zeilen
Sicherheits-, Abhängigkeits- und Lizenzprüfung auf jeder Änderung, nicht auf einer Auswahl
Am Ende steht ein Prüfergebnis, das man einem Auditor zeigen kann

Die Frage verschiebt sich von „hat das jemand gelesen" zu „lässt sich belegen, dass es tut, was es soll". Menschliche Aufmerksamkeit bleibt dabei entscheidend – sie wandert nur dorthin, wo sie nicht zu ersetzen ist: in den Architekturrahmen und in die Entscheidungen, die kein Test treffen kann.

Ihre Zahlen

Rechnen Sie es einmal für Ihre Organisation durch.

Vier Zahlen, die Sie kennen. Der Rest ist Multiplikation – und genau deshalb lässt sich das Ergebnis nicht wegdiskutieren. Nichts wird gesendet, nichts gespeichert; die Rechnung läuft in Ihrem Browser.

Entwicklerinnen und Entwickler 60

Änderungen pro Person und Woche 4

Menschen, die tatsächlich reviewen 6

Stunden pro Woche, die davon fürs Review bleiben 8

Minuten für ein ernsthaftes Review 25 Nicht die Zeit zum Überfliegen – die Zeit, in der man die Änderung wirklich versteht.

Heute: jede Zeile soll gelesen werden240 Änderungen / Woche

100 h Prüfbedarf

48 h Kapazität

Mit RisikoklassenA: Gates + Mensch · B: Gates + Stichprobe · C: Gates

16 h Prüfbedarf

48 h Kapazität

52 Stunden fehlen. Jede Woche.

Das ist keine Prognose, das ist Ihre eigene Zahl. Die Lücke wird nicht durch Disziplin geschlossen, sondern durch Überfliegen – und Überfliegen sieht in der Statistik aus wie Prüfen.

Weiter gerechnet: Der Engineering-Check nimmt vierzehn Angaben statt fünf und liefert zusätzlich Ihr Legacy-Risiko, die Reihenfolge der Module und einen Report zum Weitergeben.

Die Annahmen stehen offen: 10 % der Änderungen fallen in Klasse A und bekommen die volle Zeit, 30 % in Klasse B mit fünf Minuten Stichprobe, 60 % in Klasse C ohne menschliches Review. Diese Verteilung ist der übliche Ausgangspunkt, nicht Ihr Ergebnis – im Engineering Review wird sie an Ihrer Codebasis bestimmt. Klasse B und C bleiben nicht ungeprüft – im Gegenteil: dort laufen dieselben Quality Gates wie in Klasse A, auf jeder Änderung statt stichprobenartig. Was entfällt, ist das Lesen der Zeilen.

Prinzip 01

Erst der Rahmen. Dann die Geschwindigkeit.

Ein Modell schreibt in jede Struktur hinein, die es vorfindet – auch in keine. Wo Modulgrenzen nur in Köpfen existieren, entsteht in sechs Monaten dreimal so viel Verflechtung wie vorher in zwei Jahren. Wer den Rahmen nicht vorher setzt, prüft hinterher Symptome.

Modulgrenzen und erlaubte Abhängigkeiten

Welcher Teil darf welchen kennen – aufgeschrieben, nicht überliefert. Ein Verstoß ist dann kein Diskussionspunkt im Review, sondern ein roter Build.

Verträge vor Implementierung

Schnittstellen werden zuerst festgelegt und getestet. Was dahinter passiert, darf sich ändern, auch dreimal am Tag – solange der Vertrag hält.

Zielarchitektur als Kontext, nicht als Folie

Die Modelle bekommen dieselben Vorgaben wie die Menschen: Zielbild, Konventionen, verbotene Wege. Das ist der billigste Hebel im ganzen Modell und der am häufigsten ausgelassene.

Fitness-Functions machen den Rahmen prüfbar

Der Rahmen steht nicht in einer Präsentation, sondern als ausführbarer Test in der Pipeline. Sonst erodiert er in dem Tempo, in dem jetzt Code entsteht.

Prinzip 02

Lesen skaliert nicht. Prüfen schon.

Für jede Frage, die ein Review eigentlich beantworten soll, gibt es eine Methode, die sie besser beantwortet – reproduzierbar, auf jeder Änderung, ohne müde zu werden. Nichts davon ist neu. Neu ist, dass es jetzt der Hauptweg sein muss und nicht mehr die Kür.

Tut es, was es soll?

Die Frage, für die der Review eigentlich da war.

Property-based Tests – nicht drei Beispiele, sondern die Eigenschaft selbst: „Für jeden gültigen Vertrag gilt …". Findet die Fälle, an die niemand gedacht hat.
Contract Tests – Schnittstellen brechen nicht mehr still. Wer den Vertrag verletzt, merkt es vor dem Merge, nicht im Betrieb des anderen Teams.
Mutation Testing – prüft die Tests, nicht den Code: Welche Fehler würden unbemerkt durchgehen? Die Antwort ist meistens unangenehm und immer nützlich.

Ist es sicher?

Auf jeder Änderung statt einmal im Quartal.

Abhängigkeiten und Lizenzen als Gate – SBOM je Build. Eine neue Bibliothek ist eine Entscheidung, keine Nebensache; generierter Code bringt sie besonders gern mit.
Secret-Scan und statische Analyse – blockierend, nicht als Bericht, den jemand freitags durchsieht.
Fuzzing an den Außenschnittstellen – dort, wo fremde Eingaben ankommen. Eine Nacht Rechenzeit ersetzt eine Woche Lesen.

Ist es schnell genug?

Die Eigenschaft, die im Review am zuverlässigsten übersehen wird.

Performance-Budgets als Gate – p95-Latenz, Speicher, Datenbankabfragen je Anfrage. Überschreitung stoppt den Merge, statt drei Wochen später im Monitoring aufzufallen.
Lasttest im Pfad, nicht im Kalender – auf den kritischen Strecken, automatisch, bei jeder Änderung der Klasse A.

Bleibt der Rahmen heil?

Sonst ist in einem Jahr wieder niemand da, der das Ganze versteht.

Architektur-Fitness-Functions – Modulgrenzen und erlaubte Abhängigkeiten als ausführbarer Test. Verstoß = roter Build, nicht Diskussion im Review.
Progressive Delivery – erst ein Prozent der Last, automatischer Rückbau bei Abweichung. Die letzte Prüfung findet in der Produktion statt, kontrolliert.

Das ersetzt Menschen nicht, es verschiebt sie: weg vom Zeilenlesen, hin zu der Frage, welche Eigenschaften überhaupt gelten müssen. Diese Frage kann kein Werkzeug beantworten – und sie ist die eigentliche Ingenieursarbeit.

Prinzip 03

Guardrails als Code.

Eine Regel, die in einem Dokument steht, ist eine Bitte. Eine Regel, die in der Pipeline liegt, ist eine Regel. Wir schreiben Architektur-, Sicherheits- und Freigabevorgaben so auf, dass sie ausgeführt werden – und dass man ihnen widersprechen kann, mit einem Pull Request.

guardrails/zahlungsverkehr.yml

regel: "zahlungsverkehr"          # version 2.1
gilt_fuer: pfad("src/payment/**") oder schema("konto_*")
klasse: A                     # immer menschlich
verlangt:
  - test.abdeckung >= 90%
  - herkunft.kennzeichnung: pflicht   # Mensch oder Modell
  - keine.neue_abhaengigkeit ohne freigabe
  - secret.scan: sauber
freigabe: [architektur, security]
nachweis: signiert · revisionssicher · 10 Jahre
status: aktiv · 41 Änderungen geprüft · 3 gestoppt

Versioniert · die Regel hat eine Geschichte

Wer sie wann geändert hat und warum, steht im selben System wie der Code. Keine Datei im Intranet, die zuletzt 2023 jemand angefasst hat.

Durchgesetzt · nicht empfohlen

Was die Regel verlangt, prüft die Pipeline. Eine Ausnahme ist möglich, aber sie ist ein Vorgang mit Namen und Datum, kein stilles Übergehen.

Prüfbar · gegen echte Fälle

Guardrails bekommen Tests wie jeder andere Code. Eine Regel, die noch nie etwas gestoppt hat, ist verdächtig – entweder greift sie nicht oder sie beschreibt nichts.

policy as codeim Repositorymit Reviewmit Tests

Prinzip 04

Freigabe nach Risiko, nicht nach Gefühl.

Jede Änderung nimmt denselben Weg. Was sich unterscheidet, ist die Tiefe – und die entscheidet nicht die Tagesform, sondern die Klasse, in der die Änderung gelandet ist.

Erzeugen

Mensch, Modell oder Agent. Die Herkunft wird an der Änderung festgehalten, nicht später rekonstruiert.

Klassifizieren

Was berührt sie? Zahlungsverkehr, Personendaten und Schnittstellen nach außen sind nicht dasselbe wie ein Tooltip.

Prüfen

Guardrails laufen immer. Menschliche Tiefe kommt dort dazu, wo die Klasse es verlangt – und nur dort.

Nachweisen

Freigabe, Prüfergebnis und Herkunft bleiben zusammen. Der Beleg entsteht beim Arbeiten, nicht vor dem Audit.

Die Prozentwerte sind ein üblicher Ausgangspunkt, kein Versprechen. Welche Bereiche in welche Klasse gehören, entscheidet sich an Ihrer Codebasis – und es ist die Entscheidung, um die es im Engineering Review am längsten geht.

ArchitekturrahmenModulgrenzen, erlaubte Abhängigkeiten und Schnittstellenverträge – festgelegt, bevor Volumen darauf trifft, und als Fitness-Function prüfbar.

rahmen

PrüfmechanismenProperty-based Tests, Contract Tests, Fuzzing, Performance-Budgets. Sie beantworten die Frage, für die früher gelesen wurde.

quality gates

HerkunftJede Änderung trägt, ob sie von Hand, mit Assistenz oder von einem Agenten entstanden ist. Ohne diese Angabe ist jede weitere Regel geraten.

kennzeichnung

RisikoklassenAlle drei Klassen laufen durch dieselben Gates. Unterschiedlich ist nur, wo zusätzlich ein Mensch entscheidet – und das folgt dem Schaden, nicht der Zeilenzahl.

A · B · C

GuardrailsDie Regeln selbst als ausführbarer Code in Ihrem Repository, versioniert und mit Review. Nicht als Kapitel in einem Handbuch.

als code

NachweisführungJede Freigabe hinterlässt eine Spur, die ein Prüfer lesen kann – dieselbe Spur, mit der ein Kunde seine Lieferkette absichert.

audit

TelemetrieChange-Failure-Rate, Rückläufer und Gate-Trefferquote je Klasse. Eine Regel, die nie greift, beschreibt nichts.

messung

Der Einstieg

AI Engineering Review. Zehn Tage, eine Organisation, ein Modell.

Keine Grundsatzstudie und kein Werkzeugvergleich. Wir sehen uns an, wie bei Ihnen heute Code entsteht und geprüft wird, und legen das Modell vor, das dazu passt – mit einem ersten Satz Guardrails, der läuft.

Modul 1

AI Engineering Review

Bestandsaufnahme

Welche Werkzeuge im Einsatz sind, offiziell und inoffiziell, wie viel Volumen sie tatsächlich erzeugen und wo die Prüfung heute reißt.

Architekturrahmen

Modulgrenzen, erlaubte Abhängigkeiten und Schnittstellenverträge – aufgeschrieben und als Fitness-Function hinterlegt, statt als Zielbild in einer Präsentation.

Prüfmechanismen

Welche Eigenschaften bei Ihnen gelten müssen und mit welcher Methode sie geprüft werden. Der erste Satz läuft, bevor wir gehen.

Risikoklassen-Modell

Die Zuordnung für Ihre Codebasis: wo ein Mensch zusätzlich entscheiden muss und wo nicht – begründet, nicht pauschal.

Erster Guardrail-Satz

Lauffähig in Ihrer Pipeline, an echten Änderungen erprobt. Kein Muster-Repository, sondern Ihre Regeln an Ihrem Code.

Nachweisführung

Wie aus Freigaben ein Beleg wird, der eine Prüfung übersteht – für Auditoren, Kunden und die interne Revision.

10 Arbeitstage von Kickoff bis Übergabe Festpreis, wird bei Folgemodul angerechnet Read-only, kein Produktivzugriff nötig Ihre Toolchain bleibt, wir verkaufen kein Werkzeug

Modul 2Quality Gates ausbauen

Weitere Prüfmechanismen und Regelsätze, in die Pipeline eingebaut und scharf geschaltet. Beginnend dort, wo ein Fehler am teuersten ist.

Modul 3Engineering Enablement

Ihre Teams arbeiten künftig selbst so. Werkzeuge, Prozesse und Übungen an echtem Code – kein Tool-Training.

Modul 4Nachweisführung

Belegkette über den gesamten Änderungsweg, für interne Revision, Kundenaudits und regulatorische Fragen.

Einwände

Die sechs Sätze, die in jedem zweiten Gespräch kommen.

Alle sechs sind berechtigt. Deshalb stehen sie hier und nicht erst im Termin.

„Das ist doch nur SAST mit einem neuen Namen."

Statische Analyse prüft Code gegen bekannte Fehlermuster. Sie beantwortet nicht, wer eine Änderung freigeben muss, wie tief geprüft wird und woran das hängt. Genau das ist hier die Arbeit: die Zuordnung von Risiko zu Prüftiefe, und ein Beleg, der die Zuordnung nachvollziehbar macht.

SAST ist ein Werkzeug im Kasten – meist eines, das Sie schon haben. Wir bauen keine Alternative dazu, wir hängen es in die Kette ein.

„Wir haben SonarQube, Dependabot und ein Vier-Augen-Prinzip."

Dann haben Sie die Bausteine. Was in der Regel fehlt, ist die Verbindung: Das Vier-Augen-Prinzip gilt für alles gleich, die Werkzeuge laufen nebeneinander, und keine Instanz entscheidet, welche Änderung wie viel Aufmerksamkeit bekommt. Das Ergebnis ist eine Prüfung, die überall gleich dünn wird, sobald das Volumen steigt.

In dem Fall ist das Engineering Review kürzer, nicht länger – die Analyse fällt weg, die Zuordnung bleibt.

„Unsere Entwickler lassen sich das nicht vorschreiben."

Zu Recht, wenn es eine Vorschrift von außen ist. Guardrails liegen deshalb im Repository und werden wie Code geändert: mit Pull Request, Begründung und Review. Wer eine Regel für falsch hält, widerspricht ihr mit einem Vorschlag, nicht mit einer E-Mail an die Leitung.

In der Praxis ist der Widerstand kleiner als erwartet. Was Teams nervt, ist nicht die Prüfung – es ist die Prüfung, die bei jeder Kleinigkeit gleich streng ist und bei der wichtigen Änderung nicht tiefer wird.

„Wir dürfen die Herkunft gar nicht erfassen, das ist Leistungskontrolle."

Erfasst wird die Herkunft der Änderung, nicht die Leistung der Person: ob ein Modell beteiligt war, nicht wie produktiv jemand ist. Der Unterschied ist mitbestimmungsrechtlich entscheidend, und er lässt sich technisch sauber ziehen – die Kennzeichnung hängt am Commit, nicht am Konto.

Wir empfehlen, den Betriebsrat vor der Einführung einzubeziehen, nicht danach. Das ist auch der schnellere Weg.

„Der AI Act betrifft uns nicht, wir bauen keine KI-Produkte."

Für die meisten Häuser stimmt das: Wer KI nur zur Entwicklung der eigenen Software einsetzt, fällt in der Regel nicht unter die Hochrisiko-Pflichten. Der Druck kommt anderswoher – von Kundenaudits, von der Lieferkettenprüfung, von der internen Revision und von Versicherern, die inzwischen fragen, wie Änderungen freigegeben werden.

Wir verkaufen dieses Thema nicht über Regulierung. Wer es Ihnen so verkauft, hat entweder ein anderes Geschäftsmodell oder das Gesetz nicht gelesen.

„Und was, wenn wir das intern selbst bauen?"

Das ist der Normalfall, und er ist richtig – deshalb ist Modul 3 „Engineering Enablement" auch kein Verkaufsargument, sondern das Ziel. Was intern meist fehlt, ist nicht die Fähigkeit, sondern die zusammenhängende Zeit: Guardrails entstehen nebenher, bis die erste dringende Änderung kommt.

Wenn Sie jemanden haben, der das drei Monate am Stück machen kann, brauchen Sie uns dafür nicht. Sagen Sie es im Gespräch, dann sparen wir uns beide den Termin.

Was wir nicht versprechen

Prüfmechanismen ersetzen kein Urteil.

Automatisiert prüfbar ist weit mehr, als die meisten Organisationen heute prüfen – Eigenschaften statt Beispiele, Verträge, Abhängigkeiten, Geheimnisse, Latenz, Architekturgrenzen. Das ist der Hebel, und er ist groß. Er beantwortet nicht, welche Eigenschaften überhaupt gelten müssen. Ob eine Regel im Zahlungsverkehr fachlich so stimmt, wo die Modulgrenze richtig liegt, welches Risiko tragbar ist – das bleibt Ingenieursarbeit mit Verantwortung, und genau dafür soll die Aufmerksamkeit frei werden.

Und einen Fall gibt es, in dem wir abraten: Wenn bei Ihnen fünf Entwickler arbeiten und ohnehin jeder jede Änderung sieht, brauchen Sie dafür kein Modell. Dann sagen wir das im Erstgespräch, nicht in Woche drei.

Dreimal so viel Code.
Dieselben zwei Reviewer.