Programmieren mit KI-Unterstützung vs. Paarprogrammierung
Vorwort / Aktueller Bezug
Mit dem Aufkommen der large language models (ChatGPT und Co.) werden diese zunehmend als Unterstützungswerkzeug in der Software Entwicklung eingesetzt. Allerdings geht das Framing dieser Werkzeuge weit darüber hinaus. So wirbt Github Copilot mit dem Slogan „Your AI Pair Programmer”. Und auch in Forschungsarbeiten wird die Arbeit mit diesen KI-Werkzeugen als Ersatz für die Paarprogrammierung beschrieben:„Our results demonstrate that agents can act as effective pair programming partners and open the way towards new research on conversational agents for programming.” (Kuttal, Sandeep Kaur, et al. "Trade-offs for substituting a human with an agent in a pair programming context: the good, the bad, and the ugly." Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems. 2021.)
Die AGSE erforscht seit knapp 20 Jahren die Paarprogrammierung und wir sind sehr skeptisch was diese Aussagen anbelangt. Aus unserer Sicht bedarf es qualitativer Forschung, die aufzeigt, welche Entscheidungen und Arbeitsschritte bei der Arbeit mit einem KI-Werkzeug durch dieses unterstützt werden und welche Entscheidungen / Arbeitsschritte im Vergleich dazu von der „normalen“ Paarprogrammierung zwischen zwei Menschen profitieren.
Arbeitsthema
Ziel der Arbeit soll es sein die Unterschiede und Gemeinsamkeiten in der Arbeitsweise mit einer KI vs. In der normalen Paarprogrammierung herauszuarbeiten.
Der Forschungsansatz der Arbeitsgruppe ist dabei Daten aus der Praxis, d.h. von Entwicklern, die in Unternehmen an der bestehenden Software arbeiten, in Form von Video-Aufzeichnungen der Arbeit (1-2 Stunden) einzusammeln und diese qualitativ mittels der Grounded Theory Methodology zu analysieren. Die Arbeitsgruppe verfügt bereits über eine umfangreiche Sammlung an „normalen“ Paarprogrammierungssitzungen, die zu diesem Zweck analysiert werden können. Für diese Abschlussarbeit müssen für den Vergleich allerdings auch neue Daten, nämlich Entwickler, die zusammen mit einer KI programmieren, gesammelt werden.
In der Analyse soll ein Schema zur Klassifizierung der Entscheidungen und Arbeitsschritte, die durch die KI bzw. durch einen menschlichen Partner unterstützt werden, entwickelt werden. Dies erlaubt es dann Gemeinsamkeiten und Unterschiede zu identifizieren besonders im Hinblick auf die Fragestellung: „Gibt es Arten von Entscheidungen / Arbeitsschritten, bei denen eine KI im Gegensatz zu einem anderen Entwickler nicht (oder nur oberflächlich) helfen kann?“
Es ist auch denkbar, dass ein Ergebnis der Arbeit die Feststellung sein kann, dass sich die Arbeitsprozesse so fundamental voneinander unterscheiden, d.h. dass diese gar nicht sinnvoll miteinander vergleichbar sind.
Was ist Paarprogrammierung?
Paarprogrammierung (PP) ist ein Arbeitsmodus, in dem zwei Programmierer*innen gemeinsam an einem Rechner in enger Zusammenarbeit und ständiger Kommunikation eine Aufgabe der Softwareentwicklung bearbeiten. Die Arbeitsweise ist eine wertvolle Ergänzung jeder Art von Softwareentwicklungsprozess. Eine PP-Sitzung dauert meist zwischen wenigen Minuten und ca. 3 Stunden.
Was ist der Forschungsstand der Arbeitsgruppe?
Die Arbeitsgruppe Software Engineering erforscht die Paarprogrammierung seit 2004. Sie hat anfangs die Grundelemente des Prozesses ermittelt, genannt Basiskonzepte und sich dann auf einen von zwei Hauptaspekten des Prozesses konzentriert: Den Wissenstransfer.Wir haben Dutzende von Aufzeichnungen kompletter PP-Sitzungen in zahlreichen verschiedenen Firmen gesammelt, auf denen die beiden Ingenieur*innen ihre jeweils gerade anstehende echte Arbeitsaufgabe bearbeiten. Diese Daten analysieren wir qualitativ mit der Grounded Theory Methodology (GTM).
Damit haben wir vieles über den Wissenstransfer herausgefunden (die beste Quelle für all diese Ergebnisse ist die Dissertation von Franz Zieris, ppknowtransdiss:- Wissenstransfer hat eine Episodenstruktur. Diese Episoden laufen in unterschiedlichen Modi ab: Push, Pull, Co-Produce oder Pioneering.
- Die PP insgesamt kann in drei verschiedenen Stufen von Flüssigkeit ablaufen: normal, fast und breakdown.
- Der Gesamtverlauf einer Sitzung beginnt immer mit dem Abgleich der Wissensstände (closing the primary gap) und dann dem gemeinsamen Aufbau des Wissens, das zum Lösen der aktuellen Aufgabe fehlt (closing the secondary gap). Beides betrifft nur systemspezifisches Wissen (S-Wissen, d.h. Wissen über die Codebasis). Beim zweiten Schritt wird unterwegs manchmal auch allgemeines Programmierwissen (G-Wissen, generic) übertragen, das nicht von der Codebasis abhängt.
- Es gibt so etwas wie PP-Können, das weitgehend unabhängig vom Programmierkönnen ist. Gute Paare sorgen dafür, dass ihre mentalen Zustände immer eng beeinander bleiben (hohe Togetherness) und balancieren kurz- und mittelfristige Ziele sinnvoll miteinander.
Schwierigkeitsgrad: Für wen geeignet?
GTM ist schwierig, man hat es im Studium nicht gelernt und es ist zudem eine Talentsache: hohe Intelligenz ist keine hinreichende Bedingung dafür, dass man das gut hinbekommt. Diese Arbeit ist insofern als schwierig anzusehen. Gut geeignet sind tendenziell Menschen, die sehr assoziativ denken und hinter Geschehnissen schnell plausible Muster und Mechanismen am Werk sehen, auch wenn sie diese zuvor nicht kennen.
Es gibt in der Vorlesung "Empirische Methoden im Software Engineering" inzwischen mit den Einheiten 4 und 5 einen Kurs zur GTM, mit dem man nicht nur die Grundzüge der GTM gut lernen, sondern dabei auch eine Idee davon bekommen kann, ob eine solche Abschlussarbeit wohl Erfolg verspricht.Die für diese Arbeit erforderliche zusätzliche Datenbeschaffung ist ein weiteres Hindernis, dass sich am besten dadurch aushebeln lässt, dass Sie bereits in einem Unternehmen arbeiten, dass diese Art der Forschung spannend fände (zur Verbesserung der eigenen Prozesse) oder Sie haben gute Chancen über Ihre Kommilitonen Kontakt zu solchen Unternehmen herzustellen.