ああ、ありがとうございます。これも別トピックとして登録しました。エンジニアの転職を止める経済的介入方法

無意識であれ意図的であれ、当為・願望・予測を区別しない人たちがときどきいますね

ああ、私が疲れている理由をはっきり代わりに説明してもらった感じですね。

ユーザーの立場からしても疲れることですが、

開発者の間でも、実績を一つでも多く残そうとして、本質は同じ技術なのに言い方だけを少しずつ変え、まるで新しい技術を作ったかのように見せるのが流行になっている気がします。

登場してまだ間もない技術だから、先行して押さえようとする試み自体は、どうしても当然のことなのでしょう。
それでも、本当に疲れるなと思います。

本当に共感しますね。

つまり、AIによって学習曲線が急な人材が必要になるわけですが、「ジュニア」が「学習曲線が速い」という点には共感しにくいですね。

これからはジュニア <-> シニアの区別を、経験値の蓄積度合いで開発者を評価するのではなく、

AI時代には、学習を非常に圧縮してAIをうまく使いこなす能力でシニアを区別すべきではないかと思います

パチパチパチ :)

「Xが未来だ」という文は、「Xが未来であってほしい」と自分で読み替えて受け取る知恵が必要なのではないかと思います

ほんといろんな部分で共感するｗ まじでやってられなくて、もう力を抜いて給料分だけ働こうモードになったら、むしろ仕事がスムーズに進むって喜ばれる。実際にはリスクのある開発の方向性が見えていても、もう自分には関係ない状態になっただけなんだけど

JavaScript의 간략한 역사
この記事とあわせて読むとよさそうです

> ただし、権限モデルが実装されていないため、トークン権限を制御できない（私の認識が間違っていたら教えてほしい）

現在はサポートされています。

https://code.visualstudio.com/updates/v1_107/…

1. 「スピード感は活力になる」（肯定派）

• 立場: 退屈な作業をAIが素早く処理してくれることで、むしろ活力が湧き、新しい技術スタックの学習コストも減らせるため肯定的。
• 事例: 慣れない言語やフレームワークを使うとき、AIエージェントのおかげで退屈な学習プロセスを飛ばし、すぐ実装に集中できた。

2. 「バイブコーディングの定義論争」（用語の混乱）

• 論争: 「バイブコーディング」が単にAIの助けを借りることなのか、それとも生成されたコードをレビューせず結果だけ確認することなのか、その定義をめぐって意見が分かれている。
• 一致点: もともとは「コード未レビュー」を意味する否定的なニュアンスだったが、現在ではAI支援コーディング全般を指す用語へと意味が拡張している。

3. 「検証のない速度は技術的負債だ」（慎重派）

• 批判: コードを理解しないまま、AIが生成した成果物だけを信じるのは危険。後で発生するバグや保守コスト（技術的負債）の方が大きくなる。
• 比喩: 「運転手がどこへ向かっているのか分からないまま自動運転車に乗っているようなもの」として、理解のない実装は結局問題解決能力を下げる。

4. 「コンテキストスイッチの疲労感」（共感派）

• 同意: AIがコードを生成している間に頻繁なコンテキストスイッチ（Context Switching）が発生し、脳の認知負荷が急増する。
• 症状: AIの成果物をレビューして修正するプロセスが繰り返されることで、直接コーディングするときより精神的消耗が大きい。4時間の作業でも一日中働いたかのように疲れる。

5. 「コーディングの楽しさの喪失」（ドーパミン不足）

• 経験: 自分で問題を解決したときの達成感（ドーパミン）が消える。レゴを自分で組み立てる楽しさの代わりに、完成品だけを眺めているようで虚しい。
• 結果: プロセスの楽しさがないまま、成果物だけを素早く出す作業は開発者を疲れさせる。

6. 「初心者には毒、熟練者には薬」（習熟度による違い）

• 分析: 熟練した開発者はAIのミスを素早く見抜いて修正できるため生産性が高いが、初心者は誤ったコードをそのまま使って学習機会を失い、粗悪なコードを量産する危険が大きい。

7. 「管理者役への強制的な転換」（役割の変化）

• 現象: 開発者が自らコードを書く「創作者」から、AIが吐き出すコードをレビューして修正する「管理者／レビュアー」へと役割を強制的に転換させられる。
• 負担: 5人のジュニア開発者（AI）が書いたコードを一人でリアルタイムにレビューするのと同じような極度のストレスを引き起こす。

8. 「ビジネスロジック理解の欠如」（限界の指摘）

• 問題: AIはコードはうまく書けても、ビジネスの文脈や全体アーキテクチャは理解できない。
• 現実: 結局、ビジネス要件をコードに合わせて調整し、エッジケースを処理する複雑な作業は依然として人間の役割であり、この過程でボトルネックが発生する。

9. 「休息と余裕の消失」（機械の時間）

• 比喩: かつて工場労働者が機械の速度に合わせて働いたように、AIの高速な生成スピードに人間が振り回される「機械の時間」に閉じ込められる。
• 必要性: コンパイル待ち時間のような「強制的な休息」が消え、脳が情報を処理して休む暇がない。意図的な休息が必須だ。

10. 「ツールの過渡期的な問題」（今後の見通し）

• 診断: 現在の疲労感は、AIの生成速度に対して検証ツール（テスト、リンターなど）が追いついていないことで生じる不一致のため。
• 解決策: 生成速度に見合うだけ検証を自動化するツールが発展すれば、疲労感の問題は解決できる。

1. 形式への好き嫌い（「LinkedInっぽいノリなのか？」）

• 批判優勢: 文ごとに改行する形式が「LinkedInのインフルエンサーの気取った文章」や「AIが生成したテキスト」のようだという酷評が多数。中身はなく、見た目だけが大げさだという指摘。
• 一部擁護: 現代人の短い集中力を考慮した読みやすい配置、あるいは詩的な韻律を意図した文体だという意見。

2. 「厚い欲望」実践の体験談

• 成功事例: 彫刻（sculpting）、アナログ回路設計、絵はがき書きなど、物理的で時間のかかる趣味を通じて憂うつを克服し、人生の密度を満たした経験の共有。
• パン焼き論争: 本文の「非効率なパン焼き」の例示について、エンジニアたちがオーブンを使った「発酵時間の最適化」Tipsを共有し、逆説的なサブ議論が発生。

3. 哲学的・宗教的起源の分析

• 古い知恵のリブランディング: 仏教の「餓鬼（Hungry Ghosts）」概念や西洋哲学の古典的テーマ（アウグスティヌスなど）を、現代的な用語（Thin/Thick）で包み直したにすぎないという評価。
• 洞察の有効性: 新しい内容ではないが、現代社会に合わせてうまく整理された洞察である点には同意。

4. 二分法的論理の限界

• 概念の単純化への警戒: 「消費=浅さ、創作=厚さ」という図式は危険。深い読書（消費）も厚くなりうるし、商業的な創作も浅くなりうる。
• 休息の価値: ぼーっとすることやゲームなど、「浅く見える」活動も回復のために必要な休息でありうることを見落としているという指摘。

5. 構造的・環境的原因の指摘

• 個人のせいではない: IT企業が意図的に設計したドーパミン報酬体系（System）が根本問題だという見方。
• 現実的制約: 「私たちはすでに豊かだ」という前提への反論。住居費、医療費など生存への脅威（経済的貧困）のため、余裕のある「厚い欲望」を追求しにくい現実への訴え。

白いのがコードで黒いのがターミナルだ、という程度のリテラシー不足の状態なのではないでしょうか？ ログの見方がわからない、あるいはコピペできなければまったく開発できない状態と同じようなものです。

この記事には、Part 1 の「なぜシニアエンジニアは辞めるのか」と、Part 2 の「エンジニアの離職を止める経済的介入」という記事もあります。

https://codegood.co/writing/…

昨日も、Mac全体の空き容量を確保するために（Claudeに勝手に消させたとのことですが）すごく便利だというFacebookの投稿を見たんですが……

役員にこの記事が見られないようにできないかな…

すてきですね

こういう話を見ると、私は単純にツールのシステムプロンプトの重要性を感じます。今のところ Cursor で使うなら、個人的には opus >= gpt 5.2 > gemini 3 だと思っています。それ以外の Sonnet や 5.1 などは……個人的にはもう使っていません。ただ……gpt 5.2 は effort ごとの差がかなり大きいです……でも、いつも高い effort が良いとは限らないんですよね……なので、opus と gemini を主力で使うようになります。たまに難題にぶつかったら、3つ全部にコーディングさせて、互いにコードを評価させたあと、私が確認して適用しています。