- AWS-CEO Matt Garman erklärte, die Vorstellung, dass KI Junior-Mitarbeiter ersetzen könne, sei „eine der dümmsten Aussagen, die ich je gehört habe“
- Er betonte, dass Junior-Mitarbeiter die geringsten Kosten verursachen und zugleich KI-Tools besonders aktiv nutzen, und dass es unverzichtbar sei, Talentförderung und Lernmöglichkeiten bereitzustellen
- Außerdem wies er darauf hin, dass es ein sinnloser Messwert sei, die Leistung von KI anhand der geschriebenen Code-Menge zu bewerten, und dass weniger, aber qualitativ hochwertiger Code wichtiger sei als unnötig viel Code
- Innerhalb von AWS nutzen bereits mehr als 80 % der Entwickler KI, und sie wird auf vielfältige Weise eingesetzt, darunter für Unit-Tests, Dokumentation, Code-Unterstützung und agentenbasierte Workflows
- Garman prognostizierte, dass in einem sich rasant verändernden Technologieumfeld langfristig kritisches Denken, Kreativität und Lernfähigkeit entscheidend seien und dass Talente mit diesen Fähigkeiten im KI-Zeitalter erfolgreich sein würden
Position zur Kontroverse um den Ersatz von Junior-Mitarbeitern
- Garman widersprach entschieden einigen Führungskräften, die behaupten, KI könne alle Junior-Mitarbeiter ersetzen
- Er hob hervor, dass Junior-Mitarbeiter „am wenigsten kosten und zugleich beim Einsatz von KI am engagiertesten sind“
- Mit den Worten „Was passiert in zehn Jahren, wenn niemand mehr Erfahrung aufbauen kann?“ unterstrich er die Notwendigkeit der Talententwicklung
- Er argumentierte, dass der Prozess, Hochschulabsolventen einzustellen und ihnen beizubringen, wie man Probleme löst, sowie sie auszubilden, weiterhin unverzichtbar sei
Kritik an der Nutzung von KI und an Kennzahlen
- Die Praxis, die Leistung von KI an der Menge des geschriebenen Codes zu messen, kritisierte er als „nutzlose Kennzahl“
- Man könne unendlich viel Code erzeugen, aber dieser Code könne von schlechter Qualität sein
- „Weniger Code ist oft besser“, sagte er und kritisierte die Fixierung auf quantitative Kennzahlen
- Laut internen AWS-Daten nutzen bereits mehr als 80 % der Entwickler KI
- Sie wird auf unterschiedliche Weise eingesetzt, etwa zur Automatisierung von Unit-Tests, zur Unterstützung bei der Dokumentation, zum Schreiben einzelner Codeteile und für agentenbasierte Zusammenarbeit
- Die Nutzungsrate dieser KI-Tools steigt von Woche zu Woche
Ratschläge zu Bildung und Karriere im KI-Zeitalter
- Garman nannte kritisches Denken, Kreativität und Lernbereitschaft als die im KI-Zeitalter erforderlichen Fähigkeiten
- Nicht das Erlernen einer bestimmten Technologie, sondern das „Lernen zu lernen“ selbst
- Entscheidend seien „die Fähigkeit, selbst zu denken, Probleme zu zerlegen und zu lösen sowie die Bereitschaft, Neues zu lernen“
- Er wies darauf hin, dass es angesichts des rasanten technischen Fortschritts schwierig ist, eine 30-jährige Karriere allein auf einzelne Technologien zu stützen
- Daher sollten Lehrkräfte Studierenden die Fähigkeit beibringen, Probleme zu zerlegen und zu denken, sowie die Haltung, Neues zu lernen; Menschen mit diesen Fähigkeiten würden im KI-Zeitalter erfolgreich sein
11 Kommentare
Ich denke, man muss beides ausreichend sorgfältig abwägen.
Für den Betrieb eines Unternehmens braucht man Entwickler, und aktuell ist es wohl eine Zeit, in der es für Junior-Entwickler schwer ist, eine Stelle zu finden. Öffentlich wird zwar die AI dafür verantwortlich gemacht, aber in der Corona-Zeit wurde massiv eingestellt, und verglichen mit dem Erfolg, der dazu im Verhältnis stand, sind in den Unternehmen insgesamt die Personalkosten gestiegen. Diese Belastung führt dazu, dass weniger eingestellt wird. In so einer Situation hat sich der Einsatz von LLMs als mindestens so effizient erwiesen, wie Junior-Entwicklern Aufgaben zu übertragen, weshalb ich denke, dass sich der Arbeitsmarkt selbst noch weiter verkleinert hat.
Wie auch im Artikel steht, braucht es jedoch Junior-Entwickler, damit daraus am Ende Senior-Entwickler werden können.
Wenn man keine Junior-Entwickler einstellt, können strukturell auch keine Senior-Entwickler entstehen.
Trotzdem denke ich, dass in diesem Prozess eine erhebliche Abstimmung nötig ist.
Bei Großunternehmen ist das vermutlich weniger ausgeprägt, weil die Strukturen dort stehen. Kommt ein Junior-Entwickler ins Unternehmen, wird man ihn eher mit kleineren Nebenaufgaben betrauen (Unternehmensaufgaben, bei denen auch ein Scheitern verkraftbar ist) und ihn dabei ausbilden, statt ihn direkt die Hauptarbeit des Unternehmens machen zu lassen.
Aus Sicht von Senior-Entwicklern ist es jedoch umso schwieriger, Junior-Entwickler anzuleiten, je weniger ausgereift diese Strukturen sind.
Und ironischerweise ist es bei der Nutzung von LLMs eher von Vorteil, wenn man mehr einschlägiges Wissen hat; nur weil jemand ein Entwickleranfänger ist, erreicht er nicht automatisch die gleiche Effizienz.
Es ist vielmehr unmöglich, sämtliche Entwicklungsaufgaben durch Junior-Mitarbeiter zu ersetzen. Sehr kluge Genies könnten es vielleicht irgendwie auch ohne Senior-Entwickler schaffen. Aber wenn sich dann die Arbeit bei dieser Person zu sammeln beginnt, wird sie das wirklich aushalten können?
Kurz gesagt: Es müssen sowohl Senior- als auch Junior-Entwickler eingestellt werden, und dabei braucht es eine flexible Personalpolitik, die Produktivität, Personalkosten des Unternehmens und Ähnliches berücksichtigt.
Wer das bestreitet,
sind nur Seniors, die selbst auf niedrigem Niveau sind und deshalb nur mit schwachen Juniors gearbeitet haben, haha.
Unabhängig von der Berufserfahrung ist im KI-Zeitalter die Welt für kluge Leute überwältigend im Vorteil.
Wenn ein kluger Berufseinsteiger sich nur 1–2 Jahre richtig reinhängt, nimmt er einen soliden 10-Jährigen locker auseinander.
Auch ohne KI konnten kluge Berufseinsteiger mit 1–2 Jahren Vollgas problemlos durchschnittliche Leute mit 10 Jahren Erfahrung abhängen...
Irgendwie wirkt es so, als würde damit gesagt: „Junioren sind günstig und können KI gut nutzen, warum also sie ersetzen? Ersetzen wir lieber die Seniors!“
Oh, so kann man das natürlich auch verstehen.
Verdammt, haha
Ach ...
Bitte unterlassen Sie solche Kommentare. Das ist hier nicht DC Inside.
Hier ist nicht DC Inside..
Was für eine Ausdrucksweise.
Hacker-News-Meinungen
Stimme ich voll zu Gleichzeitig habe ich das Gefühl, dass man ein echter Prompt-Zauberer sein muss, um LLM-Code in der Praxis wirklich sinnvoll zu nutzen. Ich verwende ihn nur gelegentlich zum Debuggen oder um ein UI schnell zu skizzieren. Wenn es um echten Code geht, ist von LLMs geschriebener Code für mich meist wirklich Spaghetti-Code, weitschweifig, mit ernsten Risiken bei Performance und Sicherheit, und er missversteht fast jedes Design-Pattern, das ich vorgegeben habe, vollständig.
Jedes Mal, wenn ich auf Hacker News oder Reddit skeptische Beiträge über AI Coding sehe, überrascht mich das immer mehr. Es wirkt, als würden wir alle in völlig verschiedenen Welten leben. Ich glaube, die Vielfalt der Tools ist auch ein Faktor. Ich denke, „LLM-Code verwenden“ bedeutet für verschiedene Leute etwas völlig anderes. Konkret scheint es stark vom verwendeten LLM, vom gegebenen Kontext und von der verwendeten IDE abzuhängen. Ich habe 200.000 Zeilen B2B-SaaS-Code selbst geschrieben, bevor agentic coding aufkam. Im Sonnet-4-Agent-Modus schreibe ich heute nur noch etwa 20 % des Codes, den ich täglich produziere; die übrigen 80 % kommen von interactive Sonnet in VS Code und von GitHub Copilot Agents. Je mehr ich in Markdown dokumentiere, desto höher wird dieser Anteil. Ich reviewe und teste die Ergebnisse gründlich.
Mich würde interessieren, welche Tools du verwendest. Ich nutze aider, und selbst mit Modellen, denen nachgesagt wird, dass sie beim Coden schwach seien, etwa gpt-5, hatte ich überhaupt nicht die Erfahrung, die du beschreibst. Es schreibt tatsächlich „guten“ Code und passt sich auch dem bestehenden Code-Stil gut an. Prompting ist wirklich wichtig, und in bestehenden Codebasen steigt die Erfolgsquote deutlich, wenn man konkrete Implementierungshinweise geben kann. Das ist etwas, was einem Senior, der die Codebase gut kennt, leichtfallen kann, für einen Junior aber schwierig sein dürfte. Ich denke, man muss alle Seiten klar sehen. Bislang ist es oft noch minimal schneller, Dinge selbst zu machen, als sie über aider laufen zu lassen, aber der Unterschied ist nicht groß und es wird ständig besser. LLMs können einige Aufgaben ersetzen, die Junior-Entwickler übernehmen könnten, aber sie können sie nicht vollständig ersetzen. Juniors gehen auch in Meetings, treiben Diskussionen voran und haben letztlich einen Wachstumspfad zum Senior. Aber aus Sicht des Managements ist das womöglich uninteressant.
AI ist ein fantastisches Tool, um große Informationsmengen unscharf zu durchsuchen. In letzter Zeit nutze ich Kagis Assistant immer öfter vor einer normalen Suche. Es hilft mir, auf die Wörter zu kommen, die mir fehlen, und wenn ich dann mit diesen Begriffen die Seiten durchsuche, finde ich am Ende meist, was ich wollte. Aber aus vibe coding habe ich nie besonders dauerhaft Wert gezogen. Für One-off-Aufgaben ist es großartig. Wenn ich zum Beispiel ein matplotlib-Diagramm erstellen will, reicht es meist, zu beschreiben, was ich möchte, und nur das Datenschema zu zeigen, und es trifft zu 90 %. Es erstellt auch problemlos einfache Shell-Skripte. Kürzlich habe ich es ein kleines CLI-Tool bauen lassen, das RAW-Fotos anhand von EXIF-Daten in Ordner sortiert, und für solche Dinge bin ich sehr zufrieden damit. Aber sobald man etwas nur ein wenig Komplexeres verlangt, macht es viel Nutzloses. Es erzeugt bereits vorhandene Modelle im Projekt doppelt, nimmt irrelevante Änderungen vor oder halluziniert API-Funktionen, die es gar nicht gibt. Bevor ich das Ergebnis validiere, schreibe ich es lieber selbst. Und für mich ist der eigentliche Coding-Prozess ohnehin der schönste Teil. Für den realen Nutzungsprozess, bei dem Menschen per Prompt kurzfristig Ergebnisse erzeugen und diese sofort speichern, integrieren und weitergeben, habe ich bei LLMs noch keinen wirklich passenden Anwendungsfall gefunden.
AI ist sehr nützlich, um mir die gesuchte Antwort schnell aus Hunderten mit Werbung überladenen, chaotischen Websites herauszufiltern. Ich nutze Duck Duck Go AI häufig für Fragen und Antworten. Ich vertraue den Antworten nur so weit, wie ich ein Rechenzentrum werfen könnte, aber für Informationen, die sich schnell überprüfen lassen, etwa Programmsyntax oder Command-Optionen, ist es nützlich.
Bei AI-Nutzung gilt wirklich: Man bekommt heraus, was man hineinsteckt. Wenn man viel Zeit darauf verwendet, internes Verhalten, Edge Cases, Architektur, Bibliotheksauswahl usw. zu erklären und das sorgfältig in Markdown festzuhalten, ist die Chance hoch, dass nach ein paar Iterationen brauchbarer Code herauskommt. Das ist ein riesiger Unterschied zu kurzen Prompts wie „Baue mir Feature X“. Aber wenn man so gute Prompts schreiben kann, hat man das Problem im Grunde fast schon gelöst, und das LLM ist dann nur noch eine schnelle Auto-Tippmaschine. Nur das Tippen wird schneller; den Großteil der Denkarbeit hat der Mensch bereits geleistet.
Ich denke, immerhin versteht mindestens ein CEO diesen Punkt. Die Idee, Junior-Kräfte zu überspringen und nur mit AI aufzufüllen, schadet Unternehmen langfristig. Wenn Senior-Kräfte selbstständig gehen, bleibt nichts übrig. Ehrlich gesagt bin ich mir nicht sicher, ob AI für irgendeinen Ingenieur, auch für Juniors, wirklich vorteilhaft ist. Software Engineering ist eine Reise des Erforschens und Lernens. Jedes Mal, wenn ich AI benutze, muss ich an meinen Mathelehrer denken, der sagte: „Wenn du einen Taschenrechner benutzt, bleibt dir nichts im Kopf.“ Insgesamt fühlt sich AI auch wie das natürliche Ergebnis der US-Wirtschaftspolitik der letzten 45 Jahre an. Ein ausschließlich auf kurzfristige Ergebnisse für das oberste 1 % ausgerichteter Ansatz, der ein gesundes Unternehmensökosystem und die langfristige Entwicklung der Wirtschaft untergräbt. Wenn man so etwas sieht, wäre Jack Welch vermutlich sehr stolz.
In den letzten Monaten habe ich mit Startups gearbeitet und dabei viele Fälle gesehen, in denen sie so tief in LLM-vibe coding hineingeraten sind, dass sie nicht mehr herauskommen. Oft konnten sie keine guten Leute einstellen oder haben technisches Personal verpasst. Sie verwechseln AI-Code, insbesondere Claude-Code, mit einem internen 10x-Ingenieur und erwarten schnellere Iteration und besseren Code. Ich habe ziemlich kluge Gründer dabei beobachtet, wie sie von dem Dopaminrausch abhängig wurden, den direkt erzeugter Claude-Code auslöst, weil es sich anfühlt, als entspräche er Wochen oder Jahren an Software-Engineering-Arbeit. Zu glauben, AI könne über komplexe Probleme „nachdenken“ oder sie „verstehen“, ist viel zu großzügig. Ich denke, wir sollten eher „eingesparte Tippgeschwindigkeit“ messen als echte Denkleistung. [1] vibebusters.com
Ich stimme völlig zu, dass man „beibringen sollte, wie man denkt“ und „wie man Probleme zerlegt“. Der beste Professor an meiner Ingenieursschule hat immer Open-Book-Prüfungen gestellt. In der Realität arbeitet jeder in einer Umgebung, in der alle Daten und Informationen verfügbar sind. Menschen werden nicht dafür bezahlt, Daten einfach nur zu finden, sondern dafür, sie zu analysieren, zu verstehen und logisch anzuwenden. Genau das nennt man Engineering, und genau das hat dieser Professor gelehrt.
Ich hatte an der Uni eine Vorlesung in abstrakter Algebra. In allen Prüfungen ging es darum, berühmte Beweise auswendig niederzuschreiben und neue Beweise zu entwickeln. Das reine Auswendiglernen wirkte auf mich zunächst gezwungen, aber ich habe gemerkt, dass man nichts auswendig lernen kann, ohne den Beweis zu verstehen. Wenn man dann selbst neue Beweise entwickelt, hat man bereits Module im Kopf, wodurch der Zugang viel intuitiver wird. Echtes Auswendiglernen ist etwas ganz anderes als das Merken von Code im Stil algorithmischer Aufgaben; echtes Application Coding ist viel stärker menschlich geprägt, improvisiert und ähnelt eher einer zustandsbasierten spontanen Graphensuche. Reale Probleme kommen nicht immer in einer neuen geordneten Reihenfolge daher; am Ende sind Heuristiken entscheidend.
Ich denke, das ist das Kernproblem, vor dem das Hiring in diesem Bereich steht. Wirklich starke Entwickler sind im Wesentlichen Generalisten. Spezialisierung hat klar ihren Wert, aber außer in Situationen wie uralter Legacy-Code-Hölle oder bei Grenzdurchbrüchen ist ein Spezialist nicht zwingend nötig. Im Gegenteil: Jemand, der mit einem ungewohnten Stack gearbeitet hat, kann Schwächen ausgleichen oder frische Perspektiven einbringen. Ein fähiger Generalist passt sich schnell an jeden Stack an. Denn in jedem Unternehmen ist der verwendete Technologie-Mix anders und oft chaotisch. Selbst wenn man „15 Jahre React-Erfahrung“ verlangt, wird niemand sofort mit maximaler Produktivität starten können. Es braucht immer Onboarding-Zeit. Aber viele operative Hiring-Verantwortliche verstehen das nicht gut. Große Unternehmen bieten immerhin noch Training an, aber selbst dort ist die Stimmung heute nicht mehr wie früher. Im Wettbewerb um Einstellungen gibt man Hunderttausende Dollar aus, denkt aber kaum über die tatsächlichen Kosten nach, jemanden aufzubauen und weiterzuentwickeln. Branchenweit wäre es auch hilfreich, wenn es einen Berufsverband gäbe, damit Recruiting- und Talententwicklungsstrukturen nicht völlig aus dem Ruder laufen, aber so etwas fehlt, was das Problem verschärft. (Ich glaube, dass die aktuelle Aufmerksamkeit für Gewerkschaften im Zusammenhang mit Restrukturierungen, Outsourcing usw. in dieselbe Richtung weist.)
Ich habe das Gefühl, dass diese Veränderung bereits stattfindet. Die Hälfte des traditionellen CS-Curriculums ist Mathematik, und die andere Hälfte ist im Grunde ebenfalls Mathematik, nur unter anderen Namen. Es gibt zwar viel Kritik an der Wissenschaft, aber wenn jemand sagt: „Die Akademie ist dumm, sie sollte lieber X lehren“, dann wird X dort entweder bereits gelehrt, oder man kann es sich bei Bedarf schnell und gezielt aneignen. Die meisten neuen Trends sind Dinge, die dort ohnehin schon gemacht werden.
An meiner Universität hatte das Philosophie-Department den Marketing-Slogan „Das Denken als Fach, studieren Sie Denken“. Aus meiner Erfahrung als Hiring Manager sind Leute mit geisteswissenschaftlichem Hintergrund bei den eigentlichen Kernaufgaben wie Analyse und Verständnis viel stärker. Ich bin selbst doppelt in CS und Philosophie major gewesen und habe also sicher einen Bias, aber ein Junior mit analytischem Denkvermögen ist wirklich viel wertvoller als jemand, der einfach nur viel Code schreiben kann. Analytisches Denken ist viel schwerer zu vermitteln als Programmieren.
Im ersten Semester hatte ich einen Professor, der es „crazy finger syndrome“ nannte, wenn Informatik-Eliten Probleme nicht aus Geschäfts- oder Nutzersicht zerlegen, sondern sofort losschreiben wollen. Ich vermisse seine Witze über „ängstliche Studierende, die einfach nur coden wollen“. Ich glaube, aktuelle Bootcamps stehen nicht immer in engem Einklang mit hohen ethischen Standards.
Ich habe die Frage gehört: „Was passiert, wenn in Zukunft niemand mehr richtig ausgebildet wird?“ Viele Leute werden diese Schlussfolgerung wahrscheinlich bereits als selbstverständlich akzeptiert haben. Trotzdem ist es schwer, aus einer Struktur auszubrechen, in der die meisten Unternehmen eher auf kurzfristige Profitabilität als auf langfristige Nachhaltigkeit setzen. Immerhin werden Praktika/Co-ops weiterhin als Maßnahme betont, um die Talent-Pipeline aufrechtzuerhalten. Ich erwarte auch einen Trend, noch stärker auf Praktika zu setzen, um die Schwierigkeiten bei der Einstellung von Junior-Entwicklern zu umgehen.
Wenn ich meine Erfahrung zusammenfassen müsste, dann etwa so: Unser Chef hat sich mit großspuriger PR als AI-Führer inszeniert und verkündet, wegen AI massenhaft Leute abzubauen, aber in der Praxis war es ein komplettes Desaster, und jetzt muss ich nachträglich Erklärungen liefern und mich entschuldigen.
Chef -> VP: „Wegen AI müssen wir Personal abbauen“ VP -> Öffentlichkeit: „In zwei Jahren werden wir alle Ingenieure durch AI ersetzen“ Chef -> VP: „Auch VPs müssen wegen AI reduziert werden“ VP -> Öffentlichkeit: „Menschen durch AI zu ersetzen ist dumm“
Trotzdem werden immer noch keine Junior-Entwickler eingestellt.
Auch der AWS-CEO scheint seine Position geändert zu haben. Vor einem Jahr sagte er noch, dass „AI in zwei Jahren den gesamten Code schreiben werde“ [1]. Endlich scheint die C-Suite die Realität zu akzeptieren. [1] https://news.ycombinator.com/item?id=41462545
Der CEO hat das so tatsächlich nicht gesagt. Er sagte nur, dass Entwickler in zwei Jahren womöglich kaum noch selbst Code schreiben würden. Danach fügte er hinzu: „Stattdessen wird man sich viel stärker darauf konzentrieren, was gebaut werden soll, wie es gebaut werden soll und was Kunden tatsächlich brauchen.“ Artikellink Vom Ausgangspunkt bis zu seiner jetzigen Aussage ist das ein konsistenter Zusammenhang. Das eigentliche „Code schreiben“ könnte weniger wichtig werden, und deshalb müsse man Juniors einstellen, ihnen beibringen, wie man lernt, und Fähigkeiten aufbauen, die tatsächlich nützlich sind.
Theoretisch besteht der Großteil des Unternehmenswerts von Amazon aus den Fähigkeiten seiner Mitarbeitenden. Manche betrachten Arbeitskräfte nur als Kosten und meinen, aller Wert gehöre den Aktionären. Aber wenn Humankapital tatsächlich Wert besitzt, dann ist die Behauptung, jeder könne diesen Wert allein mit AI erhalten, eher schlecht für den Aktienkurs. Es droht sogar ein sinkendes KGV, und es ist seltsam, das positiv zu deuten. Wenn man wirklich glaubt, dass mit AI alles möglich ist, dann bedeutet das für Aktionäre eher, dass Kapital nicht mehr stabil in FAANG gebunden werden kann, sondern ständig auf der Suche nach dem nächsten „neuen Wachstumsthema“ sein muss.
Wenn man zur Führungsebene gehört, muss man immer den Zeitgeist erspüren.
Das ist überhaupt keine widersprüchliche Aussage. Um autonomen AI-Systemen Anweisungen zu geben, braucht man zwingend eine Talent-Pipeline, die nicht nur Seniors, sondern bereits Juniors aufbaut. Große Unternehmen sorgen sich um diese Pipeline, während kleinere Firmen das vielleicht ausnutzen, kurzfristig nur Seniors einstellen und keine Praktikanten nehmen.
Zwischen den beiden Aussagen besteht kein logischer Widerspruch. Man kann weiterhin Juniors einstellen, auch wenn sich ihre Arbeit faktisch von klassischer Programmierung wegbewegt.
Wenn du den Eindruck hast, dass Chef und Unternehmen unterschiedliche Positionen vertreten, würde ich empfehlen, das direkt selbst nachzuprüfen. Nachrichtenartikel einfach kontextlos zu zitieren, ist nicht wünschenswert. Schließlich kann ohnehin niemand die Zukunft wirklich vorhersagen. [1]: https://www.shrm.org/topics-tools/news/technology/ai-will-shrink-corporate-workforce--amazon-ceo-warns
Ich denke nicht, dass die Aussagen der beiden CEOs im Widerspruch zueinander stehen. „Wir müssen weiterhin Hochschulabsolventen einstellen und ihnen beibringen, wie man Software richtig baut“ - Matt Garman „Für viele der Dinge, die Menschen heute tun, wird man weniger Menschen brauchen“ - Andy Jassy Im Kern ist das sehr ähnlich, nur der Tonfall ist etwas anders.
Ich finde, beim Zitieren sollte man ethisch verpflichtet sein, das Original möglichst gleichwertig und mitsamt Kontext wiederzugeben. Wen man zitiert und in welchem Zusammenhang, bestimmt den Ton einer Nachricht.
Die beiden Aussagen sind logisch sehr konsistent.
Als jemand, der bei AWS gearbeitet hat, vertraue ich offiziellen Aussagen von AWS nicht vorbehaltlos. Ich wusste schon vorher, was AWS für ein Unternehmen ist, und bin dort mit 46 in meinem achten Job gelandet. Es gab sogar Fälle, in denen eine Stelle als „dauerhaft remote“ bezeichnet wurde, und erst nachdem ich schon gekündigt hatte, kam eine Rückkehr-ins-Büro-Anordnung.
Die Talent-Pipeline in der Forschung funktioniert so: Bachelorstudierende -> Master-/Promotionsstudierende -> Postdocs -> Tenure/Senior Von einigen wenigen Ausnahmen abgesehen, wird niemand Senior Researcher, indem er die ersten beiden Stufen überspringt. In jeder Branche ist es letztlich genauso. Ohne Juniors können keine Seniors entstehen, also sollte man auf das Risiko vorbereitet sein, wenn man stattdessen will, dass „Bots“ alles übernehmen.
Ich bin sicher, dass jeder, der lange mit diesen Modellen gearbeitet hat, dem zustimmen wird. Die sama-AGI-Posts vor dem o3-Release und die damaligen Doomer-Posts aus der Tech-Szene wirken rückblickend wirklich absurd.
AGI-Doomerism war nur eine Marketingstrategie. Inzwischen versteht jeder das Wesen von AI, und jetzt sehen wir uns einfach die nächste Wiederholung eines Search-Marktes an, in dem AI einem alle Dokumente vorliest.
Es war schon immer dummes Rauschen, aber niemand ist völlig immun gegen Hype. Vor allem deshalb nicht, weil gewaltige Summen in Astroturfing geflossen sind, das die technische Realität überhöht hat.
Ich halte ChatGPT für besser als jeden Junior-Entwickler, mit dem ich je gearbeitet habe. Ein Junior ist fast ein Jahr lang netto negativ für das Team. Aus Sicht von jemandem, der reale Projekte verantwortet, habe ich noch nie gedacht: „Ich wünschte, ich hätte mehr Juniors.“ Es ist viel sinnvoller, 20 % mehr zu zahlen und dafür jemanden auf Mid-Level abzuwerben.