AI in der Softwareentwicklung: Sparringspartner statt Ersatz

Die Nutzung von generativer AI hat sich in der Softwareentwicklung fest etabliert: So setzt heute fast jeder Entwickler generative AI-Tools im Arbeitsalltag ein – um etwa Software zu entwickeln, zu testen oder bereitzustellen. Das zeigen aktuelle Zahlen von JetBrains Research bzw. der Stack Overflow Developer Survey. Bei Letzterer handelt es sich um eine der weltweit größten Umfragen unter Softwareentwicklern mit fast 50.000 Befragten. 

Demnach nutzen 90 (JetBrains Research) bzw. 81 Prozent (Stack Overflow Developer Survey) aller professionellen Softwareentwickler zumindest unregelmäßig AI-Tools. Wie das Fraunhofer-Institut für Experimentelles Software Engineering (kurz: Fraunhofer IESE) in einem jüngst veröffentlichten Beitrag beschreibt, kann dadurch die Produktivität einzelner Entwickler deutlich gesteigert werden. 

Gleichzeitig betont das Institut: Diese Produktivitätssteigerung sagt für sich genommen wenig aus. Softwareentwickler könnten mit AI zwar quantitativ mehr Output generieren – ob dieser qualitativ trägt, sei jedoch eine ganz andere Frage. Dies betreffe sowohl den Code an sich als auch die Software-Lösung als Ganzes. Tatsächlich könne AI die Software-Auslieferung sogar verlangsamen, wenn Test-, Freigabe- oder Governance-Prozesse in Unternehmen nicht mit der Geschwindigkeit der AI-gestützten Code-Generierung Schritt halten. Entscheidend sei deshalb, den Output in die Unternehmensprozesse zu integrieren. Zudem müsse dieser gründlich validiert werden – um so die Qualität sicherzustellen. 

Das Fraunhofer IESE stützt diese Einordnung dabei maßgeblich auf aktuelle Studien – darunter insbesondere die Studie „State of AI-assisted Software Development“ des DevOps Research and Assessment Team (kurz: DORA) von Google.

AI-Tools verursachen ein „Vertrauensparadoxon“

Gerade die Notwendigkeit der Validierung geht deutlich aus der DORA-Studie hervor: Demnach konnten nur 59 Prozent der 5.000 Befragten die Code-Qualität mit AI verbessern – obwohl 80 Prozent Produktivitätssteigerungen durch AI verzeichnen. Hinzu komme eine skeptische Haltung gegenüber AI-generiertem Output: Nur 24 Prozent würden darauf vertreten, dass dieser gut sei. Demgegenüber stünden 30 Prozent, die dem Output wenig bis gar nicht trauen. 

Die Studie spricht in diesem Kontext von einem „Vertrauensparadoxon“: Softwareentwickler betrachteten AI-Tools in der Softwareentwicklung zwar als nützliches Werkzeug – ein echtes Vertrauen gegenüber den Ergebnissen bestehe jedoch vielerorts nicht. 

„Dies könnte bedeuten, dass AI als unterstützendes Werkzeug zur Steigerung von Produktivität und Effizienz in Arbeitsabläufe integriert wird, anstatt als vollständiger Ersatz für menschliches Urteilsvermögen zu dienen“, so die Studienautoren. 

Auf Basis der DORA-Studie kommt das Fraunhofer IESE zu folgender Schlussfolgerung: „Entwickler nutzen KI vorwiegend reflexiv, nicht delegativ – also eher im Sinne eines Sparringspartners, statt komplexe Aufgaben abzugeben. Wenn Entwickler Aufgaben bearbeiten, bei denen sie Entscheidungen treffen oder Inhalte interpretieren müssen, hilft die KI nur begrenzt.“ 

Mit anderen Worten: AI-Tools werden in der Softwareentwicklung heute vor allem als Sparringspartner eingesetzt, die bei der Durchführung von Aufgaben unterstützen, diese aber nicht vollständig autonom übernehmen.

IBM setzt auf „Human in the Loop“-Prinzip

An genau diesem Punkt setzen Hersteller wie IBM an. So positioniert IBM die eigene AI-Lösung IBM Bob, die eine ganze Reihe von AI-Tools und -Agenten für die Softwareentwicklung beinhaltet, als „agentischen AI-Entwicklungspartner“, der Entwicklern während des gesamten Software-Lebenszyklus (kurz: SDLC) als Sparringspartner zur Seite steht. Tatsächlich sei die Lösung auf die Nutzung durch Entwicklerteams in Unternehmen zugeschnitten – und biete unter anderem mit Bobalytics umfassende Governance- und Analyse-Funktionalitäten. IBM Bob lässt sich als Service über die Cloud und künftig auch On Premises nutzen.

Wie der Hersteller betont, können Entwickler über Berechtigungen, Freigaben und überprüfbare Pläne jederzeit festlegen, ob und in welchem Umfang IBM Bob autonom handelt. Auch können sie jederzeit die Arbeit von IBM Bob überwachen und bei Bedarf Korrekturen vornehmen („Human in the Loop“-Prinzip). Damit würden Entwickler während des kompletten SDLC die volle Kontrolle behalten.

So unterstützt IBM Bob während des Software-Lebenszyklus

Doch wie gestaltet sich dies konkret in der Praxis? IBM nennt verschiedene Aspekte. 

• Kein blinder Start der Code-Generierung: Gerade bei komplexen Aufgaben startet IBM Bob nicht sofort mit dem Erstellen von Code. Vielmehr wechselt das AI-Tool in den sogenannten „Plan-Modus“: Es erstellt einen strukturierten, schrittweisen Umsetzungsplan, den die jeweiligen Softwareentwickler explizit freigeben müssen, damit IBM Bob mit der Code-Generierung beginnt. Die Entwickler können dabei jederzeit Schritte abändern, löschen oder ergänzen. 
• Geführte Architekturentscheidungen: Anstatt eigenmächtig zu entscheiden, analysiert IBM Bob bestehende Repositories und schlägt etwa Optionen vor, um Legacy-Anwendungen zu modernisieren. Diese Vorschläge können Entwickler bewerten und jederzeit anpassen bzw. korrigieren. 
• Kontrollierte Agenten-Autonomie: Obwohl IBM Bob spezialisierte Sub-Agenten nutzt, die selbständig Code schreiben oder Dateien modifizieren, fungieren die Entwickler als eine Art „Gatekeeper“.  In der Praxis bedeutet das: Vor der Ausführung einer Aktion, etwa dem Überschreiben von bestehendem Code, wartet der AI-Agent auf die Freigabe der Entwickler. Erst wenn diese manuell erfolgt ist, führt der AI-Agent die Aktion aus.
• Kontrolle von automatisierten Testabläufen: IBM Bob ist in der Lage, automatisierte Testläufe mithilfe von Terminalbefehlen anzustoßen. Standardmäßig wird jeder Terminalbefehl den Entwicklern vorab zur Freigabe vorgelegt. Diese können jederzeit entscheiden, ob und welche Tests umgesetzt werden – und ob die Testergebnisse den Qualitätsansprüchen genügen. 
• Finale Freigabe des Codes: Bevor der mit IBM Bob generierte Code nun in die bestehende Codebasis der Software übernommen wird, müssen Entwickler diesen final freigeben. Dabei können sie unter anderem prüfen, ob der Code die Qualitätsstandards einhält und keine Sicherheitslücken in der Software verursacht.