Ein Code-Assistent macht Vorschläge; eine Person akzeptiert diese, integriert sie und übernimmt die Verantwortung. Diese Verantwortungskette bleibt auch dann bestehen, wenn sich die Person, die den Entwurf verfasst, ändert – und das ist auch gut so: Nur so kann sichergestellt werden, dass es jemanden gibt, den man fragen kann, wenn das System im Produktivbetrieb unerwartete Probleme verursacht.
Das Problem entsteht, wenn Verantwortung stillschweigend verwässert wird, ohne dass sich jemand explizit dafür entscheidet. Niemand erklärt, für seinen Code nicht mehr verantwortlich zu sein. Kurz gesagt: Die Kluft zwischen denen, die ihn akzeptieren, und denen, die ihn verstanden haben, vergrößert sich.
Diese Verwirrung ist kostspielig, da sie das Budget belastet und die Glaubwürdigkeit der Initiative untergräbt. Fragt man sechs Monate später nach Verbesserungen, lautet die ehrliche Antwort meist: «Die anfängliche Erfahrung», und das rechtfertigt kein Transformationsprogramm.
Drei Mechanismen, alle drei stumm:
Die Rezension wird oberflächlich. Bei häufigen, großen Änderungen verschiebt sich die Haltung des Gutachters von «Ich verstehe das und stimme zu» zu «Es erscheint vernünftig». Der DORA-Bericht von 2024 maß den Gesamteffekt: Mit zunehmender KI-Nutzung sank die Lieferstabilität um 7,21 TP3T, was mit dem Anstieg der Änderungsmengen zusammenhängt.
Die Urheberschaft verschwimmt. In einem Fall wird die Frage «Wer hat das geschrieben?» mit der Antwort «Wir haben es erstellt» beantwortet. Diese Antwort verhindert den weiteren Verlauf des Gesprächs.
Vertrauen ersetzt Überprüfung. Der Code funktioniert im Test, daher wird angenommen, dass er gut ist. Funktionieren und gut sein sind jedoch zwei verschiedene Dinge: Letzteres umfasst auch, was passiert, wenn sich der Kontext ändert.
Im selben DORA-Bericht gaben 39,21 % der Entwickler an, wenig bis gar kein Vertrauen in den generierten Code zu haben. Dies ist ein paradoxes Ergebnis: Es besteht zwar ein geäußertes Misstrauen, doch die Menge des akzeptierten Codes nimmt zu.
Es geht nicht um Schuldzuweisungen. Es geht um die Fähigkeit, vier Fragen zu jedem Teil des Systems zu beantworten:
Wer alle vier Fragen beantworten kann, ist für den Code verantwortlich, unabhängig davon, ob er von einer Person oder einem Tool geschrieben wurde. Wer auch nur eine der Fragen nicht beantworten kann, ist nicht verantwortlich, selbst wenn er im Repository als Autor aufgeführt ist.
Rolle | Was bietet das Tool? | Was bleibt menschlich? |
|---|---|---|
Design | Alternativen und Beispiele | Die Wahl treffen und die Wahl akzeptieren |
Durchführung | Funktionsentwurf | Prüfen Sie, ob es die Erwartungen des Unternehmens erfüllt. |
Revision | Erkennung bekannter Muster | Beurteilung der Eignung und Folgen |
Betrieb | Warnungen und Diagnose | Entscheiden, was zu tun ist, wenn etwas schiefgeht |
Verantwortung | Keiner | Alle |
Der letzte Satz ist nicht rhetorisch. Kein Tool teilt die Verantwortung gegenüber einem Kunden, einem Prüfer oder einem Gericht. Die Organisation ist für das Verhalten ihrer Software verantwortlich, unabhängig davon, wie diese entwickelt wurde, wie im Fall des Air Canada-Chatbots, der 2024 beigelegt wurde, festgestellt wurde.
Was man nicht erklären kann, lässt sich nicht miteinander verbinden. Die Grundregel. Es ist nicht erforderlich, jedes Detail zu verstehen, sondern lediglich die vier oben genannten Fragen beantworten zu können.
Für jede Änderung ist eine namentlich verantwortliche Person zuständig. Kein Team. Eine Person, die für diesen Teil des Systems verantwortlich ist und der Fragen gestellt werden können.
Die wichtigsten Tests werden von einer einzigen Person verfasst. Wenn dasselbe Tool sowohl die Implementierung als auch den Test zur Validierung generiert, schließt sich der Kreislauf und es wird nichts Relevantes geprüft.
Das Ausmaß der Änderung ist begrenzt. Diese Maßnahme ermöglicht die drei vorhergehenden. Eine grundlegende Änderung kann nicht gründlich überprüft werden, egal wie gut die Absichten des Prüfers auch sein mögen.
Wenn Ihr Unternehmen die Entwicklung auslagert, hat dieses Gespräch direkte vertragliche Auswirkungen. Drei Fragen an den Anbieter:
Wer ist für Fehler im gelieferten Code verantwortlich? Ein Fehler ist keine Änderung des Leistungsumfangs. Er sollte kostenlos behoben und schriftlich dokumentiert werden. In unserem Fall ist es die Rain-Garantie: Wir beheben alle Fehler im von uns gelieferten Code – ein Leben lang.
Können Sie sechs Monate später noch irgendeinen Teil des Systems erklären? Der Test ist einfach: Bitten Sie um eine Erklärung eines zufällig ausgewählten Moduls.
Welche Entscheidungsdokumentation wird bereitgestellt? Nicht ein detaillierter Kommentar, sondern vielmehr eine Erklärung, warum die einzelnen Ansätze gewählt und welche verworfen wurden. Das ermöglicht es einem anderen Team, die Führung zu übernehmen.
Ein Lieferant, der diese drei Bedingungen akzeptiert, signalisiert damit, dass er die Verantwortungskette intakt hält. Ein Lieferant, der sie nur bedingt erfüllt, zeigt auf, wo die Lücke liegen wird.
Für einen technischen Leiter, der den aktuellen Leistungsstand seines Teams ermitteln möchte, gibt es eine einstündige Übung: Wählen Sie nach dem Zufallsprinzip drei Teile des Systems aus und bitten Sie die dafür Verantwortlichen, die vier Fragen zu beantworten..
Das Ergebnis misst nicht die Qualität des Codes. Es misst etwas Wichtigeres: ob die Organisation ihr System kontrolliert oder es ihr lediglich besitzt.
Die Person, die die Software akzeptiert und in das System integriert, und die Organisation, die sie in Produktion nimmt, tragen die Verantwortung. Kein Tool teilt die Verantwortung gegenüber einem Kunden, einem Prüfer oder einem Gericht: Das Unternehmen ist für die Funktionsweise seiner Software verantwortlich, unabhängig davon, wie diese entstanden ist.
Mit vier Fragen: Welchen geschäftlichen Nutzen hat das? Warum ist es so, wie es ist, und welche Alternative wurde verworfen? Was würde bei einer Änderung kaputtgehen? Und wie kann man sicher sein, dass es weiterhin funktioniert? Wer alle vier Fragen beantworten kann, ist für den Code verantwortlich, egal ob er von einem Menschen oder einem Tool geschrieben wurde.
Durch drei stillschweigende Entwicklungen: Die Überprüfung wird oberflächlich, wenn die Änderungen an Umfang zunehmen, die Urheberschaft verschwimmt, bis die Antwort auf einen Vorfall lautet: «Wir haben ihn verursacht», und das Vertrauen in das Bestehen von Tests ersetzt die Überprüfung, ob das Verhalten den Erwartungen des Unternehmens entspricht.
Viertens: Niemand führt Zusammenführungen durch, die er nicht erklären kann; für jede Änderung ist eine namentlich genannte Person und nicht ein Team verantwortlich; kritische Tests werden von einer Person und nicht mit demselben Tool geschrieben, das die Implementierung hervorgebracht hat; und der Umfang der Änderungen ist begrenzt, damit eine Überprüfung möglich ist.
Sie müssen für Mängel im gelieferten Code kostenlos und schriftlich verantwortlich gemacht werden, in der Lage sein, sechs Monate später jeden Teil des Systems zu erklären und eine Dokumentation der getroffenen Entscheidungen und der verworfenen Alternativen vorzulegen, nicht nur Kommentare im Code.
Laut dem DORA-Bericht von 2024 äußerten 39,21 % der Befragten wenig oder gar kein Vertrauen in das System. Dieses Ergebnis ist relevant, da es mit einem Anstieg der Anzahl akzeptierter Tests einhergeht, was darauf hindeutet, dass geäußertes Misstrauen nicht zwangsläufig zu mehr Tests führt.
Könnte Ihr Team einen Teil Ihres Systems erläutern? Unser technisches Audit bewertet Architektur, Code, Schulden und tatsächliche Wartbarkeit – schriftlich und innerhalb von 10 Werktagen. Audit anfordern → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
