Software-Teams gibt es nicht mehr klein: 100 parallele Coding-Agenten erzwingen modulare Architektur
There's no such thing as a small software team anymore
Ein einzelner Entwickler, der 20 bis 100 Coding-Agenten parallel laufen lässt, erzeugt so viele Commits und Pull Requests wie ein großes Team – und macht monolithische Codebasen zum Flaschenhals. Jacob Gold argumentiert, dass modulare Architektur, wie sie Uber mit Tausenden Microservices betreibt, zum neuen Standard wird, weil Agenten den Overhead der Modularität drastisch senken. Wer mit vielen Agenten produktiv sein will, muss Code so aufteilen, dass er in die Kontextfenster der Modelle passt.
Wenn Sie Tausende von Microservices wie Uber haben, haben Sie eine 'peinlich parallele' Arbeitsweise am Code.
- kstenerud
Hunderte von Bots, die Tausende von Microservices verändern, mögen oberflächlich gut klingen, aber all diese Tausende von Microservices bilden eine Architektur und ein Produkt. Agenten sind nicht besonders gut darin, das gesamte Modell in ihrem Kontext zu tragen. Wenn sie also über ein kleines Stück Code nachdenken, kommen sie oft auf etwas, das anderen Teilen des Codes schadet (besonders wenn die KLOCs sich häufen). Die Komplexität wurde nicht ersetzt, nur verschoben. Und was, glaubst du, wird passieren, wenn all diese Microservices noch mehr zu einem beweglichen Ziel werden, als sie es ohnehin schon sind? KI ist in der Lage, die Produktivität zu verbessern, aber dieser Ansatz klingt eher nach einem Albtraum in der Entstehung.
- davepeck
Ein weiser Troll sagte einmal:
> Beste Waffe gegen den Komplexitäts-Geist-Dämon ist das Zauberwort: "nein"
Im Kontrast dazu glaube ich, dass kleine Teams klein bleiben können. Kleine Teams können einfache Monolithen mit hoher Geschwindigkeit, Commit-Anzahl und Qualität ausliefern. Serviceorientierung ist durch Agenten nicht plötzlich kostengünstig geworden; die Grenzen zwischen mehreren Diensten, die unabhängig versioniert und bereitgestellt werden, sind immer noch knifflige Biester, die man bändigen muss. Und es ist nicht klar, warum "mehr Agenten ausführen" inhärent wünschenswert oder wirkungsvoll ist; die Erfahrung meines kleinen Teams (zugegebenermaßen anekdotisch) ist, dass der Wert schnell gesättigt ist.
- ulrikrasmussen
Ich habe bereits kommentiert, dass dies wahrscheinlich der schlechteste Ratschlag ist, den ich seit langem gehört habe, und ich würde diesen Typen definitiv nicht in die Nähe einer Codebasis lassen, die ich warten müsste.
Aber das ist auch im Wesentlichen Blogspam. Der Autor fügt absichtlich zwei Screenshots ein, die absolut nichts zu seinem Punkt beitragen und zu klein zum Lesen sind. Wenn man auf den zweiten klickt, wird man nicht zu einer größeren Version weitergeleitet, sondern zur Startseite seiner Firmenwebsite, die denselben Screenshot zeigt.
- whatever1
Warte zwei Jahre, bis wir genügend Fluktuation von Senior-Talenten in den Teams haben. Dann werden alle Dienste täglich Ausfälle haben.
Nur die Seniors, die ihre Systeme kennen, halten heute die Lichter an, indem sie Bullshit-Commits fernhalten.
Sobald sie ausbrennen und kündigen, wird niemand eine verdammte Ahnung haben, was die LLMs getan haben und warum Dienste down sind.
- _345
Ich bin wirklich skeptisch, dass man ~10 PRs pro Tag pro Person liefern kann, es sei denn, diese PRs sind winzige Teile einer Funktion oder alle sind winzige Bugs, die jeweils ein 3-Zeilen-Fix sind, den man sofort reviewen könnte. Wie kann man sonst bestätigen, dass die KI überhaupt den richtigen Fix oder die richtige Funktion korrekt gemacht hat? Dass man diese Funktion überhaupt so umgesetzt haben wollte?
- zkmon
Ich hoffe, die Leute nennen Automatisierungen nicht "Teams". Wenn man es ein Team nennt, nur weil es Arbeit "erledigt", dann sind CPU-Kerne und Threads auch ein Team, wenn auch nicht so probabilistisch (intelligent). Sie erledigen die Arbeit auch.
- throw123fgbkjgf
Ich bin mir ziemlich sicher, dass Uber am Ende Tausende von Microservices hatte, weil sie früher den Besitz eines Dienstes an Leistung und Beförderung gekoppelt haben und seit Jahren versuchten, die Zahl zu reduzieren. Es ist lustig zu sehen, wie das als bewusste Entscheidung interpretiert wird.
- franciscop
Ich sah das `require('gulp')` und die Erinnerungen kamen definitiv zurück. So haben wir vor ~10 Jahren Code geschrieben. Ich mag das Multithreading PRO PROJEKT immer noch nicht so sehr, ich bevorzuge es, 2 Projekte zu haben und den Kontext zu wechseln. Ich finde die aktuellen Tools (zumindest die, die ich kenne) für Multithreading etwas enttäuschend. Aber ich versuche auch, mein Wissen zu erweitern.
Ein guter Weg, den ich gefunden habe, da ich viel OSS mache und eigene Bibliotheken habe: Wenn ich einen Bug in einer dieser Bibliotheken finde, kann ich am selben Projekt im Hauptfenster arbeiten, während ich die Bibliothek in einem anderen Fenster fixe. Normalerweise muss ich dem Hauptfenster sagen: "Lass das erstmal, ich fixe gerade die Bibliothek", währenddessen oder ähnlich.