Englische Version 

Coding Agents können den Entwicklungsalltag deutlich erleichtern. Sie helfen dabei, sich schneller in unbekanntem Code zurechtzufinden, wiederkehrende Implementierungsaufgaben zu erledigen oder operative Werkzeuge aufzubauen. Gleichzeitig bringen sie ein bekanntes Problem der Softwareentwicklung in neuer Form zurück: Der erzeugte Code kann auf den ersten Blick plausibel wirken, einfache Prüfungen bestehen und trotzdem eine wichtige Anforderung verletzen.

Genau deshalb bleibt Defence in Depth relevant, wenn Coding Agents Teil des Entwicklungsprozesses werden.

Warum Defence in Depth für Coding Agents wichtig ist

Die Geschwindigkeit in der Softwareentwicklung hat weiter zugenommen. Teams arbeiten mit neuen Modellen, neuen Werkzeugen und neuen Wegen, Features oder interne Automatisierung umzusetzen. Coding Agents passen gut in dieses Umfeld, weil sie aus Anweisungen sehr schnell Code, Tests oder Refactorings erzeugen können.

Was sich dadurch jedoch nicht verändert, ist der schwierigere Teil der Entwicklung. Es muss weiterhin klar sein, was eine Software tun soll, was sie ausdrücklich nicht tun darf und wie sie sich verhalten soll, wenn eine Situation unklar ist. Anforderungen sind in der Praxis häufig unvollständig, mehrdeutig oder leicht widersprüchlich. Ein Coding Agent versucht in solchen Fällen trotzdem, Fortschritt zu erzielen, und füllt Lücken mit Annahmen. Manchmal ist das hilfreich. Manchmal entsteht dadurch genau die Annahme, die nicht zur eigentlichen Absicht passt.

Besonders relevant wird das bei Software, die mit produktiven Accounts, Berechtigungen oder Kundendaten arbeitet. Dort kann ein kleines Missverständnis im generierten Code schnell zu einem operativen Problem werden.

Was Defence in Depth in diesem Zusammenhang bedeutet

Defence in Depth folgt einer einfachen Idee: Eine einzelne Prüfung sollte nicht allein dafür verantwortlich sein, einen kritischen Fehler zu verhindern. Stattdessen arbeiten mehrere Schutzschichten zusammen. Wenn eine Schicht versagt, begrenzt eine andere weiterhin den möglichen Schaden.

Viele Teams nutzen dieses Prinzip bereits im normalen Softwareentwicklungsprozess. Änderungen werden reviewed, Deployments laufen durch Pipelines, Automatisierung arbeitet mit begrenzten Rechten und produktive Zugriffe werden vorsichtiger behandelt als Entwicklungsumgebungen. Das ist keine besondere Vorsichtsmaßnahme, sondern solide Ingenieurspraxis.

Beim Einsatz von KI-generiertem Code wird dieselbe Denkweise noch wichtiger. Die zentrale Frage lautet nicht nur, ob der Agent lauffähigen Code erzeugt. Entscheidend ist, ob der umgebende Prozess wichtige Grenzen weiterhin schützt, wenn der generierte Code eine falsche Richtung einschlägt.

Die erste Schutzschicht bleibt eine klare Spezifikation

Wenn Coding Agents beteiligt sind, wird die Spezifikation wichtiger, nicht unwichtiger. Sind die Anweisungen ungenau, versucht das Modell trotzdem, die Aufgabe abzuschließen. Das Ergebnis ist dann oft Code, der in sich stimmig wirkt, aber auf Annahmen basiert, die niemand bewusst freigegeben hat.

Ein gutes Architekturdokument muss nicht lang sein. Es sollte jedoch klar beschreiben, welches Ziel verfolgt wird, welche Regeln unverhandelbar sind, unter welchen Bedingungen die Verarbeitung stoppen muss und welches Verhalten im Fehlerfall erwartet wird. Genau hier liegt in der Praxis oft weiterhin die eigentliche Engineering-Arbeit. Und genau hier lassen sich viele Risiken reduzieren, bevor überhaupt Code erzeugt wird.

Dieser Punkt wird leicht übersehen, weil Coding Agents den Eindruck vermitteln können, Implementierung sei die größte Herausforderung. Tatsächlich bleibt der schwierige Teil häufig derselbe: Das Problem muss so präzise beschrieben werden, dass die spätere Umsetzung vertrauenswürdig geprüft werden kann.

Ein praktisches Beispiel: Benutzer zwischen Systemen synchronisieren

Ein typisches Integrationsszenario ist die Synchronisierung von Benutzerkonten zwischen einem zentralen Benutzerverwaltungssystem und mehreren angebundenen Systemen. Das zentrale System dient als Quelle der Wahrheit, während nachgelagerte Plattformen regelmäßig damit abgeglichen werden.

Auf dem Papier klingt das nach einer Routineaufgabe. In der Praxis wird es sensibler, sobald Löschungen Teil des Ablaufs sind. Ein Synchronisationswerkzeug kann in einem Zielsystem ein Konto finden, das im zentralen Verzeichnis nicht mehr existiert, und dieses Konto als verwaist einstufen. Von dort ist der Schritt zur automatischen Löschung naheliegend.

Ein Konto kann aus Sicht der Benutzerverwaltung aber verwaist sein und trotzdem noch mit relevanten Daten verbunden sein. Es kann Eigentümer von Datensätzen, Dateien, Projektzuständen oder anderen Informationen sein, die weiterhin benötigt werden. Sobald diese Möglichkeit besteht, reicht reine Konsistenz zwischen den Systemen nicht mehr aus.

Die Regel muss dann strenger formuliert werden: Ein Benutzer darf nicht entfernt werden, solange noch relevante Daten vorhanden sind.

Wo die typische Falle entsteht

An dieser Stelle wird Defence in Depth sehr praktisch. Es reicht nicht, einmal früh im Ablauf zu prüfen, ob noch Daten existieren. Diese Prüfung ist wichtig, sie darf aber nicht die einzige Schutzmaßnahme sein.

In dem Fall, auf dem dieser Beitrag basiert, delegierte die generierte Implementierung das Entfernen von Benutzerkonten am Ende an ein externes Kommandozeilenwerkzeug. Dieses Werkzeug unterstützte einen Parameter, der eine Löschung auch dann erzwang, wenn noch verknüpfte Daten vorhanden waren. Genau dieser Parameter war im Skript enthalten.

Auf den ersten Blick kann diese Entscheidung harmlos wirken. Eine mögliche Begründung wäre, dass vorherige Prüfungen bereits bestätigt hatten, dass der Benutzer sicher entfernt werden kann. Der zusätzliche Parameter würde dann lediglich dafür sorgen, dass der Befehl zuverlässig durchläuft. Das Problem liegt darin, dass diese Begründung vollständig davon abhängt, dass die vorgelagerte Logik immer korrekt ist.

Wenn die Klassifizierung falsch ist, die Datensicht veraltet ist oder zwischen Prüfung und Ausführung ein Fehler entsteht, entfernt die erzwungene Löschung die letzte Barriere. Ohne diesen Parameter hätte das Zielsystem noch die Möglichkeit, die Operation abzulehnen. Mit ihm wird der gesamte Ablauf weniger fehlertolerant.

Genau darin liegt der Kern von Defence in Depth. Der letzte Schritt sollte sicher fehlschlagen können, wenn eine frühere Annahme unvollständig oder falsch war.

Was sich dadurch im Review verändert

Beim Review von Agent-generiertem Code ist die wichtigste Frage oft nicht, ob der erwartete Ablauf funktioniert. Hilfreicher ist die Frage, ob die Implementierung das gewünschte Sicherheitsmodell bewahrt.

Dafür braucht es eine etwas andere Review-Gewohnheit. Es reicht nicht, nur auf das direkte Verhalten einer Funktion oder eines Skripts zu schauen. Der Code sollte mit der architektonischen Regel verglichen werden, die er schützen soll. Wenn die Spezifikation festlegt, dass eine Löschung niemals stattfinden darf, solange Daten existieren, dann sollte jeder Teil des Workflows diese Regel verstärken und nicht stillschweigend abschwächen.

Deshalb bleiben Tests, Dokumentation und menschliches Review wichtig. Im Laufe der Zeit entstehen durch Refactorings ungenutzte Pfade, Tests werden lauter statt hilfreicher und Dokumentation entfernt sich von der tatsächlichen Implementierung. Coding Agents können diese Entwicklung ebenso beschleunigen wie produktive Arbeit. Defence in Depth hilft dabei, kritische Grenzen über mehrere Ebenen hinweg sichtbar zu halten.

Fazit

Coding Agents sind nützliche Werkzeuge, aber sie ersetzen kein sorgfältiges Systemdesign. Im Gegenteil: Sie machen es wichtiger, harte Regeln klar zu formulieren und sie über Architektur, Implementierung, Tests und Betrieb hinweg zu erhalten.

Für Synchronisationsprozesse und andere Formen operativer Automatisierung bedeutet Defence in Depth, dass keine einzelne Prüfung die gesamte Verantwortung für Sicherheit tragen sollte. Eine klare Spezifikation, ein sorgfältiges Review, vorsichtige Ausführung und ein finaler Befehl, der im Zweifel sicher scheitert, spielen zusammen. Das ist kein Argument gegen Automatisierung. Es ist ein Weg, Automatisierung vertrauenswürdiger zu machen.

Call to Action

Wenn euer Team Coding Agents in Identity Workflows, Systemintegration oder operativer Automatisierung einführt, unterstützt Jaraco dabei, die Architektur rund um diese Prozesse zu prüfen und sinnvolle Schutzmechanismen zu identifizieren.