Alex Bloss
Die Reise der KI begann in den 1960er Jahren, als Wissenschaftler versuchten, die Funktionsweise von Neuronen und Gehirnschaltkreisen in technischen Modellen abzubilden. Aufgrund der begrenzten Rechenleistung und Speicherkapazität scheiterten diese frühen Versuche, was zu einem sogenannten “KI Winter” führte. In dieser Zeit wurde die Forschung an KI weitgehend eingestellt, und diejenigen, die daran festhielten, wurden oft belächelt.
Mit der Einführung von ChatGPT begann ein neuer Hype um die KI. Obwohl die Sprachverarbeitung und das Natural Language Processing (NLP) bereits zuvor existierten, brachte ChatGPT eine neue Dimension in die KI-Welt. Plötzlich war ein Modell verfügbar, das Aufgaben lösen konnte, die zuvor Menschen vorbehalten waren. Die Fähigkeit von GPT-3.5 und später GPT-4, schulische und universitäre Tests zu bestehen, bewirkte einen bedeutenden Durchbruch und erzeugt viel Aufmerksamkeit, die sich schnell zu einem KI-Hype steigerte.
Die Möglichkeiten, die durch KI entstehen, sind vielfältig. Von der Texterstellung im Marketing über die Codegenerierung bis hin zur Bild-, Musik- und Videoproduktion – die Anwendungsfälle sind zahlreich und die Entwicklungsgeschwindigkeit ist atemberaubend. Ein bemerkenswertes Beispiel ist die Kontroverse um ein von einer KI generiertes Bild, das einen Kunstwettbewerb gewann . Diese Diskussion wirft Fragen zum Urheberrecht und zur Schöpfungstiefe auf.
In Studien wird in letzter Zeit immer wieder das Potenzial von KI-Modellen diskutiert, Bereiche menschlicher Arbeit zu übernehmen. Dabei wird oft die Frage gestellt, ob KI-Modelle wie ChatGPT die Arbeit von Menschen ergänzen oder ersetzen. Im Unterschied zu den bisherigen Automatisierungsprozessen, die vor allem repetitive und einfache Aufgaben übernommen haben, scheinen die neuen KI-Modelle in der Lage, komplexe und kreative Aufgaben zu übernehmen.
Welche Auswirkungen hat das auf die Arbeit agiler Teams? Werden wir durch Tools ergänzt oder übernimmt Agent Smith?
Immer mehr gerät der Bereich der Software-Entwicklung in den Fokus. Seit einiger Zeit können Entwickler sich durch Tools wie z.B. GitHub Copilot und TabNine unterstützen lassen, Code schneller und effizienter zu schreiben, sich schneller in unbekannten Code einzuarbeiten, neue Frameworks zu erlernen oder auch Fehler zu finden.
Wer diese Tools bereits selbst verwendet hat, weiß, dass sie eine enorme Hilfe sein können, aber nicht immer zu den gewünschten Ergebnissen führen. Aus dieser Ecke war bislang keine Bedrohung für die Entwickler zu erwarten - der Copilot kann kein komplexes Softwareprodukt von Anfang bis Ende konzipieren, entwickeln, testen und dokumentieren. Doch das könnte sich ändern.
Der Hintergrund dieser eher begrenzten Leistungsfähigkeit liegt in der Tatsache, dass die Tools im Single-Shot-Modus arbeiten. Das bedeutet, dass sie eine Aufgabe gestellt bekommen und diese in einem Rutsch erledigen müssen. Dazu bekommen sie Kontext, d.h. sie können Einblick in den bestehenden Code im Projekt nehmen, aber sie können keine Zerlegung der Aufgabe in mehrere Teilschritte vornehmen und diese inkrementell mit Feedbackschleifen abarbeiten.
Um sich die Auswirkung dieser Einschränkung vor Augen zu führen kann man sich folgenden Fall überlegen: man bekommt die Aufgabe gestellt, ein Programm mit einer bestimmten Funktionalität zu schreiben. Allerdings hat man nur einen Versuch und muss das Programm von oben bis unten in einem Rutsch schreiben. Es sind keine Korrekturen durch Verwendung der Cursor-Tasten oder der Del-Taste möglich, außerdem kann man das Programm nicht starten, um es zu testen.
Für einfache Aufgaben mag das noch funktionieren, aber für komplexere Aufgaben wird das schnell unpraktikabel. Im Endeffekt arbeiten wir als Menschen so ja auch nicht: wir lesen die Aufgabenstellung, überlegen uns eine Lösung, zerlegen die Aufgabe in Schritte, schreiben einen Teil des Codes, testen diesen, korrigieren ihn, schreiben weiter, refaktorisieren und nähern uns so iterativ einer vollständigen, funktionierenden Lösung an.
Wie wäre es, wenn wir diese Vorgehensweise auf die Tools mithilfe von Sprachmodellen übertragen könnten?
Hier kommt die Idee der agentenbasierten Workflows ins Spiel.
Ein neuer Ansatz in der KI-Entwicklung sind agentenbasierte Workflows. Diese ermöglichen es, komplexe Probleme durch die Zusammenarbeit spezialisierter Agenten zu lösen. Ein Agent kann beispielsweise als Planer fungieren, während andere Agenten spezifische Aufgaben wie das Schreiben von Code oder das Erstellen von Dokumentation übernehmen. Zudem können Agenten miteinander in Feedbackschleifen interagieren, die Arbeit des anderen kritisch betrachten und sich so gegenseitig unterstützen.
Hier sehen wir die Idee des Agenten in einem Schaubild. Ein Mensch interagiert mit dem Agenten und übermittelt die Aufgabenstellung. Dem Agenten wird mit seinem System-Prompt eine bestimmte Rolle zugewiesen, z.B. “Du bist ein Senior Angular Frontendentwickler”. Außerdem hat er Zugriff auf zusätzlichen Kontext, hilfreiche Informationen, zusätzliche Werkzeuge und ein Sprachmodell um die gestellte Aufgabe zu erledigen.
Ein Beispiel eines Software-Engineering-Agenten mit entsprechender Umgebung und Schnittstellen ist das Projekt SWE-Agent der Princeton University, das einen Agenten bereitstellt, der Bugs und Issues in GitHub-Repositories selbstständig implementiert. Zur Einordung: laut des Benchmarks SWE-Bench erreicht der SWE-Agent in 12,29% der Aufgabenstellungen eine vollständige Lösung.
Das allein wäre aber noch kein wirklicher Fortschritt zu dem bisherigen Vorgehen. Interessant wird es nun, wenn wir ein Team von Agenten in verschiedenen Rollen zusammen an einer komplexen Themenstellung arbeiten lassen.
Hier sehen wir ein Beispiel für einen agentenbasierten Workflow. Ein Planungsagent koordiniert die Zusammenarbeit von verschiedenen Spezialagenten, die jeweils für spezifische Aufgaben zuständig sind. Diese Zusammenarbeit ermöglicht es, komplexe Probleme in einzelne, überschaubare Schritte herunterzubrechen und durch dafür speziell konfigurierte Agenten zu lösen.
Die Architektur des Projekts wird von einem Agenten entworfen, der auf die spezifischen Best Practices und Vorgaben des Projektes zugeschnitten ist (z.B. via Prompt Engineering oder Retrieval Augemented Generation ). Der Architekturentwurf wird von einem zweiten Agenten kritisch überprüft, der auf die Einhaltung von Qualitätsstandards und Sicherheitsrichtlinien spezialisiert ist.
Unser Angular-Agent aus dem Bild oben übernimmt die Implementierung der Frontend-Stories. Er wird von einem Review-Agenten unterstützt, der die Vollständigkeit und Qualität des Codes überprüft und Verbesserungsvorschläge macht. Tests werden durch einen spezialisierten Test-Agenten erstellt und ausgeführt. Gefundene Fehler werden an den Implementierungs-Agenten zurückgemeldet und von diesem behoben. Ein weiterer Agent ist für das Erstellen der Dokumentation zuständig.
Zusätzliche Leistungsfähigkeit entsteht durch die Möglichkeit, die Agenten mit für ihre jeweilige Aufgabe speziell angepassten Sprachmodelle auszustatten. So kann ein Agent, der für die Codegenerierung zuständig ist, ein Sprachmodell verwenden, das speziell auf die Syntax und Semantik von Programmiersprachen zugeschnitten ist (z.B. auch durch Model Finetuning).
In der Theorie lässt sich mit diesem Konzept ein komplettes Team an spezialisierten Agenten aufbauen, die in unterschiedlichen Rollen zusammenarbeiten und sich über Feedbackschleifen gegenseitig unterstützen, ein gemeinsames Ziel zu erreichen. Dieser Ansatz verspricht eine höhere Leistungsfähigkeit als die bisherige Single-Shot-Vorgehensweise.
Wie sieht dieser Ansatz in der Praxis aus?
Es zeigt sich, dass agentenbasierte Workflows bereits heute in verschiedenen Bereichen eingesetzt werden. Unternehmen wie z.B. Microsoft und Meta experimentieren mit diesen Technologien, bei Meta beispielsweise, um die Unittest-Abdeckung zu verbessern.
Startups zeigen die Vision der agentenbasierten Lösung komplexer Software-Engineering-Aufgaben und werden aktuell großzügig finanziert, wie z.B. Devin von Cogintion Labs .
Github startet eine aktuell noch private “Technical Preview” des GitHub Copilot Workspaces , die eine Zusammenarbeit von Entwicklern und KI-Modellen in einer integrierten Entwicklungsumgebung ermöglichen soll.
Es gibt aber auch einige Open-Source-Projekte, wie z.B. GPT-Pilot , ChatDev und Devika , die unsere theoretische Idee eines Teams von Agenten praktisch umsetzen und das Potenzial dieser neuen Arbeitsweise erahnen lassen.
Wir haben uns den GPT-Pilot näher angesehen und ein Experiment durchgeführt, um zu erleben, wie sich die Zusammenarbeit mit einem Team von Agenten in der Praxis anfühlt.
GPT-Pilot ist ein in Python geschriebenes Command-Line Tool, das ganze Apps erstellen können soll. Zu diesem Zweck definiert es ein Team von zehn Agenten mit verschiedenen Aufgaben:
Zudem definiert GPT-Pilot einen Workflow, der die Zusammenarbeit der Agenten koordiniert, Feedbackschleifen ermöglicht und den Fortschritt überwacht.
Als Aufgabenstellung haben wir ein einfaches Projekt “TimR” für ein Zeiterfassungstool definiert, inspiriert von dem Beispielaus dem GPT-Pilot-Wiki .
Die Erstellung einer ausreichenden Beschreibung des gewünschten Ergebnisses ist - wie im “richtigen Leben” nicht trivial: neben den fachlichen Anforderungen sind Vorgaben zur technischen Basis (z.B. Framework, Datenbank), zur Architektur und Struktur des Projekts erforderlich. Auch nicht-funktionale Anforderungen wie Performance, Skalierbarkeit und Sicherheit sollten berücksichtigt werden.
Füttert man nun den GPT-Pilot mit der Spezifikation, so kann es sein, dass dieser Rückfragen hat oder Klarstellungen benötigt. Ist die Aufgabe dann aus Sicht des Agenten ausreichend beschrieben, so beginnt er mit der Strukturierung des Projekts und dem Formulieren der Arbeitspakete.
Sind die Schritte und Task definiert, übernehmen die Implementierungs-Agenten die Umsetzung. Nach erfolgreicher Implementierung eines Inkrements und Review durch einen weiteren Agenten werden Testfälle erstellt, die dann der menschliche Auftraggeber durchführen soll und ggf. Feedback in Form von Fehlerberichten (IST, SOLL, Fehlermeldungen) zurückgeben kann.
Heißt: der Mensch startet das bisher erstellte Projekt und führt die Testfälle manuell durch. Die Fehlermeldungen werden dann an den GPT-Pilot zurückgegeben, der diese in einem mehrstufigen Prozess mit mehreren beteiligten Agenten analysiert, Änderungen vorschlägt die Fehler behebt, den Stand reviewt und dann zusammen mit Testfällen nochmals zum Test vorlegt.
So wird die größere Aufgabe in kleinere, überschaubare Schritte zerlegt und durch spezialisierte Agenten iterativ bearbeitet. Der Mensch wird punktuell in den Prozess eingebunden, um die Qualität der Ergebnisse zu überprüfen und Feedback zu geben.
In unserem Experiment hat die Umsetzung des Projekts ca. eine Stunde gedauert und mit der Verwendung des OpenAI GPT4-Modells ca. 10 EUR für die verwendeten Token gekostet. Bemerkenswert war, dass die Inkremente zu jeder Zeit lauffähig waren und die kleine Anwendung in sinnvollen Stufen nachvollziehbar Schritt für Schritt erstellt wurde.
Während der manuellen Tests traten diverse Fehler auf, z.B. fehlende Menüpunkte oder API-Endpunkte, die nicht korrekt implementiert waren. Diese Fehler wurden von entsprechenden Agenten analysiert und umgehend vom Implementierungs-Agenten behoben - die folgenden Tests konnten erfolgreich durchgeführt werden.
Der Funktionsumfang und die Ausgestaltung der Features ist recht rudimentär, besonders die Darstellung der Reports oder die Fehlerseiten sind verbesserungswürdig. Es wäre zu testen, was man hier mit einer verbesserten Anforderung erreichen könnte.
Das Repository mit dem erzeugten Code und der Dokumentation wurde am Ende des Experiments unverändert (bis auf eine Ergänzung in der Readme-Datei) in GitHub abgelegt.
Für den Start der Anwendung benötigt man eine MongoDB-Instanz, die man einfach mit Docker starten kann:
docker run --name mongodb -d -p 27017:27017 mongodb/mongodb-community-server:latest
Die Datenbank-URL trägt man in ein .env ein:
DATABASE_URL=mongodb://localhost:27017/timr
SESSION_SECRET=123
Dann kann man die Anwendung starten:
npm i
npm run start
Zuerst legt man einen neuen Benutzer an, dann kann man sich einloggen und die ersten Zeiten erfassen.
Es war beeindruckend zu sehen, wie das “Team von Agenten” die Problemstellung analysiert, strukturiert und in kleine, überschaubare Schritte zerlegt hat. Die Zusammenarbeit der Agenten war effizient und zielgerichtet, und die Qualität der Ergebnisse war erstaunlich hoch. Auch Fehler in der Umsetzung wurden nach entsprechendem Feedback schnell behoben.
Das erstellte Projekt kann auf den ersten Blick erfüllt die Anforderungen und ist in einer sinnvollen Struktur aufgebaut, durch Dokumentation wird der Einstieg erleichtert.
Man würde sich noch eine Testsuite wünschen, die zur Validierung der Funktionalität und Absicherung von Änderungen und Refactorings genutzt werden kann. Dies lässt sich durch eine Erweiterung des Teams um einen Testautomatisierungs-Agenten realisieren.
Die interessante Frage ist, was uns dieses Experiment über die Zukunft der Software-Entwicklung sagt. Werden in Zukunft tatsächlich große Teile des Software-Entwicklungsprozesses von kooperierenden Agenten größtenteils autonom durchgeführt - diese treffen Entscheidungen anhand der Anforderungen und Vorgaben und lösen komplexe Design- und Implementierungsaufgaben selbstständig und nehmen uns nur dann hinzu, wenn Sie unsere Hilfe für Entscheidungen oder das Placet bei der Abnahme benötigen? Oder bleibt der Mensch im Fahrersitz und die Agenten ergänzen uns als virtuelle Buddies und steigern dadurch unsere Produktivität?
Natürlich stellen sich sofort viele Fragen auch bezüglich der Verantwortung für den erzeugten Code, über die langfristige Weiterentwicklung des Software-Projekts mit dem Tool. Zudem liegt auf der Hand, dass die Abhängigkeit von einer Blackbox Software-Maschine ein hohes Risiko darstellt.
Trotz der vielversprechenden Ansätze gibt es noch Herausforderungen zu bewältigen. Die Beschreibung von Aufgaben muss präzise und detailliert sein, um optimale Ergebnisse zu erzielen. Die KI ermöglicht leider immer noch nicht das automatische “do what I want” aus einer dürftigen Anforderungsbeschreibung ;-)
Zudem ist die Integration und Zusammenarbeit der verschiedenen Agenten ein komplexer Prozess, der weiterentwickelt werden muss. Ein Detail der Code-Generierung, das wir in unserem Experiment beobachten konnten war, dass die Code-Dateien immer komplett neu generiert wurden, auch wenn z.B. nur Details in einer Methode hinzugefügt werden sollten. Hier wäre eine Verbesserung durch eine inkrementelle Code-Generierung wünschenswert, da dies die Stabilität der inkrementellen Entwicklung erhöhen könnte. Mit der aktuellen Vorgehensweise besteht die Gefahr, dass bereits implementierte Teile überschrieben werden, Features verschwinden oder Fehler in bereits getesteten Teilen eingeführt werden.
Mit den aktuellen Entwicklungen zu immer leistungsfähigeren LLMs, gewaltigen Kontext-Längen (über eine Million Tokens), auf die jeweiligen Aufgabengebiete spezialisierte LLMs, und multimodalen LLMs erschießen sich neue Möglichkeiten auch für die Unterstützung der Software-Entwicklung.
Mächtige Agenten-Frameworks erleichtern die Entwicklung und den Einsatz von Agenten, die Zusammenarbeit und Kommunikation zwischen den Agenten und die Stabilität der Workflows. Wir dürfen also gespannt sein, welche Ansätze sich in den nächsten Jahren bewähren und welche Anwendungen dadurch möglich werden.
Im Lab setzen wir uns intensiv mit diesen Fragen auseinander und entwickeln eigene Agenten und Workflows für verschiedene Anwendungsfälle, um die Möglichkeiten und Grenzen dieser neuen Technologien auszuloten.
Die Entwicklung der KI hat einen langen Weg zurückgelegt, von den bescheidenen Anfängen in den 1960er Jahren bis hin zu den heutigen fortschrittlichen Modellen und agentenbasierten Workflows. Die Möglichkeiten, die sich daraus ergeben, sind enorm und könnten die Art und Weise, wie wir Software entwickeln, grundlegend verändern.
Die Idee, komplexe Probleme durch die Zusammenarbeit spezialisierter Agenten zu lösen, verspricht eine höhere Leistungsfähigkeit und Effizienz. Die ersten Experimente und Projekte zeigen vielversprechende Ergebnisse und lassen erahnen, welche Potenziale in dieser neuen Arbeitsweise stecken.
Stand heute sind die verfügbaren Tools noch in einem frühen Stadium und genügen nicht den hohen Anforderungen, die wir an hochqualitative Software-Entwicklung stellen. Wir werden den Fortschritt in diesem Bereich weiter verfolgen und regelmäßig vielversprechende Tools verproben.
Parallel müssen wir uns aber auch den gesellschaftlichen, ethischen und rechtlichen Fragen stellen, die sich bereits heute deutlich abzeichnen. Es ist unsere Entscheidung, wie wir mit den neuen Möglichkeiten auch als Gesellschaft umgehen wollen.
Written By
Alex Bloss - Leiter attempto-Lab. Kreativer Kopf, Innovator, kritischer Denker, Entwickler, praktischer Architekt, CTO, Trend Scout und neugieriger Entdecker mit mehr als zwanzig Jahren Erfahrung.
Alex BlossUnlock advanced RAG capabilities using document hierarchies. Our guide explains how structuring data like a table of contents can significantly improve information retrieval, ensuring faster, more reliable, and contextually accurate AI-generated content with reduced errors.
Sophia KeilDer erste Teil eines Glossars im Schreibstil, um etwas Licht in den Jargon rund um große Sprachmodelle zu bringen.