FurtherAI verfünffacht Code-Merges pro Engineer – und stößt an eine neue Grenze

Dieser Beitrag ist lustig für mich, weil ich finde, dass er weit hinter dem zurückbleibt, was eine ordentliche, zukunftsorientierte "AI-native" Engineering-Organisation tatsächlich wäre. Das heißt, der Autor präsentiert das als eine Art radikalen Bruch mit normalem Engineering, aber ich sehe es einfach als normales Engineering mit mehr KI. Das sehe ich nicht als AI-native.

FÜr mich wird wahres "AI-native" Engineering eines sein, in dem Fragen dazu, wie Menschen Dinge wie Code-Review erledigen, irrelevant sind. Man wirft explizit jedes Konzept von typischem Software-Engineering über Bord und überlässt stattdessen der KI das Feld. Deine Aufgabe als Mensch ist einzig und allein, das zu tun, was die KI physisch nicht kann. Das ist nicht dasselbe wie das Schließen von Lücken zwischen dem, was KI derzeit kann, und dem, was man bräuchte. Es bedeutet buchstäblich, dass alles, was eine KI tun kann, als an sich korrekt behandelt wird, und du als Mensch unterstützt sie nur dadurch, dass du ein Mensch bist.

Wenn das ausgefallen klingt, dann weil es das ist. Wir haben noch keine so leistungsfähigen KI-Systeme. Vielleicht werden wir sie nie haben. Aber das ist nebensächlich. Die Realität ist, dass der Versuch, eine "AI-native" Engineering-Organisation zu schaffen, indem man einfach KI auf bestehende Prozesse und Systeme aufsetzt, vergeblich ist. Wenn deine Erwartung ist, dass sich die Fähigkeiten der KI mit beschleunigter Rate weiter verbessern, dann sind diese Lückenfüller sinnlos. Du könntest genauso gut KI ganz ignorieren, bis sie in der Lage ist, vollständig zu übernehmen, denn das ist das unvermeidliche Ziel, richtig?

Wenn du bereit bist zu akzeptieren, dass das möglich sein wird […]

Zu diesem Zeitpunkt haben sich seit etwa März dieses Jahres eine ganze Menge Teams auf AI-first, nicht vollständig überprüften Code eingelassen.

Das bedeutet, wir sind bereits 6-8 Monate dabei und nicht weit davon entfernt, ein volles Jahr Erfahrung damit zu haben, wie das tatsächlich aussieht, wenn auch seltsam beeinflusst durch die gestiegenen Modellfähigkeiten in diesem Zeitraum.

Ich freue mich auf diese Retrospektiven. Hat sich das für die Teams, die es gemacht haben, als OK erwiesen? Was waren die größten Fehler und/oder Überraschungen? Hat das im Rückblick gute Softwarequalität hervorgebracht?

Ich habe mir gerade einige benutzerseitige Fehlermeldungen angesehen, die Claude für mich generiert hat und die unnötige/irrelevante technische Details enthielten, während sie keine klaren Anweisungen oder Lösungen boten.

Vorher habe ich Code überprüft, der weit mehr tut als spezifiziert, die öffentliche API ändert und neues Verhalten einführt. Ich musste fast alles neu machen.

Ich dachte mir, auf keinen Fall werde ich den Code so ausliefern, wie er geschrieben ist, ohne ihn tatsächlich durchgelesen zu haben (oder wie manche sagen, nur auf die "Absicht" zu schauen). Ich werde mehr Beschwerden von Nutzern bekommen, während ich absolut keine Ahnung habe, was mit dem Code oder dem tatsächlichen Verhalten los ist.

Es ist mir ein Rätsel, wie diese Organisationen das hinbekommen.

Ich sehe viele Builder (mich eingeschlossen), die in die Falle tappen, sich auf die falschen Dinge zu konzentrieren. Entwicklungsgeschwindigkeit ist an sich egal, worauf es ankommt, sind Dinge wie Gewinnwachstum oder Traktion. Es ist wirklich leicht, Automatisierung/Systeme/Prozesse mit tatsächlichen Geschäftsergebnissen zu verwechseln. Bewegung ≠ Fortschritt.

Verwandt: Dieser Artikel hätte es dank der Clickbait-Überschrift sehr unwahrscheinlich auf die Hacker-News-Startseite geschafft, aber ich empfehle trotzdem, ihn zu lesen: https://twitter.com/jsnnsa/status/2115623382721126826

Er beschreibt ein Team, das das 30-fache der Lohnkosten für Tokens ausgibt – 3.000.000 $ Token-Ausgaben pro Monat – und ein Multiplayer-Spiel baut, bei dem Vorfälle und Fehlerberichte von Nutzern direkt an Fable 5/5.1-Agenten weitergegeben werden, die dann darauf reagieren und die Änderungen in die Produktion deployen.

"Wir betrachten es als Ausfall, wenn wir nicht jede Stunde ausliefern"

Es ist lesenswert, weil es entweder eine komplette Katastrophe oder ein Blick in die Zukunft ist, oder sehr wahrscheinlich beides.

Habe ein paar Minuten damit verbracht, die Infomercial zu lesen – habe es bereut. Engineering-Prinzipien bilden das Fundament, und KI-Tools werden so gemacht, dass sie hineinpassen, nicht umgekehrt, wie diese Infomercial behauptet. Die LinkedIn-Vibe ist auch ein großer Abturner.

https://xxcancel.com/sgondala2/status/2115832070274723875