Vom Coding-Loop zum Business-Loop: KI Engineering ganzheitlich denken

Die letzten drei Folgen haben sich in genau dieser einen Schleife bewegt. Wir haben in Folge 1 die Marktbegriffe sortiert (Context, Harness, Loop Engineering), in Folge 2 gezeigt, wie Korrektheit strukturell gesichert wird, und in Folge 3 beleuchtet, wo Loops in der Praxis trotzdem scheitern können. Alle diese Begriffe beantworten dieselbe, schmale Frage: Wie kommen Agenten zuverlässig zum Code?

KI Engineering fängt dort an, wo diese Frage aufhört. Seit Frühjahr 2026 arbeiten wir bei codecentric mit einem intern entwickelten Denkrahmen: vier ineinandergreifenden Loops für Coding, Validation, Learning und Business. Dieser Blogpost zeigt das Modell zum ersten Mal als Ganzes. Wie die vier Loops verschachtelt sind und wie der Business-Loop über Enterprise Context Management mit den technischen Loops verbunden ist. Der Grund, warum das zählt: Eine Kette ist nur so stark wie ihr schwächstes Glied, und das schwächste Glied ist selten der Coding-Loop. Es ist die Frage, ob wir überhaupt das Richtige bauen. Das Loop-Modell ist kein Framework, das wir verkaufen, sondern die gemeinsame Sprache, mit der wir darüber nachdenken.

Was wir mit KI Engineering meinen – und was nicht

KI Engineering ist die Disziplin, KI-gestützte Softwareentwicklung als Gesamtsystem zu denken: Code entsteht, wird unabhängig geprüft, aus dem Betrieb wird gelernt, und das Ganze bleibt an den tatsächlichen Geschäftsbedarf gekoppelt. Coding, Validation, Learning und Business als vier Loops, die zusammen gedacht und nicht einzeln optimiert werden. Diese Disziplin ist gerade in der Entstehung, und zwar aus der Projektpraxis heraus, nicht am Reißbrett.

Drei Abgrenzungen sind uns wichtig. Erstens ist KI Engineering kein Tool. Claude Code, Codex und GitHub Copilot sind Werkzeuge, mit denen man KI Engineering betreibt, nicht die Disziplin selbst. Zweitens ist es kein lizenzierbares Framework. Es gibt keine Schulung, kein Zertifikat, kein Produkt, das man kauft. Drittens ist es nicht dasselbe wie Agentic AI. Agentic AI ist eine technische Eigenschaft moderner Systeme. KI Engineering ist die Disziplin, mit der man verantwortlich damit arbeitet.

Klassisches Software Engineering ist für eine Welt gebaut, in der das Schreiben von Code durch Menschen ein Engpass war. Daran ist vieles ausgerichtet: Wie wir Anforderungen schneiden, wie lange Reviews dauern, wann getestet wird, wie oft wir releasen. Die Methoden der letzten zwanzig Jahre optimieren diesen Engpass. DevOps beschleunigt Build und Deploy. Platform Engineering senkt die Reibung, bis der Code läuft. Alle teilen dieselbe Annahme: Schreiben ist die teure, langsame Tätigkeit. Auch Götz Markgrafs 5-Level-Modell KI-gestützter Softwareentwicklung bewegt sich in dieser Grundannahme.

KI kippt diese Annahme. Wenn Code in Minuten entsteht, verschwindet der Engpass nicht, er wandert. Er wandert dorthin, wo weiterhin Menschen gebraucht werden: in die Prüfung, ob der Code das Richtige tut, und in die Entscheidung, was überhaupt gebaut wird. Schneller schreiben beschleunigt nicht die Wertschöpfung, es verlagert nur den Druck.

Genau hier setzt KI Engineering an, und hier liegt der Unterschied zum klassischen Engineering. Der Unterschied ist nicht das bessere Werkzeug, sondern der Betrachtungsgegenstand. KI Engineering optimiert das Zusammenspiel mehrerer Loops, die unterschiedlich schnell laufen. Wer nur den Coding-Loop beschleunigt, optimiert lokal und verliert global, weil der Wert am langsamsten Glied der Kette entsteht, nicht am schnellsten.

Dazu kommt ein Effekt, den der DORA-Report seit 2025 zeigt: KI wirkt als Verstärker. Sie macht einen guten Prozess schneller und einen schlechten schlechter. Wer KI in unveränderte Abläufe steckt, bekommt die alten Probleme früher und in größerer Menge. Deshalb reicht es nicht, ein Werkzeug einzuführen. Der Prozess selbst muss sich ändern. Diese Arbeit steckt in vielen Rollen, bei Architekten, Senior-Devs, Tech-Leads, oft auch bei Product Ownern. Und wir nennen sie KI Engineering, weil sie eine Tätigkeit beschreibt, keine neue Stelle.

Die vier Loops als Landkarte

Das Modell besteht aus vier Loops. Drei davon sind technisch und liegen ineinander: Der Coding-Loop läuft viele Male innerhalb eines Validation-Zyklus, der Validation-Loop viele Male innerhalb eines Learning-Zyklus. Jeder äußere Loop enthält also viele Durchläufe des inneren. Der vierte, der Business-Loop, steht nicht in dieser Verschachtelung. Er ist über Enterprise Context Management angedockt und liefert den technischen Loops den Input: was gebaut wird und woran es gemessen wird. Das Modell beschreibt vier Loops, die in jeder Software-Entwicklung mit oder ohne KI vorkommen. Was sich mit KI ändert, ist die Geschwindigkeit und die Asymmetrie zwischen ihnen.

Coding-Loop & White Box QA – Entsteht der Code, ist er korrekt?

Der Coding-Loop ist die innerste Schleife: Code generieren, lokal prüfen, anpassen, wieder prüfen. Dazu gehört alles, was mit vollem Zugriff auf die Internals läuft. Unit Tests, Code Review, Static Analysis, Security Scanning, Compliance Checks. KI wirkt hier am stärksten, weil sie genau diesen Zugriff hat: Sie kennt den Code, die Spezifikation, die Testhistorie und kann in Sekunden iterieren. Der größte Teil dessen, was der Markt heute unter KI-gestützter Entwicklung versteht, spielt sich in diesem Loop ab.

Der Loop hat eine eingebaute Grenze: Er prüft nur, was in ihm definiert ist. Ist die Spezifikation lückenhaft, fehlen die Edge Cases, sind die Architektur-Constraints nicht beschrieben, dann merkt der Coding-Loop das nicht. Er liefert Code zu einem Problem, das so vielleicht gar nicht gestellt war. Deshalb braucht es eine zweite Ebene, die unabhängig prüft: den Validation-Loop.

Validation-Loop & Black Box QA – Würde die Software für jemanden funktionieren, der nicht beteiligt war?

Der Validation-Loop prüft aus Distanz. Tests, die unabhängig vom erzeugenden System laufen. E2E-Tests aus Nutzersicht, Integrationstests gegen echte Systeme, Akzeptanztests, die der Agent nie gesehen hat, Penetration Tests, die das System angreifen statt es zu verstehen. Die Analogie stammt aus dem Machine Learning. Ein Holdout-Set ist ein Datensatz, den das Modell im Training nie gesehen hat, damit es sich nicht selbst validiert. Der Validation-Loop ist das Holdout-Set für Software: Er verhindert, dass das System seine eigene Arbeit als gut genug durchwinkt. Wie AI Code Review diesen Loop strukturell absichert, haben wir in Folge 2 dieser Reihe im Detail gezeigt.

White Box und Black Box prüfen dieselben Fragen aus zwei Richtungen. Der Coding-Loop findet mit vollem Zugriff Struktur- und Compliance-Fehler. Der Validation-Loop findet von außen die Nutzungs- und Angriffsfehler, die man mit Innensicht übersieht. Beide sind nötig, weil sie unterschiedliche Fehlerklassen erwischen.

Ohne diesen Loop bleiben drei Auswege, und alle drei tragen nicht: Menschen prüfen alles selbst (skaliert nicht). Man auditiert erschöpfend (zu langsam). Oder man akzeptiert ungeprüft (zu hohes Risiko). Der Grund für die Notwendigkeit liegt nicht darin, dass Menschen zu wenig aufpassen. Er liegt im Tempo. Zwischen Generierung und menschlicher Erfassung entsteht eine Lücke, die kein Aufpassen mehr schließt.

Learning-Loop – Funktioniert die Software tatsächlich, liefert sie Wert?

Der Learning-Loop ist der am meisten unterschätzte der vier. Coding- und Validation-Loop lassen sich rein über Software schließen. Der Learning-Loop nicht. Er schließt sich erst, wenn Daten aus der Produktion zurückfließen: Nutzungsverhalten, Performance, Incidents, Business-Kennzahlen. Ohne diesen Rückfluss baut man schneller, weiß aber nicht, ob das Gebaute trägt.

Das ist der Unterschied zwischen schneller bauen und schneller lernen. Die anderen drei Loops sind nur so gut wie das, was über den Learning-Loop in sie zurückkommt: bessere Tests im Coding-Loop, schärfere Akzeptanzkriterien im Validation-Loop, klarere Prioritäten im Business-Loop. Wer KI einführt, ohne diese Rückkopplung technisch und organisatorisch zu verankern, hat einen sehr schnellen Bauplatz, aber kein System, das aus seiner eigenen Produktion lernt.

Business-Loop – Was wird gebaut, und warum?

Der Business-Loop sitzt nicht in der technischen Verschachtelung. Er ist über Enterprise Context Management angedockt und entscheidet, welches Problem überhaupt gelöst wird, mit welcher Priorität und gegen welche Akzeptanzkriterien. Diese Entscheidungen werden nicht durch einen schnelleren Coding-Loop besser. Sie werden besser durch Klarheit über Geschäftsziele, Marktrealität und die organisatorischen Bottlenecks, die bestimmen, wie schnell überhaupt entschieden wird.

Wer das übergeht und KI nur als Beschleuniger einsetzt, beschleunigt das Falsche. Ein Team baut in zwei Wochen ein Feature, das ein Stakeholder nie wollte, weil die Spezifikation aus einer alten Diskussion stammte. Die Lösung liegt nicht im Coding-Loop. Sie liegt in einem Business-Loop, der schnell genug ist, um eine geänderte Anforderung zu erfassen, bevor sie zu fertigem Code am Bedarf vorbei wird. Damit steht die Frage im Raum, die der Markt bisher kaum stellt: nicht wie der Agent zuverlässiger Code schreibt, sondern wie der Geschäftsbedarf überhaupt in den Coding-Loop kommt. Das ist die Brücke, um die es im nächsten Abschnitt geht.

Die Brücke zum Business – warum sie die schwerste ist

Die aktuelle Marktdiskussion bleibt im Coding-Loop. Wie wird der Agent zuverlässiger, wie wird die Loop-Architektur stabiler, wie sieht ein guter Harness aus? Wichtige Fragen, aber alle innerhalb des ersten der vier Loops. Kaum jemand redet über die Brücke vom Coding-Loop zum Business-Loop: wie Domänenwissen, Geschäftsbedarf und organisatorische Constraints in den Coding-Loop hineinkommen, und wie die Erkenntnisse aus der Entwicklung zurück in die strategischen Entscheidungen fließen. Das ist die strategisch wichtigste Brücke, und sie ist am wenigsten besetzt.

Diese Brücke hat einen Namen: Enterprise Context Management. Der Begriff ist jung und noch nicht standardisiert, manche nennen es Context Engineering oder Context Layer. Gemeint ist mehr als Dokumentensuche oder klassisches RAG. Es geht darum, einem Loop den richtigen, aktuellen und berechtigten Kontext bereitzustellen, mit Angabe von Quelle und Gültigkeit: Was bedeutet Kunde, Vertrag oder Umsatz in diesem Unternehmen, welche Datenquelle ist verbindlich, welche Regeln gelten, welche Entscheidungen wurden vorher getroffen? Der Architekturgedanke dahinter ist einfach: Nicht jeder Agent baut sich seine eigene Wahrheit, alle greifen auf einen gemeinsamen, governbaren Kontext zu. Wie man Fachwissen in eine Form bringt, die Menschen lesen und Agenten verarbeiten können, hat codecentric im Konzept der konsumierbaren Domäne beschrieben, einer pragmatischen Realisierung für ein fachlich komplexes Projekt.

Schwer ist diese Brücke aus zwei Gründen. Erstens scheitern in unserer Projekterfahrung mehr KI-Initiativen am Business-Anschluss als am technischen Loop. Eine Versicherung baute eine KI-gestützte Berechnungslogik, technisch sauber, aber drei Monate vor dem Live-Gang zeigte sich, dass eine Regulierungsänderung die zugrunde liegende Geschäftsregel längst verschoben hatte. Hätte ein Business-Loop diese Information früher in den Coding-Loop gespeist, wären Monate gespart gewesen. Zweitens macht Enterprise Context Management schlechte Unternehmensdaten sichtbar, korrigiert sie aber nicht. Uneinheitliche Stammdaten, widersprüchliche KPI-Definitionen, unklare Zugriffsrechte fallen erst auf, wenn ein Agent sie nutzen soll. Deshalb ist das kein Produkt, das man installiert, sondern ein Reifeprozess. Wir vertiefen ihn in Folge 5 und Folge 6 unserer Blogreihe.

Wann macht das einen Unterschied?

• Wenn dein Coding-Loop läuft, aber das Falsche baut → Business-Loop-Anschluss prüfen. Die Spec stimmt vermutlich nicht mit dem aktuellen Bedarf überein.
• Wenn dein Team in sechs Monaten unwartbaren Code hat → Validation- und Learning-Loop-Lücken. Wartbarkeit entsteht durch Rückkopplung, nicht durch bessere Generierung.
• Wenn KI „eingeführt" wurde, aber niemand sagen kann, was sich geändert hat → das ganze Modell. Die KI sitzt vermutlich im Coding-Loop, ohne Verbindung zu Validation, Learning, Business.

KI Engineering ist nicht das nächste Buzzword. Es ist die Disziplin, die entsteht, wenn man aufhört, KI als Tool zu sehen – und anfängt, sie als Systemveränderung zu denken. Wie das konkret in Verification-Praxis übersetzt wird, ist Thema von Folge 5.

FAQ

Ist das Loop-Modell ein Framework wie Scrum? Nein. Es ist ein Denkmodell, keine Methodik. Loops funktionieren auch ohne KI, das Modell trifft keine Aussage darüber, ob oder wie KI eingesetzt wird.

Wie unterscheidet sich KI Engineering von DevOps oder Platform Engineering? DevOps löst Build/Deploy-Bottlenecks. Platform Engineering schafft interne Dev-Plattformen. KI Engineering integriert die KI-Wirkung in alle Loops, inklusive Business-Anschluss.

Ist das eine codecentric-eigene Sache oder Standard? Eigene Synthese – der Kern ist das codecentric Loop-Modell, ein internes Denkwerkzeug, entwickelt seit Frühjahr 2026 und geschärft in Kundenprojekten.

Brauche ich das Modell, um KI im Unternehmen einzuführen? Nein. Aber wenn du die Patterns aus Folge 3 spürst, ist das Modell ein nützlicher Klärungs-Rahmen.

Was hat ECM mit KI zu tun? Enterprise Context Management ist die Brücke zwischen Business-Anforderungen und KI-fähigem Coding-Kontext. Ohne ECM halluziniert der Coding-Loop, auch wenn die Modelle perfekt sind.

Weiterführende Lektüre

In Folge 5 vertiefen wir den Begriff, den wir in dieser Reihe schon mehrfach gestreift haben: Verification Tax. Wir klären, was es bedeutet, wenn die Prüfungs-Kosten von KI-gestützter Entwicklung sichtbar werden und warum sie kein Bug, sondern Feature sind.