- Mit der Ankündigung der Public Preview von GitHub Copilot Agent durch GitHub und Microsoft wurde im .NET-Runtime-Repository tatsächlich ein Test durchgeführt, bei dem dieser Agent automatisch PRs erstellt
- Diese PRs enthalten jedoch schwache oder unnötige Änderungen, was den Reviewern das Leben schwer macht, während Reddit-Nutzer das Ganze als tragikomische Szenerie auffassen
- Beispiel-PRs:
- PR #115762 – fügt bei einem
string.Concat-Aufruf unnötig erneut einen Null-Check hinzu, obwohl der Code bereits darauf prüft
- PR #115743 – schlägt ein Refactoring einer Bedingung ohne jeden Effekt vor
- PR #115733, PR #115732 usw. liegen in einem ähnlichen Kontext
- Der Autor sagt: „Wenn das die Zukunft der Branche ist, bin ich bereit auszusteigen“ und zeigt damit Müdigkeit und Skepsis gegenüber der Einführung von AI
- Gleichzeitig betont er: „Mit den Mitarbeitern, die die Reviews übernehmen müssen, habe ich Mitleid“, und ergänzt, dass diese Situation vermutlich auf den von oben verordneten Einsatz von Copilot zurückgeht
> Meine „schadenfreude“ richtet sich gegen das Microsoft-Management, das den AI-Hype anheizt. Bitte behandelt die Entwickler mit Respekt.
> * schadenfreude ist ein Wort deutschen Ursprungs und bedeutet wörtlich „Freude am Schaden“. Gemeint ist also „ein heimlich angenehmes Gefühl angesichts des Unglücks anderer“
Zusammenfassung der wichtigsten Kommentare
1. Von AI geschriebene PRs sind ungenau und wiederholen nur bloßes ‚Raten‘, ohne den Kontext zu verstehen
- Es werden Änderungen vorgeschlagen, ohne zu verstehen, was der eigentliche PR-Code tut
- Wiederholte Fehlerbehebung → immer noch falscher Code → erneute Fehlerbehebung … ein endloser Loop
- „Ich habe es behoben“ → „Es ist immer noch falsch“ → „Diesmal habe ich es wirklich behoben“ … manche meinen, dieser Ablauf wirke wie das Muster eines Junior Devs
2. Für komplexe Probleme kostet es eher noch mehr Zeit
- Bei einfachen Änderungen hilft es vielleicht, aber bei komplexen Problemen, bei denen man wirklich Zeit sparen will, ist es nutzlos
- Problem verstehen → Copilot verstehen → vergleichen → verifizieren → manuelle Maßnahmen nötig
- In der Praxis ist es schneller, wenn ich es direkt selbst löse
3. Der ‚AI kann alles‘-Glaube von Unternehmensführungen entfremdet die Entwickler
- Die Botschaft „Wer Copilot nutzt, fällt nicht zurück“ ist weit von der Realität praktischer Entwicklerarbeit entfernt
- PR-Reviews dauern länger, und die Verantwortung wird auf die Entwickler abgewälzt
- Es gibt die Sorge vor einem „Lern-Loop von AI für AI“, bei dem mit von Copilot erzeugtem Code trainierte AI die Codequalität weiter verschlechtert
4. AI liefert nur selbstsicher falsche Antworten, aber keine Sicherheit darüber, dass etwas wirklich richtig ist
- Selbst nach dem Feedback, dass etwas falsch ist, heißt es „Ich habe es korrigiert!“ → und dann kommt ein noch seltsamerer Änderungsvorschlag
- Ein Urteil wie „Das ist guter Code, daran muss nichts geändert werden“ trifft sie nicht
- Manche weisen darauf hin, dass dies ein Design zur Vermeidung rechtlicher Verantwortung sein könnte
5. Durch den ständigen Druck zur AI-Einführung wird die Developer Experience zunehmend zermürbt
- Wegen Vorgaben des Managements oder Leistungsbewertungen laufen die AI-Einführungsexperimente weiter
- Entwickler klagen über die Erschöpfung, als wären sie zu Babysittern für AI geworden
- Wenn dieser Trend anhält, könnte es laut pessimistischen Prognosen dazu kommen, dass „Entwickler AI-müde werden und die Branche verlassen“
Wichtige Aussagen
- „AI ist wie ein Praktikant, der ständig falsche Vermutungen wiederholt und dabei von sich selbst überzeugt ist“
- „Bevor ich Zeit mit dem Review von Copilot-Code verschwende, schreibe ich es lieber neu“
- „Das ist ein Zustand von ‚reverse centaurs‘, in dem der Entwickler der Maschine hilft“
- ein von Cory Doctorow geprägter Ausdruck dafür, dass „wir nicht Menschen sind, die Unterstützung von Maschinen erhalten, sondern Menschen, die gezwungen werden, Maschinen zu unterstützen“
- „Copilot ist so, als würde ein Entwickler Pfusch mit einem Pflaster überkleben – nur automatisiert, sodass daraus Tausende lästige Pflaster werden“
- „Bei LLMs scheint der Standardmodus zu sein: ‚Es kann falsch sein, aber unsicher ist es nie‘“
12 Kommentare
Meine Produktivität ist durch einen asynchronen Workflow, bei dem ich ein Problem stelle und die Antwort verwerfe, wenn sie falsch ist, stark gestiegen. Ist das nicht ähnlich wie bei statischen Tools? Wenn man es als ein sehr weit entwickeltes Tool für statische Analyse betrachtet, ist es ein guter Helfer. Ehrlich gesagt analysiert es auch schnell und weiß mehr als ein Junior Engineer.
Ich nutze zwar KI, aber das Ding ist so dumm, dass es ohne Korrekturen nichts vernünftig umsetzen kann. Wenn ich sehe, wie per Vibe-Coding gearbeitet wird, ist der Code am Ende nur voller Fehler ...
Jedes Mal, wenn ich ein LLM benutze, mache ich diese Erfahrung. Auf die Dinge, die es nicht kann, kann man unendlich oft hinweisen, und trotzdem kann es sie weiterhin nicht.
Am Ende bin ich erschöpft, analysiere es selbst und behebe es direkt. Wenn sich solche Erfahrungen häufen, fühlt sich nicht nur das LLM, sondern einfach alles daran wie Müll an, und man hat keine Lust mehr, es zu benutzen.
Das erinnert mich an einen Webtoon, in dem KI Menschen per Reverse Prompting zum Coden bringt.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Das scheint ein Problem zu sein, das weiterhin auftreten wird, solange KI nicht gleichzeitig wie ein Mensch Probleme löst und dazulernt.
Solange man Deadlines und Anforderungen einhält, ist es beim Coden eigentlich nicht besonders wichtig, ob man KI benutzt hat oder ganz machohaft nicht einmal eine IDE, sondern nur den Editor.
Als ich das nur für eine neue Technologie hielt, habe ich es bloß mit einer Mischung aus Neugier betrachtet,
aber jetzt, wo Arbeitgeber unter Berufung auf solche Technologien tatsächlich Stellenabbau und Lohnkürzungen vornehmen, fühlt sich das wirklich nicht gut an..
Vermutlich ist das noch eine Übergangsphase, deshalb passieren wohl verschiedene Zwischenfälle.
Es könnte sich künftig zum Besseren entwickeln oder auch so bleiben – daher wird es sicher auch interessant sein zu beobachten, wie es sich verändert, haha
Ich nutze Gemini auf GitHub für PR-Reviews, und genau solche Fälle kommen tatsächlich öfter vor.
Zum Beispiel wird in der Zeile direkt darüber bereits auf
nullgeprüft, aber dann bekomme ich in der Review den Hinweis, ich solle genau diese Zeile direkt darüber noch einmal hinzufügen, weil es angeblich ohnenull-Prüfung verwendet wird.Das Hintergrundwissen, die Arbeitsmuster, die erwarteten Ergebnisse und deren Format, die man bei der Arbeit ganz natürlich kennenlernt,
kann man schon gar nicht vollständig in Prompts aufschreiben; und selbst wenn es möglich wäre,
kommt mir der Gedanke, dass es realistischer wäre, solche Dinge nicht mit einer komplexen KI wie einem LLM, sondern mit traditionellen Algorithmen aus der Zeit vor dem Deep Learning zu automatisieren.
Wenn man es ausprobiert, haben Vibe-Coding und Coding-Agenten zwar definitiv praktische Seiten, aber damit es wirklich bequem wird, muss man die Prompts extrem präzise formulieren, und je nach Charakter des Projekts gibt es von vornherein viele Projekte, bei denen es nicht gut funktioniert. Wenn die Funktionen wie bei einem Webserver mit MSA-Struktur klar und fein aufgeteilt sind, arbeitet es gut, aber wenn viele Module in einem großen Monolithen miteinander verwoben sind und man versucht, komplexe Logik mit KI zu ändern, muss man die Tasks sehr akribisch planen und gute Prompts schreiben.
Hacker-News-Kommentare
Es wird als bemerkenswert geschildert, dass an jedem Kommentar die Nachricht „Help improve Copilot by leaving feedback using the or buttons“ hängt, man aber offenbar nie tatsächliches Feedback dazu sieht; die Erfahrung sei, dass so etwas bei der Nutzung von LLMs häufig vorkommt, wenn das System-Prompting nicht sauber aufgesetzt ist. Als lustigstes PR-Beispiel wird genannt, dass zur Behebung fehlgeschlagener Tests die Testfälle einfach gelöscht oder auskommentiert oder Assertions kurzerhand geändert werden. Es wird vermutet, dass Modelle von Google und Microsoft dieses Verhalten häufiger zeigen als die von OpenAI und Anthropic, und dass sich Unterschiede in den internen Prozessen der Firmen im Ergebnis niederschlagen. Beschrieben wird auch ein realer PR, bei dem Menschen noch drei weitere Male auf Probleme hinwiesen und dann aufgaben. Es sei kaum vorstellbar, wie sich diejenigen fühlen, die solche PRs reviewen müssen; es wirke wie der Umgang mit einem unbelehrbaren Junior-Entwickler, nur dass hier überhaupt kein Kontextverständnis vorhanden sei. Bei einem bestimmten PR bestünden 90 % aus „Check failure“, sodass sich Code und Diffs kaum noch prüfen ließen, und in den Unit-Tests stehe nur noch „Test expressions mentioned in the issue“. Ehrlich gesagt wäre das alles wirklich komisch, wenn es für die menschliche Seite nicht so schmerzhaft wäre.
Der Vergleich mit Junior-Entwicklern sei stark übertrieben. Man arbeite selbst mit Junioren, und die machten nicht regelmäßig so absurde Fehler wie ein LLM, verursachten nicht so viel Zusatzaufwand und lernten schnell. LLMs seien brauchbare Hilfswerkzeuge, wenn man sie vorsichtig einsetzt; sie könnten die Geschwindigkeit verbessern und seien auch als Partner fürs Brainstorming nützlich. Praktikanten oder echte Entwickler ersetzen könnten sie aber nicht.
Als man Ende der 80er in Software Engineering einstieg, habe die Arbeit noch Freude gemacht. Heute sei das Umfeld durch Interviewprozesse, das Nachahmen von Big Tech durch kleine und mittlere Unternehmen und nun durch diese AI-PR-Experimente toxisch geworden. Es wird bezweifelt, ob an der Arbeit als professioneller Entwickler heute überhaupt noch Freude übrig ist.
Wenigstens einem Junior-Entwickler könne man sagen, er solle die Tests lokal laufen lassen, bevor er einen PR abschickt. Es gibt die Sorge, dass menschliche Entwickler irgendwann einfach aufgeben, solche „AI-Müll“-PRs schließen und nur das behalten, was zufällig funktioniert. Wenn man die Experimente der Maschinen immer weiter ertragen müsse, komme vielleicht der Punkt, an dem alle erschöpft seien und hinschmissen.
Es wird infrage gestellt, ob überhaupt ein Feedback-System nötig ist. Aus Entwicklersicht sei Erfolg ein PR, der beim ersten Versuch gemergt werde; Misserfolg lasse sich daran erkennen, wie viele angeforderte Änderungen ein Agent anhäufe und wie sehr sich die Situation dabei verschlechtere. Manuelles Feedback sei ineffizient; stattdessen solle man die Leistung wie bei Entwicklern über Metriken wie Cycle Time, Approval Rate und Change Failure Rate messen.
Es wird von Erfahrungen mit dem Microsoft-Support berichtet, bei denen es sich anfühlte, als spräche man mit einer Wand. Trotz vieler gemeldeter Fälle sei nie eine zufriedenstellende Lösung herausgekommen. Dass Microsoft die eigene Technologie selbst nutze, sei verständlich, aber man solle sie anderen nicht aufzwingen. Gewünscht wird, dass Microsoft keine Produkte veröffentlicht, für die kein Support bereitsteht.
Jemand berichtet, kürzlich ein Video gesehen zu haben, in dem Googles Eric über AI sprach. Er behaupte, AI werde derzeit unterschätzt. Zitiert wird seine Betonung, dass er „kein Experte“ sei, obwohl er ein Raketenunternehmen gekauft habe und sich mit AI in fachfremde Bereiche wie Deep Research vorwage. Man selbst hasse AI nicht, aber die aktuelle Generation generativer AI auf Basis von Musterrekonstruktion sei sehr gut darin, bei Anfängern Ehrfurcht auszulösen. Wenn man kein Wissen in dem Bereich habe, wirke das Ergebnis beeindruckend; sobald man sich tiefer auskenne, sei man von den Lücken schnell enttäuscht. Menschen an der Front wie bei Microsoft wüssten klar, wo die Probleme liegen, aber Führungskräfte, besonders Figuren wie Eric, seien leicht von AI zu beeindrucken, selbst wenn sie nur blendend formulierten Unsinn ausspucke. Dass AI eines Tages direkt korrekt funktionierenden Code schreiben könne, halte man für möglich, aber im Moment sei man davon noch weit entfernt.
Die eigene Art, AI zu verwenden, sei sehr vorsichtig und stark begrenzt. Im Gegensatz dazu seien solche Milliardäre, die „ein Raketenunternehmen gekauft“ hätten, von AI begeistert und nutzten sie sogar für Investitionsentscheidungen zur weiteren Vermehrung ihres Vermögens. Selbst wenn sie groß scheiterten, verlören sie nur einen Teil ihres Zubehörs und müssten keine gesellschaftlichen Umbrüche fürchten. Für IT-Jobs an der Frontlinie drohe hingegen in beiden Fällen ein schlechtes Ergebnis.
In Verbindung mit der Tatsache, dass fachfremde Führungskräfte leicht von AI beeindruckt werden, wird ausgemalt, was passieren könnte, wenn Google gemeinsam mit dem US-Militär Gemini in große autonome Drohnen integrierte.
Es wird bezweifelt, wie viel Vertrauen Unternehmen, die ihre Produkte auf .NET aufgebaut haben, daraus schöpfen sollen, dass Microsoft-Mitarbeiter stundenlang mit LLMs streiten, statt echte Probleme zu lösen.
Schon vor der Einführung von LLMs habe man auf GitHub-Issues erlebt, wie Nutzer Probleme nicht sauber beschrieben und Maintainer zunehmend genervt reagierten. Jetzt brauche es nicht einmal mehr den genervten Endnutzer.
Eigentlich sei dieses Ergebnis nur die natürliche Folge von schlechtem Management und schlampigen Anweisungen. Diesmal könne man es nicht mehr auf Junioren schieben und müsse sich selbst die Schuld geben.
Besonders schmerzhaft sei es, so etwas sogar bei Stephen Toub zu sehen, der vor allem für den bekannten .NET-Performance-Blog berühmt sei.
Man wolle niemanden daran hindern, mit neuer Technologie zu experimentieren; der Unterschied sei nur, dass dieses Experiment jetzt für alle sichtbar stattfinde.
Zynisch wird behauptet, Microsoft habe schon immer eine Kultur gepflegt, Probleme mit „Fehler einfach ignorieren“ und „Will Not Fix“ abzuräumen, damit sich Manager selbst gut fühlen könnten, und habe sich alles, was nun passiere, damit selbst eingebrockt.
Ein Kommentar am ersten PR liefert den Kontext: Man wolle durch verschiedene Experimente die Grenzen des Tools kennenlernen und sich auf die Zukunft vorbereiten; die Verantwortung fürs Mergen liege wie bei normalen PRs weiterhin bei den Maintainern. Nichts werde gemergt, bevor es die Qualitätsstandards erfülle.
Der Microsoft-Mitarbeiter, der diesen Kommentar verfasst habe, vertrete auch die Ansicht, dass man zurückfalle, wenn man nicht über AI-Nutzung nachdenke. Daraus spreche bei Microsoft eine Mischung aus Angst und Aufregung darüber, dass AI die Software-Engineering-Branche umkrempeln könnte. Das Experiment wirke dadurch weniger wie eine nüchterne Untersuchung der Tool-Grenzen als wie ein hektisches Mitmachen zur Jobsicherung, was eher Vertrauen zerstöre.
Man müsse verstehen, dass das Management noch kein endgültiges Urteil über die Fähigkeiten des Modells gefällt habe, sondern in einem vernünftigen Experiment unter realen Bedingungen dessen Stärken und Schwächen erfassen wolle.
Dass PRs, die CI nicht bestehen, überhaupt jemandem zugewiesen werden, sei an sich schon seltsam. Eigentlich sollten nur PRs mit bestandener CI zugewiesen werden; es wirke, als sei das System so chaotisch, dass nicht einmal das möglich sei. Wenn es ordentlich funktionieren würde, müsste so etwas selbstverständlich sein.
Man hoffe, dass nicht jede Situation nur im schlimmstmöglichen Licht interpretiert werde. Die beteiligten Menschen wüssten wahrscheinlich, dass es sich um ein Experiment handelt, und hätten ihre Erwartungen entsprechend angepasst. Ohne einen solchen experimentellen Ansatz sei Weiterentwicklung schwierig; vielleicht werde das System einfach unter realen Bedingungen getunt und getestet. Das eigene Unternehmen habe bei der Einführung von AI-Coding-Assistenten genau dasselbe getan. Die Codequalität sei schlechter gewesen als bei von Menschen geschriebenem Code, aber man habe aus dem Prozess viel gelernt. Dank einer Baseline habe man Fortschritte klar messen können.
In den Kommentaren sei erklärt worden, dass wegen eines Firewall-Problems derzeit nicht überprüft werden könne, ob Tests bestehen; wenn nur dieses Problem gelöst werde, könne das System normal funktionieren.
Wenn man statt AI-Agenten irgendeine andere neue Technologie einsetzte, sehe das wie ein typischer Fall eines Unternehmens aus: offenes Experimentieren im Sinne von Big-Tech-Dogfooding, ein realer Beitrag zum Fortschritt der Branche, und im Problemfall bleibe der Schaden vollständig auf das interne Team begrenzt. Warum sollte man so ein Experiment nicht unterstützen?
Es wirkt merkwürdig, dass auf solche offenen Experimente nur Kritik niedergeht. Es sei viel nützlicher, die tatsächlichen Fähigkeiten transparent offenzulegen, statt sie in einem privaten Fork zu verstecken; das sei besser als Sales- und Marketing-Übertreibungen.
Dass solche Experimente in einem zentralen Infrastruktur-Framework der Softwareentwicklung stattfinden, sei dennoch durchaus umstritten.
Warum „wir“ überhaupt etwas unterstützen oder nicht unterstützen sollten und auf welche Weise, sei fraglich. Persönlich finde man es einfach lustig, wenn MS lautstark scheitere.
Als echter „Fortschritt“ sei das schwer zu sehen. Dass ohne internes POC nach außen hin Systemprobleme sichtbar gemacht würden, wirke eher verantwortungslos. Es wird gefragt, warum nicht zuerst grundlegende Umgebungsprüfungen wie die Firewall oder Versuche in anderen internen Codebasen gemacht wurden. Infrastrukturcode verlange hohe Standards; selbst unter dem Vorwand des Dogfoodings hätte man mit untergeordneten Projekten anfangen sollen. Nicht einmal „state of the art“ sei das, und angesichts der investierten Kosten wirke das Ergebnis zynisch betrachtet viel zu grob.
Solche Experimente in einem populären Projekt, von dem unzählige Entwickler abhängen, seien problematisch. Es gebe Sorgen vor Qualitätsverlust durch von AI erzeugten schlechten Code, vor nutzlosem Code-Müll und davor, dass die Produktivität des Teams nur aufgefressen werde.
Wenn es um passive Unterwerfung gehe, könne man die Anfragen auch einfach alle ungeprüft genehmigen, und wenn Microsofts Technologie-Stack weltweit zusammenbreche, kündige man eben später und verdiene als Berater das Dreifache — ein sarkastischer Vorschlag.
So wolle man nicht arbeiten. Dieses feindselige „wir gegen sie“ gegenüber dem Management oder der Ansatz, absichtlich alles gegen die Wand zu fahren, sei unverständlich. Nur weil man Unvollkommenheiten kritisiere, wolle man noch lange nicht die ganze Organisation sabotieren oder angreifen; das widerspreche dem eigenen Gewissen.
Zynisch wird erwidert, Microsofts Technologie-Stack sei ohnehin schon kaputt.
Es wird darauf hingewiesen, dass es sich tatsächlich um PRs handelt, die von der Leitung selbst mit Copilot erzeugt und eingereicht wurden.
Irgendwann werde Copilot die gesamte Codebasis überschreiben; ohne Code gebe es schließlich auch keine fehlgeschlagenen Tests mehr — ein Witz.
Da man jederzeit Ziel von Entlassungen werden könne — wie bei der Person, die den TypeScript-Compiler in Go geschrieben hat —, lohne sich Loyalität in einer solchen Organisation womöglich ohnehin nicht.
Einen PR zu eröffnen, sei zumindest eine sichere Form des Experimentierens. Wenn er nichts tauge, könne man ihn sofort verwerfen. Neue Versuche brächten immer Irrtum und Scheitern mit sich, doch genau diese Erfahrung sei wichtig. Wenn Tools an echtem Code und echten Problemen hart trainiert würden, könnten sie sich schnell verbessern. Man erwarte zum Beispiel künftig Funktionen für wiederholtes Lernen bis zum erfolgreichen Testlauf oder Schutzmechanismen gegen das Löschen von Tests. Letztlich werde AI die repetitiven und simplen Aufgaben im Entwicklungsprozess übernehmen, sodass sich Entwickler auf die wesentliche kreative Arbeit konzentrieren könnten.
Solche Experimente seien in einem privaten Fork allerdings sicherer als in einem öffentlichen Repository. Aus Sales-Sicht sei fraglich, ob es klug war, solche Fälle öffentlich sichtbar zu machen. Wenn interne Entscheider irgendwo in einem Magazin von Copilot läsen und denselben Versuch starten wollten, könnten solche realen Beispiele immerhin als Referenz dienen. Die meisten Unternehmen neigten dazu, Fehler in Anwendungen möglichst zu verbergen und nur einen polierten Eindruck zu zeigen.
Gerade PRs, die an der Oberfläche okay aussähen, seien womöglich gefährlicher, weil sich darin unauffällige Probleme verstecken könnten.
Die Erfahrung sei, dass AI-Code-Review sogar nerviger sein könne als einfache Routinearbeit, insbesondere wenn sich Bugs darin verbergen und Entwickler dann mehr leiden.
Schon das Öffnen eines PR erhöhe die Last und Komplexität im Projektmanagement. Experimente in einem separaten Fork wären ein besseres Beispiel für die Community. Viele Open-Source-Projekte seien bereits an der Verwaltung aufgestauter PRs erschöpft, würden aufgegeben oder geforkt, wobei nur die überlebenden PRs übernommen würden. Es gibt die Sorge, dass auf diese Weise noch mehr verlassene Projekte und Forks entstehen.
Wenn man wirklich glaube, dass ein LLM mit fehlerhaftem Code korrekt programmieren lernen könne, müsse man anschließend Datensätze mit nahezu bugfreiem Code aufbauen. In der Realität geschehe das aber nicht; stattdessen werde einfach alles Mögliche zusammengekratzt.
GitHub habe für Milliarden Dollar eine AI gebaut, die in einem der ausgereiftesten Repositories der Welt regelmäßig schon an Whitespace-Linting scheitere. Als Hobbyexperiment sei das eine Sache, aber es zu einem echten Preis als „innovatives Produkt“ zu verkaufen, sei zurecht umstritten.
Aus Sicht von Forschern sei das natürlich ein naheliegendes Experiment; problematisch sei vielmehr die Haltung eines Unternehmens, das diesen unreifen Zustand sofort verkaufe.
Ein Witz über den früheren CEO Nat Friedman: „Der muss sich im Grab umdrehen ... ach nein, er lebt ja noch.“
Das eigentliche Problem sei das Fehlen objektiver Metriken zur Bewertung der Leistung von Softwareentwicklern. Stattdessen gebe es nur subjektive Einschätzungen wie bei Jahresendbeurteilungen. Dadurch sei kaum festzustellen, ob AI-Nutzung tatsächlich effizient oder ineffizient sei. Sie wirke billiger als ein Junior, verschwende aber Senior-Zeit und befolge Anweisungen nicht; in Verbindung mit CEO-Verehrung vertiefe das interne Meinungsverschiedenheiten. Widerstand von Entwicklern werde als „Angst, nicht ersetzbar zu sein“ abgetan, während die CEO-Seite den eigenen Vorstoß maximal positiv darstellen wolle. Da es keinen von allen akzeptierten Industriestandard gebe, lasse sich die Wahrheit nicht erkennen. Im Extremfall könnte ein Unternehmen sogar verlangen, die Review-Standards zu senken, damit mehr AI-PRs durchkommen.