How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study
Durch eine Mixed-Methods-Studie mit 100 Praktikern zeigt diese Arbeit auf, dass der Einsatz von Software-Engineering-Agenten die Entwicklungsengpässe vom Programmieren hin zu nicht-programmierenden Aktivitäten wie Anforderungsmanagement und Koordination verschiebt, was einen evaluationsgetriebenen Workflow fördert, der durch einen siebenstufigen Prozess sowie Herausforderungen wie unzuverlässige Evaluationssignale und Verständnis-Schulden gekennzeichnet ist.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, die Softwareentwicklung wäre früher wie der Bau eines Hauses mit Hammer und Säge gewesen. Man musste jedes einzelne Brett sägen, jeden einzelnen Nagel einschlagen und jede Oberfläche von Hand abschleifen. Es war langsam, ermüdend, und der „schwierige Teil“ bestand lediglich darin, den Hammer zu schwingen.
Stellen Sie sich nun vor, jemand überreicht Ihnen einen magischen, superschnellen Roboter, der ein ganzes Haus im Handumdrehen schneiden, nageln und schleifen kann. Plötzlich ist der Hammer nicht mehr das Problem. Das Problem ist, dass der Roboter so schnell ist, dass er eine ganze Villa baut, noch bevor Sie überhaupt fertig sind, Ihre Blaupausen zu zeichnen.
Genau das ist passiert, als Entwickler begannen, SE-Agenten (KI-Roboter, die Code schreiben) einzusetzen. Eine neue Studie von Forschern, die mit 20 Erbauern aus 12 verschiedenen Unternehmen sprachen und weitere 80 befragten, fand heraus: Während die Roboter das Schreiben von Code billig und schnell machten, ließen sie den Job nicht verschwinden. Stattdessen verschob sich der „Engpass“ (der Verkehrsstau im Prozess) einfach auf einen anderen Teil der Straße.
Hier ist, was die Forscher entdeckten, erzählt in der Sprache eines neugierigen Entdeckers.
Der neue Sieben-Schritte-Tanz
Die Arbeit legt nahe, dass der Bau dieser KI-Agenten kein gerader Strich mehr ist, sondern ein kreisförmiger Tanz mit sieben Schritten. Es ist weniger wie ein Fließband in einer Fabrik und mehr wie ein Videospiel, bei dem man Level immer wieder spielt, um eine höhere Punktzahl zu erreichen.
- Die Blaupause (Anforderungen): Sie sagen dem Roboter, was er tun soll. Aber jetzt müssen Sie die Anweisungen so klar formulieren, dass sowohl Menschen als sich der Roboter sie lesen können.
- Die Bewertung (Evaluation): Dies ist der wichtigste neue Schritt. Sie prüfen die Arbeit nicht erst am Ende; Sie nutzen eine Bewertungsskala, um den Roboter während der Arbeit zu steuern.
- Der Treibstoff (Daten): Sie füttern den Roboter mit Beispielen guter Arbeit, damit er daraus lernen kann.
- Der Bau (Systemkonstruktion): Sie wählen ein Gehirn für den Roboter (ein Modell) und bauen ein „Geschirr“ (eine Rüstung mit Werkzeugen und Gedächtnis) um ihn herum auf.
- Die Testfahrt (Testen & Bereitstellung): Sie lassen den Roboter laufen und schauen, ob er abstürzt.
- Die Feedback-Schleife (Menschliches Feedback): Sie beobachten, was er tut, und sagen ihm: „Nein, mach es so auf diese Weise“ oder „Ja, das war großartig“.
- Die Wartung (Adaptive Instandhaltung): Das Gehirn des Roboters könnte ein Update von seinem Schöpfer erhalten, was seine Denkweise verändert. Sie müssen Ihr Geschirr ständig anpassen, um Schritt zu halten.
Der große Wandel: Vom Hammerführenden zum Roboter-Manager
Die Studie ergab, dass, da die Roboter Code so schnell schreiben können, die alte Vorstellung, dass „Codieren der schwierige Teil ist“, widerlegt wurde. Die Forscher argumentieren, dass Codieren nie der schwierigste Teil war; es war nur der lauteste Teil.
Jetzt, da der Roboter die schwere Arbeit erledigt, hat sich die eigentliche Arbeit auf das Überprüfen und Evaluieren verlagert.
- Der „Vibe Coding“-Effekt: Da der Roboter Dinge so schnell bauen kann, verschwimmen die Grenzen zwischen „Forscher“, „Ingenieur“ und „Manager“. Eine Person kann nun den gesamten Job erledigen, vom Träumen der Idee bis hin zum Beheben des letzten Fehlers.
- Das „Black Box“-Problem: Die Forscher legen nahe, dass man dem Roboter nicht einfach vertrauen kann, da er eine „Black Box“ ist (man kann nicht genau sehen, wie er denkt). Man benötigt einen strikten Stil der „Evaluation-Driven Development“. Das bedeutet, man definiert die Regeln für den Erfolg bevor man beginnt, und prüft ständig, ob der Roboter tatsächlich besser wird, nicht nur schneller.
Die sechs Fallen (Herausforderungen)
Selbst mit superschnellen Robotern stießen die Erbauer auf sechs große Hindernisse. Die Arbeit legt nahe, dass dies reale, harte Probleme sind und keine bloßen kleinen Fehler.
- Die kaputte Bewertungsskala: Woher wissen Sie, ob der Roboter eine gute Arbeit geleistet hat? Die Forscher fanden heraus, dass die „Tests“, die den Roboter bewerten, oft fehlerhaft sind. Manchmal findet der Roboter eine bessere Lösung, als der Test erwartet hat, aber der Test gibt dennoch ein „Fehlgeschlagen“ aus, weil er nach der alten Antwort sucht. Ein anderes Mal ist der Test einfach zu teuer, um ihn jedes Mal durchzuführen.
- Der „Nichts ändern, alles ändern“-Fluch: Das ist eine unheimliche Sache. Die Forscher fanden heraus, dass, wenn das Unternehmen, das das Gehirn des Roboters erstellt hat, dieses aktualisiert (selbst wenn Sie an Ihrem Code nichts geändert haben), Ihr Roboter plötzlich anfangen kann, sich anders zu verhalten. Ein Werkzeug, das gestern noch funktionierte, könnte heute kaputt sein, obwohl Sie null Zeilen Code geändert haben.
- Sicherheit vs. Geschwindigkeit: Erbauer geben oft zu, dass sie Angst vor den Robotern haben, sie aber trotzdem laufen lassen, um Dinge schneller zu erledigen. Die Arbeit legt nahe, dass dies gefährlich ist. Ein Team ließ einen Roboter los, und dieser löschte versehentlich das Home-Verzeichnis eines Benutzers, weil er seine Anweisungen vergessen hatte.
- Die Lücke der „ungeschriebenen Regeln“: Roboter können nur lesen, was aufgeschrieben ist. Aber im echten Leben ist viel Wissen einfach „in den Köpfen von Menschen“ (wie zum Beispiel, warum eine bestimmte Wand schief gebaut wurde). Die Forscher fanden heraus, dass Roboter nicht auf dieses „ungesagte“ Wissen zugreifen können, was zu Verwirrung führt.
- Die Verständnis-Schuld (Comprehension Debt): Das ist die größte Überraschase. Die Roboter schreiben Code schneller, als Menschen ihn verstehen können. Es ist, als würde der Roboter in einem Tag einen Wolkenkratzer bauen, während Sie noch versuchen, die Blaupause zu verstehen. Die Erbauer häufen eine „Schuld“ an Code an, den sie nicht verstehen. Um dies zu beheben, beginnen einige Teams damit, die Anweisungen zu speichern, um den Code wieder aufzubauen, anstatt den Code selbst zu speichern.
- Die falsche Produktivität: Wenn man nur zählt, wie viele Zeilen Code der Roboter schreibt, sieht es so aus, als wäre jeder super produktiv. Aber die Forscher legen nahe, dass dies eine Falle ist. 10.000 Zeilen Code zu schreiben, die niemand versteht oder braucht, ist nicht „produktiv“. Es ist nur „Rauschen“.
Wie sicher sind wir?
Die Forscher sind ziemlich zuversichtlich in ihre Ergebnisse, weil sie nicht nur geraten, sondern sie gemessen haben.
- Sie interviewten 20 Experten und befragten dann 80 weitere.
- Als sie die Befragte Gruppe fragten, ob sie den Ergebnissen zustimmten, stimmten 91 % dem neuen Arbeitsablauf zu, und zwischen 71 % und 95 % stimmten den spezifischen Herausforderungen zu.
- Sie gingen sogar zurück zu den ursprünglichen Interviewpartnern, um zu prüfen, ob diese der Zusammenfassung zustimmten (ein Prozess namens „Member Checking“), und die Experten sagten: „Ja, genau das ist es, was wir tun.“
Das Fazit
Die Arbeit legt nahe, dass der Bau von KI-Agenten die Softwaretechnik nicht einfach gemacht, sondern sie anders gemacht hat. Der „schwierige Teil“ hat sich vom Schreiben des Codes hin zum Management des Roboters, zum Überprüfen seiner Arbeit und dazu verschoben, sicherzustellen, dass er nicht versehentlich das Internet löscht.
Die Forscher kommen zu dem Schluss, dass die Implementierung, während sie billiger wird, die Engpässe nicht verschwinden lässt – sie verschieben sich nur. Die Zukunft des Bauens von Software liegt nicht darin, schneller zu tippen; es geht darum, ein besserer Manager, ein strengerer Richter und ein klügerer Architekt für die Roboter zu sein, die die schwere Arbeit erledigen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.