Entwickler hängen nicht nur aus Gewohnheit an Tools wie Vim und Emacs oder integrierten Entwicklungsumgebungen, sondern weil diese Tools Teil der Art werden, wie sie Code denken, schreiben und überprüfen. Mit zunehmender langjähriger Erfahrung verwandeln sich Befehle und Abläufe in implizites Wissen und Muskelgedächtnis, sodass das Tool wie eine natürliche Verlängerung ihrer Hand wirkt. Diese Beziehung erklärt einen Teil der Zurückhaltung gegenüber agentischen Programmierwerkzeugen, die zwar ganze Anwendungen schnell erzeugen können, aber weniger präzise, transparent und vorhersehbar sind.
Der Artikel stellt eine Verbindung zwischen Tools, Vertrauen und dem sie umgebenden Prozess her. Ein vertrauenswürdiges Tool ist nicht nur eines, das eine Aufgabe ausführt, sondern eines, das dem Entwickler ermöglicht, seine Grenzen und sein Verhalten zu kennen und die Ergebnisse vorherzusehen. Agentische KI-Tools hingegen verändern ihre Fähigkeiten fortlaufend und beruhen auf Befehlen in natürlicher Sprache, die mehrdeutig sein können. Laut den im Artikel erwähnten Daten aus der jüngsten Entwicklerumfrage stieg der Anteil der KI-Nutzung von 76 % auf 84 %, während das Vertrauen in sie von 40 % auf 29 % sank.
Das Tool ist Teil des Entwicklungsprozesses
Zu lernen, in einem Terminal, in einem Texteditor oder in einer integrierten Entwicklungsumgebung zu arbeiten, bedeutet nicht nur, ein separates Programm zu erlernen. Es bedeutet, einen vollständigen Prozess zum Schreiben, Verstehen und Verbessern von Code aufzubauen. Deshalb kann der Wechsel vom Terminal zu einer integrierten Entwicklungsumgebung eine Neugestaltung der Arbeitsweise erfordern, während der Wechsel von einer dieser Umgebungen zu einem agentischen Programmierwerkzeug einen noch größeren Wandel darstellt.
Tricia Gee, eine Fürsprecherin der Entwicklerproduktivität, erklärt, dass ein Entwickler mit der Entwicklungsumgebung, die er kennt, schneller sein kann, weil sich seine Finger daran gewöhnt haben, was zu tun ist. Dasselbe gilt für erfahrene Vim- und Emacs-Nutzer. Mit der Zeit entsteht eine unbewusste Kompetenz, die dem Entwickler hilft, dem Tool zu vertrauen und es zum Erzeugen und Verbessern von Code einzusetzen.
Traditionelle Tools wie integrierte Entwicklungsumgebungen, Container-Tools und statische Analysatoren vermitteln dem Nutzer ein klares Bild ihrer Grenzen und Rollen. KI hingegen durchdringt mehrere Teile der Toolchain des Lebenszyklus der Softwareentwicklung, wodurch ein Vertrauensverlust in sie den gesamten Prozess beeinflusst. Das Schreiben von Code kann zwar schneller werden, doch seine Überprüfung und die Gewissheit, dass er bei der Produktion keine kostspieligen Ausfälle verursacht, können mehr Zeit beanspruchen.
Tools reparieren keine fehlerhaften Prozesse
Agentische Programmierwerkzeuge haben die Art des Entwicklungsprozesses verändert. Dadurch könnten Tools, die rund um den früheren Prozess entstanden sind, etwa Tools für statische Analyse, Unit-Tests, Integration und kontinuierliche Bereitstellung, in ihrer aktuellen Form weniger geeignet sein. Der Artikel unterscheidet jedoch zwischen dem Tool und dem Prozess, den es verkörpert: Ein gutes Tool für kontinuierliche Integration und Bereitstellung garantiert keinen schnelleren Versand, eine leistungsfähige integrierte Entwicklungsumgebung garantiert keinen besseren Code, und ein System zur Problemverfolgung garantiert keine präzise Aufwandsschätzung.
Ein Teil des Prozesses bildet sich innerhalb der Unternehmenskultur sowie durch das Verhalten und die Standards ihrer Mitglieder. Deshalb können neue Tools trotz großer Versprechen scheitern, wenn sie nicht mit der bestehenden Kultur und den bestehenden Prozessen übereinstimmen oder wenn die Entwickler nicht verstehen, warum sie eingesetzt werden. Der Artikel weist darauf hin, dass agentische Programmierwerkzeuge sich schnell verbreitet haben, weil sie Entwicklern helfen, Probleme rasch zu lösen. Gleichzeitig haben sie jedoch alte Mängel bei der Anforderungsdefinition, der Problemformulierung und der Bedeutung einer Lösung sichtbar gemacht.
Die Erzeugung von Code ist im Vergleich zu früher nahezu kostenlos geworden, seine Überprüfung jedoch nicht. Entwickler können mit riesigen, von Agenten in kürzester Zeit erzeugten Änderungen in Pull Requests konfrontiert werden, was die Last der Reviewer erhöht oder zu oberflächlichen Reviews führt. Es wird daran gearbeitet, ein Sprachmodell als Beurteiler einzusetzen, um den Umfang der Überprüfung zu erweitern. Der Aufbau von Vertrauen in die Fähigkeit der KI, von einer KI geschriebenen Code zu überprüfen, erfordert jedoch zusätzliche Arbeit.
Auch der Betrieb von Code verursacht Kosten. Dazu gehören Infrastrukturkosten sowie Cloud-Ressourcen für Rechenleistung, Speicher und Datenverkehr, abhängige Dienste und gehostete Programmierschnittstellen, außerdem die Kosten von Ausfällen wie Betriebsunterbrechungen, Sicherheitsverletzungen und Opportunitätskosten. Tools, die Code erzeugen, ohne diese Faktoren zu berücksichtigen, sind nicht zwangsläufig nützlich und können den Prozess schwächen, der zuvor zuverlässige Software hervorgebracht hat.
Vertrauen durch Verantwortung und Prozesse aufbauen
Im traditionellen Entwicklungszyklus war das Vertrauen auf miteinander verbundene Rollen verteilt: Produktmanager definierten die Anforderungen, Architekten entwarfen die Lösungen, Ingenieure entwickelten die Software und überprüften Änderungen, das Qualitätssicherungsteam testete Schwachstellen, und DevOps- sowie SRE-Spezialisten überwachten nach der Veröffentlichung Leistung und Ressourcen. Diese Verteilung trug dazu bei, die Wahrscheinlichkeit zu verringern, dass eine Person oder ein Tool außerhalb seiner Grenzen handelte und dadurch das System schädigte.
Der Artikel vertritt die Ansicht, dass ein KI-gestützter Entwicklungszyklus ähnliche Grundsätze benötigt: die Zusammenarbeit mit Menschen, die Festlegung von Verantwortung und Rechenschaftspflicht, die gemeinsame Nutzung und schrittweise Verbesserung von Prozessen sowie die Verringerung von Fehlermöglichkeiten. Menschen sollten weiterhin die verantwortlichen Parteien bleiben, wobei kenntlich zu machen ist, an welchen Stellen die KI beigetragen hat.
Die Verantwortung geht nicht allein deshalb auf den Agenten über, weil er die Änderung erstellt hat. Die Person, die die Änderung in das Repository überträgt, ist für den Code verantwortlich, und wer einen Pull Request genehmigt, ist für diese Genehmigung verantwortlich. Nach der im Artikel dargelegten Logik kann, wenn die Änderung die Produktionsumgebung beschädigt, nicht der Entwicklungsumgebung oder dem Tool die Schuld gegeben werden. Die Verantwortung liegt vielmehr bei den Personen und dem Prozess, die das Durchlassen der Änderung ermöglicht haben.
Dieser Wandel bringt eine weitere Herausforderung in Bezug auf die Zusammenarbeit mit sich. Ein Agent kann es einem einzelnen Entwickler ermöglichen, Aufgaben auszuführen, die von Produktanforderungen bis zu DevOps-Abläufen reichen. Dadurch steigt die Wahrscheinlichkeit, dass er zu einer isolierten Insel wird, die weder mit dem Designer noch mit dem auf eine bestimmte Codebasis spezialisierten Ingenieur kommuniziert. Der Artikel warnt davor, dass dieser Weg zu riesigen Pull Requests führen kann, selbst wenn das Tool in der Lage zu sein scheint, die Arbeit schnell auszuführen.
Die zentrale Schlussfolgerung lautet nicht, dass neue Tools nutzlos seien, sondern dass die alleinige Verbesserung von Tools nicht ausreicht, um einen fehlerhaften Entwicklungszyklus zu reparieren. Organisationen benötigen Prozesse, die Entwickler verstehen und akzeptieren, klare Grenzen für die Rolle von Agenten, eine menschliche Überprüfung mit tatsächlicher Verantwortung sowie Zusammenarbeit, die verhindert, dass Entwicklung zu einer abgeschotteten Einzelaktivität wird. Dann können Tools und Kultur gemeinsam neues Vertrauen in einer KI-gestützten Entwicklungsumgebung aufbauen.