Ein Softwarebetreuer teilt mit, dass er keine externen Pull Requests (PRs) mehr für sein Projekt akzeptiert, da die aktuelle Arbeitsweise für beide Seiten ineffizient geworden ist. Die Entscheidung basiert auf Sicherheitserwägungen, persönlichen Codierungspräferenzen und den veränderten Möglichkeiten durch künstliche Intelligenz. Der Hauptgrund für die Weigerung liegt im Sicherheitsrisiko. Da der Betreuer viele Mitwirkende nicht persönlich kennt, muss er bei externen Codeänderungen immer davon ausgehen, dass böswillige Absichten dahinterstecken könnten. Dies erhöht das Risiko für das Projekt erheblich. Zudem bestehen bei externen Entwicklern oft unterschiedliche Ansichten bezüglich Formatierung, Struktur und Abhängigkeiten, was zu langen Diskussionen und Verzögerungen durch Rückkopplungsschleifen führt. Die Einführung leistungsstarker LLMs hat das Gleichgewicht in der Softwareentwicklung verschoben. Während das Schreiben von Code früher eine zeitliche Hürde darstellte, die durch externe Beiträge gerechtfertigt war, kann der Betreuer diese Aufgabe heute schneller und sicherer selbst erledigen. Er hat seine eigenen Stilrichtlinien bereits für KI-Modelle codifiziert und kann in seinem eigenen Zeitplan iterieren, ohne mit anderen Zeitzonen oder menschlichen Reviewern synchronisieren zu müssen. Er betrachtet Quellcode heute weniger als kreativen Ursprung, sondern eher als formale Zwischenschicht zwischen einer Idee und der Computeranweisung. Der Betreuer sieht sich selbst an einem Punkt, an dem er Design-Entscheidungen trifft, von einem Agenten den Code generieren lässt und das Ergebnis anschließend überarbeitet. Sein Engpass liegt nicht im Schreiben, sondern im Design, im Überprüfen und im Testen. Daher helfen externe Implementierungen des Codes in der Regel nicht weiter. Stattdessen schlägt er andere Wege vor, wie Entwickler unterstützen können. Das Feedback von Nutzern darüber, was funktioniert und was verbessert werden muss, ist wertvoller denn je. Auch der Austausch von Ideen und unterschiedlichen Perspektiven hilft bei der Planung. Die Meldung und Untersuchung von Fehlern bleibt kritisch; ein guter Fehlerbericht, der Reproduktionsschritte enthält, spart dem Betreuer erhebliche Zeit. Ermutigend ist zudem der Vorschlag, Referenz-PRs oder die verwendeten Prompts zu teilen. Obwohl der Code selbst nicht gemergt wird, dient er als anschauliches Beispiel. Noch wichtiger ist es, die Prompt-Struktur zu offenlegen, damit der Betreuer sie als Vorlage nutzen und verfeinern kann. Auch das Überprüfen von Code durch Dritte ist willkommen, da der Betreuer hier ein Flaschenhals ist. Abschließend fordert er Nutzer auf, die Software bei Bedarf einfach zu forken. Da LLMs eine hohe Anpassungsfähigkeit ermöglichen, können Nutzer Änderungen für ihre spezifischen Anwendungsfälle schnell selbst vornehmen, ohne auf eine Einigung oder Erlaubnis warten zu müssen. Dies entlastet den Betreuer von der Last, Kompromisse für viele verschiedene Nutzungsfälle auszuhandeln, und ermöglicht es allen Beteiligten, voneinander zu lernen.