Das zweite Deliverable
Wenn ich mit anderen Entwicklern darüber spreche, wie ich KI in meiner täglichen Arbeit einsetze, merke ich schnell, dass ich vermutlich zu den eher konservativeren Nutzern gehöre. Nicht, weil ich den Tools misstraue. KI ist für mich ein wichtiges Werkzeug geworden, und ich möchte sie nicht mehr missen. Sondern weil ich eine Bedingung an ihren Einsatz stelle, die ich nicht verhandeln möchte.
Ich will verstehen, was ich da an Software schreibe. Von Anfang bis Ende.
Die Hoheit über das, was da an Software entsteht, gebe ich, zumindest für den Moment, nicht aus der Hand. KI darf und soll mir assistieren. KI soll mir aber nicht meinen Job abnehmen. Das ist übrigens keine romantische Verklärung des Handwerks, sondern eine ziemlich nüchterne Überlegung darüber, wofür ich in Projekten eigentlich bezahlt werde.
Wie das in der Praxis aussieht, lässt sich an einem konkreten Beispiel gut zeigen.
Vor kurzem hatte ich die Aufgabe, eine Architektur für eine Anwendungslandschaft zu konzipieren, die auf Microsoft Azure laufen soll. Mit Azure hatte ich bis dahin keine wirklich tiefen Erfahrungen sammeln können. Ich war in der Vergangenheit so gut wie immer im AWS Umfeld unterwegs. Dort kenne ich mich aus, dort kenne ich die Produkte, ich weiß, wie ich sie aufsetze, konfiguriere und absichere. Für Azure galt das alles nur bedingt.
Für sämtliche Ressourcen, die ich in der Cloud aufsetze, nutze ich grundsätzlich Terraform. In UIs herumzuklicken, um Services aufzusetzen, ist nicht nur nicht reproduzierbar, sondern schlicht und ergreifend zu aufwändig und fehleranfällig. Ich hätte an dieser Stelle jetzt eine kurze Diskussion mit Claude führen können, in der ich meine Anforderungen präzisiere, und mir anschließend die Terraform Konfigurationsdateien schreiben lasse. Das hätte wahrscheinlich sogar funktioniert.
Wollte ich aber nicht.
Ich will verstehen, was ich da aufsetze. Ich will verstehen, wie die einzelnen Komponenten zusammenhängen. Nur dann bin ich wirklich in der Lage zu beurteilen, ob das Setup meine Anforderungen tatsächlich abdeckt. Und nur dann bin ich wirklich in der Lage zu erkennen, ob nicht irgendwo offene Scheunentore entstehen, die Zugriffe auf das System erlauben, die ich so nicht haben will.
Mein Vorgehen war deshalb ein anderes.
Ich habe der KI zunächst eine kurze Übersicht über mich gegeben. Wer ich bin, was ich mache, wo meine bisherigen Erfahrungen liegen. Damit die KI weiß, wo sie mich abholen muss. Ich habe dabei explizit meine Erfahrungen mit AWS erwähnt und die KI instruiert, die vorgeschlagenen Komponenten, Konfigurationen und Konzepte mit ihren Entsprechungen bei AWS zu vergleichen. So konnte ich mich schneller zurechtfinden und die Azure Spezifika mit dem abgleichen, was ich ohnehin schon kannte.
Die vorgeschlagenen Terraform Konfigurationen habe ich anschließend manuell angepasst und in eine Struktur überführt, die zu mir und zum Projekt passt. Beim Deployment ergaben sich dann die üblichen kleinen Punkte. Manches funktionierte nicht so, wie ich mir das vorgestellt hatte. An anderen Stellen hatte die KI Dinge halluziniert, die schlicht und ergreifend nicht existierten. Aus dem Austausch wurde also eine längere Diskussion, ein Hin und Her mit Verständnisfragen und Fehleranalysen.
Diese längere Diskussion hat am Ende zu zwei Ergebnissen geführt.
Das erste Ergebnis war eine funktionierende Terraform Konfiguration für ein Deployment bei Microsoft Azure. Auf den ersten Blick genau das, was jeder als Ziel der Übung bezeichnen würde.
Das zweite Ergebnis war vielleicht noch wichtiger. Verständnis in meinem Kopf. Verständnis der Konzepte hinter Azure und ein Verständnis davon, was tatsächlich hinter den Kulissen passiert. Genau dieses zweite Ergebnis wird in der Diskussion über KI Nutzung nach meiner Beobachtung häufig ignoriert. Wir konzentrieren uns auf das erste Deliverable, auf das unmittelbare Artefakt, auf die Geschwindigkeit, mit der es entstanden ist.
Doch wenn ich mich allein darauf verlasse, bin ich im wahrsten Sinne des Wortes verlassen.
Was passiert, wenn mein Kunde eine professionelle Bewertung dieses Setups haben möchte? Was passiert, wenn die Compliance Abteilung oder einfach jemand mit Interesse wissen möchte, was im Falle eines Angriffs geschieht? Was passiert, wenn jemand einen Abzug der Datenbank benötigt und ich erklären muss, wer diesen Zugriff unter welchen Bedingungen bekommt und wo die Daten anschließend liegen?
In solchen Situationen zu antworten, dass die KI das so vorgeschlagen oder entschieden hat, lässt sich mit meinem Verständnis von professioneller Softwareentwicklung nicht vereinbaren. Ich habe das entschieden. Eine KI kann und soll mich dabei beraten und mir den Weg dorthin einfacher machen. Aber ich bin derjenige, der am Ende den Kopf dafür hinhalten muss, dass das Ergebnis qualitativ hochwertig ist. Und ehrlich gesagt bin ich auch derjenige, der das will.
Das ist übrigens kein Argument gegen Geschwindigkeit. Der Weg über die Erklärung, den Vergleich und die Diskussion war für mich nicht wesentlich langsamer als der direkte Weg zum fertigen Artefakt. Er hat nur an einer anderen Stelle Aufwand erzeugt, nämlich bei mir. Dieser Aufwand ist eine Investition, die sich beim nächsten Azure Projekt auszahlt, beim nächsten Sicherheitsreview und in jedem Gespräch, in dem ich für meine Architekturentscheidungen einstehen muss.
Wir hören im Moment sehr viel über den ersten Teil. Darüber, was KI scheinbar alles kann. Wenn wir uns den zweiten Teil nicht immer wieder bewusst machen, landen wir irgendwann an einem doppelten Problem. Wir sind dann nicht nur an dem Punkt, an dem man uns tatsächlich nicht mehr braucht. Wir sind auch an dem Punkt, an dem keine qualitativ hochwertige Software mehr im Einsatz ist, weil niemand mehr versteht, was da eigentlich läuft.
Ich möchte beides vermeiden. Deshalb nutze ich KI so, wie ich sie nutze.