Cursorは開発者の効率を低下させるのか？
非営利団体METRの研究によると、CursorなどのAIツールを使用した開発者は、ツールを使用しない場合よりも作業完了までに19%長く時間がかかり、生産性向上に関する開発者の楽観的な期待と現実にギャップがあることが明らかになった。
キーポイント
AIツールによる生産性の逆説的低下
METRの研究では、CursorなどのAIツールを使用した開発者は、ツールを使用しない場合よりも作業完了までに19%長く時間がかかった。
期待と現実の大きなギャップ
開発者はAIが生産性を24%向上させると期待していたが、実際には遅くなった後でも20%向上したと誤って認識しており、認識と現実の乖離が顕著である。
時間配分の変化
AIツール使用時はコーディング、調査、テストに費やす時間は短縮されたが、AIの出力確認、待機時間、IDEオーバーヘッドなどに時間を取られ、全体の作業時間が増加した。
研究手法の重要性
専門家や開発者の予測やアンケートだけに頼らず、実作業を記録・分析するフィールド実験と堅牢な成果測定の重要性が示唆されている。
学習曲線の影響
AI開発ツールの学習曲線が高く、既存のワークフローに組み込むと習得期間中は生産性が低下する可能性がある。
経験による認識の違い
AIツールを6ヶ月以上使用していないエンジニアは否定的な見解を持つ傾向が強く、短期的な使用では期待に応えられないと感じやすい。
LLMの能力の偏り
LLMのコーディング能力はデータの量や評価方法によって大きく偏りがあり、低レベルシステムコードなど特定分野では性能が低い。
影響分析・編集コメントを表示
影響分析
この研究は、AIツールが開発者の生産性を必ずしも向上させるとは限らないという逆説的な結果を示し、業界の楽観的な期待に一石を投じる。AIツールの導入効果を過信せず、実証データに基づいた評価と、ツール使用に伴う新たなオーバーヘッド（レビュー、待機時間など）の管理が今後の課題となる。
編集コメント
AIツールの「使えば速くなる」という直感的な期待を、実証データで冷静に検証した貴重な研究。ツール導入の効果測定と、開発者自身の認識バイアスへの気づきを促す内容。
こんにちは、Pragmatic Engineer Newsletter の特別無料号をお届けするゲルゲーです。毎号、シニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップについて取り上げています。今回は先週の「The Pulse」号で扱った4つのトピックのうち1つを取り上げます。この記事を7日前にフルサブスクライバーにお送りしました。このような記事を毎週あなたのメールボックスにお届けするには、こちらから購読してください。
多くの購読者が、このニュースレターを学習・開発予算として経費処理しています。そのような予算をお持ちの場合は、上司に送れるメールの例をご紹介します。
非営利団体「Model Evaluation and Threat Research (METR)」が興味深い研究を発表しました。この研究では、大規模なオープンソースリポジトリで作業した経験豊富な開発者 16 名を募集し、実在する 136 の課題を修正させる実験を行いました。報酬は時間あたり 150 ドルです。一部の開発者には AI ツールの使用が割り当てられ、他の開発者には割り当てられませんでした。研究では開発者の画面を記録し、その後 146 時間にわたる映像を検証・分析しました。
その結論は以下の通りです：
「驚くべきことに、開発者が AI ツールを使用すると、使用しない場合に比べて所要時間が 19% 長くなることが分かりました。AI は彼らを遅くするのです。(…) この認識と現実の間のギャップは際立っています。開発者は AI が自身の作業速度を 24% 向上させると予想していましたが、実際に速度低下を経験した後でも、なお AI が 20% の加速をもたらしたと信じていました。」
この結果は非常に驚くべきものです！しかし、何が起きているのでしょうか。研究論文を注意深く見てみましょう：
この研究は、Cursor が開発者の生産性に与える影響についてのものである。参加者のほぼ全員が選択した AI ツールは Cursor であり、Sonnet 3.5 または 3.7 を使用していた。開発者のうち 44% はこれまで Cursor を一度も使ったことがなく、残りの多くも最大で 50 時間程度しか利用経験がない。
AI を活用したグループは、作業完了のためにコーディングに要する時間は短縮されたものの、全体としてはより多くの時間を要した。また、調査やテストに費やす時間も減少していた。しかし、AI の待機、その出力のレビュー、「IDE オーバーヘッド」、およびプロモーションには、AI を使用しないグループよりも長い時間がかかっていた。最終的に、この研究では、AI に費やされた追加時間が、コーディング・調査・テストで節約された時間を相殺してしまったことが明らかになった。
この発見は Cursor に限らず、すべての AI ツールに当てはまることを指摘しておく必要があります。本調査では単に Cursor が選ばれただけのことです。
imageAI を利用することでコーディングにかける時間は短縮されましたが、全体としては作業に要する時間が長くなりました。出典：METR 開発者は AI の生産性への影響について、少なくとも初期段階では楽観的な見積もりをしがちです。調査より:
「専門家も開発者も、ツールを何時間も使用した後も、AI が開発者の生産性に与える有用性を過大評価しています。これは、専門家の予測や開発者へのアンケートに頼るだけでなく、堅牢な成果指標を用いた現場実験を行うことの重要性を浮き彫りにするものです。」
Cursor を 50 時間以上使用した一人の開発者は、著しい速度向上を実感しました！この研究では、過去に Cursor を合計 50 時間以上使用した開発者が一人だけ含まれていました。その開発者は、非常に印象的な 38% の速度向上を達成しています。しかしながら、サンプルサイズが一人だけでは、16 人のグループ全体を代表するものとしてはあまり適切ではありません：
imageCursor で 50 時間以上の経験を持つ一人の開発者が、はるかに速く作業を完了しました。出典：METR
ソフトウェアエンジニアのサイモン・ウィリソン氏（私は彼を AI 開発ツールに関する中立的な専門家とみなしています）はこの調査結果を以下のように解釈しています：
「私の直感では、この研究は主に、AI 支援開発の学習曲線が十分に急峻であることを示していると考えられます。つまり、既存のワークフローにそれを組み込むよう開発者に求めることは、その学習曲線を登っている間、彼らのパフォーマンスを低下させることになるのです。」
確かに、彼は『Pragmatic Engineer』ポッドキャストのエピソードでも同様の指摘を行っています：「習得し、探索し、実験し、使い方を学ぶために、非常に多くの努力を払わなければなりません。そして、何のガイダンスもありません。」
本誌が実施した AI ツールに関する研究（約 200 人のソフトウェアエンジニアからの入力に基づく）でも、これを裏付ける証拠が見つかりました：AI ツールを 6 ヶ月以上使用していない開発者は、それらに対して否定的な認識を持つ傾向が強かったのです。AI ツールを使用しなかったエンジニアから非常に頻繁に寄せられたフィードバックは、「試してみたが期待に応えなかったのでやめた」というものでした。
非 AI デベロッパーと比較して 38% の「速度向上」を報告したエンジニアは、興味深い見解を持っています。Cursor を 50 時間以上使用しているこの一人のエンジニアは、博士課程学生であるクエンティン・アンソニー氏です。彼がこの研究について語ること、そして AI ツールがデベロッパーの効率にどう影響するかを以下に示します：
「1. AI による速度向上は、誰かのデベロッパーとしての能力と非常に弱い相関しかありません。この研究に参加したすべてのデベロッパーは非常に優秀です。私はむしろ、LLM（大規模言語モデル）の能力における失敗モードや、人間のワークフローにおける失敗モードに陥っていることの方が関係していると思います。私は素晴らしい事前学習済みデベロッパーたちと多く働いていますが、人々は多くの同じ問題に直面していると信じています。
私たちは LLM をツールだと言いたがりますが、実際にはそれを魔法の弾丸のように扱っています。
実際に、難解な問題を最後にデバッグした時の満足感を、どのデベロッパーも証明できるでしょう。LLM は、一度であなたの問題を一挙に解決する可能性のある大きなドーパミンのショートカットボタンです。すべてを 1% の確率で修正するボタンを押し続けますか？少なくとも私にとっては、その過酷な代替手段よりもはるかに楽しいものです。
- 今日の LLM は、能力分布が非常にスパイク状（偏在）しています。これは主に以下の要因によるものだと考えられます：どのようなコーディングタスクに対して大量のクリーンなデータがあるか、そして成功を測定するために LLM 研究所が使用しているベンチマークや評価指標です。
例として、LLM は低レベルシステムコード（GPU カーネル、並列処理/通信など）においてすべてひどく苦手です。これは、そのコードデータが相対的に稀であり、モデルの能力を評価することが難しいからです（この点についてはここでより詳しく議論しています）。
これらのタスクは、プリトレーニング開発者としての私の業務の大きな部分を占めているため、LLM が対応可能な部分（テスト作成、見慣れないコードの理解など）とそうでない部分（カーネル作成、通信同期セマンティクスの理解など）を把握しています。私は、LLM が確実にタスクを処理できると確信できる場合のみそれを使用します。
新しいタスクが LLM に対応可能かどうかを判断する際、私は LLM との作業に時間を過度に費やしてしまわないよう、積極的にタイムボックスを設定するように心がけています。"もうすぐ完成しそう！"という瞬間から LLM から離れるのは難しいものです！
- LLM が生成を行っている間の待ち時間に気が散りやすいことです。ソーシャルメディアの注目を集めるための経済競争は過酷であり、人々は 30 秒程度の生成を"待っている間"に 30 分もスクロールしているのだと思います。
これについては一言だけ言えるのは、私たちは自分自身の落とし穴を知り、LLM の生成時間を生産的に活用するよう努めるべきだということです。もしタスクが高集中力を必要とするものであれば、この時間はサブタスクに取り組むか、次の質問について考える時間に充ててください。モデルが私の質問にワンショットで回答したとしても、まだ理解できていないことは何があるでしょうか？もしタスクが低集中力で済むものであれば、その間に別の小さなタスク（メールや Slack の返信、他の段落の読書や編集など）を行ってください。
いつも通り、デジタル衛生に関する小さなステップ（ウェブサイトブロッカー、電話を DND モードにするなど）がこれに役立ちます。おじさんくさいようですが、私には効果があります :)"
クエンティンは結論としてこう述べています：
「LLM はツールであり、その落とし穴を学び始め、自己認識を持つ必要があります。アンドレイ・カルパティ氏の講演が多くの人の支持を得ている大きな理由は、彼が非常に内省的な LLM ユーザーであるからです。これは、一部のモデルの事前トレーニング（pretraining）に関与したことで、やや早く到達した結果です。
この新しいツールをうまく使いこなすためには、その欠点（そして私たち自身の欠点！）を理解し、それらに適応する必要があります。」
AI コーディングツールの弱点が「コンテキストスイッチ」になるのではないかと思っています。開発者として最も生産的な作業ができるのは、「ゾーン」に入っている時です。問題に没頭し、一切の気晴らしがない状態で、仕事に集中している時です。一度その状態から外れた後、再びゾーンに戻るのにどれほどコストがかかるかを知っています。
しかし、時間節約型の AI コーディングツールを使用している間は、その「ゾーン」にいることはできません。コードが生成されている間に別のことをしなければならないため、コンテキストスイッチ（context switch）を強制的に行わなければならず、それぞれが私の速度を遅らせます。それは気晴らしです。
もしコードを書く際の「ゾーン」にいるという制約が、バグではなく機能であるとしたらどうでしょうか？また、AI ツールを使用しない経験豊富な開発者が、意識的に「ゾーン」に留まり、より集中することで、AI を使用する他の人々よりも優れた成果を出しているとしたらどうでしょうか？AI ツールによって繰り返されるコンテキストスイッチを強いられている開発者よりも、AI ツールを使用していない人々が「ゾーン」にいて、より高いパフォーマンスレベルで作業していた可能性はないでしょうか？
ソフトウェア構築において、コーディングに要する時間が節約されたからといって、自動的に生産性が向上するわけではないという点について、考えるべきことがここにあります。
これは先週の『The Pulse』から取り上げられた4つのトピックのうちの一つです。今回の完全版では以下も扱っています:
業界の動向。1.1.1.1 が1時間ダウンした理由、マイクロソフトがより多くの GPU を購入するために人員削減を行った件、メタの驚異的な AI データセンターへの支出、そして北朝鮮からの偽物の求職者という「業界全体の問題」について。
Windsurf の売却：OpenAI、Microsoft、Google、Cognition による複雑な物語。OpenAI は Windsurf を買収したかったが、マイクロソフトの存在により実現しなかった。その後 Google が Windsurf の創設者とコアチームを雇用し、Devin の開発元である Cognition が残りの会社を買収しました。これはカリフォルニア州でなければ起こり得ない奇妙な物語です——非競争条項禁止法があるおかげで。
VC（ベンチャーキャピタル）に依存したトークンの終焉の始まり？Cursor は、その「無制限」プランに対して制限を黙って課すことで開発者を怒らせました。私たち開発者は、LLM（大規模言語モデル）の利用コストが高騰しており、VC からの資金がトークンの実質的なコストを補助し続けることはおそらくないという現実に向き合わされています。
今週の『The Pulse』誌（フルサブスクライバー向けに配信）では以下を取り上げています:
6月10日の障害の原因に関する謎が解明されました。Heroku は Ubuntu Linux 上の systemd プロセスの更新により1日間ダウンしました。実は OpenAI、Zapier、GitLab など数十社も同様の影響を受け、最大6時間にわたる障害が発生していました。
Replit AI が本番環境を秘密裡に削除 – おっと！バイブコーディングアプリがまだ本番対応していない理由の教訓から、ソフトウェアエンジニアリングの専門知識を伴わずに出荷される本番耐性のあるアプリを予測することがいかに困難かが浮き彫りになる。
業界の動向。Windsurf の売却に関する最新詳細、Zed エディタがすべての AI 機能をオフにできる機能の実装、Microsoft SharePoint を使用している政府機関がハッキングされた件、GitHub がバイブコーディングツールをリリースした件など。
OpenAI で過ごした1年への考察。ソフトウェアエンジニアの Calvin French-Owen は OpenAI に対する自身の印象をまとめ、同社が Slack と Azure で運営されている様子、OpenAI Codex のローンチにおけるキャパシティプランニングの課題、大規模な Python コードベースでの作業から得た教訓などについて語っている。
The Pulse の各号はこちらで読むことができる。
原文を表示
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 below article seven days ago. To get articles like this in your inbox, every week, subscribe here.
Many subscribers expense this newsletter to their learning and development budget. If you have such a budget, here’s an email you could send to your manager.
An interesting study has been published by the nonprofit org, Model Evaluation and Threat Research (METR). They recruited 16 experienced developers who worked on large open source repositories, to fix 136 real issues, for pay of $150/hour. Some devs were assigned AI tools to use, and others were not. The study recorded devs’ screens, and then examined and analyzed 146 hours of footage. The takeaway:
“Surprisingly, we find that when developers use AI tools, they take 19% longer than without. AI makes them slower. (...) This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.”
This result is very surprising! But what is going on? Looking closely at the research paper:
The research is about Cursor’s impact on developer productivity. The AI tool of choice for pretty much all participants was Cursor, using Sonnet 3.5 or 3.7. A total of 44% of developers had never used Cursor before, and most others had used it for up to 50 hours.
Those using AI spent less time on coding to complete the work – but took more time, overall. They also spent less time on researching and testing. But they took longer on promoting, waiting on the AI, reviewing its output, and on “IDE overhead”, than those not using AI. In the end, additional time spent with the AI wiped out the time it saved on coding, research, and testing, the study found.
It’s worth pointing out that this finding applies to all AI tools, and not only to Cursor, which just happens to be the tool chosen for this study.
imageUsing AI meant less time spent coding, but the work took longer, overall. Source: METRDevelopers are over optimistic in their estimates about AI’s productivity impact – initially, at least. From the survey:
“Both experts and developers drastically overestimate the usefulness of AI on developer productivity, even after they have spent many hours using the tools. This underscores the importance of conducting field experiments with robust outcome measures, compared to relying solely on expert forecasts or developer surveys.”
The one dev who had used Cursor for 50+ hours saw a lot of speedup! In the study, there was a single developer who had used Cursor for a total of more than 50 hours, previously. This dev saw a very impressive 38% increase in speed. Then again, a sample size of one is not very representative of a group of 16:
imageOne developer with 50+ hours of experience on Cursor completed work much faster. Source: METRSoftware engineer Simon Willison – whom I consider an unbiased expert on AI dev tools – interprets the survey like this:
“My intuition here is that this study mainly demonstrated that the learning curve of AI-assisted development is high enough that asking developers to bake it into their existing workflows reduces their performance while they climb that learning curve.”
Indeed, he made a similar point on an episode of the Pragmatic Engineer podcast: “you have to put in so much effort to learn, to explore and experiment, and learn how to use it. And there's no guidance.”
In research on AI tools by this publication, based on input from circa 200 software engineers, we found supporting evidence of that: those who hadn’t used AI tools for longer than 6 months were more likely to have a negative perception of them. Very common feedback from engineers who didn’t use AI tooling was that they’d tried it, but it didn’t meet expectations, so they stopped.
The engineer who saw a 38% “speed-up” versus non-AI devs has an interesting take. That lone engineer with 50+ hours of Cursor experience is PhD student, Quentin Anthony. Here’s what he says about the study, and how AI tools impact developer efficiency:
“1. AI speedup is very weakly correlated to anyone's ability as a dev. All the devs in this study are very good. I think it has more to do with falling into failure modes, both in the LLM's ability and the human's workflow. I work with a ton of amazing pretraining devs, and I think people face many of the same problems.
We like to say that LLMs are tools, but treat them more like a magic bullet.
Literally any dev can attest to the satisfaction of finally debugging a thorny issue. LLMs are a big dopamine shortcut button that may one-shot your problem. Do you keep pressing the button that has a 1% chance of fixing everything? It's a lot more enjoyable than the grueling alternative, at least to me.
- LLMs today have super spiky capability distributions. I think this has more to do with:what coding tasks we have lots of clean data forwhat benchmarks/evals LLM labs are using to measure success.
As an example, LLMs are all horrible at low-level systems code (GPU kernels, parallelism/communication, etc). This is because their code data is relatively rare, and evaluating model capabilities is hard (I discuss this in more detail here).
Since these tasks are a large part of what I do as a pretraining dev, I know what parts of my work are amenable to LLMs (writing tests, understanding unfamiliar code, etc) and which are not (writing kernels, understanding communication synchronization semantics, etc). I only use LLMs when I know they can reliably handle the task.
When determining whether some new task is amenable to an LLM, I try to aggressively time-box my time working with the LLM so that I don't go down a rabbit hole. Again, tearing yourself away from an LLM when "it's just so close!" is hard!
- It's super easy to get distracted in the downtime while LLMs are generating. The social media attention economy is brutal, and I think people spend 30 mins scrolling while "waiting" for their 30-second generation.
All I can say on this one is that we should know our own pitfalls and try to fill LLM-generation time productively:If the task requires high-focus, spend this time either working on a subtask, or thinking about follow-up questions. Even if the model one-shots my question, what else don't I understand?If the task requires low-focus, do another small task in the meantime (respond to email/slack, read or edit another paragraph, etc).
As always, small digital hygiene steps help with this (website blockers, phone on dnd, etc). Sorry to be a grampy, but it works for me :)”
Quentin concludes:
“LLMs are a tool, and we need to start learning its pitfalls and have some self-awareness. A big reason people enjoy Andrej Karpathy's talks is because he's a highly introspective LLM user, which he arrived at a bit early due to his involvement in pretraining some of them.
If we expect to use this new tool well, we need to understand its (and our own!) shortcomings and adapt to them.”
I wonder if context switching could become the Achilles Heel of AI coding tools. As a dev, the most productive work I do is when I’m in “the zone”, just locked into a problem with no distractions, and when my sole focus is work! I know how expensive it is to get back into the zone after you fall out of it.
But I cannot stay in the zone when using a time-saving AI coding tool; I need to do something else while code is being generated, so context switches are forced, and each one slows me down. It’s a distraction.
What if the constraint of being “in the zone” when writing code is a feature, not a bug? And what if experienced devs not using AI tools outperform most others with AI because they consciously stay in “the zone” and focus more? Could those without AI tools have been “in the zone” and working at a higher performance level than devs forced into repeated context switches by their AI tools?
There’s food for thought here about how time saved on coding doesn’t automatically translate into higher productivity when building software.
This was one out of four topics from last week's The Pulse. The full issue also covers:
Industry pulse. Why 1.1.1.1 went down for an hour, Microsoft cut jobs to buy more GPUs, Meta’s incredible AI data center spend, and the “industry-wide problem” of fake job candidates from North Korea.
Windsurf sale: a complicated story of OpenAI, Microsoft, Google, and Cognition. OpenAI wanted to buy Windsurf but couldn’t because of Microsoft. Google then hired the founders and core team of Windsurf, and Cognition (the maker of Devin) bought the rest of the company. It’s a weird story that could not happen outside of California – thanks to California having a ban on noncompetes.
Beginning of the end for VC-subsidized tokens? Cursor angered devs by silently imposing limits on its “unlimited” tier. Us devs face the reality that LLM usage is getting more expensive – and VC funding will probably stop subsidizing the real cost of tokens.
This week's The Pulse issue – sent out to full subscribers – covers:
Mystery solved about the cause of June 10th outages. Heroku went down for a day due to an update to the systemd process on Ubuntu Linux. Turns out that dozens of other companies including OpenAI, Zapier, and GitLab, were also hit by the same issue, with outages of up to 6 hours.
Replit AI secretly deletes prod – oops! Cautionary tale of why vibe-coding apps are not yet production-ready, which makes it hard to foresee production-hardened apps being shipped with no software engineering expertise involved.
Industry pulse. Fresh details about the Windsurf sale, Zed editor allows all AI functionality to be turned off, government agencies using Microsoft Sharepoint hacked, GitHub releases vibe coding tool, and more.
Reflections on a year at OpenAI. Software engineer Calvin French-Owen summarized his impressions of OpenAI, sharing how the company runs on Slack and Azure, capacity planning challenges for OpenAI Codex launch, learnings from working on a large Python codebase, and more.
Read The Pulse issues here.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み