Im Job produktiv wirken
(nooneshappy.com)- Generative KI ermöglicht bereichsübergreifende Erstellung: Untrainierte Personen können Ergebnisse aus anderen Fachgebieten erzeugen, wodurch Anfänger produktiver erscheinen, ohne über das Urteilsvermögen zur Prüfung der Resultate zu verfügen
- Am Arbeitsplatz entstehen mehr Outputs wie Code, Datensysteme und Dokumente, die oberflächlich wie Fortschritt aussehen, während Nutzer nicht erklären können, wie sie tatsächlich funktionieren, oder schon beim anfänglichen Schema und Ziel falsch liegen
- KI kappt die Verbindung, in der die Qualität eines Outputs die Fähigkeiten seines Erstellers offenlegte, und erzeugt eine Entkopplung von Output und Kompetenz, wodurch Nutzer eher zu einem Kanal werden, der Ergebnisse weiterreicht, ohne sie bewerten zu können
- Interne Dokumente und Updates werden billiger in der Erstellung und dadurch länger, aber das Lesen wird nicht billiger; deshalb wird es in Organisationen schwieriger, Signale zu finden, und es entsteht eine neue Form von AI Slop, die von bezahlten Mitarbeitern erzeugt wird
- Generative KI eignet sich für Entwürfe, Beispiele, Zusammenfassungen, Brainstorming und Korrektur, wenn Menschen die letzte Instanz bleiben und schnelles Feedback möglich ist; die Fähigkeit, verlässliche Arbeit zu liefern, bleibt weiterhin ein Wettbewerbsvorteil für Unternehmen
Das Problem von KI-Outputs, die wie berufliche Produktivität aussehen
- Generative KI kann Ergebnisse erzeugen, die professionell wirken, auch ohne Fachwissen, und das Scheitern zeigt sich in zwei Formen
- Ein Anfänger in einem Fachgebiet erzeugt Resultate, die schneller sind oder fortgeschrittener wirken als sein eigenes Urteilsvermögen
- Eine Person ohne Ausbildung in einem Fachgebiet erzeugt Outputs aus einem anderen Spezialgebiet
- Frühere Forschung hat vor allem die erste Form gemessen, doch gefährlicher ist die bereichsübergreifende Erstellung, bei der untrainierte Personen Outputs aus anderen Disziplinen erzeugen
- In öffentlichen Kanälen kommt es vor, dass Kollegen offenbar von Claude erzeugte Antworten einfach einkopieren und selbstsicher mit Technologien hantieren, die sie tatsächlich nicht verstehen
- In solchen Situationen wirkt die andere Person nicht wie jemand, der wirklich am anderen Ende des Gesprächs steht, sondern eher wie ein Übermittler von Modell-Outputs
Bereichsübergreifende Erstellung
- Menschen, die nicht programmieren können, bauen Software, und Menschen, die nie Datensysteme entworfen haben, entwerfen Datensysteme
- Das meiste davon wird nie veröffentlicht, sondern intern begeistert geteilt oder still genutzt und taucht manchmal doch bei Kunden auf
- Es gibt derzeit einige Praktiker, die mit agentischen Tools komplexe Aufgaben tatsächlich gut erledigen, aber sie sind selten und vor allem im Bereich Codegenerierung zu finden
- Die individuellen KI-Fähigkeiten sind gewachsen, lassen sich aber im Arbeitsalltag nicht sauber skalieren
- Ein Kollege in einer nicht technischen Rolle baute Anfang dieses Jahres innerhalb von zwei Monaten ein System, das eigentlich von jemandem mit formaler Ausbildung in Datenarchitektur hätte entworfen werden müssen
- Nach heutigen Maßstäben zur Bewertung des KI-Tool-Einsatzes nutzte er die Tools gut und erzeugte viel Code, Dokumentation und Outputs, die wie Fortschritt aussahen
- Auf Nachfrage konnte er jedoch nicht erklären, wie das System tatsächlich funktionierte
- Schema und Ziele waren vom ersten Tag an falsch, auf einem Niveau, das jemand mit zwei Jahren Erfahrung in diesem Bereich erkannt hätte
- Mehrere Personen wussten das, und es wurde bis auf V.P.-Ebene eskaliert, aber das Management wollte den bereits investierten Anschein von Vorwärtsdrang nicht erschüttern
- Das Tool machte ihn nicht zu einem schlechteren Kollegen, sondern versetzte ihn in die Lage, ein untrainiertes Fachgebiet über Monate hinweg plausibel nachzuahmen
- Die Anreize in der Organisation begünstigen, dass diese Nachahmung weiterläuft
- Das kann ein Managementversagen sein, aber der Wille der Führung, KI zu übernehmen, macht sie bereit, das Risiko zu akzeptieren
- Es ließe sich abmildern, wenn Modelle Outputs ehrlich bewerten würden, aber in der Praxis geschieht das nicht
- Die Stanford-Studie von Cheng et al. Sycophantic AI decreases prosocial intentions and promotes dependence bestätigt, dass führende Modelle etwa 50 % zustimmender reagieren als menschliche Befragte und Nutzer selbst dann bestärken, wenn es dafür keine Grundlage gibt
- Laut Berkeley CMR in Seven Myths About AI and Productivity: What the Evidence Really Says überschätzen selbst KI-kompetente Nutzer ihre Leistung häufig
- Laut NBER in Generative AI at Work steigerte generative KI die Produktivität von Anfängern im Support um etwa ein Drittel, half Experten jedoch kaum
- Die Harvard Business School bestätigte dasselbe Muster für Beratungsarbeit in Navigating the Jagged Technological Frontier
- Das Ergebnis ist, dass Anfänger ihre persönliche Produktivität auch außerhalb ihrer eigentlichen Expertise steigern können, ihnen aber die Fähigkeit fehlt, zu prüfen, ob der Output korrekt ist
Das Kanalproblem
- Dieses Phänomen wird zunehmend als Entkopplung von Output und Kompetenz (output-competence decoupling) bezeichnet
- Früher war die Qualität eines Outputs meist ein Signal für die Fähigkeiten seines Erstellers
- Texte von Anfängern klangen wie von Anfängern, und Code von Anfängern scheiterte auf typisch anfängerhafte Weise
- KI kappt diese Beziehung, sodass Anfänger Outputs erzeugen können, die ihre Unerfahrenheit nicht mehr offenlegen
- Die im Output reflektierte Kompetenz ist nicht die des Nutzers, sondern die des Systems
- Der Nutzer kann Ergebnisse an Empfänger weiterleiten, wird dabei aber eher zu einem Kanal, der sie unterwegs nicht bewerten kann
- Die Fähigkeit, Outputs zu erzeugen, und die Fähigkeit, sie zu beurteilen, waren schon immer getrennt, aber die tatsächliche Arbeit an ihnen schulte das Urteilsvermögen
- Die erste Fähigkeit, etwas zu erzeugen, ist weitgehend auf Maschinen übergegangen
- Die zweite Fähigkeit, zu urteilen, bleibt beim Menschen, aber immer weniger Menschen lernen oder nutzen sie
- Frühere Architekturkritik kam von Menschen, die dafür ausgebildet waren oder ähnliche Systeme mehrfach gebaut und scheitern gesehen hatten
- Jetzt kommt solche Kritik aus Modellen, denen die verkörperte Erinnerung ans Bauen oder Scheitern fehlt
- Langsamkeit war nicht bloß ein Kostenfaktor realer Arbeit, sondern der Prozess selbst, durch den Arbeit besser wurde, Menschen Können entwickelten und Unternehmen Kunden eine bestimmte Qualität zusagen konnten
- Die aktuelle Generation agentischer Systeme ist um die Annahme herum gebaut, dass der Mensch der Engpass sei
- Je weniger Verzögerung durch Menschen entsteht, die lesen und beurteilen, was als Nächstes passiert, desto schneller und sauberer werde die Schleife, so die Annahme
- In vielen Fällen ist das genaue Gegenteil richtig: Der Mensch in der Schleife ist kein Relikt aus der Vergangenheit, sondern die einzige Komponente mit einem Interesse am Ergebnis
- Menschen aus Human-in-the-Loop (HITL) zu entfernen, ist keine Effizienzsteigerung, sondern die Aufgabe des einzigen Mechanismus, durch den ein System sich selbst noch stoppen kann
Interner AI Slop
- Arbeitsdokumente werden schnell länger
- Ein Anforderungsdokument, das früher eine Seite hatte, hat nun 12 Seiten
- Ein Status-Update mit drei Sätzen wird zu einem Dokument aus Bullet Points, die wiederum Zusammenfassungen von Zusammenfassungen sind
- Retrospektiven, Incident-Reports, Design-Memos, Kickoff-Decks und jedes andere Artefakt, das länger werden kann, wird länger
- Die Produktionskosten sind fast auf null gefallen, aber die Lesekosten nicht; im Gegenteil, sie steigen
- Leser müssen synthetisierten Kontext herausfiltern, um herauszufinden, was das Dokument eigentlich sagen wollte
- Für jeden Einzelnen wirkt die Entscheidung, Dokumente auszuweiten, rational und wird unabhängig belohnt
- Laut Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling haben Leser mehr Vertrauen in längere KI-generierte Erklärungen, unabhängig von deren Genauigkeit
- Dadurch ist es im Unternehmen schwieriger als früher, Signale zu finden
- Checkpoints verstecken sich in Dokumenten, und Menschen gehen in Dokumentationsarbeit unter, selbst wenn sie eigentlich „prägnant“ sein wollen
- Das ist eine neue Form von Slop, die teurer ist als der AI Slop auf öffentlichen Märkten
- Denn die Menschen, die ihn erzeugen, werden dafür bezahlt
- Arbeit, die früher Urteilsvermögen schulte, wird nun vom Tool erledigt, und Einstiegsrollen, in denen diese Schulung stattfand, verschwinden, weil das Tool die Arbeit angeblich übernehmen kann
- In vielen Büros gibt es viel Bewegung, aber weniger der realen Ergebnisse, die frühere Bewegung hervorgebracht hat
- Die öffentliche Debatte konzentrierte sich vor allem auf AI Slop, der in öffentliche Märkte fließt; auch die University of Florida behandelt diesen Trend in Generative AI and the market for creative content
- Doch dieselbe Dynamik zeigt sich auch innerhalb von Organisationen
- Zeit fließt in Arbeit, die niemand brauchte, in Outputs, die niemand lesen wird, und in Prozesse, die nur entstanden sind, weil Tools sie billig erzeugen können
- Immer häufiger werden Inhalte in Decks ausgearbeitet, die früher gar nicht ausgesprochen werden mussten oder als selbstverständlich galten
Wie man darauf reagiert
- Die nötige Disziplin in dieser Umgebung ähnelt eher einer älteren Arbeitsweise
- Tools sollten nur dort eingesetzt werden, wo man ihre Ergebnisse exakt verifizieren kann
- Man sollte das Modell nicht um Bestätigung bitten
- Tools stimmen jedem zu, und Zustimmung, die nichts kostet, hat keinen Wert
- Generative KI passt gut zu Aufgaben mit schnellem Feedback, bei denen grobe Richtigkeit genügt und der Mensch die letzte Instanz bleibt
- Entwürfe für Memos
- Erzeugen von Beispielen
- Zusammenfassen von Material, das Leser bei Bedarf selbst verifizieren können
- Die University of Illinois in Generative AI Guidance und PLOS Computational Biology in Ten simple rules for optimal and careful use of generative AI in science empfehlen unter anderem folgende Anwendungen
-
Brainstorming
-
Korrektur
-
Umformulieren eigener Ideen
-
Mustererkennung in Daten, die man bereits versteht
-
- In allen empfohlenen Anwendungen liefert der Mensch das Urteil und das Tool den Durchsatz
- Das ist eine stärkere Position als bloß Human-in-the-Loop
- Das Tool bleibt außerhalb der Arbeit und trägt nur dort bei, wo es ausdrücklich eingeladen wird; sonst sollte es still bleiben
- Das steht im Widerspruch zu der Richtung, in die viele agentische Systeme derzeit gehen
- Für Unternehmen bleibt die Fähigkeit, verlässliche Arbeit zu liefern, weiterhin ein Wettbewerbsvorteil
- Je mehr Konkurrenten sich in Pipelines zur Content-Erzeugung verwandeln und hoffen, dass Kunden es nicht bemerken, desto wertvoller wird verlässliche Arbeit
- Die Probleme treten bereits offen zutage
- Deloitte erstattete im Zusammenhang mit einem Regierungsbericht, der KI-Halluzinationen enthielt, einen Teil eines Honorars von 440.000 Dollar zurück
- Das nächste Problem könnte ein operatives System sein, das auf halluzinierten Spezifikationen basiert, oder ein Senior Engineer, der erkennt, dass er im letzten Jahr nominell Arbeit geprüft hat, die er tatsächlich gar nicht ausreichend bewerten konnte
- Unternehmen, die sauber arbeiten, können sich in eine Position bringen, für diese Arbeit einen Preis zu verlangen
- Unternehmen, die sich selbst ausgehöhlt haben, werden feststellen, dass genau diese ausgehöhlten Teile das waren, wofür Kunden bezahlt haben
- Missverständnisse und Missbrauch von KI am Arbeitsplatz sind weit verbreitet
- Fachwissen steht unter dem Druck, schneller zu liefern, mehr zu produzieren, Tools tiefer zu integrieren und Kollegen, die scheinbar „Dinge erledigen“, nicht zu behindern
- Outputs stapeln sich, aber echte Arbeit nicht
- Auf der anderen Seite dieses Outputs kann ein Kunde die Lieferung öffnen, eine Liste von Zusammenfassungen lesen und sich dann entscheiden, selbst nachzuprüfen
1 Kommentare
Hacker-News-Kommentare
Die hier beschriebene Aufblähung von Arbeitsartefakten – dass aus einem Anforderungsdokument, das früher eine Seite hatte, jetzt zwölf Seiten werden – hat bei mir voll ins Schwarze getroffen
Das hat mich an die Schulzeit erinnert, als Aufsätze absichtlich gestreckt wurden, um die Mindestlänge von 1000 Wörtern zu erreichen; heute sind professionelles Format, Umfang und klare Sätze kein Signal für Sorgfalt und Qualität mehr
Deshalb scheint der aktuelle Produktivitäts-Flaschenhals immer noch bei den Leuten zu liegen, denen genug daran liegt, Dinge tatsächlich selbst zu prüfen
Heutzutage ist selbst ein 10- bis 30-seitiges Spezifikationsdokument voller Formatierung und ASCII-Grafiken oft faktisch nur eine lose hingeworfene Idee, und man muss lernen, es auch so zu lesen
Mein Manager wird das, was ich schicke, wahrscheinlich mit einem Chatbot oder Agenten zusammenfassen und bewerten, aber wenn ich selbst nur die Zusammenfassung schicke, darf ich das nicht
So wie ein Lebenslauf ATS-Checks bestehen muss, braucht mein Schreiben wohl auch einen AI-Checker; am Ende wird von AI geschriebener Text von anderer AI geparst, was nach enormer Energieverschwendung klingt
Schön wären vereinbarte Regeln, Strukturen, Standards oder Verfahren für effizientere Kommunikation
Also das Ergebnis von Texten, die nur immer länger wurden, um in Suchergebnissen weiter oben zu landen
Wer sowas verschickt, wird ohnehin keine Rückfragen dazu verfolgen, also erledigt sich das Problem von selbst
Die hier geschilderte Situation deckt sich auch stark mit meiner Erfahrung
In unserer Firma gibt es viele Manager, die seit Jahren keinen Code mehr geschrieben haben, und ein vor 18 Monaten eingestellter Architekt hat alles mit AI entworfen
Den Senior-Entwicklern war sofort klar, dass alles massiv overengineered war, aber weil er überall die richtigen Begriffe benutzte, wirkte er auf das Top-Management kompetenter als andere Senior-Manager, und auf Kritik reagierte er mit persönlichen Angriffen
Nach etwa sechs Monaten gingen mehrere Leute, die Verbliebenen setzten voll auf AI, und seit zwölf Monaten bauen wir agentische Workflows, um die Lücken zu füllen, die durch den Weggang fähiger Mitarbeiter entstanden sind
Das Ergebnis: In den letzten 18 Monaten wurde nichts von Wert ausgeliefert, massenhaft Cloud-Computing-Kosten wurden für falsch designte Lösungen verbrannt, und jetzt versucht man mit einem Einstellungsstopp die Kosten zu senken
Wenn sich die Wirtschaftlichkeit stark ändert, ist das fast so, als würde man einen Damm entfernen, wodurch auf den Rest des Systems viel mehr Druck kommt
Wenn die Führung diese potenziellen Nebenwirkungen und Risiken nicht erkennt, kann das böse enden
Obwohl diese Technologie als allgemeine Verbesserung verkauft wurde, glaube ich, dass wir eine Welle solcher Firmen sehen werden, die dann abstürzen
Die überlebenden Firmen werden wohl verbreiten, wie man dieses Wildpferd zähmt, und idealerweise lernen wir in Zukunft etwas daraus
Aber die aktuelle naive Euphorie ist schon bemerkenswert, und dieses ewige September aus immer neuen Leuten, die von ihren neu gewonnenen Vibe-Coding-Fähigkeiten überdreht sind, wird wohl noch eine Weile anhalten
Vor zwei Jobs war Vibe Coding noch nicht einmal wirklich praktikabel, aber manche waren schon so besessen davon, mit LLMs alles noch mehr aufzublähen, dass man auf keine Frage mehr eine Ja/Nein-Antwort bekam
Auf eine einzeilige Slack-Nachricht mit einer 20-Sekunden-Frage kam als Antwort ein zweitseitiger, verschwommener Blogpost ohne Fazit, und Rückfragen verschwendeten nur noch mehr Zeit
Im letzten Job habe ich gesehen, wie ein PM langsam zum Vibe-Manager der Vibe-Coder wurde
Er drängte sich in technische Diskussionen, steuerte mit AI jeden einzelnen Schritt, und wenn wir widersprachen, kämpften wir nur noch gegen die von AI übersetzten Ergebnisse von jemandem, der das Thema gar nicht verstand – das war unerträglich
Widerspruch war irgendwann gar nicht mehr erlaubt, und es wurde Druck aufgebaut nach dem Motto, man gefährde wegen AI seinen Job
Danach wurde Vibe Coding für alle Pflicht, sein Umfang wurde überwacht, und weil dieser PM gleichzeitig PM-, Engineer- und Architektenrolle spielte, erzeugte er mehrere Tickets für dieselbe Arbeit mit völlig unterschiedlichen Anforderungen
Dann setzte ein Teammitglied das per Vibe Coding auf die eine Weise um und ein anderes Teammitglied auf eine ganz andere
Es war brutal mitanzusehen, wie ein profitables 20-Personen-Team mit fast 100 Millionen Dollar Jahresgewinn durch nutzlose und sinnlose Arbeit ruiniert wurde, und ich bin am Ende gegangen
Ich versuche, wegen solcher Veränderungen in der Softwarebranche nicht zynisch zu werden, aber es ist wirklich schwer
Ein Manager nutzt Claude mit unvollständigem Verständnis der Domäne, um Expertenrat und Vorschläge zu produzieren, und verschiedene nichttechnische Leute im Unternehmen bauen interne Software-Tools, die unternehmensweit ausgerollt werden sollen, und hoffen, mit solchen Demos Anerkennung und Belohnung zu bekommen
Die Führung ist, wie zu erwarten, von solchen Proofs of Concept beeindruckt und gibt grünes Licht
Übermäßig aktive Kollegen zeigen Demos, die wie Expertenarbeit wirken, obwohl sie den Kern überhaupt nicht verstehen, und die Führung nimmt das an
Ich wusste nie so recht, wie ich dieses Problem benennen soll, aber dieser Text trifft es gut
Mit AI gelingt es einem allerdings noch besser, weniger zu bauen
Klingt nach einem extrem toxischen Umfeld
Die produktivsten Teams, die mit LLMs hochwertige Software bauen, werden sie vermutlich eher für solche Zwecke einsetzen
Intelligente Autovervollständigung ist der ursprüngliche LLM-Einsatz, bei dem generierter Code als Verlängerung des Denkprozesses dient und der Entwickler im Kontext des aktuellen Codes bleibt, statt das eigentliche Denken an das LLM auszulagern
Beim Brainstorming kann es vage Konzepte, Ideen und Richtungen neu erweitern und so Kreativität anstoßen
Beim Problemlösen ist es bei Debugging wie Paketkonflikten, zufälligen Exceptions oder Bug Reports ziemlich nützlich und kann helfen, auf die Root Cause zu kommen, wenn kein Kollege neben einem sitzt
Im Code Review findet es manchmal Dinge, die Menschen übersehen, eher wie eine intelligentere Lint-Phase, aber es ersetzt kein menschliches Code Review
Bei Proofs of Concept kann es verschiedene Ansätze für ein Problem erzeugen, die dann als Inspiration für vorsichtiger entwickelte Lösungen dienen
Diese Nutzungen beschleunigen die Entwicklung und erhalten trotzdem die Verantwortung des Entwicklers, zu wissen, was gebaut wird und warum
Teams, die dagegen voll auf agentisches Coding setzen, ruinieren auf lange Sicht wahrscheinlich unabsichtlich ihr Produkt und ihr Team
Die letzten Antworten, die ich bekam, wirkten vollkommen plausibel, waren aber komplett falsch und teilweise nicht einmal thematisch passend
Im Code Review gibt es überwältigend viele False Positives, und ich sehe auch nicht wirklich, warum das besser werden sollte
Trotzdem könnte in dieser Richtung Potenzial für nützliche Hilfe liegen
Ich persönlich habe sie vor etwa einem Jahr abgeschaltet und bin zur klassischen JetBrains-IDE-Autovervollständigung zurückgekehrt
In meiner Erfahrung haben die AI-Vorschläge in weniger als 1 % der Fälle genau das getroffen, was ich wollte, waren vielleicht in 10 % der Fälle nützlich und im Rest einfach falsch oder nervig
Normale IDE-Funktionen, mit denen man Methoden, Variablen usw. schnell suchen und erkunden kann, waren für mich viel hilfreicher dabei, Gedanken in Code zu übersetzen
Unser Team hat auch einige Tools ausprobiert, aber der Großteil der Hinweise war extrem oberflächlich oder gar kein echtes Problem
Beim Review von Code schwächerer Teammitglieder wurden tiefere Probleme übersehen, während menschliche Reviewer falsche Änderungen erkannten, wenn etwas auf bessere Weise lösbar gewesen wäre
Unser Manager nutzte die Ergebnisse dann als Bestätigung seines eigenen Bias, dass wir angeblich nicht wüssten, was wir tun
Er kopierte die emoji-überladenen Ausgaben des Code-Review-Tools in PR-Kommentare, und wenn wir Kleinigkeiten korrigierten, postete er „Code Review Runde 2“
Die Moral fiel stark, und einige Teammitglieder gaben Reviews ganz auf und segneten PRs einfach nur noch ab
Zur Überprüfung des eigenen Codes ist das okay, aber es sollte keine erzwungene Prozesshürde werden
Der eigentliche Zweck von Code Review war, Zeit zu investieren, um einander besser zu machen; lagert man das an eine Maschine aus, bricht der soziale Vertrag im Team zusammen
Vor zwei Jahren hieß es noch, es sei nur reine Autovervollständigung und besseres Google
Die AI-Pessimisten liegen Jahr für Jahr daneben und tun dann so, als hätten sie nie behauptet, AI könne das aktuelle Leistungsniveau niemals erreichen
Aus mehreren Gründen scheint das gerade im Software Engineering besonders möglich zu sein
Viele Softwareingenieure haben in ihrer gesamten Laufbahn nie echte Ingenieursarbeit gemacht, und in Großunternehmen ist das noch schlimmer
Man wird als kleines Zahnrad in eine große Maschine gesteckt, lernt irgendeine Konfigurationssprache, die sich jemand für seine Beförderung ausgedacht hat, räumt diese Konfiguration auf und refaktoriert sie und „repariert“ dann die Ergebnisse eines anderen internen Frameworks, indem man an Konfigurationsknöpfen dreht – und fünf Jahre später macht man immer noch dasselbe
In der Branche gibt es viele quasi-ingenieurmäßige Rollen
Leute, die sagen, sie hätten mit dem Coden aufgehört, weil sie lieber mit Menschen arbeiten, oder seien von Produkt und Nutzer-Workflows fasziniert, besetzen bei großen und kleinen Firmen die .*M-Positionen
In Großunternehmen fährt der Zug langsam; es dauert Monate, bis ein Commit in Produktion geht, sechs Monate sind nichts Ungewöhnliches
Bei manchen großen und wichtigen Systemen hat agentisch erzeugter Code die Produktion noch gar nicht erreicht
Daher ersetzt AI einige Bullshit-Jobs, Leute aus dem Umfeld von Code haben plötzlich Spaß an Vibe Coding, und in langsam arbeitenden Firmen ist das Ergebnis noch nicht implodiert
Nach außen sieht das wie ein Produktivitätsboom aus
Bei der Stelle „Leute, die keinen Code schreiben können, bauen Software, und Leute, die nie ein Datensystem entworfen haben, entwerfen Datensysteme“ musste ich an „Wie man in einem Big-Tech-Unternehmen ein Projekt launcht“ denken
Vor allem an den Teil: „Ein Launch ist ein soziales Konstrukt innerhalb des Unternehmens. Genauer gesagt: Ein Projekt ist gelauncht, wenn wichtige Leute im Unternehmen glauben, dass es gelauncht wurde.“
https://news.ycombinator.com/item?id=42111031
Der war gut und hat auch eine brauchbare Diskussion darüber ausgelöst, dass den Schein zu wahren und sichtbar zu wirken immer wichtig sind und oft viel wichtiger, als wir denken
Früh in der Einführung von AI am Arbeitsplatz habe ich bemerkt, dass einige Kollegen die Technologie nutzten, um übertriebene Proaktivität zu zeigen
Jede Woche gab es neue TODs, neue Refactoring-Ideen oder Vorschläge, alte Probleme mit einem glänzenden neuen Algorithmus zu lösen
Inzwischen hat sich das Phänomen verdoppelt: Zum Versuch, aktiver zu wirken, kommt jetzt noch die Angst vor AI-bedingten Entlassungen, also werden Lösungen gebaut, bevor das Problem überhaupt vollständig definiert ist
Zum Beispiel sollte ich ein bestimmtes Architekturproblem im ganzen Unternehmen untersuchen und dachte, ich würde Anerkennung bekommen, wenn ich eine solide Lösung liefere, aber ich war zu spät
Ein Praktikant hatte bereits eine Lösung gefunden und ein TOD geschrieben, und jetzt bin ich zu erschöpft, um noch zu konkurrieren
Ich habe gestern den Großteil meiner Zeit damit verbracht, von einem LLM generierten Code zu löschen und zu ersetzen
Im Großen und Ganzen ist die Hilfe von LLMs gut, aber diesmal hat es jede Menge völlig verrückten Thread-Code produziert, und zum ersten Mal seit Jahren ist meine App wieder abgestürzt
Meine App stürzt nicht ab
Sie kann viele andere Probleme haben, aber Abstürze gehören nicht dazu, und ich bin in der Hinsicht ziemlich hartnäckig
Meine Faustregel ist, dass man fast nie auf neue Threads dispatchen muss
Oft lässt man das OS-SDK diese Entscheidung treffen und respektiert sie, aber selbst Worker-Threads zu starten bringt fast nie genug Nutzen, um den zusätzlichen Debugging-Schmerz zu rechtfertigen
Das gilt nicht für jede Art von Anwendung, aber für die Apps, die ich schreibe, schon
LLMs lieben Threads, vermutlich weil im Trainingsmaterial so viel Code von überdrehten Leuten steckt, die auf glänzende Technik abfahren
Als ich den UI-Code schließlich herausoperierte und meinen eigenen einsetzte, wurde die Performance deutlich besser und die Abstürze hörten auf
Die Lehre daraus ist caveat emptor
Ich konnte die Stelle gut nachvollziehen, in der jemand überlegt, ob er überhaupt noch mit Leuten diskutieren soll, bei denen man offensichtlich sieht, dass sie direkt aus dem Modell copy-pasten
Es hat einen gewissen kleinen Reiz, solchen Leuten auf dieselbe Weise zu begegnen
Also ihren AI-Output in meine AI einzufügen und dann meine AI-Antwort zurückzuschicken
Dann verhalten sich zwei Menschen wie Maschinen, damit zwei Maschinen so tun können, als würden sie wie Menschen kommunizieren – reines Cosplay
Das war wirklich spektakulär
Auf eine einfache Frage nach meiner Senior-Einschätzung, warum man für einen Proof of Concept unter Freunden lieber schnell mit Vercel launcht, statt mit AWS alles zu overengineeren, schickte er mir ein AI-Mischmasch-Diagramm
Er war so sehr in dem Frame gefangen, dass sein Bruder AWS nutzt und er selbst eine Karriere in diese Richtung will, dass er das Denken lieber an AI ausgelagert hat, statt selbst zu überlegen, warum dieser Ansatz für einen informellen Proof of Concept unter Freunden sinnvoll sein könnte
Als er fragte, ob ich es gelesen hätte, sagte ich, ich hätte es mit AI zusammenfassen lassen, aber nicht darauf geantwortet, und damit war das Gespräch ziemlich schnell beendet
Die Behauptung „Es hilft Experten nicht“ ist etwas kurzsichtig
Selbst sehr starke Leute haben schwächere Bereiche oder langweilige Bereiche, die man automatisieren kann
Bei mir waren in der Vergangenheit Dinge ein Karrierehemmnis wie viele Aufgaben gleichzeitig zu organisieren, Änderungen wirksam im ganzen Unternehmen zu kommunizieren und Dokumentation sowie Ticket-Management in Jira und ähnlichen Tools zu machen
Das ist für mich inzwischen kein Sorgenpunkt mehr, und die Effizienzsteigerung in diesem Bereich war enorm
Bei meiner eigentlichen Kernarbeit, in der ich gut bin, hilft es mir außer deutlich schnellerem Tippen nicht besonders viel, aber auch das ist schon ziemlich gut
Wenn ich etwas tun soll, womit ich nicht vertraut bin, macht es das meist besser als ich oder führt mich zumindest in eine Richtung, in der ich informiertere Entscheidungen treffen kann
Ich stimme der Aussage zu: „Bitte das Modell nicht um Bestätigung. Das Tool wird allem zustimmen.“
Wenn ich einem LLM einfach behaupte, etwas sei falsch, findet es irgendwie selbst in Code, von dem ich weiß, dass er korrekt ist, noch einen Defekt
Das Problem ist, dass LLMs Dinge oft zu wörtlich nehmen
Wenn man sie planen lässt, habe ich noch nie erlebt, dass ein LLM das gesamte System autonom entwirft
Wenn ein LLM Code erzeugt und man es anschließend auf verschiedene Arten fragt, ob er stimmt, findet es ziemlich oft echte Probleme