Von Maurern und KI

Maurer sind Macher. Wir von der esveo sind es auch, aber gehen nicht ohne Vorbereitung ins Rennen. Eine Anekdote auf der Weihnachtsfeier trieb mich zu der Frage, inwiefern ich mit meinem Werkzeug der Konkurrenz durch KI noch voraus bin. Als Consultant frage ich viel und leite Empfehlungen ab – das kann eine KI auch. Unzählige Vibe Coding Erfolgsstories sprechen Bände. Doch noch gibt es einige Aspekte, die mir insbesondere in komplexen Fragestellungen einen strategischen Vorteil gegenüber der KI gewähren, welche ich im folgenden Text näher beleuchte.

Die Weihnachtsfeier und der Stein des Anstoßes

Neulich hatten wir Weihnachtsfeier und wie zu jedem Teamevent starteten wir mit einer Aktivität, die das ganze Team einbindet: Diesmal trafen wir uns auf dem Weißen Hirsch und verabredeten uns in der “Hall of Game” auf eine Reihe von Spielen ähnlich denen von Schlag den Raab / Schlag den Star. Drei Stunden lang spielten wir neun verschiedene Spiele in drei Teams – wurden in Form von analogem Rocket League und Nerf-Gun-Scheibenschießen als Firma vollends abgeholt, wo doch diese beiden Dinge vor etwa sieben Jahren noch fest zu unserem Firmenalltag gehörten.

Beim Ehrgeiz gepackt, lieferten sich alle drei Teams ein enges Kopf-an-Kopf-Rennen, das erst auf dem letzten Meter entschieden wurde. Spannend war es, kurzweilig ohnehin und insgesamt sehr zu empfehlen! Im Kopf geblieben ist mir seitdem aber vor allem das, was uns der Spielleiter am Ende sagte: “Ich hatte neulich eine Gruppe Maurer da, da musste ich nicht groß die Regeln erklären – die wollten spielen. Aber bei euch: Euch musste ich ja fast schon Bremsen beim Erklären der Spielregeln, so viel wie ihr nachgefragt habt!” Das klingt in erster Instanz vielleicht ganz schön langweilig, wenn Leute mehr für die Regeln als das eigentliche Spiel brennen. Andersrum zeigt es aber auch ziemlich gut, wie wir als Firma ticken: Dass wir erst alle Rahmenparameter kennen und verstehen wollen, anstatt einfach drauf los zu entwickeln. Nun will ich im Umkehrschluss natürlich nicht sagen, dass Maurer stumpf Wände einfach mal so drauf los nach oben ziehen. Aber irgendwas scheint unsere Herangehensweisen zu unterscheiden.

Vom Mauern-Bauen und Softwareentwicklung

Eine Wand ist eine Wand, egal ob der Eigentümer, die Mieterin, der Besucher oder die Nachbarin davorsteht. Eine Software indes verhält sich unterschiedlich, wenn eine Administratorin sie bedient oder ein normaler Nutzer, trotzdem muss dieses Verhalten definiert sein - deterministisch. Wer ein „Wenn, dann“ implementiert, sollte auch das „sonst“ bedenken, denn sonst funktioniert es nicht. Eine Wand indes gibt ziemlich genau ihr Erwartungsbild vor, welche Handgriffe zu erfolgen haben. Software ist also in der Regel schon komplexer als eine Wand und muss im Laufe ihres Bestehens ggf. die eine oder andere Anpassung mehr mitmachen – flexibel sein und bleiben. Während ein Maurer beim Hochziehen der Wand eventuelle Feinheiten mit Geschick und Erfahrung bewerkstelligt, mit der Wasserwaage nachmisst und ggf. nachreguliert, verzeiht eine Software selten noch auf halber Strecke Kurskorrekturen. Bei Software sollte von Anfang an bedacht werden, dass auch die letzte Komponente zur ersten passt. Bei einer Wand ist das plump gesagt einfacher: Da sind erste und letzte Komponente gleich: Ein Stein.

Nun mag das eine sehr vereinfachende Sicht auf die Unterschiede sein, zumal ich vom Maurer-Beruf offen gestanden nicht allzu viel verstehe. Doch zumindest reichte es mir erstmal aus, um zu erklären, warum die Maurer einfach drauf los spielten und dabei Spaß haben (oder eine Mauer hochziehen, die den Kundenerwartungen vollauf entspricht), während wir erst eine Extrarunde Regelkunde brauchen, ehe wir loslegen können (oder erstmal sehr viele Fragen klären wollen, um uns nicht schon mit der Grundsteinlegung hintenraus alles zu verbauen.) So weit, so gut also, auch wenn es bis hierhin zu einem gewissen Grad auch nur eine Selbstvergewisserung der eigenen Daseinsberechtigung sein mag.

Die omnipräsente KI

Die zweite Frage, die sich mir direkt im Anschluss aufdrängte, war die Frage, die mich zur Zeit in nahezu allen Bereichen begleitet: Und wie verändert KI diese Betrachtung? Der Maurer braucht wohl in aller Regel wenig KI-Unterstützung, um seine Arbeit zu erledigen - das ist eben noch echtes Handwerk und KI-gesteuerte Handwerker-Roboter brauchen wohl noch ein paar Jahre, ehe ich mir über sie den Kopf zermartere. Aber bei Software? Wir starten die Anforderungsaufnahme stets mit Fragen. Das kann eine KI ja wohl auch ziemlich gut übernehmen. Auch die Kundenziele kann eine KI schon heute ziemlich gut erfassen, daran habe ich keinen Zweifel. Erfolgsgeschichten vom Vibe Coding, die ja genau darauf basieren, gibt es zu Hauf! Und schon beginnt die eigene Daseinsberechtigung zu bröckeln. Oder?

Wir alle bei esveo haben KI in unseren Arbeitsalltag integriert und testen die verschiedensten Anwendungsfälle und Strategien aus, wo und wie KI-Funktionalitäten in unseren Arbeitsablauf integriert werden können: Was bewährt sich, was nicht, wo fehlt aktuell noch ein Stück, bis KI auch diese Lücke füllt? Und siehe da: So vielfältig dieses Einsatzspektrum ist, so weit entfernt sind wir aktuell auch noch davon, dass KI uns die Daseinsberechtigung komplett entzieht. Doch wie meine ich das?

Was uns von der KI unterscheidet

Statt nur zu fragen, wie wir eine bestehende Idee umsetzen sollen – was eine KI sicher auch hervorragend leistet –, betrachten wir die Ideen unserer Kunden im Kontext weiterer Aspekte, denn Softwareentwicklung ist in der Regel ein nichtlineares Optimierungsproblem, die Bestimmung einer optimalen Lösung damit nicht trivial möglich und die erstbeste Idee nicht zwingend die Beste. Grundsätzlich nachfragen könnte eine KI in diese Richtungen sicherlich auch, aber sie fragt zumeist nur das, was man sie fragen lässt. Sie ist vom Grundtypen her sehr höflich; Kontrageben gehört nicht zu ihren Stärken. Um eine gute Lösung für ein Problem zu finden, braucht es jedoch ein kritisches Hinterfragen der ersten Lösungsideen. Welche Aspekte zu diesem Hinterfragen dazugehören, habe ich in Form von vier Clustern under einer Reihe von Beispielfragen gesammelt:

Image
  • Ziel: Durch kritisches Hinterfragen & Challengen sicherstellen, aufs richtige Pferd zu setzen
    • Was möchtest du mit deiner Idee erreichen?
    • Warum möchtest du dieses Ziel erreichen?
    • Liegt hinter deinem direkten Ziel ein anderes Ziel?
    • Ist deine bisherige Idee dafür wirklich am besten geeignet oder gibt es andere Ansatzpunkte?
    • Welche weiteren Ziele verfolgt du?
    • Wie bettet sich das aktuelle Thema in die übergreifende Themenlandschaft ein; ist es wirklich so hoch zu priorisieren oder gibt es andere Baustellen, die mehr Nutzen stiften würden?
  • Umgebung: Wie passt die Idee zum restlichen Unternehmen?
    • Welche Schnittstellen und Austauschfrequenzen mit anderen (IT-)Systemen brauche ich?
    • Sind diese Schnittstellen problemlos zugänglich?
    • Welche Lösungen bestehen schon und können ggf. durch geringfügige Anpassung eingebunden werden?
    • Wie wahrscheinlich ist eine mögliche Weiterentwicklung?
    • Welche Stakeholder müssen eingebunden werden und wollen diese in der Konzeption mitreden?
    • Was muss bedacht werden, um die Lösung erfolgreich bei den Endnutzern auszurollen?
  • Aufwand: Schonender Umgang mit Zeit- und Kostenbudget statt planloser Ressourcenverschwendung
    • Gibt es in der Gemengelage Low Hanging Fruits; also Ansätze, bei denen man mit Minimierung des Einsatzes den Nutzen maximieren kann?
    • Braucht’s eine quick & dirty Einmal-Lösung, ein Proof of Concept, einen soliden ersten Schwung oder die robuste Dauerlösung?
    • Wie schnell braucht’s welchen Funktionsumfang der anvisierten Gesamtlösung?
    • Wie groß darf das Kostenrisiko sein, um auf Unvorhergesehenes reagieren zu können?
    • Anforderungen sind relativ: Ein Feature für 500 EUR kann ein klares Muss-Feature sein, während dasselbe Feature bei höheren Entwicklungskosten zum Kann-Feature wird.
  • Faktor Mensch:
    • Wie entscheiden, wenn im Zweifel? Während das Prinzip des Frage-Antwort-Spiels zwischen Kunde und KI oder zwischen Kunde und Dienstleister technisch-praktisch-einfach klingt, ist das Antwortgeben nicht immer klar und einfach. Welcher Kunde wählt schon eine einfache Legehenne, wenn ihm zugleich eine eierlegende Wollmilchsau angeboten wird? Oft braucht es Beratung, um die richtigen Antworten zu finden und da häufig auch keine Hilfe zur Selbsterkenntnis möglich ist, ist es letztlich eine erfahrungsbasierte Empfehlung: Ein Stups durch den Consultant, um der Lösungsfindung näher zu kommen.
    • Bist du dir sicher? Einzelne Sinne sind im menschlichen 1:1 stärker im Einsatz: Während die KI Anforderungen nur sieht (liest) oder hört, sehen menschliche Berater Nuancen, spüren Unsicherheiten beim Kunden, die wir als Zögern, Augenbewegungen oder unentschiedene Aussprache wahrnehmen, sodass wir proaktiv nachhaken können, wenn ein Kunde unsicher ist und zögert.
    • Mehr Sinne im Einsatz: Wir sind schneller im Erfassen eines breiteren Kontextes, entwickeln ein Gespür für die Werte des Kunden, da wir Eindrücke nicht nur lesend (sehend) oder hörend aufnehmen, sondern ebenso beim Kunden sitzend dessen Umgebung erriechen (frischer Bohnenkaffee), erfühlen (schöne Büromöbel) und auch erschmecken (der Keks zum Kaffee). Dieses Kontextwissen vermittelt oft ein gutes Bauchgefühl für die Werte des Kunden und helfen mitunter dabei, bei einzelnen Entscheidungen den entscheidenden Ausschlag zu geben.
    • Wie schafft man Akzeptanz für eine neue Lösung? Dinge, die im 1:1 mit KI entwickelt wurden, werden von außen womöglich skeptischer beäugt und haben es unter Umständen schwerer, Akzeptanz zu finden. Etwas, das man zusammen geschaffen hat, ist teambildend & schafft eine breitere Identifikation. Gemeinsam positive Veränderungen zu schaffen, macht Spaß und schafft Multiplikatoren. Oft fühlt es sich sicherer an, neue Projekte mit erfahrenen Partnern umzusetzen und Entscheidungen im (menschlichen) Austausch zu treffen.

Fazit

Kleinere Tools mit eng begrenztem Funktionsumfang, trivialen Logiken und engem Nutzerkreis lassen sich prima vibe coden, aber je komplexer das System und die abzubildenden Logiken, desto größer die Wahrscheinlichkeit, dass eine gute Lösung noch echtes Spezifikations- und Entwickler-Handwerk braucht. Dafür müssen sehr viele Fragen gestellt und Antworten abgewogen werden, müssen Rahmenparameter wie Technologieauswahl, Zeit- und Geldbudget berücksichtigt werden und da sind wir Consultants und Entwickler von der esveo plötzlich doch ganz nah beim Maurer und machen mit viel Erfahrung und Gespür Dinge intuitiv richtiger als eine KI, die dieses Erfahrungswissen und Handlungskompetenz (noch) nicht mitbringt. Nicht zuletzt erkennen wir im 1:1 beim Kunden auch, wenn die Körpersprache sagt, dass ein Kunde eine bestimmte Entscheidung eigentlich gar nicht so treffen will, wie er oder sie es sagt - wir arbeiten mit mehr Sinnen und schöpfen auch daraus (noch) einen Kompetenzvorsprung im Vergleich zur KI, die uns rein in Wissensfragen sicherlich hoch und weit überflügelt. Nicht zu unterschätzen ist aber auch unsere Beratungskompetenz: Die KI kann viele Fragen stellen, vielleicht auch mal kritisch nachhaken, aber wirklich Kontra geben, Ideen challengen, Bedenken äußern, mal den Blickwinkel komplett drehen und mitunter von ganzen Teilaspekten abraten, dafür fehlen der KI (noch) die Erfahrung oder sie ist meist schlicht und einfach zu höflich dafür. Alles in allem ist KI Stand heute ein ziemlich hervorragender Junior Entwickler und Sparring Partner in Einzelfragen, aber momentan nicht nur ein ganzes Stück vom Senior Developer, sondern auch vom Senior Consultant / Product Owner / Requirements Engineer weit weg. Sorgen um einen baldigen Ersatz brauchen wir uns wohl nicht zu machen, auch wenn wir die atemberaubende Entwicklung staunend im Blick behalten – Daseinsberechtigung vorerst (noch) sicher.