In meinen vorherigen Artikeln „Effektive Code Reviews“ und „Moderne PHP-Entwicklung“ habe ich die Grundlagen der modernen Softwareentwicklung beleuchtet. Dabei ging es unter anderem um die Vor- und Nachteile synchroner und asynchroner Code-Review-Ansätze, die wichtige Rolle umfassender Tests und statischer Codeanalyse sowie die Notwendigkeit einer gut gepflegten Dokumentation.
Das mag wie eine Untersuchung bewährter Praktiken aussehen. Es geht jedoch nicht nur um bewährte Praktiken für menschliche Teams, sondern auch um wichtige Voraussetzungen für eine zuverlässige Zusammenarbeit mit KI-Agenten.
Von Assistenz zu Eigenständigkeit
Das Aufkommen von agentenbasierter KI in der Softwareentwicklung geht weit über reine Automatisierung hinaus. Anders als Code-Vervollständigungstools, die die nächsten Zeilen vorschlagen, oder Dialogassistenten, die einzelne Fragen beantworten, arbeiten KI-Agenten proaktiv auf einer deutlich höheren Abstraktionsebene. Anhand einer Spezifikation oder eines Fehlerberichts kann ein Agent die Codebasis analysieren, eine Implementierung erstellen und die entsprechenden Tests schreiben. Anschließend kann er diese Tests ausführen, etwaige Fehler beheben und einen Pull Request vorbereiten. All dies kann ohne kontinuierliche menschliche Anleitung erfolgen. Dieser Wandel verändert unsere Sichtweise auf Code Reviews, Tests und Dokumentationen grundlegend, ohne diese zu ersetzen, sondern indem er ihre Bedeutung als Kontrollrahmen erhöht, der die Vertrauenswürdigkeit der autonomen KI-Beteiligung ermöglicht und sicherstellt.
Diese Autonomie birgt sowohl Chancen als auch Risiken. Ohne angemessene Sicherheitsvorkehrungen können KI-Agenten bedenkliche Verhaltensweisen zeigen. Dazu gehört beispielsweise die Störung funktionierenden Codes, die Änderung von Logik in Bereichen, die nicht für Modifikationen vorgesehen sind, sowie die Einführung subtiler Architekturverstöße, die sich zu technischen Schulden summieren.
Die Unterscheidung zwischen KI-gestützter und agentenbasierter Entwicklung ist daher von entscheidender Bedeutung:
- Bei der unterstützten Entwicklung hat der Mensch die Kontrolle, wobei die KI Vorschläge macht und der Mensch die Entscheidungen trifft.
- Bei der agentenbasierten Entwicklung ist das Verhältnis umgekehrt: Die KI strebt ein Ziel an, während Menschen die Ziele definieren und die Ergebnisse überprüfen.
Für diese Umkehrung ist ein grundlegend anderer Ansatz für die Qualitätssicherung erforderlich. Die in meinen vorherigen Artikeln beschriebenen Praktiken sind dabei nicht nur hilfreich, sondern unverzichtbar.
Abstraktion, kein Ersatz
Anders als gelegentlich behauptet, ersetzen LLM-basierte Coding Agents keine Compiler. Sie sind vielmehr Teil einer Tradition von Tools, die es uns ermöglichen, auf einer höheren Abstraktionsebene über die Probleme nachzudenken, die wir lösen wollen. Wir haben uns vom Schreiben von Maschinencode-Anweisungen über Assembler zu höheren Programmiersprachen, Frameworks und anderen wiederverwendbaren Komponenten entwickelt. Diese Entwicklung spiegelt ein grundlegendes Prinzip der Softwareentwicklung wider: Je höher die Ebene ist, auf der wir über Probleme nachdenken, desto geringer ist die kognitive Belastung und desto komplexere Herausforderungen können wir angehen.
Dieses Muster zeigt sich ganz klar in der Geschichte der Programmiersprachen. Beim Maschinencode mussten wir in einzelnen Prozessorbefehlen und Speicheradressen denken. Assembler abstrahierte einige dieser Details, führte Mnemonik und Labels ein. Programmiersprachen wie Fortran und Cobol abstrahierten dann weiter und ermöglichten es, Logik in Begriffen auszudrücken, die mathematischen oder geschäftlichen Konzepten näherkamen. Objektorientierte Sprachen führten weitere Abstraktionen für die Modellierung realer Konzepte ein. Frameworks und Bibliotheken setzen diese Entwicklung fort, indem sie gängige Muster und allgemeine Logik kapseln.
Agentische KI-Systeme erweitern diese Tradition um eine weitere Ebene. Anstatt Code direkt zu schreiben, spezifizieren wir das Verhalten zunehmend durch Tests, Anforderungen und architektonische Einschränkungen. Der KI-Agent übernimmt dann den Zwischenschritt der Codegenerierung. Dadurch werden Compiler und andere grundlegende Tools jedoch nicht überflüssig. Compiler übersetzen nach wie vor Programmcode in Maschinenbefehle, und zwar unabhängig davon, ob der Code von einem Menschen oder einem KI-Agenten stammt. Stattdessen wird die Abstraktionsebene erhöht. Wir konzentrieren uns darauf, was die Software tun soll und warum, und überlassen die Details der Implementierung der Automatisierung.
Wir dürfen nicht vergessen, dass es bei der Softwareentwicklung im Wesentlichen darum geht, Probleme zu lösen. Die von uns geschaffenen Abstraktionen, von Assembler über Frameworks bis hin zu agentenbasierten Systemen, dienen diesem Zweck und sind kein Selbstzweck. Jede Generation von Werkzeugen hat Entwicklerinnen und Entwickler von Routinearbeit befreit, damit sie sich auf das eigentliche Problem konzentrieren können. Doch mit agentenbasierten Systemen verschärft sich die Grundfrage: Sie wandelt sich von „Wie organisieren wir die Arbeit?" zu „Wer macht die Arbeit?".
Menschliche Zusammenarbeit, Urteilsvermögen und kreative Problemlösung bilden auch weiterhin den unersetzlichen Kern der Entwicklung. KI-Agenten sind lediglich Werkzeuge, die menschliche Fähigkeiten durch die Ausführung mechanischer Aufgaben verbessern. Sie arbeiten jedoch im Rahmen menschlicher Absichten und unter menschlicher Aufsicht. Die höchste Abstraktionsebene in der Softwareentwicklung ist das menschliche Verständnis des zu lösenden Problems sowie die menschlichen Beziehungen, die es Teams ermöglichen, Lösungen gemeinsam zu verstehen, zu verfeinern und zu validieren.
Je klarer wir unsere Absichten durch Dokumentation, Tests und Spezifikationen kommunizieren, desto leistungsfähiger werden diese Werkzeuge. Denn auch weiterhin sind wir Menschen es, die die Probleme definieren, Lösungen durch strenge Anforderungen und Tests festlegen und die Verantwortung für die von uns geschaffenen Systeme tragen.
Code Review-Disziplin
In meinem Artikel über effektive Code Reviews habe ich die verschiedenen Kompromisse untersucht, die in der menschlichen Zusammenarbeit durch das Timing (synchron versus asynchron) und die Auswirkungen (blockierend versus nicht blockierend) entstehen. Die gleichen Dimensionen gelten auch, wenn KI-Agenten zu Mitwirkenden werden, allerdings mit neuen Implikationen.
Betrachten wir beispielsweise das Pair Programming, den synchronsten und blockierendsten Ansatz der menschlichen Codeüberprüfung. Mit KI entwickelt sich dieses Muster zu einem Prozess, bei dem ein Mensch Tests schreibt, die das Verhalten spezifizieren, während ein KI-Agent die Implementierung generiert. Die Synchronität dieses Prozesses sorgt für sofortiges Feedback: Wenn der von der KI generierte Code einen Test nicht besteht, kann der Mensch die Spezifikation sofort klarstellen. Der blockierende Aspekt stellt sicher, dass kein ungetesteter Code weiterverarbeitet wird. Dadurch bleiben die Qualitätskontrollen erhalten, die bereits für menschliche Teams wertvoll waren.
Asynchrone, blockierende Überprüfungen, die üblicherweise durch Pull Requests umgesetzt werden, lassen sich nahtlos in agentenbasierte Workflows übertragen. Ein KI-Agent erstellt einen Branch, implementiert Änderungen und öffnet einen Pull Request. Menschliche Reviewer untersuchen die Änderungen dann asynchron, der entscheidende Unterschied liegt jedoch darin, was sie überprüfen. Anstatt jede Zeile des Implementierungscodes zu hinterfragen, konzentrieren sie sich auf übergeordnete Aspekte.
- Passt diese Änderung zu den architektonischen Entscheidungen?
- Sind die Testspezifikationen umfassend?
- Führt sie zu technischen Schulden?
Obwohl die blockierende Natur des Review-Prozesses weiterhin wichtig ist, verlagert sich der Fokus der Überprüfung von der Korrektheit des Codes hin zur Angemessenheit der Spezifikationen sowie zur Integrität der Architektur.
Die Trunk-basierte Entwicklung mit ihren asynchronen, nicht blockierenden Code Reviews ist der fortschrittlichste Ansatz. Sie wird mit KI-Agenten jedoch nur dann praktikabel, wenn eine robuste Infrastruktur vorhanden ist.
Wie in meinem Artikel zu Code Review erwähnt, erfordert dieser Ansatz Feature Flags, das Branch-by-Abstraction-Muster und einfache Reversibilität. Bei KI-Agenten erfüllen diese Mechanismen einen zusätzlichen Zweck: Sie ermöglichen eine schrittweise Autonomie. So kann der Code eines Agenten hinter einem Feature Flag deployed werden, um eine schrittweise Einführung zu ermöglichen, während das Verhalten in der Produktion überwacht wird. Tritt ein Problem auf, kann die sofortige Rollback-Funktion verhindern, dass sich ein Incident in die Länge zieht.
Dieser Ansatz erfordert die umfassende Automatisierung und Testdisziplin, die ich in meinem Artikel über moderne PHP-Entwicklung beschrieben habe. Ohne diese wird der nicht blockierende Beitrag der KI eher leichtsinnig als schnell.
KI-Sicherheitsnetz
Die von mir beschriebenen modernen PHP-Entwicklungspraktiken, statische Analyse mit PHPStan, umfassende Tests mit PHPUnit, Mutation Testing mit Infection und eine gut gepflegte Dokumentation, wurden als Säulen einer nachhaltigen Entwicklung vorgestellt. Im Zusammenhang mit der agentenbasierten Entwicklung dienen dieselben Praktiken als Sicherheitsnetz, das die KI-Autonomie innerhalb akzeptabler Grenzen hält.
Werkzeuge für die statische Codeanalyse wie PHPStan bilden die erste Verteidigungslinie. Sie überprüfen den Code, ohne ihn auszuführen, und finden dabei Typfehler, undefinierte Variablen und potenzielle Laufzeitfehler. Wenn ein KI-Agent Code generiert, gibt die statische Analyse sofort objektives Feedback darüber, ob der Code die grundlegenden Korrektheitskriterien erfüllt. Durch diese automatisierte Überprüfung werden ganze Kategorien von Fehlern verhindert, noch bevor Menschen den Code überhaupt sehen und prüfen können.
Schon vor dem Aufkommen von KI-Agenten galt es als unprofessionell, auf automatisierte Tests zu verzichten. Bei der Arbeit mit KI-Agenten sind sie jedoch absolut entscheidend. Tests erfüllen einen doppelten Zweck: Einerseits überprüfen sie, ob sich der von der KI generierte Code korrekt verhält, andererseits legen sie fest, was „korrektes Verhalten“ bedeutet. Letzteres, also die Rolle der Tests als Spezifikation und Dokumentation, stellt eine grundlegende Veränderung der Perspektive dar. Menschen legen die Anforderungen durch die von ihnen geschriebenen automatisierten Tests fest. Eine umfassende Testsuite kodifiziert im Wesentlichen die Geschäftslogik, Architekturmuster und Edge Cases, die ein KI-Agent erfüllen muss. Je vollständiger und strenger die Tests sind, desto weniger Unklarheiten muss die KI interpretieren.
Mutationstests fügen eine weitere Verifizierungsebene hinzu, indem sie die Tests selbst testen. Tools wie Infection mutieren den Code, indem sie Operatoren ändern, Konstanten modifizieren und Bedingungen entfernen. So wird überprüft, ob die Tests bei Codeänderungen fehlschlagen. Dies ist für KI-generierten Code von entscheidender Bedeutung, da eine KI potenziell Code generieren könnte, der alle Tests besteht, aber dennoch subtil fehlerhaft ist. Mutationstests decken diese Probleme auf und stellen sicher, dass die Testsuite die Implementierungsentscheidungen der KI effektiv einschränkt.
Tests eliminieren Mehrdeutigkeit
Bei der testgetriebenen Entwicklung (TDD) mit KI-Agenten schreiben Menschen Tests, die das gewünschte Verhalten festlegen. Dann werden KI-Agenten eingesetzt, um Implementierungen zu erstellen, die diese Tests erfüllen. Der Red-Green-Refactor-Zyklus bleibt dabei gleich, aber die Arbeit wird zwischen Mensch und Maschine aufgeteilt:
- In der roten Phase, in der ein fehlgeschlagener Test geschrieben wird, geht es darum, Anforderungen in ausführbare Spezifikationen umzuwandeln, und diese Phase wird komplett vom Menschen gesteuert.
- Die grüne Phase, in der minimaler Code geschrieben wird, um den Test zu bestehen, wird KI-gesteuert.
- Die Refaktorierungsphase wird kollaborativ: Die KI kann Verbesserungen vorschlagen, während Menschen sicherstellen, dass die Refaktorierung die architektonische Integrität bewahrt.
Dieser Ansatz befasst sich mit einem grundlegenden Problem in der agentenbasierten Entwicklung: Wie können wir einem KI-Agenten unsere Absicht so präzise mitteilen, dass eine korrekte Implementierung gewährleistet ist? Beschreibungen in natürlicher Sprache sind, egal wie detailliert sie sind, immer mehrdeutig. Die Anforderung „Berechne den Rabatt für Bestandskunden" lässt offen, ab wann jemand als Bestandskunde gilt, wie der Rabatt gerundet wird und was bei negativen Beträgen passiert. Ein Test hingegen, der für einen Kunden mit mindestens drei Bestellungen einen Rabatt von 10 % erwartet und auf zwei Nachkommastellen rundet, lässt keinen Interpretationsspielraum.
Tests beseitigen diese Mehrdeutigkeit.
Dokumentation: Wissen und Einschränkungen
In meinem Artikel über moderne PHP-Entwicklung habe ich argumentiert, dass Dokumentation zwar schon immer für Menschen nützlich war, heute aber wichtiger denn je ist, weil „KI-basierte Codierungsagenten sie auch als Wissensbasis nutzen können“. Diese Beobachtung verdient eine genauere Betrachtung.
Mit Architecture Decision Records (ADR) werden wichtige Architekturentscheidungen einschließlich ihrer Begründung und der zu erwartenden Konsequenzen dokumentiert. Für menschliche Teams bieten diese Protokolle einen historischen Kontext und erklären, warum ein bestimmter Ansatz gewählt wurde, welche Alternativen in Betracht gezogen wurden und welche Kompromisse eingegangen wurden. Für KI-Agenten hingegen schränken sie den Lösungsraum ein. Ein ADR, das die Entscheidung dokumentiert, für bestimmte Bereiche Event Sourcing zu verwenden, würde beispielsweise implizit CRUD-artige Datenbankoperationen in diesen Bereichen verbieten. Ein KI-Agent, der darauf trainiert ist, ADRs zu beachten, wird entsprechenden Code generieren und so die architektonische Kohärenz aufrechterhalten, ohne dass ständige menschliche Eingriffe nötig sind.
Ähnlich verhält es sich mit Technical Debt Records (TDRs): Sie schränken das Verhalten der KI in die andere Richtung ein, indem sie bewusst eingegangene Kompromisse und deren geplante Lösungen dokumentieren. Ein KI-Agent, der sich der technischen Schulden bewusst ist, kann vermeiden, an anderer Stelle die gleichen Kompromisse einzugehen. Er kann auch Aufgaben priorisieren, die die dokumentierten Schulden reduzieren. Qualitätsziele legen messbare Qualitätsstandards für das gesamte Projekt fest, beispielsweise Anforderungen an die Reaktionszeit, Verfügbarkeitsziele und Sicherheits-Compliance-Level. Diese Ziele können direkt in Fitnessfunktionen umgesetzt werden. Dabei handelt es sich um automatisierte Checks, die überprüfen, ob das System die gewünschten Qualitätsmerkmale aufweist.
Werden sie richtig verstanden, nämlich als Grundsätze und nicht als Formatierungsregeln, dann sind Coding Guidelines die Brücke zwischen den großen Architekturentscheidungen und den kleinen Implementierungsentscheidungen. Eine Richtlinie, die besagt, dass Wertobjekte unveränderlich sein sollten, würde beispielsweise die Art und Weise einschränken, wie ein KI-Agent neue Wertobjekte implementiert. Eine Richtlinie, die eine explizite Ausnahmebehandlung für E/A-Operationen vorschreibt, legt fest, wie der Agent das Fehlermanagement strukturiert. Das sind keine Stilpräferenzen. Es handelt sich um Architekturmuster, die auf Codeebene ausgedrückt werden und die Konsistenz gewährleisten, wenn sowohl Menschen als auch KI-Agenten einen Beitrag leisten.
Wenn KI schneller ist als Lernen
Die ambivalente Natur von KI-Agenten zeigt sich auch in einer differenzierten Betrachtung ihrer tatsächlichen Auswirkungen auf Entwicklungsteams. Prof. Dr. Dirk Riehle fasst diese Spannung prägnant zusammen:
Code AIs are beneficial in that they increase speed of developers who were brought up without code AIs and they also reduce traditional bugs that junior or distracted developers might introduce. At the same time they introduce a new type of bug that requires new skills. I suspect developers need to learn to be much more flexible with speed, in particular to learn when to slow down and review thoroughly. What I don't know is how to compensate for the deskilling of developers—throwing more AI at the problem seems to be an unlikely solution.
Diese Beobachtung unterstreicht einen zentralen Punkt: Der Geschwindigkeitsvorteil von KI-Agenten ist real, jedoch nur für Entwicklerinnen und Entwickler, die bereits über ein fundiertes Verständnis der zugrunde liegenden Prinzipien verfügen.
Jüngste groß angelegte empirische Untersuchungen zur KI-gestützten Programmierung bestätigen diese Befürchtung. Eine Analyse von Millionen von GitHub-Commits zeigt, dass jüngere Entwicklerinnen und Entwickler tatsächlich stärker auf KI-generierten Code zurückgreifen als ihre älteren Kolleginnen und Kollegen, obwohl die messbaren Produktivitätsgewinne fast ausschließlich erfahrenen Entwicklerinnen und Entwicklern zugutekommen. Diese Umkehrung, mehr Einsatz von KI, aber weniger Nutzen für jüngere Entwicklerinnen und Entwickler, deutet darauf hin, dass generative Tools das vorhandene Fachwissen erweitern, anstatt fehlende Grundlagen zu ersetzen, was die von Riehle beschriebene Gefahr der Dequalifizierung noch verstärkt.
In meinem Artikel „Schneller als Verstehen" habe ich diese Asymmetrie anhand eines konkreten Experiments untersucht: Ein KI-Agent implementierte einen nicht trivialen Algorithmus in 15 Minuten, aber die Überprüfung des Ergebnisses dauerte länger als die eingesparte Zeit, und die Korrektheit blieb letztlich ungeklärt. Richtig aussehen und richtig sein sind nicht dasselbe.
Gleichzeitig verlagert sich die Art der Fehler. Während früher Syntaxfehler und einfache Logikfehler dominierten, entstehen nun subtilere Probleme durch fehlerhafte Architekturentscheidungen, unvollständige Kontexterfassung oder inkonsistente Implementierungen über verschiedene Codebereiche hinweg.
Die von Riehle angesprochene Notwendigkeit, flexibel zwischen verschiedenen Geschwindigkeiten zu wechseln und zu erkennen, wann eine gründliche manuelle Überprüfung erforderlich ist, verweist direkt auf die Bedeutung der in diesem Artikel beschriebenen Praktiken. Besonders besorgniserregend ist die Frage nach den Auswirkungen von KI-Agenten auf die Kompetenzentwicklung: Wenn Junior-Entwicklerinnen und -Entwickler von Anfang an mit KI-Agenten arbeiten, welche fundamentalen Fähigkeiten eignen sie sich dann nicht mehr an?
Tests, Code Reviews und umfassende Dokumentation werden in diesem Kontext zu mehr als nur Qualitätssicherungsinstrumenten. Sie werden zu unverzichtbaren Lernumgebungen, in denen auch KI-gestützte Entwicklerinnen und Entwickler die tieferen Zusammenhänge ihrer Arbeit erfassen und hinterfragen müssen.
Wenn wir diese Lernumgebungen ignorieren, wird sich das derzeitige Muster, bei dem Nachwuchsentwicklerinnen und Nachwuchsentwickler mehr KI einsetzen, aber weniger davon profitieren, wahrscheinlich eher verfestigen als korrigieren.
Menschliche Handlungsfähigkeit bewahren
Das in diesem Artikel beschriebene Framework ermöglicht eine sichere und zuverlässige Entwicklung mit Agenten. Dieses basiert auf einer strengen Codeüberprüfung, umfassenden Tests, statischer Analyse und klarer Dokumentation. Diese Praktiken sind keine professionellen Feinheiten mehr. Sie sind die Kontrollmechanismen, die es uns ermöglichen, KI-Agenten als Kooperationspartner in der Softwareentwicklung zu nutzen.
Diese technische Lösung zeigt aber auch ein tieferes strukturelles Problem auf, das wir uns klar machen müssen: Wer ist eigentlich für den Entwicklungsprozess selbst verantwortlich?
Die hier besprochenen technischen Praktiken wie Code Reviews, statische Codeanalyse, automatisierte Tests und CI/CD-Pipelines bilden seit Jahrzehnten die Grundlage der professionellen Softwareentwicklung. Dass sie jetzt als unverzichtbar gelten, ist ein Grund zur Freude: Endlich erkennt die Branche in großem Maßstab, dass nachhaltige Software Disziplin, Zusammenarbeit und menschliche Aufsicht erfordert. Als jemand, der diese Prinzipien seit über 25 Jahren in Open Source-Communities und in der technischen Ausbildung vertritt, freut es mich sehr, diese Bestätigung zu erhalten.
Die Konzentration der Infrastruktur für die agentenbasierte Entwicklung wirft jedoch berechtigte Bedenken hinsichtlich der kreativen Kontrolle und der wirtschaftlichen Macht auf. Da die Entwicklung zunehmend über Cloud-Plattformen, KI-Systeme und automatisierte Workflows vermittelt wird, nimmt die praktische Fähigkeit, Software unabhängig zu erstellen, ab. Die versprochenen Effizienzgewinne bei der Entwicklungsgeschwindigkeit können mit subtilen, aber bedeutenden strukturellen Abhängigkeiten von proprietären Toolchains, Infrastrukturanbietern und Systemen einhergehen, deren interne Entscheidungsprozesse undurchsichtig sind.
Die Praktiken, die ich in diesem Artikel diskutiere, gehen davon aus, dass KI-Agenten innerhalb bestehender Codebasen arbeiten und diese durch die systematische Anwendung klar definierter Spezifikationen umgestalten, erweitern und verbessern. Das ist eine überzeugende Vision. Es gibt jedoch eine berechtigte Sorge: Wenn agentenbasierte Systeme Code durchgängig effizienter generieren können, als wir bestehende Bibliotheken navigieren, verstehen und wiederverwenden können, dann sinkt der Anreiz, modulare, wiederverwendbare Software zu entwickeln. Diese Dynamik stellt ein besonderes Risiko für Open Source dar. Warum sollten wir eine Bibliothek pflegen, wenn eine KI für jeden neuen Kontext spezialisierten Code generieren kann? Warum sollten wir zu Open Source beitragen, wenn die vom Anbieter bereitgestellte Infrastruktur die Codegenerierung, -überprüfung und -bereitstellung übernehmen kann?
Wie jede Entwicklung hängt auch die agentenbasierte Entwicklung von menschlichen Spezifikationen ab. Je strenger, detaillierter und durchdachter die Spezifikationen sind, egal ob sie als Tests, Dokumentation oder architektonische Einschränkungen kodiert sind, desto besser arbeiten die KI-Agenten. Das ist keine Schwäche, sondern ein grundlegendes Merkmal. Es bedeutet, dass es immer wichtiger wird, zu definieren, was Software leisten soll, die Bedürfnisse der Nutzerinnen und Nutzer zu verstehen und wartbare, erweiterbare Systeme zu entwerfen. Es bedeutet auch, dass Open Source-Projekte, die sich durch klare Spezifikationen, umfassende Tests und eine gut dokumentierte Architektur auszeichnen, nicht überflüssig werden, sondern vielmehr unverzichtbar sind. Entwicklerinnen und Entwickler, die ein tiefes Verständnis für Systeme haben, bei komplexen Problemen effektiv zusammenarbeiten und Bibliotheken pflegen, die hart erarbeitetes Fachwissen verkörpern, bleiben unersetzlich.
Die eigentliche Herausforderung besteht darin, sicherzustellen, dass dieses Fachwissen und diese Fähigkeit zur Zusammenarbeit über Unternehmensplattformen hinaus bestehen bleiben. Dazu müssen Open Source-Communities die in diesem Artikel beschriebenen Grundsätze aktiv einhalten. Dazu gehört, nicht nur den Code zu dokumentieren, sondern auch die Gründe für architektonische Entscheidungen zu erläutern und Räume für echte Zusammenarbeit zu schaffen, in denen Menschen voneinander und von den gemeinsam entwickelten Systemen lernen können. Auch bei den Bedingungen, unter denen Open Source existiert, ist Vorsicht geboten, um sicherzustellen, dass wir nicht unter Druck gesetzt werden, die Kontrolle über unsere Arbeit aufzugeben, und dass wir weiterhin unabhängige Projekte verzweigen und pflegen können. Auch der kreative Prozess selbst muss davor geschützt werden, vollständig von proprietären Infrastrukturen vereinnahmt zu werden.
Die hier beschriebenen Praktiken sind nicht nur Schutzmaßnahmen für die Autonomie der KI, sondern auch Voraussetzungen für menschliches Handeln. Durch das Beharren auf klaren Spezifikationen, strengen Tests, transparenten Überprüfungsprozessen und verständlicher Dokumentation sichern wir nicht nur die Qualität der von uns entwickelten Software, sondern auch unsere Fähigkeit, ihre Entwicklung zu steuern. Dieser Grundsatz gilt unabhängig davon, ob wir mit KI-Agenten oder miteinander arbeiten.
Die Frage ist nicht, ob die Entwicklung von Agenten unsere Arbeitsweise verändern wird. Das tut sie bereits. Die Frage ist, ob wir gemeinsam auf Bedingungen bestehen werden, unter denen diese Technologie der menschlichen Kreativität und Zusammenarbeit dient, anstatt sie zu ersetzen.
Dieser Artikel bietet einen technischen Rahmen für diese Zukunft. Um das zu erreichen, braucht es mehr als nur Protokolle zur Codeüberprüfung und Testdisziplin. Es braucht ein bewusstes Engagement dafür, dass die Softwareentwicklung ein offenes, verständliches und kollaboratives Handwerk bleibt.
Das ist persönlich
Die Frage, die am Ende des letzten Abschnitts gestellt wurde, hat Auswirkungen, die weit über Softwareentwicklerinnen und Softwareentwickler hinausgehen. Ob Technologie der menschlichen Kreativität und Zusammenarbeit dient oder sie ersetzt, ist im Grunde eine Frage danach, wie Computer unser aller Alltag prägen und ob wir uns gemeinsam für Ersteres einsetzen.
Wie Jürgen Geuter argumentiert:
Personal computing must be based on individual human or group needs but also on the technology side based on open standards that allow different tools and infrastructures to connect and share and collaborate. And it's a social project of all of us building things, trying things, learning from one another. So we can build upon each others successes and failures. It's „human needs, community sharing and standards“ instead of „platforms“ or „everything machines“.
Diese Vision steht im direkten Gegensatz zum aktuellen, von Plattformen dominierten Modell, das die Kontrolle und den wirtschaftlichen Wert innerhalb von Unternehmensstrukturen konzentriert und die Nutzerinnen und Nutzer eher als Datenquellen denn als kreative Akteure behandelt. Die Alternative konzentriert sich auf menschliche Bedürfnisse statt auf Lock-in, auf gemeinschaftliches Teilen statt auf proprietäre Kontrolle und auf offene Standards statt auf geschlossene Ökosysteme.
Die praktischen Auswirkungen für alle, die digitale Tools nutzen – Lehrerinnen und Lehrer, die Lehrpläne entwerfen, Kunstschaffende, die ihre Werke teilen, Organisatorinnen und Organisatoren von Communities, die Aktionen koordinieren – sind die gleichen wie für Menschen, die Software entwickeln. Kannst du deine Daten verschieben, ohne sie zu verlieren? Verstehst du, was Systeme mit deinen Informationen machen? Kannst du über Plattformgrenzen hinweg zusammenarbeiten? Kannst du auf der Arbeit anderer aufbauen?
Die für die agentenbasierte Entwicklung beschriebenen Praktiken – klare Spezifikationen, strenge Tests, transparente Überprüfungen und umfassende Dokumentation – sind mehr als nur technische Disziplin. Sie sind auch Beispiele für die Prinzipien der technologischen Bürgerschaft, die darauf bestehen, dass Systeme menschlichen Zwecken dienen und nicht dazu, die von denjenigen, die sie kontrollieren, definierten Kennzahlen zu optimieren.
So wie KI-Agenten das Risiko bergen, Entwicklerinnen und Entwickler überflüssig zu machen, indem sie ihnen die Möglichkeit nehmen, ein tiefes Verständnis zu entwickeln, besteht bei plattformvermittelter Datenverarbeitung die Gefahr, dass Nutzerinnen und Nutzer überflüssig werden, weil ihnen jede sinnvolle Kontrolle genommen wird. Dieser Weg ist nicht unausweichlich. Die Wahl zwischen „menschlichen Bedürfnissen, gemeinschaftlichem Austausch und Standards“ und „Plattformen“ bleibt offen, aber nur durch das gemeinsame Beharren auf Verständlichkeit, Interoperabilität und einer Governance, die die Handlungsfähigkeit des Menschen bewahrt.
Dies erfordert nachhaltige Investitionen in offene Standards, von der Gemeinschaft gesteuerte Alternativen und institutionelle Vereinbarungen, die verhindern, dass Unternehmen Projekte an sich reißen. Wie Geuter es treffend nennt, handelt es sich um „ein soziales Projekt, bei dem wir alle gemeinsam Dinge erschaffen, ausprobieren und voneinander lernen“.
