- LLMツールが開発生産性を高めるのは事実
- しかし長期的には、こうしたツールに依存することで自力で問題を解決する能力が低下する
- コードを書く過程で得られる達成感が失われ、問題解決よりもAIの回答を待つようになる
開発に対する情熱と挑戦精神の弱体化
- コーディングそのものを楽しめない人もいる → その場合、開発分野は向いていないかもしれない
- 私が出会った最高のエンジニアたちは、週末でも自発的にツールやソフトウェアを作り、イノベーションを追求している
- システムの性能改善は根本的な理解があってこそ可能であり、そうでなければ無作為に試しているにすぎない
「Copilot Lag」現象
- 「Copilot Lag」は、AIからの次の指示を待っている状態を意味する
- まるで新人開発者が先輩の指示を待っているのと似ている
- GitHub Copilotを使っているうちに、基本的な言語要素や構文さえ忘れてしまうようになる
- 短期的な速度向上の代償として、長期的な知識が衰えていく
LLMは学習プロセスを妨げる可能性がある
- Thorsten Ballの"Writing An Interpreter In Go"を学んでいたとき、Copilotがコードを生成してくれたが、自分で書き直せる力は身につかなかった
- メモリ管理やデータ指向設計のような重要な概念を見落としてしまう
- AIが作ったコードは見た目には正しそうでも、根本原理を理解していなければ意味がない
LLMを効果的に活用する方法
- LLMは検索エンジンのように有用に使える
- Stack Overflowを検索するように、LLMの回答を参考にできる
- しかしLLMは実際の専門家の知識をそのまま反映しているわけではなく、学習したパターンとトークン列に基づいて回答を生成する → 誤りも多い
- LLMの回答をそのまま受け入れず、なぜそのアプローチを勧めるのかを分析しなければならない
- 分からないことがあれば、自分で調べて学ぶべきだ
- 新しい言語（Zigなど）を学ぶときは、学んだ内容をメモしておくと役立つ
- メモは学習の参考資料になり、他の人と共有するときにも役立つ
結論
- AIツールは有用だが、盲目的に依存するとかえって逆効果になる
- AIが提示した解決策の原理を理解し、自分で学ぼうとする姿勢が重要だ
- 結局重要なのは、ツールに依存せず根本的な問題解決能力を維持することだ
29件のコメント
うーん……そもそもAIを道具として見るのか、知能として見るのかという観点の違いのようです。私はこの記事に同意できないのですが、下のコメントでも話したように、開発者をコードレベルだけで見ること自体が誤った考えですし、かつて英国で産業革命が起きたときも、農民たちは自分たちは飢え死にすると大騒ぎしていましたが、結果的にはより多くの雇用が生まれ、人類に多くの恩恵をもたらしました。また、過去にコンピュータが登場したときも、コンピュータのせいで人々はだんだん馬鹿になると言われていましたが、結果的にはより多くのことをより短時間で解決できるようになり、人々はより賢くなりました。
ディープリサーチを含むLLMは、まだ高水準の問題解決には有用ではありません。（例えば、論文レベルのアルゴリズム開発）
極限の最適化や、さまざまなシステム特性と技術的イシューを理解しなければならないコーディングも同様で、まだ人の手が必要です。開発者は単なるプログラマーではなく、問題解決者です。いつかはend-to-endの問題解決も可能になるでしょうが、今はタイピングや単純なプログラミングに使う時間を節約し、より難しい問題へのアプローチ方法に投資できるので、生産性の面では前向きに見ています。
いつの頃からか、コードレビューのような感覚で使うことが多くなった気がします。コードの提案を受けて、コードの方向性について話し、より良い方法を考えて提案し、自分が納得できる結果が出たらそれを採用しています。
アプリケーション全体のロジックとビジネスロジックは、人間が考えるべきだ。
開発者をコーディングだけに限定すると、こういう懸念が出てくる。実際には開発者はもっと多くの仕事をしており、コーディングの部分をAIに依存することを愚かになることだと考えることもできるが、別の部分により集中できるようにしてくれると見ることもできる。
うぅ…私はバカ開発者…
Unityがゲーム開発者をバカにしているという話もあったけど、みんな別にバカにならずに、むしろいろんなことをもっと学んで、仕事だけ増えた感じでしたねｗ
仕事が増えただけだなんて…そんな…
バカにしている……という言い方には同意しがたいです。
AI導入以降、生産性は本当に飛躍的に向上しましたから。
ここにバカがいるね
最近は、AIで何でもできるという意見に同意しないと叩かれる時代だから、まあそんなものだよね
知らなかったライブラリの機能や、すぐには思い出せないシェルスクリプトのようなものならまだいいのですが、すでにdeprecatedになった機能や存在しないfunctionのようなものが混ざっていて、デバッグに時間を全部取られてしまいます。
> LLMの回答をそのまま受け入れず、なぜそのアプローチを勧めるのかを分析すべき
この言葉が核心だと思います
ツールは常に、思考の拡張と同時に思考の破壊ももたらすものだと感じます。思考の破壊を通じて、より高次の思考の拡張へ進めるべきなのですが、その準備ができていない瞬間には、いつもこうした問題がついてくるのだと思います。
したがって、結局のところ、ツールの使用には常にこうした悩みが伴うのだと思います。私はそれは必ず必要な過程だと考えています。単に拒否したり盲目的に使ったりするのではなく、このツールをどう使うのがよいのか、こうしたツールをどう活用して本質的により重要な部分へリソースを注げるのかに重点を置いて使うのが望ましいと思います。
(cursorのusageを月1,000回以上使いながら...)
キム代理。私があえて助言したいことがあります。ほかでもなく、Excelの関数？をあまり使わないでください。便利さがあるなら、危険性は増大するものです。牛をさばくにはそれなりの刃があり、鶏をさばくのに刃物が必要でしょうか？ 簡単なことが正解であることもあります。
上の記事はExcel関数のGPT版ですね（笑）
私の意見では、暗算は速いこともあるし、電卓は便利です。コンピュータは牛刀のようなものではないかと思い、意見を述べます。
もう二度とChatGPTを使わない
私も似たような文章を書いたことがあります。
生産性が向上する効果は確かにありますが、脳を委ねてしまう行為そのものは避けるべきだと思います。
まだcursorとanthropicの熱心な支持者ではありますが、ある時から熱狂していたagentモードを徐々に使わなくなり、askモードでアーキテクチャや実装方法を先に尋ね、十分に納得できたときだけ、一つひとつAIの変更提案を受け入れるように自分でも変わっていったことに気づきました。
それほど大きくはないものの（ただし私たちの業務プロジェクトではかなり重要な）モジュールを、2人のエンジニアがそれぞれagentモードを使ってリファクタリングし、構成を追加していく中で、ある時点でアーキテクチャを整理するはずだった意図のコードが、実際には可読性も構造もかえってひどくしてしまう状況を直接目の当たりにし、こうして変わるようになりました。
私もこんなふうに使っています。本当にまったく初めて触る言語なら agent モードを使いますが、知っている言語なら、まず納得できるコードかどうかを確認するようになります。
AIが開発者をバカにしているというよりは…
バカな開発者はAIを使ってもバカな開発者のまま…
Garbage in, garbage out
まったくその通りです（笑）
同意します。無条件に悪いわけでも無条件に良いわけでもなく、使い勝手のいい生産性向上ツールがひとつ増えるようなものだと思います。
共感します。
以前から、開発者といってもみんな同じ開発者ではない、という話をよくしていました。
このお話は正しいようです...
乱暴ですが、まったく的外れというわけでもないですね。良い質問から良い答えが生まれる、というのと同じ文脈で…。
著者は、AIツールだけに盲目的に依存して使うことについて述べているように思います。
私個人の意見としては、AIを活用して業務の効率性が高まったのであれば、
それを積極的に活用して反復的な作業を減らし、
確保できた時間をより広い領域（例：バックエンド開発者がフロントエンドやアプリ開発まで拡張する）や、
アーキテクチャ設計のような発展的な方向に投資するのが望ましいのではないかと思います。
全体的な内容を見る限りでは、著者もこの意見に同意されるように思いますが、
時々AIそのものを拒否される開発者の方もいるので、返信を少し書いてみました……（笑）
.
私も同意します。Excel の関数を使うなと言っていた記事を思い出します。
ある機能はうまく活用して、さらに有用性を高められるなら得だと思います。
同意します。^^
Hacker Newsの意見