ザ・パルス:『トークンマキシマイズ』という奇妙な新トレンド
メタ社内のAIトークン使用量を競う「Tokenmaxxing」 leaderboardが大量の浪費とシステム障害を引き起こしたため、メディア報道後に削除された。
キーポイント
トークン leaderboard の設立と実態
Meta社員がAIトークン使用量を競う社内ランキングを作成し、60.2兆トークンを30日で消費する異常な利用パターンが報告された。
大量の浪費とSEV発生のリスク
品質より出力量を重視する使い方が広がり、不要なエージェント実行や不適切なコード生成によりシステム障害(SEV)が発生した。
メディア報道後の leaderboard 削除
The Informationの報道と社内からの批判を受け、メタはインセンティブが不要な浪費を生むと判断し、わずか1週間でランキングを削除した。
トークンコストの試算と実費
AnthropicのAPI価格で換算すると約9億ドルとなるが、メタは割引契約を利用しているため実費は1億ドル以上と推定される。
Metaのトークンリーダーボードには学習データ生成の裏目的があった
AI利用を増やすことで大規模な実世界の利用痕跡(トレース)を生成し、次世代コードモデルの訓練データ収集を主目的としていた可能性がある。
Microsoftでのtokenmaxxingと雇用不安の関連
上位表示や「AI利用率が低い」と見られることを避けるため、エンジニアが意図的にトークン消費を増やす行動が見られ、これは雇用不安や「AIネイティブ」と見られることへの強いプレッシャーに起因している。
Salesforceのインセンティブ設計が非効率利用を助長
最小・理想のトークン消費目標を設定するツールを導入しており、企業側の施策が意図しない過度なトークン消費と非効率な業務フローを招いている。
影響分析・編集コメントを表示
影響分析
本記事は、企業内でのAI活用を単純な数値指標で評価することの危険性を示しており、組織がAI導入時にインセンティブ設計と品質管理を両立させる必要性を浮き彫りにしている。メタの事例は、他のテック企業や大規模組織がAIツールを導入する際の教訓となり、トークン経済の透明性と適切なガバナンスの重要性を強調している。
編集コメント
企業内AIツールの導入において、利用量を競うインセンティブは逆効果になりかねない。メタの事例から、適切な使用ポリシーと品質管理プロセスの早期構築が不可欠であることがわかる。
こんにちは、Gergelyです。今回は『Pragmatic Engineer Newsletter』のボーナス号として無料でお送りします。毎号、シニアエンジニアやエンジニアリングリーダーの視点からBig Techとスタートアップについて取り上げています。今回は先週の『The Pulse』号で扱った4つのトピックのうち1つをご紹介します。フル購読者は7日前に以下の記事を受け取っています。このメールを転送された方は、こちらから購読できます。
Meta内部では、あるエンジニアがトークン(token)使用量で従業員をランキングする「トークンリーダーボード(token leaderboard)」を作成しました。先週、The Informationが以下のように報じています:
「Meta Platformsの従業員の中には、自身のAI上級者としてのスキルを誇示したい者が、『Session Immortal』という地位、あるいはさらに良い『Token Legend』の称号を目指して社内リーダーボードで競い合っています。
このランキングは、Metaの社員が社内イントラネット上で自社データを用いて作成したもので、AIモデル(AI model)が処理するデータの単位であるトークン(token)を従業員がどれほど消費しているかを計測します。AIスタートアップAnthropicの主力製品にちなんで「Claudeonomics」と名付けられたこのリーダーボードは、85,000人以上のMeta従業員のAI使用状況を統合し、上位250人のパワーユーザーをリストアップしています。
この風習は、シリコンバレーの新たな見せびらかし消費として知られる「tokenmaxxing(トークン最大化)」を象徴するもので、トークン使用量が生産性の基準となり、誰が最もAIネイティブ(AI native)かを競う指標となっています。従業員たちはプロンプト(prompt)、コーディングセッション、並列で動作するエージェントの数を最大化し、Metaや他の企業での社内ランキングを上位に上げることで、コーディングなどの機能をAIが自動化する中で自らの価値を示そうとしています。」
私はMetaのエンジニア数名に現状について話を聞きました。彼らの意見は以下の通りです:
莫大な浪費。多くの開発者がOpenClawに似た社内エージェントを稼働させており、ほとんど成果がないにもかかわらず莫大なトークン(token)を消費しています。
AIの過剰使用によるシステム障害。ある開発者は、一部のSEV(Severity)が不注意なAIによるコード生成に起因していたと明かしました。まるでSEVを担当した開発者が、製品の品質よりもAIを使って大量のコードを生成することに重点を置いていたかのようでした。
ゲーム化されたリーダーボード。ランキング上位者は、使い捨てで無駄な作業を生み出しています。閲覧可能なTrajectories(AIプロンプト)を確認する誰にとっても、これは明白です。
The Informationによると、Metaの従業員は30日間で合計60.2兆個のAIトークン(!!)を使用しました。これがAnthropicのAPI価格で課金されたら9億ドルになります。もちろんMetaは割引で購入している可能性が高いですが、それでも1億ドル以上になるでしょう—その大部分が無意味な「tokenmaxxing(トークン最大化)」に起因しています。
ソーシャルメディア上での反発を受け、Metaは先週社内リーダーボードを廃止しました。The Informationが驚くべきtokenmaxxing(トークン最大化)の数字の詳細を公開した翌日、Metaがリーダーボードを削除したことを確認しました。おそらく彼らは、このインセンティブが莫大で不要な浪費を生み出していることに気づいたのでしょう。もしそうなら、ソーシャルメディアの巨人がその結論に達するのにメディア報道を待たなければならなかったことは少し驚きです。
メタのエンジニアの一人は、メタがトークンリーダーボード(token leaderboard)に対して異なる目的を持っていたと考えていると私に語った。長年の勤務経験を持つエンジニアは、実際にはAIの使用量を増やすことが真の目的だったと疑っている。彼らはこう語った:
「リーダーボードを導入することは、常にAIの使用を大幅に促進するインセンティブを生み出すことにつながっていた。そして、AI使用量の増加は、より多くの実世界のトレース(real-world traces)の生成を意味する。これらのトレースはその後、メタの次世代コーディングモデル(next-generation coding model)の学習により良く使用できる。
誰も口に出さなかっただろうが、これが目的だったと信じている。
これは学習用データを生成するための高価な方法ではあるが、それを行う手段を持つ会社がもしいるなら、それはメタだ。」
Microsoft: full-force tokenmaxxing
同様に、Microsoftも1月以来、メタのような内部トークンリーダーボード(token leaderboard)を導入しており、当初は順調に始まったと私が当時報告した通りだ:トークンの使用量が最も多い個人を表示する内部トークンダッシュボードがあり、これによりトークンの利用と大規模言語モデル(LLMs)の実験を促進している。Windowsメーカーである同社では、このリーダーボードは興味深い結果を示している:
過去にほとんどコードを書かなかったこのグループにもかかわらず、非常にシニアなエンジニア――ディスティングイッシュドレベルの社員(distinguished-level folks)――が会社全体のトップ5に入っている。
上級副社長クラス(VP-level folks)の社員は、1日中会議に出ることが多く、ほとんどコードを書かないにもかかわらず、トップ10およびトップ20に入っている。
しかし、パフォーマンスレビュー(performance reviews)や昇進のための指標として始まったものが、すぐに開発者の目標となる可能性がある。Windowsメーカーのソフトウェアエンジニアに話を聞いたところ、彼らは「tokenmaxxing(トークン最大化)」を全開で行っていると認めた。リーダーボードに乗るためではなく、むしろトークンの使用量が少なすぎると見なされるのを避けたいからだ:
「社内ダッシュボードと指標で、AI使用量、トークン使用量、AIが書いたコードの割合 versus 手書きコードの割合を追跡している。
「AIの使用が少なすぎる」と見なされたくないという意識があり、それを達成するためにtokenmaxxingを行う必要があることを恥じる必要はない。トークン使用量の数値を水増しするために私が行っていること:ドキュメントに含まれている既存のコードについてAIに質問する。AIはドキュメントを呼び出し、処理し、結果を返すのだが、10倍の時間がかかる代わりに大量のトークンを消費する。「readthedocs」(社内製品)を使えばよいが、そうするとトークン数が低くなってしまう。AIに、実装するつもりがない機能のプロトタイプ作成を依頼する。プロンプトを数回追加して、そのまま破棄する。手書きで作業した方がはるかに速いと知りつつも、エージェント(agent)の使用を常にデフォルトにする。その後、失敗するのを見守る」
このエンジニアは会社に入社して比較的新しいため、雇用の安定を気にしており、必要な遥かに上回るトークンを消費することで、「AIネイティブ(AI-native)」度が不十分とラベル付けされるのを避けるために、このゲームに参加している。
Salesforce: burning tokens to hit “minimum” & “ideal” targets
一方、Salesforceも「tokenmaxxing(トークン最大化)」のインセンティブを作成している。同社のエンジニアに話を聞いたところ、同社がトークンの過剰な消費を効果的に促す2つのツールを開発したことが分かった:
追跡ツールによる「最低限」のインセンティブ。Macウィジェット(Mac widget)があり、自分の使用量を15分ごとに更新して表示する。また、最低限の予想使用量も表示される。先週、Claude Codeでの目標は100ドル、Cursorでは70ドルだった。
全員の使用量を表示。チームメイトのどこまで使用しているかを確認するために使われる、任意の同僚のトークン使用量(token spend)を見られるWebベースのツール。
超えられる「最大」使用量制限。先週まで、Claude Codeの月間上限は250ドル、Cursorは170ドルだった。ただし、この制限に達してもボタンを一つ押すだけで上限を超過できる。先週、Salesforceの一部エンジニア組織が開発プロセスから「摩擦を完全に取り除く」ために、「最大」制限を撤去したことを知った。
Salesforceが社員に送るメッセージは明確だ。「月170ドル分のトークンを最低限使用せよ、さもなくばフラグ(flagged)される」。少ないトークン使用でフラグを立てられる者など誰がいるだろうか?その結果、多少無駄なトークン使用量となる:
何の役にも立たないトークンの消費。開発者はClaudeやCursorに「Xを構築して」と依頼する。ここで言うXは、彼らの業務とは無関係なプロジェクトやプロダクトであり、決してリリースするものではない。単にトークンを消費する方法に過ぎない。
平均を上回るようトークン使用量を調整する。多くの開発者が同僚の使用量を確認し、平均を少し上回るポイントを見極めた後、その目標に達するために必要なトークンを使用する。
Shopify:トークンマキシミング(tokenmaxxing)を避けるための事例
私が知る限り、初めてトークンリーダーボード(token leaderboard)を構築したのは2025年のShopifyだ。そしてそれはうまく機能した!昨年6月、Shopifyのエンジニアリング責任者であるFarhan Thawarは『The Pragmatic Engineer Podcast』で私にこう語った:
「私たちはリーダーボードを持っており、最も多くのトークンを使用する人々を積極的に称賛しています。これは、AIを活用して素晴らしい成果を上げている場合に、彼らが確実に[称賛される]ようにするためです。
[そしてリーダーボードの上位者については]、例えばCursorに月1,000ドル分のクレジットを使用する理由を見てみたい。おそらく、素晴らしいものを構築中であり、その下にエージェントチーム(agent workforce)を擁しているからでしょう!」
Farhanにそれ以降の状況について詳細を尋ねた。彼からの回答は以下の通りだ:
「その後、明らかな理由からトークンリーダーボードを使用量ダッシュボード(usage dashboard)に名称を変更した。このボードの上位を目指すような「競争」を促したくないからだ。内部Wikiプロフィールと使用量ダッシュボードの両方にトークン使用量を記載している。
また、「暴走するエージェント(runaway agents)」を検知するためのサーキットブレーカー(circuit breakers)も導入している。そのため、個人の使用量が1日以内に急増した場合、すぐにアクセスを停止できる。その使用量急増が意図的なものであれば、あるいは暴走エージェントによるものであれば、アクセスを再許可する。サーキットブレーカーは我々にとってうまく機能している:暴走エージェントを検知しただけでなく、この方法でインフラ(infra)のバグも発見できた!」
Shopifyのアプローチが成功した理由はいくつかある:
初期段階において、使用量ダッシュボードは開発者にAIツールを使用するよう促す「押し(push)」の役割を果たした。昨年、開発者は主にAIツールの実験を行っていたが、それは当時のパフォーマンスが今日ほど高くなかったためだ。使用量ダッシュボードは開発者に新ツールの試行を促し、パワーユーザー(power users)を浮き彫りにした。
サーキットブレーカー(circuit breaker)が役立ちました。使用量が急増した際に支出を停止することで、「暴走するエージェント(runaway agents)」を検出できました。
高使用率も監視対象となっています。Farhanは高額利用者の個別ヒアリングを行い、ユースケースを把握しています。もしtokenmaxxing(トークン最大化行為)が行われていたとしても、おそらくこの段階で発見されていたでしょう。そうなればユーザー側としては少し恥ずかしい話ですね!
Farhanから共有されたもう1つの興味深い知見があります。「トークンコスト(token cost)の総額で最も多く支出したのは誰か?」を見るのではなく、「どのユーザーの生成したトークンが高額だったか?」を見る方が興味深いということです。高額なトークンを生成した開発者たちは、実際には学び甲斐のある詳細な作業を行っていたことが判明しました!
トークン最大化行為(tokenmaxxing):AIベンダーには有利だが、他者には不利益
どの企業にとってもtokenmaxxing(トークン最大化行為)をインセンティブとして設定することに合理的な理由がほとんど見当たりません。それは、ほとんどあるいは全く価値をもたらさないのに、AI支出(AI spend)を大幅に増大させる結果になります。ひどい場合では、実際により遅い作業を促すことさえあります。例えば、ドキュメントがすぐに入手できる状況で開発者が質問に答えるためにAIを使用するケースや、リリースしたくないプロジェクトのプロンプトを作成させる「忙しさ偽装(busywork)」を助長するケースなどです。tokenmaxxingは、開発者をビジネスに何の影響も与えない作業に集中させる方向に押しやるようです。
業界の多くの部分が、数年前に「生成されたコード行数(lines-of-code-produced)」指標が使われていたのと同様に、トークン数を扱っているように感じます。かつては1日または1ヶ月に書かれた行数がプログラマの生産性において重要な指標でしたが、これに焦点を当てるのは極めて不適切であることが明確になるまでには時間がかかりませんでした。コード行数指標は、定型文(boilerplate)や捨てコード(throwaway code)を書くことで簡単に操作できます。また、最高の開発者とは必ずしも最も多くのコードを書く人ではなく、ビジネス上の難しい問題を迅速かつ確実に解決する(コードを使う場合も使わない場合もある)人々です!
同様に、開発者が生成するトークン数も簡単に操作可能であり、この指標が測定される場合、開発者は実際にそれを操作するでしょう。しかし、それを行うと莫大なAI請求書が伴います!
—-
先週号『The Pulse』の全文をお読みいただくか、今週号をチェックしてください。今週号でカバーしている内容は以下の通りです:
新トレンド:トークン支出(token spend)が予算を超過 – 次の一手は?過去2〜3ヶ月で、多くのテック企業におけるAIエージェント(AI agents)への支出が爆発的に増加しており、その影響についてエンジニアリングリーダーたちの認識が始まっています。この認識に対処するさまざまな方法を含め、15社から詳細情報を収集しました。
新トレンド:多くのAIベンダーが需要に対応しきれない。支出の大幅な増加に伴い、GitHub CopilotとAnthropicは収益性の低い個人ユーザーの利用を制限し始め、その分、過去数ヶ月で支出が10倍以上に増えたビジネスユーザーへの対応を優先しています。例外はOpenAIとCodexです。
Metaでの社気は過去最低水準に?ビジネスは好調だが、Metaの開発者たちは近接するレイオフの懸念と全米従業員への展開された侵入性の高い追跡プログラムにより、怒りと不安でいっぱいです。
原文を表示
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week’s The Pulse issue. Full subscribers received the article below seven days ago. If you’ve been forwarded this email, you can subscribe here.
Inside Meta, an engineer created a “token leaderboard” that ranks employees by token usage. Last week, The Information reported:
“Employees at Meta Platforms who want to show off their AI superuser chops are competing on an internal leaderboard for status as a “Session Immortal”— or, even better, “Token Legend.”
The rankings, set up by a Meta employee on its intranet using company data, measure how many tokens — the units of data processed by AI models — employees are burning through. Dubbed “Claudeonomics” after the flagship product of AI startup Anthropic, the leaderboard aggregates AI usage from more than 85,000 Meta employees, listing the top 250 power users.
The practice is emblematic of Silicon Valley’s newest form of conspicuous consumption, known as “tokenmaxxing,” which has turned token usage into a benchmark for productivity and a competitive measure of who is most AI native. Workers are maximizing their prompts, coding sessions and the number of agents working in parallel to climb internal rankings at Meta and other companies and demonstrate their value as AI automates functions such as coding.”
I spoke with a few engineers at Meta about what’s happening, and this is what they said:
Massive waste. Plenty of devs are running an OpenClaw-like internal agent that burns massive amounts of tokens for little to no outcome.
Outages caused by AI overuse. A dev mentioned that some SEVs were caused by what looked like careless AI code generation; almost like a dev behind the SEV was more concerned with churning out massive amounts of code with AI than with product quality.
Gamified leaderboard. Those at the top of the leaderboard produce throwaway, wasteful work. This is painfully clear to anyone who checks Trajectories (AI prompts), which can be viewed.
As per The Information, Meta employees used a total of 60.2 trillion AI tokens (!!) in 30 days. If this was charged at Anthropic’s API prices, it would cost $900M. Of course, Meta is likely purchasing tokens at a discount, but that could still come in at $100M+ – in large part from senseless “tokenmaxxing”.
After backlash on social media, Meta abolished the internal leaderboard last week. One day after The Information revealed details about the incredible tokenmaxxing numbers, I confirmed that Meta has taken down its leaderboard; perhaps they realized that the incentive created enormous and unnecessary waste. If so, it’s a bit surprising that it took media coverage for the social media giant to reach that conclusion.
One engineer at Meta told me they think Meta had a different goal with the token leaderboard. A long-tenured engineer suspects increasing AI usage actually was the real goal. They said:
“Putting a leaderboard in place was always going to incentivize much more AI usage. And more AI usage means producing a lot more real-world traces. These traces can then be used to train Meta’s next-generation coding model better.
I believe this was the goal, even if no one said it out loud.
It’s an expensive way to generate data for training, but if any company has the means to do so, it’s Meta.”
Microsoft: full-force tokenmaxxing
Similarly, Microsoft has had an internal token leaderboard like Meta’s since January, and it started pretty well, as I reported back at the time: there’s an internal token dashboard that displays the individuals who use the most tokens in order to promote the use of tokens and experimentation with LLMs. At the Windows maker, this leaderboard is interesting:
Very senior engineers – distinguished-level folks – are in the top 5 across the whole company, despite the fact that this group generally wrote little code in the past.
VP-level folks make the top 10 and top 20, despite often being in meetings for most of the day and rarely writing code.
However, what starts as a metric for performance reviews or promotions can quickly become a target for devs. I talked with a software engineer at the Windows maker who admitted they’re full-on “tokenmaxxing” – not to get on the leaderboard, but rather because they don’t want to be seen as using too few tokens:
“We have internal dashboards and metrics tracking AI usage, token usage, percentage of code written by AI vs hand-written code.
I am conscious of not wanting to be seen as “uses too little AI,” and I’m not ashamed to say I need to do tokenmaxxing to do this. Things I do to inflate my token usage metrics:Ask AI questions about the code already in the documentation. The AI pulls up the documentation, processes it, and gives me results 10x slower, but while burning lots of tokens. I could use “readthedocs” [an internal product], but then my token numbers would be lowerAsk the AI to prototype a feature that I have no intention of working on. Prompt it a few more times, then throw the whole thing awayDefault to always using the agent, even when I know I could do the work by hand much faster. Then watch it fail”
This engineer is relatively new at the company, so is concerned about job security, and is playing this game to avoid being tagged as insufficiently “AI-native” by burning far more tokens than necessary.
Salesforce: burning tokens to hit “minimum” & “ideal” targets
Elsewhere, Salesforce has created “tokenmaxxing” incentives, as well. Talking with an engineer there, I learned that the company built two tools that effectively incentivize excessive spending on tokens:
“Minimum” incentives with a tracking tool. There’s a Mac widget that shows your own spend, updated every 15 minutes. It also displays minimum expected spend. Last week, the target was $100 on Claude Code, and $70 on Cursor.
Showing everyone’s spend. A web-based tool to see the token spend of any colleague. It’s used to check where team mates’ usage is at.
“Maximum” spend limits that can be exceeded. Up to a week ago, there was also a maximum monthly limit of $250 for Claude Code and $170 for Cursor. However, this can be exceeded with the simple press of a button if the limit is reached. I’ve learned that last week, some engineering organisations at Salesforce had their “maximum” limit removed in order to “remove any friction from the development process.”
The message Salesforce sends to staff is clear: “use a minimum of $170/month tokens or be flagged.” Who wants to get flagged for using too few tokens? The outcome is somewhat wasteful token spend:
Burning tokens for nothing. Devs ask Claude or Cursor: “build me X,” where X is a project or product with nothing to do with their work, and not something they’d ever ship. It’s just a way to burn tokens
Calibrating token spend to be above average. Plenty of devs browse peers’ token spend to figure out the slightly-above average point, then use the tokens needed to hit that mark
Shopify: an example on how to avoid tokenmaxxing
The first-ever token leaderboard that I’m aware of was built by Shopify in 2025. And it worked well! Last June, the Head of Engineering at Shopify, Farhan Thawar, told me on The Pragmatic Engineer Podcast:
“We have a leaderboard where we actively celebrate the people who use the most tokens because we want to make sure they are [celebrated] if they’re doing great work with AI.
[And for the top people on the leaderboard,] I want to see why they spent say $1,000 a month in credits for Cursor. Maybe that’s because they’re building something great and they have an agent workforce underneath them!”
I asked Farhan for details on how it’s gone since. Here’s what he told me:
“We have since renamed the token leaderboard to usage dashboard: for obvious reasons, as we don’t want to encourage “competing” to make it to the top of this board. We have token spend on our internal wiki profile as well as on the usage dashboard.
We also have circuit breakers to catch “runaway agents.” So if personal spend spikes within a day, we can cut off access immediately, and you can renew if the usage spike was deliberate, or if it was a runaway agent. The circuit breaker worked well for us: we’ve not only caught runaway agents, but found bugs in our infra this way!”
Shopify’s approach seems to have worked for a few reasons:
The usage dashboard served as a “push” for devs to use AI tools, early-on. Last year, devs were mostly experimenting with AI tools because they were not as performant as today. The usage dashboard encouraged developers to try new tools, and highlighted power users.
Circuit breakers helped. Cutting off spend when usage spikes helped catch “runaway agents.”
High usage is looked at. Farhan checks-in with top-spending individuals to understand the use cases. Any tokenmaxxing would likely have been spotted at this stage, which would have been a bit embarrassing for the user!
One more interesting learning Farhan shared with me: it’s more interesting to not look at “who spent the most in overall token cost?” but instead, “whose tokens cost the most?” Devs who generate tokens that come out as expensive have turned out to do in-depth work that was interesting to learn about!
Tokenmaxxing: great for AI vendors, bad for everyone else
I see very few rational reasons why incentivizing tokenmaxxing makes sense for any company. It results in increasing AI spend – by a lot! – in return for little to no value. Heck, in some cases it actually incentivises slower work – as shown by devs using the AI to answer questions when documentation is readily available – and encouraging ‘busywork’ where devs prompt projects that they don’t even want to ship. Tokenmaxxing seems to push devs to focus on stuff that makes no difference to a business.
It feels to me that a good part of the industry is using token count numbers similarly to how the lines-of-code-produced metric was used years ago. There was a time when the number of lines written daily or monthly was an important metric in programmer productivity, until it became clear that it’s a terrible thing to focus on. A lines-of-code metric can easily be gamed by writing boilerplate or throwaway code. Also, the best developers are not necessarily those who write the most code; they’re the ones who solve hard problems for the business quickly and reliably with – or without – code!
Similarly, the number of tokens a dev generates can easily be gamed, and if this metric is measured then devs will indeed game it. But doing so generates a massive accompanying AI bill!
—-
Read the full issue of last week’s The Pulse, or check out this week’s The Pulse. This week’s issue covers:
New trend: token spend breaks budgets – what next? In the past 2-3 months, spending on AI agents has exploded at many tech companies, and the ramifications of this are starting to dawn on engineering leaders. We’ve sourced details from 15 companies, including the different ways they are coping with this realization.
New trend: more AI vendors can’t keep up with demand. Related to massively increased spending, GitHub Copilot and Anthropic are starting to limit less-profitable individual users, so they can serve business users whose spend has easily 10x’d in the last few months. The exception is OpenAI and Codex.
Morale at Meta hits all-time low? Business is booming but devs at Meta are furious and worried due to looming layoffs, and an invasive tracking program rolled out to all US employees.
関連記事
フォーブスが8人の子供殺害銃乱射事件の報道を予測市場ゲーム化する
フォーブスは銃乱射事件の報道記事に、国会の銃規制動向を予測するボックスを設置し、読者に投票を促した。
The Pulse:フォワード・デプロイエンジニアの需要が再び高まる
ゲルゲー氏が、大手テック企業やスタートアップにおけるシニアエンジニアの視点から、先月取り上げられたフォワード・デプロイエンジニア(FDE)への急激な需要の高まりについて解説している。
Google Cloud、豪州の取引ファンドのインフラを削除
Google Cloud は豪州の1240億ドル規模のファンドからデータを誤って削除したが、サードパーティ製のバックアップにより被害は免れた。同社CEOが責任を認め、地域複製機能でも削除を防げなかったことを認めた。