Die Active Group und "Agentic Engineering"

In den letzten Monaten haben wir - wie alle in der Branche - viele Gespräche dazu geführt, wie die Zukunft der Softwareentwicklung aussehen wird. Es geht natürlich um „Agentic Engineering“ (AE), also der Benutzung von LLM-basierenden Agenten, um direkt aus Anforderungen den Code für Softwaresysteme zu generieren. Neben der allgemeinen Frage haben wir uns überlegt, was diese Entwicklung für uns bei der Active Group bedeutet und wie wir mit den veränderten Rahmenbedingungen umgehen.

Jenseits von Produktivität

Agentic Engineering verspricht signifikante Produktivitätssteigerungen bei der Softwareentwicklung. Entsprechend investieren viele softwareentwickelnde Firmen gerade massiv in die Benutzung von AE in ihren Prozessen. Viele unserer Konkurrenten bewerben Beratung zu und Entwicklung mit Agentic Engineering.¹

Bei der Active Group entwickeln wir natürlich auch ohne AE effizient. Unser Anspruch ist aber primär, sondern dass unsere Software besser ist, weil wir sie sorgfältig entwickeln. „Besser“ bedeutet besser für Menschen, also für Benutzer:innen, deren Leben durch die Software verbessert wird. (Doch, so etwas gibt es.) Dafür sprechen wir mit unseren Kund:innen und suchen nach den besten Lösungen jenseits einer bloßen Übersetzung von Anforderungen in Code. Oft genug sieht diese beste Lösung dann ganz anders aus, als die Anforderungen am Anfang des Prozesses vermuten ließen.

Entsprechend passt unser Motto „Software, sorgfältig“ nicht zum Einsatz von AE: Die Qualität generierten Codes ist geringer als die Qualität von Code, der von Menschen geschrieben wurde. Quellen gibt es zahlreiche im Netz, zum Beispiel dieses Posting aus dem COOP Blog oder dieser AI Productivity Paradox Report.

Probleme mit Agentic Engineering

Uns beunruhigt außerdem, dass LLMs für Aufgaben eingesetzt werden, die eigentlich deterministischer, nachvollziehbarer Verarbeitung zugänglich sind beziehungsweise diese sogar erfordern. Dazu gehörte zum Beispiel der spektakuläre Hack von Instagram-Konten, bei dem eine KI den normalen Ablauf bei Passwort-Änderungen ersetzte, die Überprüfung von behördlichen Formularen mit KI oder der Einsatz von LLMs zur Übersetzung von Codebases von einer Programmiersprache in eine andere statt einem Compiler.

Das allgemeine Thema - wann LLMs für bestimmte Aufgaben überhaupt das richtige Werkzeug sind - hat sich unser BOB-Keynote-Sprecher Stefan Kaufmann in diesem Vortrag vorgenommen. Es geht vorgeblich um die öffentliche Verwaltung, aber die von Stefan Kaufmann vorgeschlagenen Prinzipien würden auch vielen anderen Anwendungsbereichen gut zu Gesicht stehen.

Abseits der Nützlichkeit hören die Probleme nicht auf: LLMs haben gigantische Externalitäten. Johannes Links Blog-Post fasst das Problem gut zusammen:

• Befeuerung der Klimakatastrophe
• massiver Lohndruck auf ganze Berufsgruppen
• gigantischer Diebstahl geistigen Eigentums
• Zerstörung zwischenmenschlicher Verbindungen
• Zerstörung von Open-Source-Ökosystemen
• Verzerrung des politischen Diskurses
• Zerstörung von Lernerfahrung und Ausbildungspfaden

Entsprechend groß sind unsere Bauchschmerzen, LLMs als Teil unserer Softwareentwicklung einzusetzen. Wir erlauben uns kein ethisches Urteil über die Benutzer:innen von LLMs - so gut wie jeder von uns tut Dinge mit Externalitäten, ob Fleisch essen, Autofahren etc.

Expertise und Freude im Programmieren

Unsere Software macht nicht nur den Benutzer:innen Freude. All die Techniken und Technologien, die wir verwenden, sorgen für eleganten Code und flexible Architektur. Dazu gehören funktionale Programmierung, reichhaltige Datenmodellierung und domänenspezifischen Sprachen. Gelungene Umsetzungen machen auch uns Freude.

Insbesondere schreiben wir gern Code, denken gern über den besten Ansatz bei einem Softwareprojekt nach, freuen uns über tollen Code der Kolleg:innen und lernen gern neue Dinge. All das tun wir gern gemeinsam und gemeinsam mit den Nutzer:innen unseres Code. Was uns Freude macht an der Softwareentwicklung, fehlt beim Einsatz von AE weitgehend. Und es ist vielleicht kitschig, aber wir glauben, dass gute Software eine Verbindung zwischen Entwickler:innen und Nutzer:innen vermitteln kann, und ich freue mich als Nutzer:in, wenn ich das Gefühl habe, dass die Entwickler:in persönlich Sorgfalt investiert hat.

Das geht offenbar nicht nur uns so. Unsere Hauskonferenz BOB hatte dieses Jahr soviele Besucher:innen wie noch nie, obwohl das Programm ganz ohne KI auskam. (Oder weil? Eine spontane Reaktion eines unserer PR-Outlets war: „Endlich auch mal wieder eine Konferenz ohne KI“.) Wenn wir unsere Vorbehalte gegen AE auf Veranstaltungen thematisieren, bekommen wir regelmäßig Zuspruch.

Gelentlich wird uns vorgehalten, dass LLMs das Programmieren demokratisieren und Menschen zugänglich macht, die andernfalls ihren Computer nur „passiv benutzen“ können. Das Argument ignoriert allerdings die Abhängigkeiten, die der Einsatz von LLMs für Automatisierung mit sich bringt - Demokratisierung sieht anders aus.

In der Tat hat sich die Softwareentwicklungs-Community durch immer komplexere Technologiestacks und undurchdringliche Terminologielabyrinthe nicht mit Ruhm bekleckert. Leider generiert das LLM keine Kompetenz im Umgang mit eben diesen Technologien, sondern nur Output.

Außerdem haben wir als Community vielleicht vergessen, dass es andere Wege gibt, Computer und insbesondere Computerprogrammierung zugänglich zu machen durch einfach zu benutzende Technologien, breitentaugliche Didaktik und das Schaffen und Schätzen von Expertise. Daran arbeiten wir persönlich im Rahmen unserer Schulungen und des DeinProgramm-Projekts. Da geht aber sicherlich noch mehr.

Was bedeutet das für uns?

Wir werden AE vorläufig nicht als essenziellen Teil in unsere Software-Entwicklungsprozesse integrieren. Wir übernehmen für jede Zeile Code, die in Richtung Kund:in geht, die Verantwortung für Korrektheit und urheberrechtliche Unbedenklichkeit. Wir werden weiterhin in jedem Projekt nach der besten Lösung suchen, mit vertrauensvoller Zusammenarbeit mit Kund:innen und Partner:innen, großer Sorgfalt und den besten Techniken und Technologien.

Wir unterstützen weiterhin unser Partner:innen und Kund:innen in allen Belangen der Softwareentwicklung, also auch im Umgang mit AE-generiertem Code. Wir gehen aber davon aus, dass dort mittelfristig große Mengen qualitativ minderwertigen Codes entsteht, welcher Verbesserung bedarf.

Entsprechend beraten und schulen wir, wie AE-gestützte Entwicklungsprozesse und der daraus entstandenen Code verbessert werden, insbesondere im Hinblick auf Architektur und langfristige Evolution.

Diese Strategie ist für uns mit Risiken verbunden: Kund:innen könnten entscheiden, nur noch solche Dienstleister zu beauftragen, die AE benutzen, weil sie glauben, dass das billiger ist.

Aber wie gesagt: Die Software, die wir entwickeln, ist anders: Wir hoffen, dass wir auch weiterhin Kund:innen und Partner:innen finden, die Sorgfalt in der Softwareentwicklung schätzen, die sich auf gemeinsame Arbeit an bereichernder Software einlassen und sich freuen, wenn ihre Anliegen von Menschen wahr- und ernstgenommen werden.