Früher luden wir unsere Kunden und Partner regelmässig zu technischen Vorträgen ein, sogenannten “Get Togethers”. Besonders gut ist mir der Anlass vom 29. November 2017 in Erinnerung. Bitcoin war angesagt und mein Vortrag hiess “Trust Shifts – Vertrauen im digitalen Zeitalter”. Es ging darum, wie Vertrauen im sozialen Kontext und innerhalb von Organisationen funktioniert, mit welchen Fassaden wir abstrahieren und vereinfachen, wie schlecht Vertrauen in grossen Organisationen skaliert und wie funktionierende Prozesse der Integrität einer Firma helfen.
Das Thema kam mit den KI-Agenten wieder in den Fokus. Es gibt eine neue Fassade. Ähnlich wie beim Google-Suchfeld versteckt sich hinter den Agenten ein System, zu dem ich entweder Vertrauen aufbaue, oder eben nicht. Welchen Antworten vertraue ich, welchen nicht? Was muss ich kontrollieren, bevor ich mein Leben danach ausrichte? Oder welche Konsequenzen haben auch die selbständigen Aktionen dieses Dschinni (ich nenne die Agenten gerne “Dschinni”, wie Kent Beck), der meine Wünsche erfüllt?
Für uns Software-Ingenieure ist diese Frage lebenswichtig: wir verdienen unser Geld, indem wir Verantwortung über digitale Prozesse übernehmen. Wir sitzen mit Kunden zusammen und versuchen einen digitalen Prozess möglichst der Realität entsprechend zu spezifizieren und dann zu implementieren. Unser Ruf hängt davon ab, dass wir dies mit grösster Gewissenhaftigkeit tun. Wir brechen Komplexität runter, schätzen Konsequenzen und isolieren Risiken.
Dem Dschinni vertrauen?
Heute schreibt nicht mehr nur der Mensch Code, sondern auch der KI-Agent. Das stellt uns vor ein Problem: das Tempo und die Grösse der Software nimmt zu. Wie halten wir als Software-Ingenieure da mit? Wie fällen wir gute Entscheidungen darüber, ob wir Verantwortung über immer umfangreichere Software übernehmen?
Als Software-Ingenieurbüro, das sich Gründlichkeit auf die Fahnen schreibt, hatten wir schon immer bewährte Mittel zur Vertrauensbildung in Code. Massgebend sind zum Beispiel, wie viele Stars eine Software-Bibliothek auf Github hat, oder wie viele offene, unaufgearbeitete Issues. Oft kennen wir auch die Maintainer persönlich von Konferenzen. Wir haben auch technische Kennzahlen, wie automatisierte Tests mit Code-Coverage. Die ist bei uns selbst immer 100 %, ähnlich wie die doppelte Buchführung, aber halt für Software. Auch in Code-Reviews hat es schon immer eine Rolle gespielt, wer die Änderung machen will: der Praktikant? Oder ein Senior-Software-Ingenieur mit 10 Jahren Erfahrung?
Was nun aber, wenn ein Dschinni hinter der Code-Änderung steckt? Was, wenn ein Praktikant oder sogar der Kunde selbst nun viel, 100%-test-abgedeckten und plausibel aussehenden Code produziert?
Wir haben die Erfahrung gemacht, dass die Vertrauensbildung hier schlecht skaliert, ähnlich wie bei den grossen Organisationen in meinem Vortrag von 2017. Das Spannungsfeld ist der erhöhte Aufwand für Code-Reviews gegenüber dem Kunden, der schneller und mehr Resultate erwartet. Schneller, mehr und besser skaliert nicht natürlich mit Verantwortungsbewusstsein mit. Es sind neue Wege gefragt und wir haben ein paar Ideen.
Der Weg des Shikigami
Wir entwickeln seit Ende letzten Jahres eine KI-Integration für Redmine, unser Ticketing-System. Der Kunde schreibt wie bisher sein Ticket, aber statt einem Menschen weist man es "Jean Claude Opus" zu und setzt es auf "To Start". Jean Claude nimmt sich das Ticket und implementiert es. Wenn er fertig ist, gibt er es dem Kunden zurück im Status "QA", was heisst, dass ein menschliches Code-Review gemacht werden soll. Wir nennen das Tool intern "Shikigamiya", das Haus der Shikigami. Die Hauptidee ist, dass Redmine uns die Kontrolle über den Entwicklungsprozess ermöglicht, auf eine Weise, die wir als Ingenieure verantworten können. Der Software-Entwicklungsprozess ist genau der gleiche, wie wenn ein Mensch umsetzen würde – nur schneller.
Werbeeinschub: Falls sich jemand für das Shikigamiya-Tool interessiert, zum Beispiel weil ihr selbst ein Redmine betreibt, können wir die Beta auch ausweiten, holt euch dazu einfach einen Lunch-Termin mit Samuel Steiner.
Der perfekte Pull-Request
Code-Änderungen werden bei uns mittels Pull-Requests (meist bei Github) vorgeschlagen. Bisher messen wir die Qualität dieser Änderungsvorschläge mit automatisierten Tests, Linters und kritischen Self-Reviews. Auch eine Referenz zum sauber spezifizierten Ticket gehört dazu. Wir wollen die Qualität unserer Pull-Requests noch weiter erhöhen mit automatischen Review-Apps. Dabei wird automatisch eine Kopie der laufenden Staging-Applikation gemacht, wo sich der Review-Ingenieur die Änderungen anschauen kann, ohne das Projekt selbst lokal aufsetzen zu müssen. Bei einem Hoster wie Deploio sind Review-Apps besonders einfach aufzusetzen, weil die Apps dort 12factor sind.
Perimeter abstecken
Die Spezifikation – immer von einem Menschen verantwortet – ist immer auch der Anhaltspunkt für automatisierte Tests. Man sagt in der Software-Entwicklung auch oft: “Die Spezifikation IST der Test” und nennt das Test-Driven-Development, kurz TDD. Der wichtigste Punkt ist hier, dass die Tests zuerst geschrieben werden. Sonst hat man einen Bias gegenüber der Implementation. Das ergibt Bugs oder Feature-Creep. Die KI-Agenten machen das sehr schlecht, sogar wenn man sie dazu anweist. Das liegt am Design des Kontext-Fensters: der Agent kann nicht vergessen oder bewusst ausblenden. Wir möchten nun Methoden einführen, um das Schreiben der automatisierten Tests möglichst von der Implementation zu trennen. Das ist ähnlich wie bei der wissenschaftlichen Methode: zuerst die Erwartung formulieren, dann messen, ob sie erfüllt wird. In diesem Themenkomplex gibt es auch alte Methoden, wie Design-by-Contract, die wir wieder hervorkramen können, um Laufzeit-Erwartungen an ein Programm zu stellen. Weiter wollen wir auch innerhalb des Codes mit algorithmischen Regelwerken (Policies) Perimeter abstecken. Es soll Orte geben, welche der Dschinni nicht anfassen darf und wo ich darauf vertrauen kann, dass sie nicht angefasst wurden, so dass ich mir im Code-Review diese Prüfungen sparen kann.
Dies braucht noch ein bisschen gemeinsame Denkarbeit innerhalb der Renuo. Die Learning Week im September 2026 ist genau der richtige Ort. Dort können wir das zusammen als Menschen anschauen und daran wachsen.
