KI & Tools: Entwicklungsumgebungen neu denken

• Massives Multitasking: Der Entwickler arbeitet regelmäßig an 2-3 Tasks. Während die KI einen Task implementiert, wird ein weiterer ausspezifiziert oder eine Implementierung getestet.
• Erfassung von Kontext: Damit heutige KIs effizient Code generieren können, benötigen sie das richtige Kontextwissen. Ähnlich wie ein menschlicher Entwickler muss die KI sich diesen Kontext zusammensuchen und kann auf dieser Basis dann ihre Arbeit tun. Die Bereitstellung eines möglichst kompletten Kontexts für Planung und Implementierung ist eine der größten Herausforderungen. Aktuelle KI-Systeme sind zwar in der Lage, sich sehr viel selbst zusammenzusuchen, allerdings übersehen sie oft Details – ähnlich wie ein Mensch.
• Historie ist wichtig: Heutige Tools stellen die KI hauptsächlich als Chatbot zur Verfügung. Dabei obliegt es dem Nutzer, dafür zu sorgen, dass eine entsprechende Dokumentation der Interaktion mit der KI angelegt wird. Das ist mühsame Handarbeit, die oft unterbleibt. Dabei sind für die Nachvollziehbarkeit sowohl die Nutzereingaben als auch bspw. der Implementierungsplan der KI wichtige Unterlagen.
• Das Volumenproblem: Die Produktivität von KI-Systemen bei gleichzeitig steigender Qualität der Ausgabe führt dazu, dass mehr und mehr Code von KIs erzeugt wird. Die Menge des so produzierten Codes ist heute schon in vielen Fällen kaum mehr realistisch zu inspizieren – die menschliche Aufmerksamkeit ist begrenzt. Schlussendlich bedeutet das, dass die direkte Arbeit mit dem Code nicht mehr der ideale Interaktionsmodus ist und der Mensch sich eher mit höheren Konzepten befassen sollte.
• Kosteneffizienz: Die Kosten von leistungsfähigen KI-Modellen sind erheblich, weshalb eine moderne Umgebung in der Lage ist, das Modell in Abhängigkeit von der Tätigkeit zu wählen: Einfache Tätigkeiten können mit billigeren Modellen erledigt werden, für komplexere werden mächtigere, teurere Modelle verwendet.

Diese genannten Punkte werden von heutigen Tools bislang nicht adressiert. Alle bislang gängigen Entwicklungstools verstehen sich primär als Codeeditoren und erst in zweiter Linie als Schnittstelle zur KI. Die große Frage ist, wie eine Entwicklungsumgebung aussähe, die ernsthaft versucht, einen AI-First-Anspruch umzusetzen, und dem Bediener die Werkzeuge an die Hand gibt, um das effizient zu tun. Im Folgenden zeigen wir Punkte auf, an denen sich IDEs der Zukunft – unserer Meinung nach – orientieren sollten, um den maximalen Nutzen aus dem Einsatz von KI ziehen zu können.

AI-First-IDE – Interaktionsmuster

Anhand der oben genannten Anforderungen drängt sich ein System auf, das näher an klassischen Issuetrackern bzw. Requirementsmanagementsystemen ist als an einem Codeeditor. Die genannten Systeme modellieren heute bereits Abhängigkeitsgraphen zwischen Softwarefunktionen, sie gliedern die Software in Funktionsgruppen und geben den Kanten des Abhängigkeitsgraphen eine Semantik („z.B. Funktion A ist eine Erweiterung von Funktion B“ oder „Funktion B hängt von Funktion C ab“). Der Graph bildet somit ein semantisches Modell der Software, das von einer KI effizient traversiert werden kann. Daraus ergibt sich eine Lösung des Kontextproblems: Die KI kann durch Traversierung feststellen, welche Anforderungen einen Einfluss auf die gerade zu bearbeitende Anforderung haben. Das funktioniert zu einem gewissen Grad sogar dann, wenn die verwandten Anforderungen noch gar nicht komplett ausspezifiziert sind – jedes bisschen Wissen ist besser als gar keins.

Im Verlauf der Entwicklung reichert die KI den Graphen mit den von ihr generierten Daten an:

• Implementierungspläne beschreiben, wie ein Feature implementiert werden soll und was ggf. out-of-scope ist.
• Implementierungszusammenfassungen beschreiben, was implementiert wurde und welcher Kontrakt von der Implementierung zur Verfügung gestellt wird.

Diese Daten können von der KI direkt wiederverwendet werden, wenn sie ein verwandtes Ticket plant – über die Graphtraversierung erhält sie somit Wissen darüber, wie Features implementiert wurden, auf die sie bei ihrer eigenen Planung Rücksicht nehmen muss. Gleichzeitig liefern sie die für den Menschen wichtige Nachvollziehbarkeit der Entwicklung.

Zuletzt hat ein vollintegrierter Wissensgraph einige interessante Eigenschaften, z.B.:

• Durch die Maschinenlesbarkeit kann automatisch erkannt werden, ob eine geänderte Anforderung Probleme mit anderen Anforderungen erzeugen wird.
• Akzeptanzkriterien können als Bürger erster Klasse abgelegt und mit Tests verknüpft werden. Schlägt ein Test fehl, so ist die Rückverfolgung zum zugehörigen Feature gratis.
• Die Struktur gibt vor, wann welche definierte Anforderung überhaupt umgesetzt werden kann: Eine Anforderung X kann nur dann umgesetzt werden, wenn alle Kindanforderungen von X bereits umgesetzt sind.

Wie würde ein menschlicher Entwickler mit so einem Werkzeug arbeiten?

Im Zentrum des Werkzeugs steht die Arbeitsteilung von Mensch und Maschine. Ein „Workitem“ hat einen Eigentümer, der gerade damit arbeitet:

In der Grafik sehen wir Workitemzustände zusammen mit den jeweiligen Eigentümern. Ein Workitem im Zustand „Draft“ wird gerade vom Menschen ausspezifiziert. Der Übergangs- bzw. Parkzustand „Ready For Planning“ signalisiert der KI, dass das Workitem ausspezifiziert und geplant werden kann. Die KI übernimmt es („Planning“); sobald ein Plan erstellt wurde, geht das Workitem zurück zum Menschen. Die beiden Reviewzustände sind die Stellen, an denen der Mensch eingreifen kann. Der gezeigte Fluss ist das etablierte Modell zur KI-gestützten Entwicklung, selbst wenn „nur“ ein Terminalagent verwendet wird und alles ad hoc geschieht. Der Mehrwert, den ein dediziertes Tool bringt, liegt darin, dass Informationen strukturiert und miteinander verlinkt werden können, sowie dass der Nutzer auch nach Monaten noch nachvollziehen kann, auf welchem Wege eine Funktion zustande kam. Wo bei einem Terminalagenten die Session u.U. nicht mehr verfügbar ist oder nur auf dem Rechner, auf dem sie erzeugt wurde, rekonstruiert werden kann, ist bei der Verwendung eines dedizierten Tools bspw. der ursprüngliche Plan zu einem beliebigen späteren Zeitpunkt noch nachvollziehbar:

Im Screenshot sehen wir den Plan, den der Agent für eine Spezifikation erzeugt hat. Der Text wird vom Werkzeug vorgehalten und kann jederzeit inspiziert werden, genauso wie die Spezifikation („Spec“), die als Eingabe gedient hat.

Strukturierte Kontextaufbereitung & Prompterstellung

Der beschriebene Wissensgraph ist zwar über eine geeignete API für die KI traversierbar, allerdings ist das in den allermeisten Fällen gar nicht notwendig. Durch die maschinenlesbare Struktur des Graphen können die Daten, die die KI vermutlich benötigen wird (i.d.R. alle Workitems, die eine direkte Verbindung mit dem zu bearbeitenden Workitem haben) automatisch zusammengesucht und direkt im Prompt für die KI bereitgestellt werden. Beispiel:

Wenn wir den oben gezeigten Wissensgraphen voraussetzen, so können wir – ohne die KI zu involvieren – direkt feststellen, dass für die Planung von Ticket 1 vermutlich sehr relevant ist, was in Ticket 2 und 3 gemacht wurde bzw. geplant ist. Dem kann das Werkzeug Rechnung tragen und die relevanten Teile der jeweiligen Tickets (z.B. Implementation Notes, Liste von bearbeiteten Dateien etc.) Teil des Prompts für Ticket 1 machen. Der Effekt:

• In der Explorationsphase wird der Agent regelmäßig zuerst den Code anschauen, der zu verwandten Tickets gehört, und damit effizienter und kostengünstiger explorieren können.
• Die Betrachtung von Ticket 1 im Kontext der beiden anderen Tickets führt dazu, dass der Agent in der Lage ist, bessere Rückfragen zu stellen bzw. auf Widersprüche hinzuweisen.
• Durch das Wissen um die anderen Tickets und ihre Anforderungen wird der so entstehende Plan Rücksicht auf die Anforderungen nehmen und die Wahrscheinlichkeit, dass Defekte eingeführt werden, ist geringer.

Einbettung in fixe Abläufe

Bei der Verwendung aktueller Agent-Harnesses oder Integrationen in IDEs werden der KI regelmäßig Aufgaben gegeben, die auch durch ein Programm gelöst werden können. Daraus ergeben sich folgende Nachteile:

• Kosten: Wenn eine KI verwendet wird, um Daten zu analysieren, zwischen verschiedenen Formaten zu transkribieren oder andere eher einfache Tätigkeiten durchzuführen, so werden dadurch unnötig viele Tokens benötigt, was zu hohen Kosten führen kann.
• Determinismus: KIs sind nicht deterministisch. Geben wir einer KI mehrfach denselben Auftrag, so kann es sein, dass sie ihn jedes Mal unterschiedlich ausführt. Was beim Generieren von Code u.U. gewollt ist, ist bei anderen Tätigkeiten problematisch, wenn die Korrektheit des Ergebnisses vom genauen Einhalten von Schritten abhängt.
• Performance: Die Ausführung eines Programms ist um Größenordnungen schneller, als einen KI-Agenten eine Tätigkeit ausführen zu lassen. Wenn also eine Tätigkeit als Programm oder Skript komplett auszudrücken ist, so ist dieser Ansatz zu bevorzugen.

Ein dediziertes Werkzeug (Meta-Harness), das den Agenten steuert, kann sowohl Kosten dämpfen als auch Determinismus sicherstellen. Beim Meta-Harness handelt es sich um ein normales Programm, das fest einprogrammierte Schritte ausführt und den Agenten einbettet:

Ein Beispiel für die Verwendung eines Meta-Harness wäre die Verwendung eines Versionskontrollsystems. Im Regelfall ist klar, welche Strategie zur Verwendung des SCM im Projekt verfolgt wird (z.B. Feature Branches o.Ä.). Diese Strategie kann durch den Meta-Harness implementiert werden. Wenn nun ein neuer Plan implementiert werden soll, so stellt der Meta-Harness sicher, dass das Arbeitsverzeichnis im korrekten Zustand ist (z.B. via Erzeugen und Auschecken des korrekten Branches) und übergibt dann die Kontrolle an den Agenten. Nachdem der Agent mit seiner Arbeit fertig ist, sorgt der Meta-Harness dafür, dass die Arbeit ordnungsgemäß eingecheckt wird.

Das genannte Beispiel ist nur eines von vielen, bei denen eine Automatisierung auf traditionelle Weise deutliche Vorteile gegenüber dem KI-Einsatz hat. Unserer Erfahrung nach ist das Einbetten der KI in ein striktes und enges Korsett ein Erfolgsfaktor für den nachhaltigen KI-Einsatz.

Zusammenfassung

AI-First-IDEs werden den Arbeitsmodus verschieben – weg von der unmittelbaren Arbeit mit Code, hin zur Arbeit mit Spezifikationen und strukturiertem Kontext, mit dem Ziel, den implementierenden KI-Systemen die bestmögliche Grundlage zu bieten. Ein Ansatz, um das strukturell umzusetzen, ist ein semantischer Wissensgraph, der als Basis zur Prompt- und Kontextgenerierung für die KI dient. Ein Meta-Harness legt der KI dort ein enges Korsett an, wo Determinismus gefragt ist, und stellt so die notwendige Verlässlichkeit her.

Diese Vision weiterzuentwickeln ist das Ziel von „synapse“: Mit dieser Forschungs-IDE sammelt awinia Erkenntnisse zum erfolgreichen KI-Einsatz in der Produkt- und Softwareentwicklung – und macht sie für unsere Kunden nutzbar. Mit unseren Ideen und Showcases kommen wir gerne auch zu Ihnen!