- ソフトウェア業界では エンジニアのバーンアウト が深刻化しており、特にジュニアエンジニアが AIツールを過剰利用 することで、コード品質や協業に問題を引き起こしている
- シニアエンジニアのフィードバックは学習機会ではなく、AIに渡す新たなプロンプトとして使われ、「AIが書いたコード」 がチーム全体のレビュー工数を消費している
- 一部の組織ではAIが作った不完全なコードを「成果」のように見せて発表し、AI依存を奨励する空気 が形成されている
- 著者は自身の経験として、AIによるコード回答を受け取ったときに 不快感と違和感 を覚え、AIがむしろ学習とメンタリングの文化を損なっていると批判する
- AIスタートアップのエコシステムも結局は 非経済性、電力消費、環境問題 のため持続不可能であり、現状は 「裸の王様」 のような茶番にほかならないと強調する
序論: 不安定なエンジニアリング環境
- 最近、エンジニア の間で バーンアウト が深刻化している
- 組織ではシニアエンジニアに対し、実際にはまともに動かない 「雰囲気（ミーム）ベースの機能」 をレビューし、貢献することが期待されている
- 私の経験では、優れたエンジニアほど新しいチームメンバーが成長できるよう、常に熱意を持って助けようとする
- しかし、そのフィードバックは成長の機会として使われる代わりに、初級開発者 たちはそれを単に 生成AI に送る次のプロンプトとしてしか活用していない
- 実際、多くの ジュニアエンジニア が LLM（大規模言語モデル） ツールを（乱用と言えるレベルで）使っている事例を直接目にしてきた
組織内の実例: AI乱用の弊害
- 最近、会社の タウンホール でジュニアエンジニアたちが新しい成果物をデモする様子を見た
- 彼らは機能の目的や動作方法すら十分に理解していない様子だった
- しかし規模の大きい組織では、実際の結果とは無関係に「成功」を演出することに集中しがちだ
- あるシニアマネージャーが彼らのAI活用事例を公開し、「これはClaudeが書いた4,000行のコードです」と誇らしげに説明し、拍手喝采を浴びた
- 私自身も既存機能の小規模改善を依頼されてコードをレビューしていた際、最近変更を加えた ジュニアエンジニア にコンテキストを尋ねた
- GitHubのコミットURLを送って質問したが、その内容をLLMに入力し、返ってきた回答をコピーして送ってきたのだろうと推測された
- この過程で、何とも言えない違和感と不快さを覚えた
AIスロップとコードレビューの限界
- 友人の事例から、1か月のあいだ 複数のエンジニアが LLMが自動生成したコード（vibe-coded PR）をレビューしてマージしようとして時間を浪費する事態が実際に起きていることを確認した
- 別の友人も、AIが作った「雑なコード」を繰り返しレビューするうちに消耗した経験を打ち明けていた
- AIによってコード品質の改善や学習が進むどころか、単純な反復労働だけが増えている
開発文化と人間的成長の本当の価値
- すべてのエンジニアは同僚やメンターのおかげで一歩ずつ成長する
- 直接教え、成長させることこそソフトウェアエンジニアリング文化の本質である
- しかし、そうした投資の成果がすぐに「最新モデル」の学習データとしてコピーされる現実には懐疑を覚える
- それなら、いっそジュニアエンジニアではなくモデルだけを学習させるほうがよいのかという根本的な問いが浮かぶ
AIを使わない実験と結論
- 率直に言って、「AIの使用をやめてみよう」という実験を提案している
- 著者自身も最近コンピュータを初期化した際にClaude Proの契約をやめた
- 何度かの 検索 と Stack Overflow、公式ドキュメントを読む過程のほうが、むしろはるかに信頼できる結論にたどり着けた
- LLMが出す結果よりも、自分の判断のほうが正確性と信頼性の面で優れていると考えるようになった
生成AIツールの経済的価値、そして本質的な限界
- 「AIは本当に役に立つのか？」 という問いを投げかける
- 客観的に見れば、その価値には大きな疑問がある状況だ
- AIスタートアップの典型的な流れは次の通りである
- 既存分野に「AI」が適用され、効率化を名目に新興企業が登場する
- AIスタートアップはベンチャーキャピタルからの資金調達に成功する
- AIサービス提供企業（OpenAIなど）に利用料を支払う
- AIスタートアップ自体は利益を出せない
- この流れ自体は従来のVCエコシステムと大きく変わらないが、核心的な違いは サービス提供者（OpenAIなど）ですら、まだ利益を出せていない 点にある
- この技術自体が 本質的に非効率 であり、大規模拡張に不向きな構造になっている
- 過剰な 電力消費 と環境面での副作用も深刻な問題である
結び: 現実認識の必要性
- Mooreの法則が復活することや、宇宙が冷え切る前に皆が豊かになることを願うことはできる
- しかし 現実を直視 するなら、生成AIビジネスは一種の 幻想 であり、「裸の王様」 的な現象である
5件のコメント
今、何が起きているのか？
最先端技術である核爆弾については、世界大戦の後に人類が再び原始時代へ戻るのではないかという懸念がありましたが、今や
sw開発分野ではそれが現在進行形です。過剰なバイブコーディングさえやめればいい気もしますね。アシスタントや、一部の細かいけれど単純なアルゴリズム作成においては、これほどのものもなかなかないと思えるほどです。
Hacker Newsの意見
AIを組織に導入するのは、単なる技術的課題ではなく変革管理の問題であることを強調している。信頼と透明性に基づく有能なチームが、人間の専門性とLLMの強みをバランスよく組み合わせるプロセスを作ってこそ、本当の効果が得られる。少人数チームがAIで大きな成果を出す事例も生まれている。しかし大半の組織、特に大企業は健全な組織文化を持っておらず、AIがむしろその毒性を増幅させる現象が起きている。企業幹部の中には「Story Point」を単なる時間単位だと誤解し、AIをあらゆるものを半分に短縮してくれる道具としてしか見ていない場合もある。根本的には保守可能なソフトウェアを作る過程そのものとかけ離れており、AIを手っ取り早く利益だけを増やす通路として認識している。最近、AIパイロットプロジェクトの95%がROIを達成できなかったという調査結果も、現代の経営陣の無能さを示す事例である
「Prompstitudes（プロンプトにだけ依存する会社員）」の登場について語っている。同僚が自分の意見を推測したChatGPTの回答だけを投げてきたことがあり、まるで記事で言う「侵害されたような気分」を感じた。彼らは無能というより、LLMに依存しすぎていて、まるでスロットマシンを回し続けるカジノの老人のようだと感じる
最近、同僚との会話で明らかにChatGPTの出力が返ってきたせいか、気持ち悪さを感じた経験を共有している。むしろ無視されたほうがましだったと思っている。特にLLMが自信満々に間違ったことを強く主張するので、なおさら問題だった。小さな違い（例えば設定と実装で名前が少し違うだけでも）が、LLMを完全に混乱させることがある。人間と違って、LLMは失敗から学んだり気づいたりしないので、継続的に間違った方向へ流れていく現象がある。むしろひどい人間のコードと格闘するほうが、精神的にはましだと感じる
「AIツールは本当に役に立つのか？」という問いに対し、自分は他の人とは違う使い方をしているので役に立つと考えている。1983年から開発をしており、現在は引退して一人で作業することが多い。さまざまなツールを試したが、今はChatGPTとPerplexityだけを使っている。直接コードを書かせることはせず、LLMが提示したコードを参考にしながら出発点として活用している。たまに丸ごと使うこともあるが、たいていは修正と書き直しの過程を経る。LLMがますますひどい結果を出すようになったら、そこで切って別のアプローチを試す。この流れの中で、初心者エンジニアがLLMコードだけをなぞって使う姿を想像すると震える。自分にとって最大の価値は「即座に応答してくれるStackOverflow」のような感覚である。どんなばかげた質問でも恥ずかしがらずに聞けて、すぐにそこそこの答えを得られる。最近iOSでPassKey実装を学ぶ際、ChatGPTのサンプルコードをそのまま出発点にして、一行ずつ理解しながら勉強した。最初に書いたコードと今完成したコードはまったく違っており、この過程を通じて技術理解が深まった
LLMは技術的な質問に答えたり、新しいアプローチを提案したりするのが非常に得意だと感じる。初心者でもstackoverflowのように評価されたり壁にぶつかったりせず、自由に質問できる。Copilotは自動補完機能が優れており、コード記述速度を高め、ドキュメントコメントやコード行を自動補完してくれる。こうした小さな支援は簡単にレビューできる。しかし、LLMに複雑なコードを丸ごと任せると混乱が生じ、かえってデバッグに苦しむ経験がある。初心者がLLMに過度に依存すると、まともな開発能力を育てにくいと思う
個人的にZedを趣味開発で使う理由は、AIが過剰に賢そうにしゃしゃり出てこないからだと感じている。必要な時だけAI機能を自然に呼び出せて、普段はただ自分がコーディングする。職場ではVSCode AIのせいで妨害を受けすぎる。問題は二つある。第一に、インタラクションが壊れやすすぎること（ポップアップをクリックしたり、誤って巨大な自動補完を挿入したりする）。第二に、流れが途切れることだ。AI自動補完が役立つこともあるが（約3分の1の割合）、残りの時間は本来の思考の流れが壊れ、AIの結果を確認するせいで集中が削がれる。Zedにはこうした問題がないので、再びプログラミングの楽しさを取り戻せたと思っている。結局のところ、問題はAI機能そのものより実装方法にある
AIはUXプロトタイプ作成に非常に有用だと感じる。短時間でクリック可能な成果物をすぐ作れて、何度も反復しながら方向性だけを定め、後でそうしたコードは捨てて新しく開発する。このやり方は、誤った方向に早い段階から多くの時間を浪費するのを防いでくれる。ただし、まだAIで意味のあるアプリ全体を丸ごと作るには遠いと思う
AIは自分にとって単なる一つの道具にすぎないと見ている。自分はハイレベルな開発者ではないが、個人プロジェクトで行き詰まる部分についてAIにアイデアやフィードバックを求める形で使っている。重要なのは、コード作成をAIに任せないことだ（ごく単純なボイラープレートを除いて）。自分でコードを書くのは、問題解決と創作、そして学ぶ過程から得られる喜びのためである
最近、同僚のコードレビュー中に「prepareData」という多次元配列を混ぜてフィルタリングする複雑な関数を見たが、その同僚に「これは何をする役割なのか」と尋ねたところ、時間を節約するためにLLMに聞けと言われ、当惑したというエピソードである。コードレビューのための最も基本的な質問にさえ答えない態度に失望している
10年後、新人開発者が自分でコードを書く経験もなくそのままシニアになろうとする現象を懸念している
開発初期段階での環境構築や、小さなfunction単位のmodule開発ではAIは非常に効果的だが、それ以外でコードやプロンプトを放り込むvibe codingは、保守の観点では災厄だ。最初の数回はうまくいくかもしれないが、結局問題が発生するたびに、AIが自分の問題を解決してくれるまでN回試してみなければならず、そのソリューションが別のどんなバグを引き起こすのか分からないという恐怖が続く。
開発者の能力次第で
基礎力のある人が使えば、AIを活用して高品質な開発が可能だが、
基礎力がなければ話があらぬ方向へ進んでしまう
料理人に基礎があるかないかの違いと同じ