- コーディングLLMを活用して明確な価値創出に苦労している開発者がいる
- 一部のユーザーはLLMの出力品質に満足していない
- 具体的な要件や複雑な問題では、LLMが期待に及ばない傾向がある
- 一方で、簡単な自動化や反復作業では一定の利便性を感じている
- 開発者たちはプロンプトエンジニアリングやワークフロー改善の方法を模索している
コーディングLLM利用の難しさと改善方法の議論
LLMの限定的な価値
- 最近、多くの開発者がChatGPT、GitHub Copilot、ClaudeなどのコーディングLLMをさまざまな用途で試している
- しかし、かなりのユーザーは期待したほどの実質的な生産性向上を実感できていない
- 特に複雑なアルゴリズム作成、大規模なコード構造化、プロジェクトのアーキテクチャ設計などでは、LLMの提案コードがしばしば断片的だったり非効率だったりする
出力品質への不満
- 一部の開発者は、LLMが提供するコードにバグが含まれていたり、文脈を十分に理解できず不正確な成果物を出したりすると感じている
- 説明や分析が不足していたり、コードがプロジェクトの複雑さや文脈を適切に反映できていないケースが多い
簡単な活用分野での助け
- 短いコードスニペット生成、反復作業、単純な文法上の問題解決など、基本レベルの自動化という面では明確な利便性が確認できる
- 単体テスト、リファクタリング、コードスタイル修正など、ルーティン作業への活用度は高く評価されている
改善に向けた試み
- 一部の開発者は、より良い結果を得るためにプロンプトエンジニアリングの手法を積極的に適用している
- 自分のワークフローに合ったLLM活用法や、複数のオープンソースツールとの組み合わせを試している
結論と学び
- 現時点では、LLMがあらゆる開発ニーズに対する万能な解決策にはなり得ないことが認識されている
- コミュニティと開発者たちは経験を共有しながら、効率的な活用戦略と限界を乗り越える方法を模索している
1件のコメント
Hacker Newsの意見
開発者には2つのタイプがいる気がする。1つは、LLMはコーディングにおける完全なスーパーパワーで、生産性が100倍になったと騒ぐグループ。もう1つは、かなり手がかかり苦労して使っても、せいぜい普通の結果しか得られない、かなり扱いづらいツールだと見るグループ。だが、本当にLLMが革命的に生産性を高めてくれる前者がそれほどすごいなら、その人たちはすでに市場を圧倒し、競合を一掃していてもおかしくないのでは、という疑問が湧く
グリーンフィールド開発では、LLMのおかげで体感では生産性が100倍まで上がる感覚がある。たとえばReactアプリに複数ページ、Reduxストア、認証などの基本構成を追加する作業を、数分でどんどん作れる。「次にXを追加して」と言えば、たいてい良い結果を出してくれる。でも既存システムの保守や複雑な機能追加、ドメイン知識が重要な場面では、LLMはあまり役に立たない。コード補完や関数の下書きには良いが、機能全体の実装段階ではすぐ限界にぶつかる。こういう場合、LLMに指示する時間と自分で直接コーディングする時間があまり変わらない。だから普通は、自分が望む構造でスタブコードを先に書いておき、空欄だけLLMに埋めさせる。LLMで生産性100倍だと言う人たちは、まだ簡単な部分しか見ていないか、難所にまだぶつかっていないのだと思う。実際には仕事の90%は簡単で、最後の10%が本当に難しく、LLMはそこをうまくこなせない状況だ
少し皮肉っぽく言えば、100倍の生産性だと言う人たちは、実際には小さな数字を100倍しているだけだ。LLMはリサーチ段階ではものすごく役に立つ。たとえば最近、明示的に一部のドメインに特化した線形代数コードを書く必要があったが、LAPACKのようなライブラリが使えなかったので自前で実装した。そういうときLLMを参考書代わりに使い、欲しい情報を一度に整理してもらえるので、本当の研究時間は100倍短縮できた。でも実際のコード実装をLLMに任せると、専門家でなければ見抜きにくい微妙なミスが入る。ジュニアなら見逃してしまうかもしれない類のものだ。自分はコードレビューを重視しているので、LLMがどれだけ良くなっても、コードを書く速度そのものはそれほど速くならないと思う。ただ、どんなコードを書くべきかを決める探索と要約の段階では、LLMはものすごく速度を上げてくれる。結局、革新と創造的なアイデアこそが世界の本当の価値であり、それは依然として人間の仕事だと思う。LLMは重要な助っ人にはなるが、高付加価値のコードは自分で書くべきだと信じている
実際には、この2つのタイプのどちらにも当てはまらない場合がある。100倍の生産性ではないが、ものすごく苦労して使っているわけでもない。30年以上プロとしてコーディングしてきたが、常に何かを調べる必要があったし、具体的な言語や文法はしょっちゅう忘れる。複数の言語を行き来して使う仕事も多かったからだ。昔はリファレンス本やマニュアル、もっと扱いづらい資料まで延々と調べる必要があった。Googleのような検索エンジンが登場して少し良くなり、Stack Overflowのようなプラットフォームはそれよりさらに効率的だった。今はLLMがさらに一歩先へ進めたということだ。オートコンプリートの提案が、ときにはまさに自分が探していた手がかりになることもある。もちろん不要なものは無視するが、チャットインターフェースはGoogleやSO検索よりも、はるかに対話的に質問できる点が良い
数学の勉強をMath Academy、ChatGPT、YouTube（特に3Blue1Brownなど）でしている。この組み合わせがなければ苦痛だっただろうが、今は楽しい。以前、University of Amsterdamで似たようなコースを受けたときは、ChatGPTが今ほど賢くなかったので、ずっと大変だった。ChatGPTは先生でも答えにくい質問に答えてくれるので、数学の文化的背景まで理解してこそ共感でき、創造的な解法ができる自分にはぴったりだ。たとえば、なぜ角度でmを使うのかと聞いたら、歴史的にはmeasureに由来すると教えてくれた。だから今は本質的な数学に改めて集中できるようになった。高速な分散計算の公式もChatGPTがわかりやすく説明してくれた。世界を支配する手段ではないが、本来なら学べなかった知識を学べている。もちろんYouTubeとMath Academyの役割も大きい
LLMは多くの分野を広く扱うので、どの分野でも専門家ではない人にとってはスーパーパワーになる。特定の1分野だけを深く掘り続け、常にそこだけで仕事をしているなら、あまり役に立たない。たとえば、プロジェクトごとに1回程度しか必要なく、専任のデプロイ担当がいない状況で、LLMでDockerfileを書くのは本当に優秀だ。ちょっとした文法ミスや細かな問題もGoogleより速く解決できる。アーキテクチャのトレードオフについてLLMに分析させつつ、最終判断は自分で下せば、生産性向上に役立つ。ただし、プロンプトでLLMがばかなことをしないよう範囲をうまく絞る必要があり、実際には存在しないAPIをでっち上げるなど、とんでもないミスも頻繁にするので、反復的な修正も必要だ。それでも繰り返してなお速度面の利点はある
自分もいろいろな形でLLMを使っている。小さなデバッグ問題、シェルスクリプト、コーディング、質問など、さまざまな場面で助けてもらっている。私的な用途ではClaude、OpenAIのほか、GoogleやPerplexityなど複数のツールの中から結果が最も良いものを選んで使う。業務ではVSCodeでCopilotや社内プラットフォーム経由でClaude、OpenAI、Googleを使っており、Copilot Studioも少し試した。1年半以上こうしたやり方で働いてきて、すべてのツールをずっと使っていたわけではないが、全体的な印象はこうだ。確かにLLMのおかげで生産性は上がった。複数のプログラミング言語で試行錯誤し、さまざまなテーマへの理解も深まって、いくつかの仕事は明らかにずっと楽になった。しかしモデルやバージョンに関係なく、仕事が複雑になり、自分だけの道を進み、単なる組み合わせを超えた段階に入ると、すべて失敗する傾向がはっきりある。LLMのでたらめな出力を直すのにかかる時間が、最初にLLMペースで節約した時間を食い潰してしまうことさえある。今の率直な結論として、LLMは小さなコード補完、デバッグ、説明には有用だが、それ以上ではない。私たちの仕事を今すぐ脅かすものではない
LLMは新しいライブラリやAPI、言語を学ぶときに本当に大いに助けになる。たとえばOpenGLでテキストをレンダリングする方法のようなものは、膨大で混沌とした公式ドキュメントを読むより、LLMに直接聞いたほうがずっと速い。また、反復的で退屈なボイラープレートコードを書くとき、既存コードに参考になるものがなければLLMが役立つ。ただし、自分が本当の「仕事」だと考える、自分のサービス特有の固有コード領域では、「コードを代わりに書いてくれる」という意味でのLLM活用度は高くない。シニアエンジニアとして、実際のコーディングに費やす時間はほとんどなく、重要なのは構造設計、レガシーのリファクタ、性能問題、まれなバグのデバッグなどだ。LLMは反復的なコード記述の速度しか上げないので、毎週新しいプロジェクトをゼロから作るのでなければ、あまり大きな価値はない。今でもボイラープレートを大量に書いているなら、LLMだけに頼らず、別の根本的な解決策も考えるべきだ
混沌とした公式ドキュメントを読み解いて説明することに関しては、LLMは普通のプログラマよりはるかに優れている。この分野では明らかに価値を加えている。ボイラープレートが多すぎる言語もあるのではないかと思う
銀の弾丸なんてなくて、概念化こそが本当に難しい部分だ。Mythical man-monthは重要なテキストなので、ぜひもっと読んでみるべきだ
銀の弾丸はない。フレッド・ブルックスの簡潔な助言を、私たちが何度も忘れてしまうのは不思議だ。期待を膨らませすぎず、学習データにはバグのあるコードが多いのだから、LLMにも当然バグがあると理解して使えば、LLMはずっと有用になる。設計を丸投げせず、関数分割などの事前作業は自分で行い、退屈な作業や不慣れな領域で手間を減らすためにLLMを使うべきだ。ただし、LLMが生成したコードであっても責任を持つなら、必ず自分の知識と検証が前提でなければならない。LLMのコードが完璧に見えても欠陥が潜んでいるかもしれないので、自分の学習とスキルを伸ばし続け、疑いを持つ必要がある。決して盲信してはいけない
問題の規模が大きくなると、LLMが役に立たなくなるのは確かだ。反復作業や複雑なfind & replaceには卓越している。APIリソースにCRUDメソッドを埋めるなど、日常的で明確なコードでは非常に有用だ。最近はClaude Opus 4で自分のパッチレビューもさせてみたが、ときどきミスも見つけてくれるし、自分がやるべきことを思い出させるのにも効果的だった。しかし、複雑さの閾値を一度超えると、LLMの有用性は急激に落ちる。たとえば比較的大きい複数のファイルにまたがって変更が必要になると、結局は自分でどのファイルを変えるべきか自然に推論することになる。それでもLLMを「ラバーダック」として使うのは悪くない。AIがうまくやってくれればよいし、だめならすぐ自分で引き継げばいい。結局のところ、LLMは序盤を手伝ってくれるだけで、修正の大半はどうせ自分がやることだった。フレームワークだけざっくり合わせてもらい、自分が望む形に手を入れるほうが、完全にゼロから書くよりは楽な気がする。LLMが明らかに苦戦しているなら、無理に続けさせない。仕様が曖昧で誤った推測をしたならそれを指摘し、それでもできないなら自分で仕上げるだけだ
自分の経験も似ている。次のような部分でLLMの価値を感じる。かなり独立したReactコンポーネントやページは、人気のあるUIライブラリと組み合わせればとても上手く作ってくれる。よく定義された純粋関数もかなり信頼できる形で作ってくれ、検証もしやすい。有名フレームワークのボイラープレートは本当に簡単に、しかもうまく作れる。なのに周囲の人たちは強力なエンドツーエンド体験を自慢するが、自分は実際そうならず、少し気が狂いそうになる。普段かなり頑張っても、完全な機能単位になるとLLMは完全に崩壊する。aiderなどのツールでNext.jsの単純なテンプレートメール機能すら作れず、機能を細分化して1つずつやらせると少しはましになるが、だんだん既存コードが壊れていく。問題点を説明しても、プロンプトを重ねるほどおかしくなる。結局は手作業で直そうとしたが、コードは完全にぐちゃぐちゃだった
友人のvibe coderたちに「自分の基準が高すぎる」と言われたことがある。vibe coderは基本的にコードをきちんとレビューしないので、品質基準そのものがないのだと思う。もしvibe codingが本当にうまく機能するなら、Google AIのようなところは莫大なGPU、TPU予算と最新のAIモデルで、人間より圧倒的に速く製品を改善しているはずだ。もし本当にそんなことが起きているなら、私たちの仕事はだんだん楽になるという形ではなく、まずニュースで予想外のとんでもない出来事として知るはずで、その原因がAIだとわかるのはもっと後になるだろう
LLMは使い捨てのコードには向いている。開発、保守、デバッグ、修正のすべてが簡単というわけではない。コードの大半は実質的に製品ではなく「消耗品」のコードなので、そこには適している。ファストフード、組立工場、自動化生産のような概念が当てはまるとしても、大きな違いがある。工場で機械が作る物は99.99%以上の精度で正しく作られるので信頼できる。しかしLLMは各段階で自分がいちいち検証しなければならず、検証しなければ単に動かない。LLMが24時間無人で自律的にうまく解決することは不可能だ。だから今すぐ仕事を奪われるわけではない
自分は複雑な問題全体をまるごとLLMに任せて結果を受け取ろうとは絶対に思わない。それはLLMの強みではない。LLMの本当の価値は、進行を助ける「ヒント」と、単純だが時間のかかる部分をスキップさせてくれる点にある。数日前、ログ文字列を作る作業があったのだが、LLMが自分の考えていたものよりきれいに整ったコードをすぐ提案してくれて、15分かかる仕事を30秒で見事に終えられた。こうした小さな成果が積み重なって価値になる