Uber verpulvert gesamtes KI-Budget für 2026 in nur vier Monaten für Claude Code

• Uber hat durch die Ausweitung der Nutzung von Claude Code und Cursor sein gesamtes KI-Budget für 2026 bereits in vier Monaten aufgebraucht; ein Produktivitätsexperiment führte damit unmittelbar zu einer Neubewertung des Budgets
• Der CTO von Uber erklärte, dass die monatlichen API-Kosten pro Ingenieur bei 500 bis 2.000 US-Dollar lagen und 95 % der Ingenieure jeden Monat KI-Tools nutzen
• 70 % des bei Uber committeten Codes stammen aus KI, und KI-Coding-Tools sind in den Kern-Workflow der Engineering-Arbeit eingezogen
• Claude Code wurde im Dezember 2025 im Engineering-Team ausgerollt; nachdem seine Fähigkeiten für mehrstufige Aufgaben bestätigt worden waren, verdoppelte sich die Nutzung bis Februar 2026 und im April war das Jahresbudget vollständig aufgebraucht
• Während das Wachstum bei Cursor stagnierte, wurde Claude Code zum dominierenden Tool, und Uber muss die Kosten für KI-Coding-Tools innerhalb seiner jährlichen F&E-Ausgaben von 3,4 Milliarden US-Dollar neu kalkulieren

---

Breitere Einführung und Neubewertung des Budgets

• Uber erkannte im Zuge des schnellen Wachstums bei Claude Code und Cursor einen starken Wertzuwachs dieser beiden Tools, so sehr, dass es Ingenieuren trotz der stark steigenden Kosten schwerfällt, ihre Nutzung einzuschränken
• Im Dezember 2025 wurde der Zugriff auf Claude Code an das Engineering-Team verteilt, und nachdem seine Fähigkeiten für mehrstufige Aufgaben bestätigt worden waren, verdoppelte sich die Nutzung bis Februar 2026
• Als die Kosten im April 2026 das gesamte jährliche KI-Budget aufbrauchten, sah sich das Management zu einer unerwarteten Entscheidung gezwungen
• Der CTO von Uber sagte, das Unternehmen habe seine KI-Budgetplanung wieder auf „back to the drawing board“ zurückgesetzt

Veränderungen bei der Tool-Nutzung

• Cursor war ein weiteres wichtiges Tool im Wettbewerb um Akzeptanz, doch das Nutzungswachstum stagnierte
• Claude Code wurde zum dominierenden Tool im Engineering-Workflow
• Was als Produktivitätsexperiment begann, wurde schnell ausgeweitet, wodurch der Einsatz von KI-Tools in der internen Engineering-Arbeit des Unternehmens ernsthaft in Gang kam

Bedeutung des Kostendrucks

• Ubers unerwarteter Budgetverbrauch zeigt, wie wertvoll KI-Tools für die Engineering-Produktivität eingeschätzt werden
• Die Rolle von KI-Tools ist inzwischen so groß geworden, dass eine Einschränkung des Zugangs eher als unproduktiv empfunden würde
• Da mehr Entwickler Claude Code übernehmen, könnten auch andere Unternehmen ähnliche Auswirkungen erleben
• Softwareunternehmen geraten unter Druck, die Entwicklungsgeschwindigkeit aufrechtzuerhalten und gleichzeitig die Kosten zu kontrollieren
• Wenn Tools für die Entwicklerproduktivität so wertvoll sind, dass Ingenieure in vier Monaten das gesamte Budget verbrauchen, liegt die Schlussfolgerung nahe, dass nicht das Tool das Problem ist, sondern dass das Budget zu früh angesetzt wurde, um die Adoptionskurve vorherzusagen

[picopress]

Genussvolles Verprassen

[GN⁺]

Hacker-News-Kommentare

• Wenn ich mir etwa einmal im Monat die Ausgaben des Unternehmens anschaue, irritiert mich, dass immer mehr Leute 1.000 $ pro Monat an Token-Kosten ausgeben, und ich frage mich, wie das überhaupt möglich ist
  Selbst wenn man täglich LLMs nutzt und beim teuersten Modell sogar den Deep-Thinking-Modus verwendet, liegt das Limit normalerweise bei 200 bis 400 $. Ich bin kein Luddit, der die Nutzung an sich ablehnt; ich meine nur, dass ich schwer nachvollziehen kann, wie man verantwortungsvoll so viel Geld pro Monat verbrennt. Ich würde gern sehen, wie jemand, der 5.000 bis 10.000 $ pro Monat ausgibt, zeigt, wie daraus 50.000 bis 100.000 $ an Wert werden. Aus Sicht eines Unternehmens scheint es sinnvoller, einen Junior Engineer einzustellen, der für 100 bis 200 $ pro Monat produktiv ist, als Token-Ausgaben von 100.000 $ pro Jahr zu rechtfertigen

  • Es scheint im Wesentlichen drei Fälle zu geben, in denen man verantwortungsvoll so viel Geld verbrennt. Anfänger erstellen wegen der Wiederverwendung langer Unterhaltungen keine Kontextkomprimierung oder Zusammenfassungs-Checkpoints und schleppen eine riesige einzelne Unterhaltung weiter mit sich herum, weil es sich anfühlt, als sei der Agent darin „trainiert“ worden
    Fortgeschrittene kennen dann Muster wie „Starte 5 Unteragenten, die die Lösung aus verschiedenen Blickwinkeln analysieren und zusammenfassen“, und werden leicht süchtig danach. Das ist an sich keine schlechte Gewohnheit, aber wenn man nicht aufpasst, überschreitet man die Credits massiv. Erfahrene Nutzer lassen 10 Aufgabenzweige ständig parallel laufen und springen extrem multitaskend zwischen Agentenantworten hin und her, wodurch die Kosten exponentiell steigen können
  • Erstens gibt es den naheliegenden Grund: „Wenn die Firma es erlaubt, wird verschwendet.“ Dazu gehört auch, den Kontext nicht oft genug zu leeren oder zu komprimieren. Opus’ 1M-Kontextfenster gibt es jetzt, und bis 200K ist die Qualität auch ordentlich, daher verbrennt man bei jeder Anfrage viele Token, bis man leert
    Große Codebasen oder komplexe Probleme sind ebenfalls ein großer Faktor. Wenn man neu im Team ist und viele Bereiche noch nicht kennt, lässt man Claude bei einer Aufgabe erst den relevanten Code finden und den bestehenden Ablauf verstehen, bevor überhaupt Änderungen versucht werden. Man baut dabei weniger eigenes Fachwissen auf, aber mit Claude kann man etwas, das sonst 5 Tage dauert, in 1 Tag erledigen, und wenn das alle tun, kann man sich schwer entziehen. Deshalb wähle ich einen Mittelweg: statt 1 Tag eher 2 bis 3 Tage und dabei selbst auch etwas in den Code schauen. Gerade weil sich Code dank AI extrem schnell verändert, habe ich sogar ein Tool gebaut, das Pull Requests dem LLM tiefgehend erklären lässt. Nicht als Reviewer, sondern um bei der Teamarbeit noch mitzukommen. Ich habe mir noch nicht einmal besonders viele Gedanken gemacht, wie ich LLMs besser einsetzen könnte, und wenn ich die Codebase besser kennen würde, hätte ich sie vermutlich noch viel mehr genutzt. Der Engpass sind weiterhin vernünftige Tests und Reviews. Weniger wichtiger interner Code oder privater Code wird meist fast komplett der AI überlassen, und wenn man die „superpowers“-Skills nutzt, verbrennt man schon bei Grundfunktionen viele Token. Meist startet es bei 20 bis 40K Token und liegt am Ende bei 80 bis 90K Token, sodass mehrere Anfragen kurz vor Abschluss jeweils fast 80K Token senden. Das ist verschwenderisch, aber wenn andere zahlen, passiert genau das
  • Ich habe gesehen, wie Claude Code für ein Problem eine absurd token-ineffiziente Lösung gewählt hat. Ich hatte ein komplexes Machine-Learning-/Vorhersageproblem auf mehrere Agenten verteilt, und jeder Agent nutzte, führte aus und las Jupyter-Notebooks
    Anfangs war das okay, aber dann schrieb ein Agent Hunderttausende Zeilen in eine Zellenausgabe und erzeugte so eine 500-MB-ipynb-Datei, die Claude dann mehrfach einzulesen versuchte und damit das gesamte Kontextlimit verbrannte. Die Lösung war, die Arbeit besser zu strukturieren, mit CLI-Analyseskripten und einem Ordner für Forschungsergebnisse, aber ich als Operator musste Planung und Design übernehmen. Bei Leuten, die 10.000 $ pro Monat an Token ausgeben, kann ich nur schwer etwas anderes sehen, als dass sie mit dem teuren Hammer Claude Code Probleme faul und ohne nachzudenken erschlagen. Zum Beispiel Claude jeden Tag alle E-Mails lesen zu lassen, obwohl die klügere Lösung wäre, zuerst das Rauschen aus dem E-Mail-HTML zu entfernen
  • Es hängt wirklich stark vom Repository ab, an dem man arbeitet. Wenn es sehr groß ist und man insbesondere Custom Frameworks und API-Dokumentation nachschlagen muss, braucht man ein großes Kontextfenster und die Token gehen viel schneller weg
    Umgekehrt kann man bei kleinen Projekten oder bei gängigen Frameworks, auf die das Modell trainiert wurde, mit einem kleineren Kontextfenster sehr viel schaffen und hat deutlich geringeren Tokenverbrauch
  • Ich verstehe es nicht nur bei den Kosten nicht, sondern auch bei den Quoten. Ich habe den 200-Euro-ChatGPT-Tarif, also vermutlich die höchste Quote, und selbst wenn ich mit dem teuersten Modell, höchster Inferenz und schnellem Modus den ganzen Tag fast nur Agent-Programming mache, komme ich nicht einmal in die Nähe des Limits
    Seit ich Coding-Agenten nutze, war ich dem Limit nur dann nahe, als ich unter denselben Bedingungen plattformübergreifende Entwicklung gleichzeitig auf drei Computern gemacht habe, und selbst da war es nur fast das Wochenlimit. Normalerweise komme ich auf etwa 20 % der Quote herunter, aber tiefer geht es fast nie. Ich werfe aus Spaß viele Prompts und Anfragen hinein und weiß trotzdem nicht, wie ich mehr verbrauchen sollte

• Ich weiß, dass ich das gerade einer AI antworte, aber die Aussage „herausfinden, ob das Unternehmen dieses Produktivitätsniveau in großem Maßstab verkraften kann“ klingt seltsam. Wenn es tatsächlich produktiv wäre, würde der Umsatz steigen, und ob man es sich leisten kann, wäre kein Problem

  • Genau. Produktivität erzeugt per Definition irgendetwas, idealerweise etwas Wertvolles. Man muss prüfen, ob die Zusatzkosten für den Chatbot diesen Wert liefern. Ich frage mich, ob Uber durch diese massive Budgetüberschreitung dramatisch effizienter und wirksamer geworden ist oder ob man den Leuten nur eine glänzende und teure neue Art gegeben hat, dieselbe Arbeit umzuverpacken
  • Der Umsatz ist gestiegen. Wenn man sich die jüngsten Ergebnisse von Meta anschaut, liegt der Umsatz bei +33 % selbst in dieser Wirtschaftslage. Ob man es sich leisten kann, ist nicht das Problem, und es gibt einen Grund, warum Unternehmen wie Meta nicht mit der Wimper zucken, wenn ein Engineer 1.000 $ pro Tag für Token ausgibt. Verglichen mit dem Geld, das ein Mitarbeiter einbringt, ist das kein so großer Betrag
  • Nicht jede Änderung, die ein Entwickler macht, erhöht den Umsatz, und selbst Änderungen, die den Umsatz steigern, haben in der Regel eine Zeitverzögerung
  • Wenn man die Gegenseite möglichst wohlwollend sehen will, wäre ein Gegenbeispiel, dass Konkurrenten dieselben Tools nutzen und dieselbe Produktivitätssteigerung erzielen
  • Wenn man es richtig einsetzt, ist es wirklich extrem produktiv. Ich mache mir fast Sorgen, wie klug diese ähnlichen AI-Modelle nächstes Jahr sein werden

• „95 % der Uber-Ingenieure nutzen jetzt monatlich AI-Tools, und 70 % des committeten Codes stammen von AI“ ist absehbar. So etwas passiert, wenn die Nutzung von AI-Tools in die Leistungsbewertung einfließt

  • Es ist erstaunlich, wie sehr unterschätzt wird, wie leicht sich so etwas gamifizieren lässt, wenn Nicht-Entwickler Entwicklern KPIs aufzwingen. Ob AI oder das Zählen von Pull Requests/Zeilen, ist egal
  • In dem Moment, in dem der KPI nicht mehr „Was wurde ausgeliefert?“ lautet, sondern „Wie viel AI wurde genutzt?“, folgt der Budgetexzess ganz natürlich. Die Leute werden versuchen, die Zahl zu treffen
  • Wenn Manager und VPs alle sagen: „Wer hier keine AI nutzt, kann hier nicht arbeiten“, dann werden die Leute sie natürlich nutzen
  • Ich verstehe diese Kritik nicht ganz. Wurde man nicht schon immer dafür bezahlt, das zu tun, was das Unternehmen will und was das Unternehmen für produktiv hält? Und ich frage mich, ob du wirklich glaubst, dass AI-generierter Code komplett nutzlos ist

• Ich verstehe den Teil „herausfinden, ob das Unternehmen dieses Produktivitätsniveau in großem Maßstab verkraften kann“ nicht. Das Budget wurde ausgegeben und es gibt 4 Monate Daten; entscheidend ist doch, welche Ergebnisse man vorweisen kann
  Ich bin kein AI-Hasser und kein Luddit und nutze selbst den 200-$-Max-Tarif. Aber meint Uber damit, dass man dieses Tool geöffnet und allen zur Nutzung empfohlen hat und nun verwirrt ist, was passiert, wenn es tatsächlich gut funktioniert? Eine andere Frage ist, ob AI im Verhältnis zu den Kosten produktiv genug ist. Man fragt sich fast, ob ihnen ausgegangen ist, was sie als Nächstes bauen sollen

  • Der persönliche Max-Tarif und der Teams-Tarif sind im Vergleich zu nutzungsbasierten API-Kosten im Enterprise-Bereich wirklich erstaunliche Sonderangebote. Offenbar brauchten sie die Enterprise-Funktionen unbedingt. Sonst hätte man den Nutzern auch einfach ein 200-$-Max-Abo als Ausgabe erstatten können. Unternehmen verhalten sich am Ende eben wie Unternehmen
  • Wahrscheinlich sieht man aktuell noch nichts. Große Änderungen, die externen Nutzern auffallen, brauchen viel länger, bis sie breit ausgerollt sind. Intern dürften mehrere Features schneller vorangekommen sein
    Auch bei Salesforce habe ich erlebt, dass Dinge, die früher Wochen dauerten, plötzlich nur noch Tage brauchen. Das verwandelt sich nicht sofort in Geld, erhöht aber das Potenzial, Geld zu verdienen
  • Man kann auch fragen, was Uber als Nächstes überhaupt noch bauen will. Die Ride-Hailing-Plattform existiert und funktioniert. Man hat auf Essen, Lebensmittel und die Lieferung von „allem, was ins Auto passt“ erweitert. Ich weiß nicht, was im Bereich jemand fährt ein Auto noch groß übrig ist
  • Die Mittel zur Ausgabenkontrolle sind gut, deshalb verstehe ich nicht, warum man keine Obergrenzen gesetzt hat. Man hätte von den Ingenieuren verlangen können, diese Ausgaben zu rechtfertigen
    Man müsste fragen, warum so viele Token nötig sind und was man dafür bekommt. Wäre das AWS gewesen, hätten alle gesagt: „Habt ihr euch die Monatsausgaben überhaupt angesehen?“
  • Es wirkt so, als sei die AI-Debatte inzwischen an dem Punkt, an dem man jeder Kritik voranstellen muss: „Ich gehöre auch zum Kult und bin kein Ungläubiger“, um nicht sofort als Ketzer zu gelten

• Es ist interessant, dass bei solchen Artikeln plötzlich viele Leute glauben, die Messung von Entwicklerproduktivität sei simpel. Es stimmt zwar, dass Produktivität irgendwann zu Umsatz oder Kostensenkung führt und dass Umsatz messbar ist, aber so einfach ist es nicht
  Man gibt heute Geld aus, um Features zu bauen, die zukünftigen Umsatz bringen, deshalb kann heute ein Kostenanstieg auftreten, ohne dass es schon messbaren Umsatz gibt. Nur weil ein Feature heute mit AI fertig wurde, kann man nicht sofort sagen, ob AI produktiv oder unproduktiv war; man müsste schätzen, was ohne AI in welchem Umfang passiert wäre und wie sich das auf den Umsatz ausgewirkt hätte. Business ist oft ein Rote-Königin-Rennen: Wenn man sich nicht verbessert, verliert man Umsatz an die Konkurrenz. Wahrscheinlich war der AI-Einsatz eine Mischung aus wichtigen Aufgaben und „jetzt ist es leicht, also probieren wir einfach alles Mögliche aus“. Um echte Produktivitätsgewinne zu messen, muss man lernen, Ersteres beizubehalten und Letzteres zu vermeiden. Es geht nicht um pro oder contra AI, sondern darum, nicht träge zu behaupten: „Wenn es produktiv wäre, könnte man es schon messen“

  • Der Hauptkonsens scheint mir eher zu sein, dass Entwicklerproduktivität zu messen sehr schwer ist. Sobald man versucht, sie zu messen, wird diese Messgröße selbst zum Ziel, und selbst wenn sie ursprünglich robust war, wird sie bedeutungslos
    Ich weiß nicht, woher die Vorstellung kommt, die Produktivität von Menschen, die keine Fabrikarbeiter sind, lasse sich leicht messen
  • Ich glaube nicht, dass neue Features oder bessere Software Ubers Umsatz/Gewinn stark erhöhen werden
  • Die Optionen sind nicht nur Null Produktivität oder etwas Produktivität, es kann auch negative Produktivität sein. Nach meiner Erfahrung mit Claude Code wäre ich sehr skeptisch, weil so viele Token in einer Organisation nicht nur unproduktiv, sondern aktiv schädlich sein können
  • Kleine Produktivitätsänderungen sind schwer messbar, aber große Sprünge wären klar sichtbar gewesen. Wenn AI die Produktivität beeinflusst, dann wohl höchstens in kleinem Maß
  • 10-fache Produktivität hätte sich zumindest indirekt messen lassen, man hätte die Messung eher gar nicht vermeiden können. Die frühen Behauptungen waren offensichtlich falsch, und die eigentliche Forschungsfrage ist, ob es mehr als 1,0x ist
    Ich stimme zu, dass das sehr schwer zu messen ist. Aber bei diesen Kosten muss man die Frage beantworten können, und auch der Faktor selbst muss die Ausgaben rechtfertigen

• Laut [1] hat Ubers Engineering-Organisation etwa 5.500 Mitarbeiter. Wenn man als Mittelwert der Ausgabenspanne 1.250 $ nimmt, lägen die AI-Ausgaben im Engineering bei etwa 6,8 Mio. $, mit einer Spanne von 2,75 bis 12 Mio. $. Im Artikel steht, dass die F&E-Ausgaben bei 3,4 Mrd. $ liegen
  Die AI-Ausgaben machen also keinen großen Anteil an den F&E-Ausgaben aus. Für 4 Monate sind es 0,3 %, auf das Jahr hochgerechnet etwa 1 %. Wenn es nicht geplant war, ist es kein Kleingeld, aber im Kontext auch nicht riesig. Die eigentliche Frage ist, was man für das Geld bekommen hat. Der Artikel behauptet, 70 % der Code-Commits seien AI-generiert, also haben sie vermutlich Reviews und Tests bestanden. Wichtig wäre, ob Features schneller entstanden sind, Qualitätsprobleme zurückgingen oder es andere Vorteile gab. Leider nennt der Artikel außer den gestiegenen Ausgaben keine Ergebnisse. Vielleicht sind 4 Monate zu kurz, um den Nutzen zu bewerten. In einer agilen Welt könnte man das aber auch anders sehen. [1] https://www.unifygtm.com/insights-headcount/uber

  • In der eigentlichen Quelle https://www.theinformation.com/newsletters/applied-ai/uber-c... steht: „Ungefähr 11 % der tatsächlichen Live-Code-Updates in Backend-Systemen werden von AI-Agenten geschrieben, die hauptsächlich mit Claude Code erstellt wurden, gegenüber weniger als 1 % vor drei Monaten“
    Dort steht auch, dass „das Unternehmen keine genauen Zahlen zum Softwarebudget oder zu den Ausgaben für AI-Coding-Tools offengelegt hat“
  • Alles an diesem Artikel wirkt einfach komplett erfunden. Die Zahlen stimmen nicht, es passt nicht zu den berichteten Informationen, es wirkt schlicht wie Fiktion

• Als Bootstrapping-Gründer beneide ich oft die Ingenieure in Großunternehmen, aber ich mache mir auch Sorgen, dass die Anreize kaputt sind
  Wenn ich Uber-Ingenieur wäre, gäbe es für mich keinen Grund, bei kleinen Änderungen nicht gpt 5.5 pro @ very high thinking + fast mode in den Prompt zu schreiben. Es gibt keinen Anreiz, nicht das leistungsstärkste und damit teuerste Modell zu verwenden. Ich habe das bei einem Bild-zu-HTML-Test mit genau so einem Prompt ausprobiert, und ein einzelner Prompt hat 40 $ gekostet. Wenn ich das selbst zahlen müsste, würde ich diese Einstellung fast nie verwenden; in einem Großunternehmen, in dem jemand anderes die Rechnung bezahlt, würde ich sie oft laufen lassen. Die Ausgabe war definitiv besser. Ingenieure werden danach bewertet, was sie liefern, nicht nach den Kosten des Weges dorthin. Es gibt günstigere Methoden, aber der Ingenieur hat keinen Anreiz, sie zu wählen

  • Software Engineers sind teuer. Das mittlere Gehalt liegt bei 133.000 $, und Krankenversicherung, Lohnnebenkosten usw. sind da noch nicht einmal enthalten. Wenn 40 $ an LLM-Credits eine Stunde Entwicklungszeit sparen, ist das rechnerisch 26,50 $ günstiger, als es nicht zu tun
    Ob das in der Praxis wirklich so ist, davon bin ich noch nicht überzeugt, aber theoretisch stimmt die Rechnung. Auch das Senken von LLM-Kosten ist ein zweischneidiges Schwert. Denn die eingesparten LLM-Kosten müssen größer sein als die Kosten des Entwicklers, der sie reduziert. Wenn jemand einen ganzen Tag investiert, um 1 $ pro Aufruf zu sparen, dauert es fast zwei Jahre, bis sich allein die Personalkosten amortisieren. Außerdem ändern sich LLMs so schnell, dass man kaum sicher sein kann, dass diese Lösung nicht innerhalb von zwei Jahren obsolet wird. Ob es in zwei Jahren überhaupt noch Tool-Calls oder Inferenzmodi gibt, wissen nicht einmal die Frontier-Anbieter selbst
  • Ein Unternehmen will vielleicht zuerst sehen, wie schnell es die Arbeit skalieren kann, und danach aus Effizienzgründen wieder zurückschneiden
  • Bild-zu-HTML ist eine ziemlich komplexe Aufgabe. Im Grunde ist das Frontend-Entwicklerarbeit, und für 40 $ bekommt man nicht einmal eine Stunde von deren Zeit

• Je häufiger Führungskräfte glauben, sie könnten Software Engineering durch Agenten ersetzen, desto mehr frage ich mich, ob sie Entscheidungen auf einem unrealistischen Bild des durchschnittlichen Software Engineers aufbauen
  Einerseits gilt schon: raus kommt, was man hineinsteckt. Ein kluger CTO kann von dem, was Agenten leisten können, sehr begeistert sein und daraus fälschlich schließen, dass alle Engineers dasselbe könnten. In Wirklichkeit fehlt es dem durchschnittlichen Engineer in der Organisation vielleicht schon an der Kreativität, überhaupt zu erkennen, wo sich Arbeit einsparen lässt. Wenn man also den Einsatz von Agenten zur Pflicht macht, steigt womöglich nicht die Produktivität, sondern nur die AI-Rechnung. Andererseits macht AI zwei Lücken noch deutlicher: Wer sagt den Agenten überhaupt, was sie tun sollen, und wie bewältigt man den QA-/Review-Zyklus? In vielen Organisationen sind Produktverantwortliche technisch nicht versiert genug, um die detaillierten Spezifikationen oder Pläne zu erstellen, die ein LLM nutzen könnte, und die Entwickler als Zahnräder der Maschine wollen oft nur implementieren, statt Spezifikationen zu verfassen. Wenn man erwartet, dass die Entwickler, die Agenten nutzen, auch die Umsetzung definieren, könnte das sogar zu mehr untätiger Kapazität führen, die nur darauf wartet, dass Arbeit hereinkommt. Für selektive LLM-Einführung, die Geschwindigkeit und Qualität bestehender Entwickler erhöht, bin ich, aber der Impuls „Lasst uns die Organisation umbauen“ ist gerade für kleine und mittlere Unternehmen ziemlich riskant

  • Noch mehr als das ist AI ein Kraftverstärker, dem es egal ist, ob diese Kraft positiv oder negativ ist. Wenn jemand mit schlechten Software-Engineering-Prinzipien AI nutzt, kann daraus sehr schnell ein komplettes Chaos entstehen
  • Zu Punkt 2: Unser Unternehmen drängt stark darauf, dass Entwickler Produktverständnis entwickeln und weniger nur Zahnräder sind
    Ich bin voreingenommen, weil ich selbst stärker produktorientiert bin als andere Entwickler, aber ich glaube, genau solche Leute sind in der besten Position, mit Agenten produktiver zu werden. Sie kennen die Technik gut genug, um mit Agenten zu implementieren, und das Produkt gut genug, um zu wissen, was implementiert werden muss. Ich erwarte, dass andere Unternehmen nachziehen werden
  • Am Ende heißt das wohl schlicht: großer Personalabbau

• Ich verstehe nicht, woran Uber überhaupt entwickelt. Es gibt die App und das Backend für die Fahrzeugzuweisung, und beides funktioniert ordentlich. Ich frage mich, warum sie so viel ausgeben
  Autonomes Fahren haben sie aufgegeben, also ist es das wohl nicht

  • Das ist wirklich eine unterschätzte Frage. Sie zeigt gut, womit moderne Tech-Unternehmen all diese Ressourcen eigentlich verbringen. Elon hat den Großteil des Twitter-Teams gestrichen, und nach den furchtbaren Anfangsfehlern lief es trotz 80 % weniger Personal doch im Wesentlichen weiter, oder?
  • Es wäre schön, wenn „beides funktioniert ordentlich“ stimmen würde, aber das tut es nicht. Wegen Optimierungen am Matching-Algorithmus ist die Nutzererfahrung inzwischen so schlecht, dass ich jetzt regelmäßig Lyft nutze
  • Kommentare nach dem Muster „X ist doch einfach nur Y, warum ist das so kompliziert?“ gehören zu den unerquicklichsten Dingen auf HN. Das unter jeden Artikel über ein unbeliebtes Großunternehmen zu schreiben, ist faul und langweilig zu lesen

• Bei API-Token ist es gerade mit 1M Kontext sehr leicht, in einer einzigen Sitzung Hunderte Dollar zu verbrennen, wenn man alten Kontext nicht sorgfältig entfernt
  Gleichzeitig erlauben Abos dieselbe Nutzung für ein paar Hundert Dollar im Monat. Entweder verlangt Anthropic API-Nutzern massiv zu viel, oder sie subventionieren die Abos stark, oder beides

  • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
    „Cursor schätzte vergangenes Jahr, dass ein 200-$-Claude-Code-Abo bis zu 2.000 $ an Compute-Leistung nutzen könne, was auf eine erhebliche Subventionierung durch Anthropic hindeute. Inzwischen scheint diese Subvention noch aggressiver zu sein: Mit dem 200-$-Tarif lassen sich etwa 5.000 $ an Compute-Leistung verbrauchen“
  • Anthropic hat ein ziemlich „interessantes“ Geschäftsmodell. Solange ein Unternehmen 150 Mitarbeiter oder weniger hat, zahlt es Abo-Preise, aber in dem Moment, in dem es 151 Mitarbeiter hat, müssen plötzlich alle über Nacht API-Preise zahlen, und die Gesamtrechnung steigt sofort um ein Mehrfaches
    Man macht die Kunden erst von günstigen Token abhängig und kassiert dann ab, sobald sie skalieren. Uber bekommt sicher Rabatt gegenüber dem Listenpreis, aber sicher nichts in der Nähe der Abo-Preise für Unternehmen mit bis zu 150 Leuten
  • Ich habe mir die Preise angesehen, konnte den Sprung von Team zu Enterprise aber nicht rechtfertigen. Mit Enterprise verschwindet das monatliche Abo komplett und man verliert die Möglichkeit der Kostenkontrolle
    Man kann Limits pro Nutzer setzen, aber ohne ein rollierendes Monatslimit muss man Teammitgliedern dann unter Umständen sagen: „Für den Rest des Monats gibt es keine AI mehr.“ In der aktuellen Struktur halte ich das für einen ziemlich riskanten Deal