Wenn alle AI haben, das Unternehmen aber trotzdem nichts lernt
(robert-glaser.de)- Eine individuelle Produktivitätssteigerung von Mitarbeitenden durch AI führt nicht automatisch zu Lernen auf Organisationsebene; die zentrale Herausforderung ist, wie echte Erkenntnisse von Einzelnen in Teams und in organisatorische Fähigkeiten übergehen
- In der komplexen Zwischenphase der AI-Einführung sind Tools wie Copilot, ChatGPT Enterprise, Claude, Gemini und Cursor zwar weit verbreitet, doch die Nutzungstiefe variiert von Team zu Team, und ein Teil des Lernens bleibt verborgen, was Vergleich und Verbreitung erschwert
- Klassische Change-Management-Ansätze wie Communities, Champion-Netzwerke, Demos, Umfragen und Dashboards erfassen den Kontext, die Fehlschläge, die Validierung und die menschlichen Eingriffe bei AI-Nutzung in der realen Arbeit nur unzureichend
- Agentic Engineering senkt die Kosten von Iterationen und ermöglicht es, schnell von der Absicht zu Prototyp und Evaluation zu gelangen; die Scrum-, Sprint- und Übergabeprozesse vieler Organisationen gehen jedoch weiterhin implizit davon aus, dass Iteration knapp ist
- Organisationen brauchen gemeinsam Agent Operations, Loop Intelligence und Agent Capabilities; entscheidend ist ein Feedback-Harness, das nicht Mitarbeitende überwacht, sondern reale Arbeits-"Loops" versteht und in wiederverwendbare Fähigkeiten sowie schnelleres Lernen zurückführt
Die komplexe Zwischenphase der AI-Einführung, in der die Organisation nicht lernt
- Aus der Perspektive von Ethan Mollicks
Leadership, Lab, and Crowdwird aus individueller Produktivitätssteigerung durch AI nicht automatisch organisatorische Leistung- Mitarbeitende können schneller schreiben, mehr analysieren, automatisieren und wie „Cyborgs“ arbeiten, während das Unternehmen trotzdem fast nichts lernt
- Tools wie GitHub Copilot, ChatGPT Enterprise, Claude, Gemini und Cursor sind in Unternehmen angekommen, und in jedem Team gibt es Menschen, die dem offiziellen Schulungsmaterial weit voraus sind
- Das Management kann Lizenznutzung, Anzahl der Prompts, Umfragen, interne PoCs und Materialien aus Steering Committees sehen, aber wo das eigentliche Lernen stattfindet, bleibt weitgehend unsichtbar
- In manchen Unternehmen landet AI direkt bei der IT-Abteilung und kommt danach kaum noch voran
- Die komplexe Zwischenphase der AI-Einführung beginnt dort, wo AI-Nutzung zwar verbreitet, aber ungleichmäßig, teilweise verborgen, schwer vergleichbar und noch nicht mit organisatorischem Lernen verknüpft ist
- Die Einheit der Einführung ist nicht mehr die gesamte Organisation und vielleicht nicht einmal mehr das Team, sondern der Loop innerhalb der realen Arbeit
Was passiert, nachdem alle Copilot haben
- Die erste Phase der AI-Einführung wirkt relativ vertraut, weil sie einer klassischen Enterprise-Rollout ähnelt
- Man kauft Seats, definiert den zulässigen Nutzungsrahmen, schult, baut Champion-Netzwerke auf und lässt Use Cases in Teams-Kanälen teilen
- Solche Kanäle sind kurzzeitig aktiv und können dann zu einer Art internem Lagerhaus guter Absichten werden
- In der zweiten Phase gehen die Arten der AI-Nutzung selbst innerhalb desselben Unternehmens stark auseinander
- Manche Teams nutzen Copilot nur auf dem Niveau von Autovervollständigung
- Andere betreiben Claude Code in engen Loops mit Tests, Reviews und kontinuierlicher Anpassung
- Produktverantwortliche prototypen echte Software, statt nur Figma-Screens zu erstellen
- Senior Engineers delegieren Root-Cause-Analysen an Agenten, erhalten innerhalb einer Stunde tragfähige Lösungsansätze und verkürzen Arbeiten, die ohne AI zwei Wochen gedauert hätten
- Juniors erzeugen möglicherweise eleganten Code, wissen aber nicht unbedingt, welche Architekturannahmen sich in das System eingeschlichen haben
- Support-Teams verwandeln wiederkehrende Tickets stillschweigend in Workflow-Automatisierung und kennen reale Schmerzpunkte, nach denen das Center of Excellence nie gefragt hat
- In Mollicks Struktur gibt Leadership die Richtung und Erlaubnis vor, die Crowd entdeckt Use Cases, weil sie die eigentliche Arbeit macht, und das Lab verwandelt diese Entdeckungen in geteilte Praktiken, Tools, Benchmarks und neue Systeme
- Die zentrale Schwierigkeit liegt darin, wie Entdeckungen tatsächlich von Einzelnen in Teams und von Teams in organisatorische Fähigkeiten übergehen
Klassisches Change Management ist zu langsam
- Die meisten Unternehmen versuchen, AI-Einführung mit etablierten Change-Management-Instrumenten zu bewältigen
- Zum Einsatz kommen Communities of Practice, Lunch Sessions, Champion-Netzwerke, Enablement-Materialien, Office Hours, monatliche Demos, Umfragen und Dashboards
- In Organisationen, in denen schon die Erlaubnis zum Experimentieren fehlt, können solche Ansätze durchaus helfen
- Doch die interessanten Formen der AI-Nutzung entstehen während der realen Arbeit und warten nicht auf das nächste Community-Meeting
- Sie zeigen sich in Code Reviews, Vertriebsangeboten, Research-Arbeit, Produktprototypen, Betriebsstörungen, Teststrategien und Compliance-Fragen
- Bei bestimmten Typen von Produktkomponenten können Muster entstehen, die einer „Dark Factory“ nahekommen
- Die Absicht wird formuliert
- Ein Agent durchläuft einen lockeren Loop
- Es wird genug Backpressure erzeugt, um ihn auf Kurs zu halten
- Das Ergebnis wird mit starken Szenarien evaluiert
- Die Absicht wird verfeinert und iterativ zu Ergebnissen hoher Qualität weiterentwickelt
- Nützliches Lernen verliert oft seine Schärfe, sobald es zu Best-Practice-Folien verarbeitet wird
- Denn den eigentlichen Wert erzeugten der fehlende Kontext, gescheiterte Tests, seltsames API-Verhalten und die Reibung, mit der Menschen den Agenten zurückholten, wenn er in Unsinn abdriftete
- Aus Sicht des elastic loop ist die Zusammenarbeit mit AI kein einzelner Modus
- Sie reicht von enger, synchroner Co-Piloting-Arbeit bis zu lockerer, asynchroner Delegation
- Die entscheidende Frage ist nicht „Nutzen Menschen AI?“, sondern welche Loop-Größe Teams verwenden sollten, wo Widerstand nötig ist, welche Artefakte den Loop überdauern müssen und wie diese Artefakte zu organisatorischem Lernen werden
- Das ist sehr viel schwieriger als Tool-Nutzung oder Token-Zahlen zu messen
Scrum wurde unter der Annahme teurer Iterationen geschaffen
- Große Teile moderner Softwareprozesse existieren, weil menschliche Iteration teuer war
- Dazu gehören Sprint Planning, Schätzungen, Stand-ups, User Stories, Ticket-Pflege, Übergaben sowie Rituale für Koordination und Risikoreduzierung
- Wenn eine Iteration Tage oder Wochen dauert, braucht man Strukturen, die verschwendete Iterationen verhindern
- Agentic Engineering verändert die Ökonomie der Iteration
- Es macht mehr Optionen praktisch ausprobierbar
- Es beschleunigt den Weg von der Absicht zum Prototyp und zur Evaluation
- Produktverantwortliche sehen funktionierende Software früher
- Engineers können vor Entscheidungen mehr Hypothesen testen
- Delivery wird dadurch nicht magisch einfach, aber die Engpässe verschieben sich von der Implementierung zu Absicht, Validierung, Urteilsvermögen und Feedback
- Viele Organisationen nennen sich seit 20 Jahren agil, behalten aber die organisatorischen Reflexe bei, die Agile eigentlich beseitigen wollte
- AI lässt echte Agilität plausibler erscheinen, doch das System verlangt weiterhin zweiwöchige Sprint-Zusagen, Übergabedokumente und Prozesse, die voraussetzen, dass Iteration knapp ist
- Loops können sich schneller bewegen, als die Organisation das Gelernte aus ihnen aufnehmen kann
AI-Nutzungsgebühren erzwingen bessere Fragen in Organisationen
- AI-Nutzung wird sich vermutlich klarer quantifizieren lassen
- Die aktuelle Enterprise-Stimmung von „alle haben Zugang und die Kosten sind vorerst kein großes Thema“ könnte nicht lange anhalten
- Model Routing, Token-Budgets, nutzungsbasierte Preise, Inferenzkosten und Governance darüber, welches Modell für welche Aufgaben erlaubt ist, werden expliziter
- Die wichtige Frage ist nicht, abstrakt die Token-Kosten zu senken
- Genauso wenig wie es bei Software Delivery je darum ging, die Zahl der Tastenanschläge zu minimieren
- Die bessere Frage lautet: „Was hat sich verändert, weil wir diese Tokens ausgegeben haben?“
- Es sollte vermieden werden, einfach Pull Requests zu zählen
- Welche Loops wurden schneller geschlossen?
- Welche Entscheidungen wurden besser?
- Welche Root-Cause-Analysen wurden präziser?
- Welche Reviews haben mehr Probleme entdeckt?
- Welche Teams haben wiederverwendbare Muster gelernt?
- Welche Produktideen wurden dank Prototypen früher verworfen, weil ihre Schwächen sichtbar wurden?
- Wo hat AI Lernen erzeugt und wo nur mehr Output?
- „Output pro Token“ ist nur ein alter Messreflex in neuer Verpackung
- Wichtiger ist eher Lernen pro Token
Loop Intelligence als fehlender Feedback-Pfad
- In der komplexen Zwischenphase der AI-Einführung brauchen Unternehmen drei Fähigkeiten
-
Agent Operations
- Steuert, welche Agenten und AI-Tools im Einsatz sind, welche Systeme sie berühren dürfen und welche Daten sie sehen können
- Dazu gehört auch, für welche Aktionen Genehmigungen nötig sind und wo Identität, Audit, Berechtigungen und Runtime-Transparenz liegen
- Da agentische Arbeit am Ende reale Systeme berührt, ist die Kontrollseite wichtig
-
Loop Intelligence
- Erkennt, welche AI-unterstützten oder vollständig agentischen Loops tatsächlich Lernen erzeugen
- Beobachtet, welche Loops offen bleiben, welche verfallen, wo Agenten Hebelwirkung schaffen und wo sie sich in Nebenzweige verlieren
- Beurteilt, welche Teams wegen fehlender Tests, fehlendem Kontext oder mangelnder Intuition an enge Aufsicht gebunden sind und welche Teams für lockerere Delegation bereit sind
-
Agent Capabilities
- Verteilt nützliche Fähigkeiten organisationsweit, ohne anzunehmen, dass drei riesige Agenten die Arbeit aller erledigen können
- AI beginnt sich eher wie eine fluide Basistechnologie als wie eine einzelne Anwendungskategorie zu verhalten
- Sie passt schlecht zu einem Enterprise-Zoo aus je einem „HR-Agenten“, „Engineering-Agenten“ und „Sales-Agenten“
- Fähigkeiten müssen dorthin fließen, wo die reale Arbeit stattfindet
- Mitarbeitenden-Harnesses
- Background-Agenten
- Produktteams
- Plattform-Services
- lokale Skills
- MCP-Server
- Eval-Suites
- Runbooks
- Beispiele
- domänenspezifische Verfahren
Die Plattformfrage und das Feedback-Harness
- Auf Plattformebene geht es zentral um die Frage, wem nützliche Fähigkeiten gehören und wie sie sich bewegen
- Es braucht einen Weg, wie ein in einem Team entdeckter nützlicher Agenten-Skill an andere Teams weitergegeben wird, ohne zu einer toten Vorlage zu verkommen
- Das Harness eines Developers, das Harness eines Produktverantwortlichen, der Background-Agent eines Support-Teams und ein Compliance-Workflow müssen unterschiedlich verstärkt werden
- Manche Fähigkeiten sollten teamnah bleiben, manche in einer Plattformschicht liegen, und manche sollte man gerade nicht verallgemeinern, weil ihr lokaler Kontext entscheidend ist
- Wenn nur eine der drei Fähigkeiten vorhanden ist, wird es schnell schief
- Nur Agent Operations ohne Loop Intelligence führt zu Kontrollbürokratie
- Nur Loop Intelligence ohne Agent Capabilities erzeugt eine Analyseschicht, die zwar nützliche Muster entdeckt, sie aber nicht zurück in die Arbeit bringt
- Nur Agent Capabilities ohne Operations und Loop Intelligence führt zu Tool-Chaos mit besserem Branding
- Kontrollpfad, Lernpfad und Fähigkeits-Pfad müssen sich irgendwo treffen
- Intern könnte man das als Feedback-Harness bezeichnen
- Was Kundinnen und Kunden kaufen, ist kein eleganter Mechanismus, sondern Zuversicht, bessere Entscheidungen, schnelleres Lernen, weniger Verschwendung und sicherere Delegation
- Ein für Kundinnen und Kunden nützlicherer Begriff könnte Loop Intelligence Hub sein
- Ein Feedback-Harness ist ein Mechanismus, der den realen Arbeits-Loops zuhört
- Es betrachtet Aufgaben, Prompts, Spezifikationen, Reviews, Szenarien, angenommene und verworfene Hypothesen, operative Signale, Nacharbeit sowie menschliche Entscheidungen und Eingriffe
- Es dient nicht zur Überwachung von Menschen, sondern zum Verständnis von Loops
- Die erste Version muss keine gigantische Plattform sein
- Es reicht, einige reale Workflows auszuwählen, die Punkte zu instrumentieren, an denen Absicht, Agentenarbeit, Validierung und menschliche Entscheidungen bereits Spuren hinterlassen, genug qualitatives Feedback zu sammeln, um zu verstehen, warum ein Loop erfolgreich war oder scheiterte, und dies in wiederkehrende Lernartefakte zu überführen
- Ein Loop Intelligence Hub übersetzt Signale in Formen, mit denen die Organisation handeln kann
- Enablement-Backlog
- Capability-Radar
- Investment-Briefs
- Governance-Lücken
- wiederverwendbare Workflows
- Schulungsbedarf
- Evaluationsprioritäten
- Nötig sind keine Einheits-Dashboards, sondern Ausgaben nach Relevanz
- Das Interessante ist nicht das Dashboard selbst, sondern die Entscheidung dahinter
- Manche Teams brauchen bessere Backpressure, bevor sie mehr delegieren
- Manche Produktgruppen haben für einen engen Komponententyp ein wiederholbares Dark-Factory-Muster
- Manche Compliance-Workflows brauchen Tool-Grenzen mit angewandter Governance
- Manche Skills sollten in die Plattform verschoben werden, weil fünf Teams sie schlecht neu erfunden haben
- Das Harness sammelt, der Hub hilft der Organisation beim Entscheiden, und die Capability-Schicht bringt das Gelernte zurück in die Arbeit
Wenn es zur Mitarbeitendenüberwachung wird, scheitert es
- Wenn diese Struktur in Mitarbeiterbewertung umschlägt, bricht das Ganze zusammen
- Wenn Mitarbeitende glauben, die Organisation messe, ob sie AI ausreichend genutzt haben, manipulieren sie die Signale
- Wenn sie glauben, dass jedes Experiment sofort zur Produktivitätserwartung wird, verbergen sie Experimente
- Wenn sie glauben, dass die besten Workflows sofort zur neuen Standardarbeitslast werden, behalten sie sie für sich
- Das Unternehmen erhält dann die schlechteste Form der Einführung: sichtbare Compliance und unsichtbares Lernen
- Die nützliche Frage lautet nicht „Wer nutzt AI genug?“
- Wo hat AI Arbeit so verändert, dass die Organisation daraus lernen kann?
- Welche Loops sind gesünder geworden?
- Welche Teams brauchen bessere Backpressure, bevor sie mehr delegieren?
- Welche Produktteams brauchen ein anderes Umfeld, wenn Prototypen zu realer Software werden?
- Richtlinien sind nötig, aber Governance wird wie Lernen erst durch Nutzung real
- wenn Agenten betriebsnahe Aufgaben berühren
- wenn Produktverantwortliche Prototypen bauen statt Spezifikationen zu schreiben
- wenn Developers Root-Cause-Analysen delegieren
- wenn Token-Ausgaben steigen und das Management Antworten will
- Dann wird sichtbar, ob die Organisation ein Lernsystem aufgebaut oder nur viele Seats gekauft hat
Die komplexe Zwischenphase ist keine Phase, die man nur aushalten muss
- Die erste Phase der AI-Einführung drehte sich um Zugang
- Wichtig war, wer die Tools bekommt, wer die Erlaubnis erhält, wer Verträge verhandelt und wer die neuesten Modelle ohne Procurement-Ticket ausprobieren kann
- Diese Phase bleibt wichtig, wird aber nicht lange differenzierend sein
- Zugang zu Frontline-Intelligence kann man einkaufen, operative Kontrolle und organisatorisches Lernen jedoch nicht auf dieselbe Weise
- Der nächste Vorteil ist Lerngeschwindigkeit
- Wer findet reale Muster schneller?
- Wer überführt Entdeckungen von Einzelnen in Teams und von Teams in organisatorische Fähigkeiten?
- Wer baut Backpressure in agentische Loops ein, damit Agenten nicht ausfransen?
- Wer verteilt nützliche agentische Fähigkeiten, ohne daraus riesige Enterprise-Agenten zu machen, die für alle passen sollen?
- Wer macht Agile durch Agentic Engineering realer, statt AI nur auf bestehende Rituale aufzusetzen?
- Diese Veränderung lässt sich kaum verstehen, wenn man auf ein fertiges Einführungs-Playbook wartet
- Statt auf die endgültige Antwort von Vendoren, Beratungen oder AI-Labs zu warten, sollte man reale Arbeit instrumentieren, das unordentliche Lernen teilen, andere die Schwachstellen aufdecken lassen und öffentlich iterieren
1 Kommentare
Hacker-News-Kommentare
In Umgebungen großer Unternehmen ist die Einführung von AI kaum über die Entwicklungsteams hinausgekommen, und nur Entwickler dürfen GitHub Copilot nutzen
Es dauert 6–12 Monate, bis Code vom Commit bis zum Deployment in Produktion gelangt, und die Entwicklungsgeschwindigkeit war ursprünglich nicht der Engpass
Zeit kosten die Verfahren rund um Infrastruktur-Provisionierung, Tests, Freigaben, Change Management und Deployment-Zeitpläne, und AI verschärft die Engpässe nach der Entwicklung sogar noch, sodass sich Änderungen vor dem Release-Zug aufstauen
Wenn Großunternehmen eine Rendite auf die Token-Kosten erzielen wollen, müssen sie lernen, Software schneller auszuliefern, und nicht deployter Code ist kein Vermögenswert, sondern eine Verbindlichkeit
Es stimmt zwar, dass Softwareentwicklung ineffizient ist, aber der Kern ist nicht das Schreiben von Code, sondern die Recherche und das Design, um herauszufinden, welcher Code überhaupt geschrieben werden muss, und genau das wird kaum berücksichtigt
Wenn Microsoft ruft: „Code 50 % schneller!“, versteht das Management darunter: „Produkte 50 % schneller, Geld 50 % schneller“
In dem Moment, in dem ein ROI eingefordert wird, dürfte es zur Katastrophe werden, und im Moment vermeiden einfach alle die Messung
Irgendwann werden Investoren sagen: „Wir haben 2 Millionen Dollar ausgegeben, also liefert 4 Millionen Dollar Nettogewinn“, doch so ein Ergebnis ist kaum realistisch
Copilot und Claude lösen die echten Engpässe nicht: altes Organisationswissen, nicht dokumentierte Speziallösungen und potenzielle künftige Nutzungsmöglichkeiten
Code ist weder das eigentliche Produkt noch die eigentliche Arbeit; in einer gesunden Codebasis ist er fast nur ein kostenloses Nebenprodukt von Design- und Rechercheprozessen
Wenn man „Das Einkaufsteam findet die Suche schwer bedienbar“ erst einmal zu einem praktikablen Ticket verdichtet hat, ist die React-Suchfilter-Komponente praktisch schon festgelegt, und das Codieren ist fast nur noch eine formale 10-Minuten-Prozedur
Selbst wenn Copilot das auf 5 Minuten reduziert, ist das angesichts der 6 Stunden Meetings und Anrufe davor nicht besonders beeindruckend
Auch Ernährung und Kalorien sind nur bis zu einem gewissen Punkt nützlich; danach sinkt der Nutzen und irgendwann wird der Effekt sogar negativ
Es ist keine perfekte Analogie, aber sie hilft als Denkmodell dafür, dass mehr Output am Ende sogar weniger Wert erzeugen kann
Wir bekamen von Kunden das Feedback, dass die Dokumentation vollständig und detailliert, aber zu überwältigend sei, und stellten schließlich fest, dass ein paar kurze Bullet Points den Kern besser vermitteln als ein fünfseitiges Dokument
[0] https://en.wikipedia.org/wiki/Theory_of_constraints
[1] https://www.goodreads.com/book/show/113934.The_Goal
[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
Das Finance-Team kam zu uns und fragte, ob es mit Copilot, Cursor und Claude eine App für die Finanzplanung vibe-coden dürfe, und begründete das sogar mit: „Der CFO hat Lovable getestet, ist überzeugt und hat uns gesagt, wir sollen die App vibe-coden“
Offenbar setzten sie darauf, dass das Management einfriert, sobald nur „der CFO hat es gesagt“ fällt
Am Ende wurde das Ganze noch mit einer plausibel klingenden Verpackung versehen, nämlich dass man prüfen müsse, „ob eine vibe-gecodete App mit angemessener Datensicherheit und Wartbarkeit im Bereich Unternehmensfinanzen existieren kann“
Noch erstaunlicher ist, dass dieses reasoning aus einem Unternehmen mit mehr als 20 Milliarden Dollar Jahresumsatz kommt
Für einen ganz normalen Ingenieur wie mich hat der Einsatz von AI im Unternehmen keinen wirklichen Vorteil
Das Unternehmen kocht uns langsam weich, und die Elite von HN – Investoren, Führungskräfte, Berühmtheiten, Top-Ingenieure – wird sagen: „Wie kann man gegen Innovation sein?“
AI/LLMs sind keine Innovation nach Art von TCP/IP, Linux oder Postgres
Dinge wie Claude, Codex, Gemini und Grok existieren, um Profit zu erzeugen; es sind Werkzeuge, um Produktivität bis auf den letzten Tropfen auszupressen und Leute entlassen zu können, wenn man sie nicht mehr braucht
Wenn AI gut ist, dann nutzt man besser Open-Source-Modelle und setzt sie in privaten Projekten ein
AI kann viel Code ausschütten, aber man braucht weiterhin Ingenieure, die verstehen, was tatsächlich passiert, und das war schon immer der Engpass
Junior-Positionen könnten verschwinden, aber Senior Engineers scheinen vorerst noch sicher zu sein
Ich bin eigentlich von Natur aus kontra, aber das ist eine Lektion, die ich mühsam gelernt habe: Wenn man angestellt ist, dann ist man dafür angestellt, das zu tun, was das Management will
Wenn man Widerstand leistet, kann man nur hoffen, dass sie es nicht merken oder sich nicht darum kümmern, und große Veränderungen lassen sich schwer herbeiführen
Ich weiß nicht, ob sich noch jemand daran erinnert, was SCO im Niedergang der Branche angetan hat
Für mich bleibt unverständlich, warum Unternehmen ihren internen Geheimstoff – Code, Prozesse, Kundenanforderungen, interne Politik, Vorstellungen der Führung – an Startups und fragwürdige Großkonzerne ausliefern
Auch Microsoft war einst berüchtigt für Geheimhaltungsvereinbarungen und Missbrauch im Geschäftsverkehr
Ich glaube nicht, dass die großen LLM-Unternehmen nicht auf Unternehmensdaten trainieren würden, und auch nicht, dass sie darüber nicht lügen würden
Wenn diese Giganten ins Wanken geraten, könnte dieser Goldrausch einen langen und hässlichen Nachlauf haben
Tatsächlich werden eher diejenigen entlassen, die solche Technologien nicht einführen, und wenn man sich so verhält, bringt man sich selbst in die Entlassungszone
Man muss sich heute nur den Fall Coinbase ansehen: Dort werden die aussortiert, die die Zukunft nicht annehmen
Sie helfen dem Fortschritt nicht, treiben ihn nicht voran und halten diejenigen zurück, die es tun
Der Text trifft das messy middle sehr genau
Entwickler, bei denen Verantwortung und Arbeitsplatz auf dem Spiel stehen, haben kaum einen Anreiz, solche Intelligenzschleifen aufzubauen
Egal wie freundlich das Management bittet: Ich habe nicht vor, Produktivitätsgewinne aus meiner Arbeit altruistisch und kostenlos mit dem ganzen Unternehmen zu teilen
Wenn es um nützliche Tools geht, würde ich sie vielleicht teilen, aber das Know-how, wie man mit AI umgeht oder Agents konfiguriert, behält man besser für sich, solange es für das Teilen keine Anerkennung gibt
Unser Unternehmen hat zur Förderung der Einführung Preise wie „Prompt der Woche“ und Lunch-Sessions eingeführt, und es gibt sogar Teams, die solche Abläufe entwickeln
Aber ohne echte finanzielle Belohnung oder Jobsicherheit landen Risiko und Kosten der Wissensverbreitung vollständig bei den Entwicklern
Schon lange bevor AI überhaupt auf diesem Niveau war, habe ich persönliche CLIs gebaut, um die Arbeit einfacher zu machen und Automatisierungsskripte bequemer schreiben zu können
Kollegen sahen die Tools und wollten, dass ich sie teile, aber meine diplomatisch formulierte Antwort war nein
Wenn ich sie teile, entsteht Support-Aufwand, und alle arbeiten plötzlich genauso produktiv wie ich; mein Vorteil verschwindet also, was einen negativen Ertrag bedeutet
Außerdem erkennt die Führung meine Kreativität nicht als Vermögenswert an, also steigt dadurch auch meine Jobsicherheit nicht
Wenn ich in naher Zukunft ohnehin entlassen werden könnte, habe ich wenig Lust, dem Unternehmen aus reiner Gutmütigkeit zu helfen
Wenn Entwickler sich im aktuellen Markt Sorgen um ihre Jobs machen, sollten sie ihren persönlichen Workflow wie ein Betriebsgeheimnis behandeln
Dieses Beispiel ist nicht auf AI beschränkt, gilt aber für AI-Workflows genauso
In einem Arbeitnehmermarkt machte es manchmal sogar Spaß, solches Wissen mit der Organisation zu teilen, aber in einem Arbeitgebermarkt gilt: Wer Zugang zu meinen persönlichen Entscheidungen will, muss dafür bezahlen
Ich halte den Arbeitsplatz nicht für eine Familie, aber es wäre schön, wenn wir gut zusammenarbeiten und Wissen teilen könnten, ohne uns dabei Sorgen machen zu müssen, ob wir unser eigenes Grab schaufeln
Die meisten Menschen werden dafür bezahlt, Arbeit zu leisten, und während der Arbeitszeit sollten sie selbstverständlich für ihren Arbeitgeber arbeiten
Tatsächlich ist fast nichts dabei, was andere sich nicht auch selbst hätten ausdenken können
Meiner Erfahrung nach nutzen nur wenige Leute geteilte Prompts oder Techniken überhaupt, oder es ist so grundlegend, dass ohnehin schon jeder seine eigene Version davon hatte
Wenn sich vor AI schon niemand für xyz interessiert hat, wird sich daran auch nach AI nichts ändern, selbst wenn man es ihnen auf dem Silbertablett serviert
Langweilige Arbeit verschwindet fast vollständig, und manche Probleme werden erledigt, wenn man sie nur anstößt, wodurch pro Tag 1–4 Stunden zurückkommen
Wird diese Person diese Zeit vernünftigerweise nutzen, um sich noch mehr Arbeit zu suchen? Eher nicht, außer es ist ihre eigene Firma oder sie hat eine besondere Motivation
Als Systemanalyst, der seit drei Jahren im Ruhestand ist, tun mir die jungen Kollegen leid
2023 setzte unser Team vergleichsweise früh AI ein, um Legacy-Code auf Perl-Basis zu entschlüsseln, dessen ursprünglicher Autor schon lange weg war und kaum Kommentare oder Dokumentation hinterlassen hatte
Dieser Code erledigte geschäftskritische Aufgaben, und AI hat uns aus der Klemme geholfen, sodass alle über diese neue Technologie staunten
Aber je mehr Zeit vergeht, desto mehr wirkt das nicht wie ein Werkzeug, das ich nutzen kann, sondern wie etwas, das mir angetan wird
Niemand hat darum gebeten
Ich weiß nicht, seit wann Inspiration und Denken im Namen von Soforterledigung abgewertet und wertlos gemacht werden, aber der Arbeit ist die Seele verloren gegangen
AI allein ist nicht besonders nützlich
Agents vergessen Dinge und machen genug Fehler, dass man trotzdem jede Aufgabe überprüfen muss; dadurch kann die Produktivität am Ende sogar sinken
Ihren eigentlichen Wert entfaltet AI erst, wenn man sie als Werkzeug zum Bauen anderer Werkzeuge behandelt
Man lässt sich zum Beispiel Tools bauen, die erzwingen, dass eine Aufgabe so lange weitergeführt wird, bis eine bestimmte Qualität erreicht ist, oder die Compliance-Checks auf den Output ausführen und sagen, was noch korrigiert werden muss
Erst dann kann man der Arbeit wirklich vertrauen
Die meisten Rollen und Workflows sind derzeit darauf ausgelegt, mit gegebenen Tools bestimmte Aufgaben zu erledigen, und in so einem System kann AI nur am Rand eingreifen
Guter Text, und besonders auffällig war der Teil darüber, dass sich die Art, wie Organisationen Arbeit definieren, verändert
Im alten Modell waren Leistung und OKRs an Fachbereiche, Titel und Rollenerwartungen gebunden
Im AI-Zeitalter beginnen diese Grenzen zu zerfallen
Das tiefere Problem ist psychologisch und organisatorisch: Menschen verhandeln ständig neu, wo die Grenze zwischen „Das ist meine Arbeit“ und „Dafür bin ich nicht verantwortlich“ verläuft
Daraus entsteht das zentrale Einführungsproblem: Welchen Vorteil hat es, sichtbar als fortgeschrittener AI-Nutzer anerkannt zu werden?
Wenn bekannt wird, dass ich schneller, besser und funktionsübergreifend arbeiten kann, warum sollte ich das offenlegen, solange das Unternehmen kein klares System für Anerkennung, Vergütung und Karrierewachstum schafft?
In einer Welt, in der Agents diese Grenzen überschreiten, kann das ziemlich chaotisch werden
Wird ein AI Engineer mit einem ganzen Schwarm von Agents dann auch die Verantwortung dafür tragen, dass der ganze Betrieb weiterläuft? Ich habe meine Zweifel, aber man wird sehen
Wenn jemand, der sich zu so einem neuen Beruf hingezogen fühlt, ein paar Wochen firmenspezifischen Kontext mit aktuelleren Methoden kombiniert, landet diese Person am Ende womöglich in der Rolle eines zu entfernenden Domänenexperten
Die Antwort auf „Wo ist der ROI der 2 Millionen Euro, die wir letztes Jahr an Anthropic gezahlt haben?“ ist die YouTube-artige Platinum-Token-Plakette im Büro des CEO
Die verzerrte Annahme hinter der Frage „Wo ist der ROI der 2 Millionen Euro, die wir letztes Jahr an Anthropic gezahlt haben?“ ist wirklich absurd
Das Problem ist, dass generative AI keinen sichtbaren ROI erzeugt
Die „Lösung“ soll dann aber darin bestehen, die gesamte Entwicklungsorganisation um diese Technologie herum neu anzuordnen und neue Tools zu erfinden
Der eigentliche Zweck solcher Texte liegt nicht in dem, was sie oberflächlich behandeln, sondern in der Normalisierung der Annahmen, auf denen die Diskussion beruht
Gerade jetzt in diesem Bereich zu arbeiten ist wirklich unerquicklich
In meinem Unternehmen lassen die Vorgesetzten mittlerweile sogar Nicht-Entwickler mit AI arbeiten
Ich würde wirklich gern kündigen und in einem anderen Bereich arbeiten, aber dort, wo ich lebe, kann man sich mit einem Einstiegsgehalt die Miete nicht leisten, und ich werde auch nicht jünger
Mir hat es geholfen, das Versprechen von AI mit dem Dotcom-Boom zu vergleichen, und es gibt viele Ähnlichkeiten
Das Internet war aus Unternehmenssicht allerdings ein einfacheres Konzept
Im Grunde bedeutete es nur, dass Menschen jetzt Dinge an ihrem Computer kaufen konnten
Was genau ist das Versprechen von AI? Dass sie Schlussfolgern über Dinge annähern kann?
Das ist als Implementierungspuzzle tatsächlich viel schwerer zu lösen
Außerhalb von Coding-Aufgaben habe ich bislang noch nichts wirklich Substanzielles gesehen