ハクソク

世界を動かす技術を、日本語で。

AIがコーディングを容易にしたが、エンジニアでいることは難しくなった

70日前原文(ivanturkovic.com)

概要

  • AIツールの進化 によりコード作成のハードルは大幅に低下
  • エンジニアの業務負荷や期待値 は逆に増加し、複雑化
  • 職業的アイデンティティの危機 やバーンアウトが深刻化
  • 役割の拡大・曖昧化 が進み、専門性の希薄化と疲弊
  • AI活用によるパラドックス と「加速の罠」にエンジニアが直面

コードは簡単になったが、仕事は難しくなった現実

  • AIアシスタントやエージェント による自動補完・機能生成の普及
  • 自然言語で要件を伝えるだけでコードが生成 される時代の到来
  • コード作成の障壁が史上最低レベル に低下
  • しかし エンジニアの日常業務は複雑化・負荷増大
  • 業界全体が新ツールの副作用を考慮せず導入 した結果の現実

ベースラインの変化と「誰も教えてくれなかった期待値の上昇」

  • 2026年のエンジニアの期待成果は2023年比で大幅増
  • AIによるタスク高速化が即「もっとやれ」の圧力 に直結
  • ハーバード・ビジネス・レビュー2026年2月の調査
    • AI導入で業務終了が早まるのではなく、業務量が増加
    • 自己強化的サイクル：AIで加速→期待値上昇→依存度増→業務範囲拡大
    • 83%がAIで業務負荷増、バーンアウト62%（一般職）、C-suiteは38%
  • 経営層と現場のギャップ
    • リーダーは「楽になった」と思い込むが現場は疲弊
    • 信頼・士気・人材流出リスク
  • 別調査ではエンジニアの2/3がバーンアウト、43%が経営層の認識不足を指摘
  • ベースラインは上がったが、誰も「仕事が根本的に変わった」と認めない現実

語られないアイデンティティクライシス

  • 多くのエンジニアは「コードを書くこと」自体が動機
  • AI活用で「書く」から「管理・監督」への役割転換が進行
  • 「コードを書く価値は下がり、システムを指揮する価値が上昇」への変化
  • 一部には進化と感じる者もいるが、多くは「職能の喪失感」
  • ビルダーからレビュアーへの転換、ものづくり感覚の希薄化
  • 本質的な職業アイデンティティの喪失、急激な変化への戸惑い
  • 過去の技術革新とは質的に異なり、「エンジニアである意味」自体が問われる状況

拡大する役割とスコープクリープ

  • コードを書く量は減るが、周辺業務は増加
  • プロダクト思考・設計判断・コードレビュー・文脈切替・計画・テスト監督・リスク評価などの負担増
  • AIによる実装高速化でボトルネックが実装以外にシフト
  • 従来は各専門職が担っていた業務がエンジニアに集約
  • 職種境界の曖昧化、「T字型」「フルスタック」への期待
  • 45%のエンジニア職が複数領域のスキルを要求
  • 実態は裁量や報酬が増えず、役割だけが拡大するスコープクリープ
  • 結果として「何も深くできず、バーンアウト」
  • 生き残るのは「ノーと言える」「優先順位付けができる」エンジニア

監督パラドックス：AIコードレビューの難しさ

  • AI生成コードのレビューは自分で書くより難しい
  • 自作なら設計意図・判断を把握、AI生成は文脈不明
  • 統計モデルが生成したコードは「なぜこうなったか」が不透明
  • Harness調査：67%がAIコードのデバッグ、68%がレビューに従来以上の時間を要する
  • コードレビューの本質は「文脈共有」だが、AI生成はそれを欠く
  • AIでコード量は増えるが、品質保証負担・文脈維持負担も増大
  • 生産ボトルネックは「書く」から「理解する」へ移動、理解速度は上げにくい

加速の罠と見えない負荷

  • AIで一部タスクは加速、結果「余力がある」と見なされ追加業務が発生
  • AI依存→コード量増→レビュー・文脈維持・システム理解の負担増
  • 「ワークロードクリープ」：個々の変化は些細でも、積み重ねで持続不能なペースに
  • AI前は思考・タイピング速度が自然な「リミッター」だったが、今は「認知的限界」が唯一の制約
  • 多くのエンジニアが「過去最高の生産量」と「過去最高の疲弊」を同時に経験
  • 生産性向上の「罠」に陥る現場

Hackerたちの意見

これ、めっちゃ共感できる。去年、AIを使って7つのサイドプロジェクトを進めたんだけど、コードを書くのが10倍速くなった。でも、逆に気づいたことがあるんだ。アイデアから製品を出すまでのトータルの時間はほとんど減ってない。なんでかっていうと、ボトルネックはコードを書くことじゃなかったから。問題を理解すること、アーキテクチャの決定をすること、エッジケースのデバッグ、そして一番大事なのは「何を作らないか」を知ることだった。AIのおかげでコードを早く書けるようになったけど、その分、もっとコードを生産するようになった。つまり、バグが増える面積が広がって、メンテナンスの負担も増えて、複雑さが増すってこと。今は「コードを少なく書く」っていう規律が難しくなってる。コードを書くのがほとんどタダみたいなもんだからね。エンジニアとして成功するのは、複雑さを追加するコストがほぼゼロに近づいたときに、過剰設計の誘惑に耐えられる人たちだと思う。

└

問題は、AIが登場する前は、人口の1%が年に1つのサイドプロジェクトを作ることができたのに対し、AIの後では10%が年に10個のサイドプロジェクトを作れるようになったことだ。競争が100倍に増えた。悲観的な自分は、成功するためのチャンスの窓が狭まっている気がする。

└

自分もサイドプロジェクトを作ったんだけど、コードを自分の感覚で進めた。おそらく、1チームが6ヶ月かかることを、1ヶ月で自分で作った。ユーザーは少数だから、壊れるのを恐れてない。でも、プロの仕事のための自分のコードは、そんなに早く進めることはできない。何百万のユーザーに影響を与えるからね。企業がチームを丸ごと置き換えられると思っているのは本当にクレイジーだ。

└

なんで？それは、ボトルネックはコードを書くことじゃなかったから。常に問題を理解すること、アーキテクチャの決定をすること、エッジケースのデバッグ、そして最も重要なのは「何を作らないべきか」を知ることだった。私にとってはちょっと違うんだ。コードを書くことがボトルネックだった。エッジケースを解決したり、最適化を見つけたりすることに一番喜びを感じる。好きなプロジェクトは、既存のコードベースを渡されて、「火星と金星が対になったときに、再現できない変なバグが出るんだ」っていうタスクを与えられるとき。プロジェクトがゼロから始める必要があると、他の人よりも時間がかかる。アーキテクチャを考えたら、実装を書くのが退屈になっちゃう。AIのおかげで、これがすごく楽になった。成功するエンジニアは、どのツールをいつ使うかを知っている人たちだと思う。これはAI以前からそうだったし、AIはただのツールで、もっと多くの人が成功できるようにしてくれる。

└

結果を出すことが目標なら、アイデアを試すためにLLMを使うのは全然構わない。でも、私のサイドプロジェクトには正確に一つの目標があるとは言えないから、それはフェアじゃない。だから、すでにやり方を知っていて、何度もやったことがあることに関しては、AI生成のコードを使うことにしてる。AIを使うことで得られるのは、タイピングの時間だけ。その他のことは、開発者として成長するために頑張るよ、ありがとう。で、「でもアーキテクチャの決定とかがあるから、成長するでしょ」って言う人がいるかもしれないけど、それは元々あったことだし。練習が必要なら、マイクロスキルとマクロスキルの両方を練習するよ。

└

これに関してはもっと指標が必要だよね。HNでこの主張をしてる人たちをよく見るけど、絶対にそうだとは思えない。これだけは保証するよ…ストーリーは絶対じゃない。誰で、何に取り組むかによって、開発時間は遅くなることもあれば、同じか早くなることもある。でも、わからないのはその割合。60%の人には早いのか？70%、80%？これについてはまだ確実にはわからない。でも、君の直感は完全に間違ってると思うし、90%の人は全体的に早い…かなり早いと思う。バグが増えたり、メンテナンスのハードルが上がるのは同意するけど、それでも早いんだ。LLMもバグを潰せるし、しかも人間よりずっと早いことが多い。私のエージェント設定は、問題に関するスラックのメッセージを読み取って、チケットを作成し、コードを修正して、PRを一発で作成するんだ。

└

幸いなことに、AIは複雑さを減らすためにも使える。私がよく気づくのは、ちょっと見栄えの悪いAPIを使ったり、一般的なコードを複製したりして、依存関係を引き込まないようにすること。例えば、UIフレームワークを避けて、シンプルなウェブプロジェクトでDOMに直接アクセスしたり、標準ライブラリのCLI引数パーサーを使ったり、left-padのような依存関係を引き込む代わりにシンプルなヘルパー関数を追加したりする。依存関係の管理は、私のプロジェクトの中で大きなメンテナンスの負担の一つだから（更新したり、APIを考慮したり、過剰一般化による複雑さ）、これがかなり助けになる。私の考えについては、https://www.karl.berlin/simplicity-by-llm.htmlも見てみて。

└

「私は過去1年でAIを活用して7つのサイドプロジェクトを出荷した。でも、逆に直感に反することに気づいた。アイデアから出荷された製品までの総時間はほとんど減らなかった。」 > なんで？ボトルネックは決してコードを書くことではなかったから。AIの前に2ヶ月ごとにサイドプロジェクトを出荷してた？もしそうじゃないなら、このコメントは認知的不協和に聞こえるよ。あなたの主張は、AIが12ヶ月で7つのプロジェクトを出荷するのを可能にしたってことだよね。これは、AI以前にはやってなかったことだよね？だから、AIはプロジェクトを早く出荷するのを助けてるの？AIが万能ではないのは同意するし、熟練した開発者が必要なのも同意する。でも、AIが早く出荷するのを助けてるって言った直後に、AIが早く出荷するのを助けてないってどうやって言えるの？

└

「ボトルネックは決してコードを書くことではなかった。常に問題を理解すること、アーキテクチャの決定をすること、エッジケースのデバッグ、そして最も重要なのは、何を作らないかを知ることだった。AIはこれらのタスクでも助けてくれるけど、助けを求める時は、AIが助けられる形で頼まないといけないし、本当に知的であるとか、クリスタルボールを持っていると期待してはいけない。ボーナスとして、これらのことをエージェンティックなコンテキストに入れたら、コード自体も良くなるよ。一発で決めるコーディングはアンチパターンだね。」

└

新しいボトルネックはコードの所有権だね。長期的に維持するためには、それが何をしているのか、どう機能しているのかを理解しないといけない。LLMを使って維持しやすい状態にするのはできるけど、逆に維持しづらい状態からは抜け出せない。手に負えないことをやろうとするのは、今まで以上に危険だよ。

└

その通りだね。ただ、ツールに慣れれば慣れるほど、物事は良くなって速く進むと思う。ここ3年でこの分野はすごく進化してきたけど、最近は少し鈍化してきてる気がする。これっていいことだと思うよ。みんなが追いつく時間ができるし、新しいコーディングのパラダイムに適応するためのアプローチを洗練させることができるから。

このエッセイは、部分的にAI生成か、LLMを通してかなり編集された可能性があるってことは言っておく価値がある。いくつかのサインがあるんだよね（「XじゃなくてYだ」みたいな）。2015年から2025年の間はほとんど活動がなかったブログが、その後急に投稿やテキスト出力が爆発的に増えたのも、ちょっと怪しいよね。

└

今や、LLMに関するすべての投稿は、LLMによって書かれる（または支援される）ことがほぼ確実になったね。この種の文章が多くの人を遠ざけるってことは、この業界で成功を求める人たちにはあまり重要じゃないみたい。「これは自分の言葉で、LLMが手伝ってくれたんだ」って声が聞こえるよ。確かにプロンプトを書く必要があるね。

└

個人ブログでAIを使って書くのって、自己尊重や他人へのリスペクトが欠けてる気がする。AIのコードを読むのはすごく楽しい。注釈もちゃんとあって、一貫性があるから、私がコードを読むのが好きなスタイルなんだ（ただし、私がコードを書くスタイルとは全然違うけど笑）。言語や意見を読むのは、そういうもんじゃないよね。繰り返しになって退屈で、すごく模倣的に感じる。なんで私たちのコミュニケーションのメインの方法を、魂のない面倒な作業に変えちゃうの？コーディングに関しては、ロボットが何をしているかに気を使ってるからだと思う。でも、コミュニケーションでは、その人が頭の中で考えていることに気を使いたい。ロボットの解釈を通してじゃなくてね。たとえその人の考えがそんなに強くなくても。そうすれば、その人を理解できるから、相互理解が大事な理由の一つでもあるし、ロボットを挟むとそれが台無しになるんだ。

└

タイトルからして、明らかにLinkedInの深い言葉っぽい匂いがするね。

└

これ、最後まで読めなかった。前にフロントページに載った別の記事を読んでから気づいたんだ。もしずっとフロントページがこういうスラップで埋まってるなら、このサイトに来る意味がないと思うかも。もしかしたら、モデレーターはAI生成コンテンツの投稿にタグやフラグを考慮すべきかもね？

└

自分もLLMの助けを借りて、いくつかのとても個人的な記事を書いたことがあるから、これがいくつかの箇条書きから生成されたものだとほぼ確信している。繰り返しやリズムがLLMの出力に強く似ている。人間味がなくて、内容も薄いから、私はこういうフワフワした部分は削除する。

└

AIはブログを書くのを楽にしたけど、批判的思考を難しくした。

└

いくつかの段落を読み終えた後、私も同じことを思った。最初は「これは面白い、同僚にシェアする価値があるかも」と思ったけど、すぐにAIが書いたか「支援された」ものだと明らかになった。そんなの真剣に受け取れないよ。

└

AIは言葉を書くのを楽にしたけど、うまくコミュニケーションを取るのは難しくなった。

└

こういう記事がAI生成っぽいってすぐ分かるのが面白い。最初に疑念を抱かせたのは「誰も話さないアイデンティティクライシス」って見出し。こういう「誰も話さない」ってフレーズ、めっちゃGenAIっぽい。嫌いだわ。それ以降はあんまり読めなかった。

└

LLMは人がこう書くからこう書くんだよね。全員じゃないかもしれないけど、モデルを訓練するには十分な数だよ。私の書き方もLLMが書いたように見えるけど、それが私をLLMにするわけじゃない。

そういうことは想像してないよ。仕事が変わった。期待も変わった。誰もメモを送ってくれなかった。AIが言いそうなことだね。本当にどう書かれたかは関係ないけど。

└

記事は確実にAIのライティングスタイルだね。

└

なんでAIはこんなに下手なライターなんだろう？こういう表現は、まるでFox Newsを読んでるみたい。

└

本当に長ったらしい。全体を数個の箇条書きにまとめられたはず。正直、あまりにも長くて基本的すぎて、途中で読むのをやめちゃった。

「新しいエンジニアリングの風景が実際に必要とするスキル：システム設計、アーキテクチャ思考、プロダクト推論、セキュリティ意識、そして自分が書いていないコードを批判的に評価する能力。」これらは、確かに常に必要とされていたスキルだよね？これらのスキルを持っていない人は、すでに人間のチャットGPTみたいなもので、プロンプトを受け取って、誰かに評価してもらうために結果を提示しているだけだった。

└

それはいい指摘だけど、確かに多くの開発者はただの派手なLLMに過ぎなくて、レビューの時には高いリンターみたいなもんだったよね。現実がそのことに追いついてきてる。

投稿自体は100%AIが書いたものだよ。https://www.pangram.com/history/6572a5c4-f548-46e2-977d-9813...

└

AIライティング検出ツールはほとんど役に立たないってことを思い出してね。

それは違うスキルセットと考え方だね。エンジニアは技術的な問題に対して縦に深く考える傾向があるけど、AIを使う場合は横に広く、かつ縦に上に考えなきゃいけない。コツは、詳細をAIに任せることに慣れることだよ。具体的な例を挙げると、エージェントやスキルを使って自分のClaudeコード環境を最適化する方法を調べてた時のこと。補助プラグインがどう機能するか、どうやって作るかの技術文書をたくさん読んだんだけど、1時間読んだ後に、プロジェクトのコンテキストを考慮してClaudeに環境を最適化してもらえばいいんだって気づいたんだ。実際に頼んだら、インストールしたり作ったりできるプラグインやスキル、エージェントを指摘してくれた。作成する許可を与えたら、うまくいったよ。これは、もっと技術的に深く考えるべきじゃなくて、プロジェクトを定義するために「メタ」なレベルで考えるべきだってことの例だった。実際にどれだけの効果があったかは別の話だけど、文脈キャッシングや少しツール指向のプロンプトのおかげで、結果が早くなったし、トークンの使用量も減った気がする。

「AIの生産性についての興奮の中で失われがちなことがある。ほとんどのソフトウェアエンジニアは、コードを書くのが好きだからエンジニアになった。」 1) 私は「ほとんどのソフトウェアエンジニア」というグループには入ってないと思う。2) 「ソフトウェアエンジニア」という肩書きなら、コードを書くんじゃなくてエンジニアリングをするべきだと思う。これについてはもう散々議論されてるけど、ソフトウェアの世界で「AI賛成」と「AI反対」の最大の違いは、「コードを書くのが好きだからやってるのか、それとも世の中のために何かを作るのが好きだからやってるのか」ってことだと思う。もちろん、これは二項対立ではないけど、私は物を作ることにもっとモチベーションを感じる一方で、以前はもっと頻繁にプログラマーのフロー状態を楽しんでたのが少し恋しい。

「AIの生産性についての興奮の中で失われがちなことがある。ほとんどのソフトウェアエンジニアは、コードを書くのが好きだからエンジニアになった。」 これは少し共感できるけど、理由は違う。私の考えでは、開発者には職人とアーティストの2種類がいる。アーティストはコードを書く行為を自分の実現だと考えている。美しく書かれたコードに喜びを感じるんだ。彼らは自分のコードに愛着を持ちすぎて、誰かに批判されたり削除されたりすると傷つくこともある。職人は、コードは目的のために存在することを理解していて、それは誰かの生活を楽にすることだと認識している。これは全く技術的でない顧客やユーザーで、今までよりも仕事がうまくいくようになることもあるし、私たちが書いたライブラリを使うことで他の開発者が恩恵を受けることもある。アーティストはLLMが自分の仕事を奪って、彼らの美しい作品を一般的なテンプレート化されたコードに置き換えるから嫌っている。職人はLLMをツールの一つとして認めていて、それを使うことで顧客にもっと利益をもたらすことができると考えている。

ああ、最近の出来事をまとめてくれてちょうどいいね。私たちの「リーダーたち」が、すでに意味不明な目標リストにこれを追加したんだ。A. コード/テストの少なくとも50%がAI生成であることを測定可能に示す。B. 生産性向上ツールによるX%の納期短縮。早い生地作り機を買ったからって、ピザを50%早く作れるとは思わないよね。特に、生地がこねすぎてるのか、こね足りないのか、ただの塊なのかも分からないのに！

ChatGPTの意見を聞くのが大好きなんだ。