Die vier apokalyptischen Reiter des agentischen Codings

Es ist sehr gut möglich, diese Tools falsch einzusetzen. Unternehmen, die verstehen, wie man KI nutzt, werden besser abschneiden, diejenigen mit diesen 4 Problemen nicht.

- KI sollte dein Verständnis der Codebasis und technischer Konzepte beschleunigen.

- Fähigkeiten sollten eine höhere Codequalität gewährleisten, als du ohne KI erstellen könntest.

- Ingenieure sollten für den Code, den sie produzieren, verantwortlich bleiben.

- Die verfügbare freigewordene Zeit sollte für Kommunikation, Produkt- und Marketingforschung genutzt werden. Die Definition eines Ingenieurs, der nur Code schreibt, verschwindet.

Es sei denn, etwas ist so einfach, dass die KI es autonom ausführen kann. Es gibt heutzutage tatsächlich viele solcher Projekte. Und in diesen Fällen ist es auch eine praktikable Strategie, den Code nicht anzuschauen, wie DHH es tut.

Ich habe das Gefühl, in einem alternativen Universum zu leben – mein Unternehmen hat agentisches Coding vollständig übernommen, wir arbeiten mit:

- großen Codebasen

- geschäftskritischer Software für Kunden, die keine Ausfallzeiten tolerieren

- agentischen und klassischen Funktionen

Wir arbeiten immer noch gut zusammen, uns liegt immer noch Qualität am Herzen, wir haben immer noch gutes Wissen über die Codebasis, aber ich habe seit über einem Jahr keine einzige Zeile Code selbst geschrieben.

Wir hatten keinen einzigen Vorfall, von dem ich wüsste, bei dem wir Slop ausgeliefert haben und dadurch Ausfallzeiten entstanden sind.

Wir bauen eine "Softwarefabrik", die derzeit einfache Routine-Tickets bearbeitet und etwa ein Drittel unserer PRs merged. In einem Jahr, stelle ich mir vor, wird sie deutlich mehr erledigen, und ich glaube nicht, dass deshalb jemand entlassen wird (wenn überhaupt, werden wir weiterhin mehr einstellen).

Ich sehe das nicht als Entweder-oder. Wenn es irgendwo einen verborgenen Ozean aus Slop gibt, in den wir unweigerlich fallen werden, sehe ich ihn nirgends. Wo ist die Diskrepanz?

Meine Arbeits-Slack-Kanäle sind Geisterstädte. Leute sind eingeloggt, aber sie sagen nie etwas. Ich frage mich oft, ob überhaupt jemand arbeitet. PRs tragen ihre Namen, sogar die Review-Kommentare werden von _ihren_ Accounts gepostet, aber es ist offensichtlich, dass Claude alles geschrieben hat – vom Code über die unnötig weitschweifige Änderungszusammenfassung bis hin zu ihren Kommentaren. Sogar ihre Antworten auf meine Änderungswünsche beginnen mit "Du hast recht – …".

Ich vermisse die Zeiten, als die Engineering-Slack-Kanäle lange Threads mit neuen und interessanten Herangehensweisen hatten, Diskussionen darüber, was wir als Nächstes tun könnten, um die Arbeit einfacher zu machen oder langjährige Probleme zu beheben. Wir haben unser eigenes Wissen darüber aufgebaut, wer worin gut war, woran sie interessiert wären zu arbeiten. Jetzt lässt jeder einfach seine Slop-Maschine jeden Teil einer Änderung für den gesamten Stack ausspucken, ohne auf die Details zu achten.

Ich stimme allem in diesem Artikel zu (obwohl ich immer noch optimistisch bin, dass LLMs unqualifizierten Menschen helfen werden, persönliche Software zu schreiben), aber wenn die Arbeitnehmerschaft nicht beginnt, sich sinnvoll zu organisieren und gegen die Unternehmensmacht zu wehren, die diese Ergebnisse verursacht, wird es nur schlimmer werden.

Wir können zwanzigtausendmal sagen "das ist scheiße", aber was ist der Plan? Vielleicht sollten sich einige der erfahrenen Leute, die aufgrund unseres Wissens produktiv sein können und die als Klasse aufhören könnten zu existieren, was zu einem Jahrhundert voller Slop führen würde, zusammentun und über Praxis reden. Sonst sind all diese Artikel nur Trainingsdaten.