私がLLMの利用を減らすことにした理由
(zed.dev)- 15年の経験を持つソフトウェアエンジニア Alberto Fortin は、LLM（大規模言語モデル）の導入に大きな期待を抱いていたが、実際の プロダクション環境 ではさまざまな限界を経験した
- Go と ClickHouse ベースのインフラ再構築の過程で AIの実態と限界 を痛感し、モデルが改善しても 根本的な問題の解決は不十分 だと感じた
- 生産性向上への幻想 が存在し、実際には バグや予期しない問題 がむしろ増えると指摘している
- LLMを 補助者（assistant） と捉え、中核となる設計や意思決定は開発者自身が担うべきだ という教訓を強調している
- "AIは革新的だが、まだ完全ではないので、バランスの取れた活用と冷静な現実認識 が必要だ"
Alberto FortinのLLM体験と振り返り
- 15年の経験を持つ ソフトウェアエンジニア Alberto Fortin は、LLMを積極的に開発作業へ導入し、大きな期待を抱いていた
- Go と ClickHouse を活用してインフラを再構築する過程で、さまざまな挑戦と限界に直面し、AIと実際の開発とのギャップについてブログ記事を書いた
- その後、最近の追加分析を通じて、Claude Opus 4 など最新モデルがこうした問題を解決したのかを検証した
- Albertoの体験は、実務環境でLLM導入を検討するエンジニアに 実践的な教訓 を与えるとともに、どの部分でツールが価値を提供し、どこまでが限界なのかについて現実的な視点を示している
LLM体験に関するAlbertoの主な引用
"誤作動や機能が動かないことだけが問題だったわけではないと、本当に驚いた。今後数年間このコードを保守しようとする開発者として、コードは 十分にクリーンである必要がある。"
"問題はすぐ解決しそうに見えるのに、結局また次の新しいエラーが発生し、それを解決するのにさらに2週間ほどかかる、そんな経験が繰り返された。"
"エラー出力をLLMに渡すと新しい回答は返ってくるが、また何かを複雑に絡ませたり、別の部分を壊してしまう問題 が頻繁に起きる。"
LLMへの過度な期待に対する認識
"初期のオートコンプリートのような小さな機能を初めて使ったとき、開発者は皆驚きを感じる。まるで自分の考えを読まれているようで、期待値が膨らんでしまう現象がある。"
"開発生産性 が10倍くらい上がるように思えてしまうが、実際にはそこまでの期待をあまりにも早く持ってしまう傾向がある。"
役割と期待の再定義
"最も大きな違いは役割認識の変化だ。私は アーキテクトでありシニア開発者 で、LLMは私の助手にすぎない。私が計画を立て、LLMは補助役を担う。"
"信頼を失ってからは、もはや重要な機能は任せない。リファクタリングのような小さな単位でのみ活用している。"
"私はバグを自分で修正し始めた。コードベースを完全に理解しているなら、問題を自分で解決するほうが はるかに速く効率的だ。"
LLMを見る視点の変化と助言
"シニア開発者として、LLM導入が自分にうまく合わないのは 自分の能力不足ではない と認めた。従来の作業スタイルを守りつつ、AIは補助的に活用することが重要だ。"
"技術の進歩によって 一段階前進 したのは事実だが、まだ次の段階には到達していない。意思決定とアーキテクチャ は依然として人間が担うべきだ。"
"AI革命は驚くべきものだが、今は バランスの取れた現実的な期待値 が必要だ。"
2件のコメント
> https://ja.news.hada.io/topic?id=20955
Hacker Newsの意見
HNに時間をかけすぎていると感じるのは、ほとんどすべての記事やコメントで同じ話が繰り返されているから。LLMは興味深いが、生成されたコードは複雑で所有感がなく、自分で書いたコードのように全体構造が頭に入らないため管理が難しい、という話。保守するつもりのない短いスクリプトには使えるが、大規模プロジェクトでは問題になる。また一方では、複数のLLMエージェントを使ってさまざまな作業を分散処理して統合するワークフローがすごいと言う人たちもいるが、実際のコードは見せず、ただ自慢しているだけのように感じる
この要約は本当に核心をよく捉えていると思う。LLMは開発速度を大幅に上げてくれるが、自分がコード全体を理解できていないため、いつどこで問題が起きたのか把握しにくい。結局、新しく入った開発者が自分のプロジェクトに適応しているような感覚になる。だからコードは頻繁にコミットし、定期的にLLMにコードの説明をあらためて求めている。この過程でLLMが自分のバグを見つけることも多い。主にデータ分析のように範囲が狭い作業なら、十分に管理しながら素早く進められる。逆に大規模なコードベースでLLMをきちんと活用する能力や習慣がなければ、簡単にぐちゃぐちゃになる。プロンプト作成、コンテキスト管理、速度調整、作業の整理、LLMの成果物を正確にレビューすることなどは、必ず身につけるべきLLM活用スキル。まだ誰もこれを正式には教えてくれないので、みんな試行錯誤で学んでいる。それでも一度その良さを味わうと、以前には戻りにくい。面倒だったり反復的だったりする作業はLLMに任せられるから。20年以上開発してきて昔ほど忍耐力もなくなったし、実装方法がよく分からないアイデアもLLMに任せれば、はるかに効率よく進められる
プログラミングを「理論構築」の過程として考える見方が気に入っている。Programming as Theory Building 参照。AI活用そのものに反感はない。ただ、生成されたコードの結果に対する責任を放棄する態度には賛成できない。grep などのツールを使うときと同じで、ツールとして使った結果にも責任を持って向き合ってこそ意味がある。生成コードはなおさらで、ディスクレーマーだけで済む問題ではない
AI関連の話題に疲れを感じるのは共感できる。意見が割れているのも事実。それでも実際に自分たちのコードを公開している例はある。Flask/Jinja2/Sentryを作った Armin Ronacher が YouTube に ワークフロー動画 と 自作AIライブラリの紹介 を上げていて、自分もオープンソースプロジェクトの50%〜80%ほどをAIで作っている。cijene-api 参照
ユーザー層はベルカーブのように分かれている感じがする。一方には、LLMが大量のコードを自分のスタイルで出してくるせいで、利用者の頭に文脈が入らず圧倒されてしまう層がいる。反対に、もともと一人では実装不可能だった利用者には、LLMのおかげで何でも作ってみる道が開けた。さらに別の層には、本来なら自分でゆっくり実装できるが、LLMをジュニア開発者の軍団のように使い、全体のアルゴリズムのレベルだけを覚えておくことに集中して、はるかに大きなプロジェクトを素早く組み立てる利用者もいる
25人を超える開発者が同時に関わる大規模コードベースで働くのと、それほど変わらないという気もする。自分の組織では160人のエンジニアがフロントエンドとミドルティアを担当していて、常に所有感のないコードを掘り返さなければならず、git blame には3年前の外部委託開発者の名前が出てくることもしょっちゅう。LLMは小規模では良く、中規模では合わず、大規模プロジェクトで小さなモジュールとして使うとまた良いように思う
LLMは自分の目標達成には大いに役立つが、直接プログラミングする能力そのものは落ちる感じがする。まるでステロイドのように筋肉はすぐ大きくなるが副作用が多く、やめた瞬間に一気に崩れてしまう状況。会社は健全さより速い成果にしか関心がないので、この現象はさらに強まる。最近は適度なラインを守りながら調整して使うようにしている
LLMのおかげで、多くの開発者が "Simple Made Easy" で強調されていた教訓を忘れてしまったように思う。LLMが作るコードは「Ball of Mud」（複雑で、リファクタリングも保守もできないぐちゃぐちゃなコード）を生み出すのが得意。複雑な問題を小さく分解し、それぞれの小さなコンポーネントが単純に動作し、それらが相互作用して複雑さを実現することこそ本当の力。各コンポーネントが単純なら理解しやすく、デバッグや性能予測も容易になる。LLMがこの原則を本当にうまく守るようになれば、そのときは本当に開発者が不要になるかもしれない
実際には、LLMに望む方向を直接伝えることもできる。LLMを有用だと感じる人とそうでない人の違いは、LLMの得意分野と苦手分野を把握し、入力（プロンプト）によって結果の質が変わることを予測できるかどうかにかかっている。たとえば、複雑な問題の分解方法をLLMに尋ねて、自分が見落としている点がないか確認し、その後で具体的な実装を任せるやり方を好む。何の指示もなく巨大プロジェクト全体を生成しろとは言わない
「Ball of Mud」の問題はコードだけで起きるわけではない。自分の職場にも「AIを積極的に受け入れよう」と主張するリーダーたちがいるが、デプロイシステムや複雑な運用までAIで回そうという発想を見た。結局、複雑なシステムの上にさらに複雑なブラックボックスを載せて、「ブラックボックスを理解するには新しいブラックボックスが必要だ」という理屈になっていて、自分にはまったく納得できない。組織内の強圧的な雰囲気のせいで、自分の考えの方がおかしいのではと感じさせられることさえある
LLMが本当に完璧になったとして、開発者が本当に不要になるのか考えてしまう。LLMが24/7でソフトウェアをひたすら「生産する機械」のように動き続けることを望む人は、結局いないと思う。最終的には、依然として問題を分解し、実際に必要なソフトウェアを見つけて作る人が必要になる。今の私たちがそうした人たちをソフトウェア開発者と呼んでいるように
結局、自分も似た結論に達した。LLMはコードベース全体をオートコンプリートのように埋めていく用途にはあまり向いていない。何がどこで何をしているかという頭の中のモデルが失われてしまうから。LLMはパーソナライズされた StackOverflow のように、キーワードの説明、よく知らない概念の要約、方向性の提示などにだけ使い、実際の実装と意思決定は自分で担う方がずっと効率的だった
自分も同じ使い方をしているが、cursor はしつこくコード修正を提案してくる。コードベースの内容をいじらせず、introspect だけさせる秘訣が知りたい
自分の場合は違う。LLMが提示したコードをいつも丁寧にレビューすれば、何がどこにあり、どう相互作用しているかはかなり明確に把握できる
自分も使用頻度をかなり減らしている。LLMの回答が間違っていることがかなり多かった。だから最近は、「どのマニュアルあるいはドキュメントを見ればよいか」その場所だけを尋ねて、実際の内容は自分で直接確認している。この方法は情報の所在を把握する力を鍛えるのに役立ち、検索エンジンやLLMへの依存も減らせる。LLMはあくまで道具にすぎず、正確性も高くない
どこでも触れられていなかった点がひとつある。LLMはときに生産性を下げることがあるという点。もっともらしい回答で見当違いの方向へ引っ張られると、かえって深刻な時間の無駄になる。全体として見れば役立つことが多いが、「根拠の確認」が重要で、実際には自分で実装した方が早いことも少なくない
LLMの限界は明らか。非常に強力ではあるが、人間のような創造的ジャンプは苦手。たとえば「Android で 1000 未満のポートに bind できないが、Webサーバーを動かすには？」という質問に対して、Claude と Gemini の両方が次の3つの常識的な解法しか出してこなかった。1) リバースプロキシ 2) root 化 3) ポート番号を上げる。自分が求めていた本当の解法は HTTPS RR レコードだった（関連参考）。どちらもこの仕様自体は知っているのに、その状況には当てはめられなかった。自分で文脈を補ってやっと答えにたどり着いた
実際、LLMがそれを勧められなかったのはそれほど不思議ではないと思う。Chrome でも正式対応していない新しい仕様を勧めてくれることを期待するのは難しいし、自分でもそこまで思いつかなかっただろう
この情報は自分もメモしておく。最近LLMと実際に会話していて、人と接するように少し寛容でいるとストレスが減ると感じる。たとえば cursor でコードを書くときに「ここが抜けてる」と指摘されると、自分だって同じミスをしたかもしれないと思えることがある。「ブッククラブ」や「映画クラブ」の相手としてLLMに映画2本を議論させたことがあるが、登場人物の状況を言い間違えるエラーもあった。それでも100%正確である必要はなく、人に対するのと同じように寛容でいれば、会話はずっと柔軟になる。AIと話すときも前向きに接するとよい
SRV レコードは聞いたことがあったが、ほとんど使われていない印象だった。HTTPS RR は初めて知った。実際のサポート状況も SRV より良さそうだ
「正解をこちらから言うと、そのとき初めて解決策の一覧に加える」という、LLMによくある古典的な問題だ
目標と制約条件を十分に明確に指定すれば、ChatGPT o3 はこの解決策を提示してくれる。ただし最新ブラウザでしか動かない点も正確に案内してくれる。参考例
ChatGPT Enterprise 版を頻繁に使う中で、時間が経つにつれていくつか学んだことがある。大量のコードを投入するのではなく、非常に独立した関数や小さなクラス単位で扱うと効果が高い。コード生成や補完を頼む場合、10%程度は追加指示で解決できるが品質は落ちるし、25%程度はどれだけ説明しても品質が上がらない。そういうときは思い切って無視して自分で解決する。逆に、新しく書いたコードのレビューにはかなり使える。コメントの半分は役に立たず、一部は曖昧だが、ときどき本当に重要なバグや問題を指摘してくれることがある。複数ページを一度に入れず、分割して投入しながら使うのがよい。HLSL shader や SIMD のようなニッチな分野は、学習データ不足のためほとんど答えを返せない。全体としてコード品質の改善には役立つ。コードを小さな単位に分けて検証するようになるので、関数・クラス・モジュールといったアーキテクチャ構造に分割され、全体品質が良くなる
長期的なソフトウェア開発では、LLMを「高度なボイラープレート生成器」として使うのがいちばん魅力的。保守を気にしなくてよい使い捨て作業にはすでに向いているが、長期開発でも抽象化しにくい反復コード（たとえばテストコード）に本当に便利。最初は抵抗があったが、今はとても満足している。退屈で反復的な部分が「プロンプト最適化」という面白い新しいゲームに変わり、生産性も大きく上がった。プロンプト作成とコードレビューは単純作業よりずっと早く終わる。そのおかげで、頭を使うべき面白い部分だけが残る
LLMは結局、コーディングに限らずさまざまな作業において「流行のダイエット法」と似た現象なのだと気づいた。誰もが速くて簡単な解決策を求める気持ちは同じだが、結局近道はない。利便性には必ずトレードオフがあり、いずれ誰もがその現実を受け入れることになる