ソフトウェアエンジニアリングの今後2年
(addyosmani.com)- AIエージェントベース開発が自動補完の水準を超え、実際の作業を遂行する段階に入り、ソフトウェアエンジニアリングの役割と参入構造が急速に揺らいでいる
- ジュニア採用の減少と効率性重視の組織が同時に現れ、少数の熟練人材がAIツールでより多くの仕事を処理する構造が拡大
- コーディング自体よりも検証・設計・判断能力が重要になり、AIの出力を扱える人間の能力が中核的な差別化要因として浮上
- **T字型人材（深い専門性 + 幅広い適応力）**が急速に変化するAI環境で有利となり、1つの分野での深さと多分野への適応力を同時に求める流れが加速
- 従来のCS学位中心の経路の弱体化とともに、ポートフォリオ・ブートキャンプ・企業主導の教育など多層的な学習エコシステムが拡大
1. ジュニア開発者の問題
- AIがエントリーレベル業務を自動化することでジュニア開発者の採用が急減する流れと、ソフトウェアが全産業へ広がることで需要が再び増える流れが同時に存在
- Harvardの6,200万人の労働者を対象とした研究では、企業が生成AIを導入した場合、ジュニア開発者の雇用は約 9-10%減少する一方、シニアの雇用にはほぼ影響がない
- ビッグテック企業は過去3年間で 新卒採用を50%縮小
- あるエンジニアの表現: "AIコーディングエージェントのほうが安いのに、なぜジュニアに9万ドルを払うのか?"
- 2022年ごろの 金利上昇とパンデミック後の調整 などのマクロ要因が、AIツールの拡大以前に先に影響していたが、AIがこの傾向を加速させている
- AI支援を活用するシニアエンジニア1人が、以前であれば 小規模チームが必要だった作業量を処理可能
- 楽観的シナリオ: AIが技術分野だけでなく、ヘルスケア、農業、製造、金融などあらゆる産業で開発者需要を爆発的に増加させる可能性
- 開発者を置き換えるのではなく、AIが開発作業をこれまでコーダーを雇ったことのないドメインへ拡大させる 力の増幅器(force multiplier) として機能
- "AIネイティブ" 開発者が特定のニッチ向けの自動化や統合を素早く構築する、別の形のエントリーレベル職務が増える可能性
- 米国労働統計局は依然として2024-2034年のソフトウェア職種で約15%の成長を予測
- 悲観的シナリオの長期的リスク: 今日のジュニアは明日のシニアエンジニアであり技術リーダーでもあるため、人材パイプラインを完全に遮断すれば5-10年後に リーダーシップの空白 が発生
- 業界のベテランはこれを "緩やかな衰退(slow decay)" と表現: 後継者育成をやめるエコシステム
-
ジュニア開発者への助言
- AIへの習熟度と多才さ を備えるべき
- ジュニア1人 + AIで小規模チーム並みのアウトプットを出せることを証明すべき
- Cursor、Antigravity、Claude Code、Gemini CLIのような AIコーディングエージェント でより大きな機能を構築しつつ、コードの大半を理解し説明できなければならない
- AIが容易に代替できないスキルに集中: コミュニケーション、問題分解、ドメイン知識
- QA、DevRel、データ分析のような 隣接ロール を入口として検討
- AI APIを統合したプロジェクトを含むポートフォリオを構築
- 見習い職、インターンシップ、契約職、オープンソースへの貢献など多様な形の経験を確保
- "訓練が必要なもう1人の新卒" ではなく、素早く学習しすぐに貢献できる 即戦力のエンジニア になるべき
-
シニア開発者への助言
- ジュニア減少により より多くの単純作業や反復業務 がシニアに回ってくる
- 日常的な作業には自動化を活用しつつ、すべてを1人で抱え込まないこと
- CI/CD、リンター、AIベースのテストを構築し、基本的な問題を早い段階で防ぐ
- オープンソースや他部署の同僚へのコーチングを通じて 非公式なメンタリング の役割を果たす
- 経営陣に オールシニアチームが持つ長期的リスク を明確に伝えるべき
- ジュニア需要が再び増える場合に備え、効果的なオンボーディングとAIベースの業務委任構造を準備
- 個人の生産性ではなく チーム全体のアウトプットと影響力を増幅 する役割に価値を集中
2. スキルの問題
- 現在 開発者の84%がAI支援ツールを定期的に使用
- バグや新機能に直面したとき、最初からコードを書くよりも プロンプトを書き、AIが生成したコード断片を組み合わせる 方式が一般化
- エントリーレベルのコーダーは "難しいやり方" を飛ばしている: 二分探索木を最初から構築したり、メモリリークを自力でデバッグした経験がないかもしれない
- 能力の中心がアルゴリズム実装から AIに正しい問いを投げ、出力を検証 する方法へ移動
- 一部のシニアエンジニアは、この流れが 独力でコーディングできない世代、つまり脱スキル化を生む可能性があると懸念
- AIが生成したコードには、経験の浅い開発者が見落としやすい 微妙なバグやセキュリティ脆弱性 が含まれる可能性がある
-
代替シナリオ
- AIが反復的で日常的な 80%の作業を処理 し、人間は最も難しい 20%の問題 に集中
- アーキテクチャ設計、複雑な統合、創造的設計、エッジケース処理
- AIの普及は深い知識を無用にするのではなく、人間の専門性をさらに重要 にする
- 誰もがAIコーディングエージェントにアクセスできるとき、優れた開発者を分けるのは AIが間違っている、または最適でないときに気づけること
- あるシニアエンジニアの言葉のとおり、"最高のソフトウェアエンジニアとは最も速いコーダーではなく、AIを疑うべき時を知っている人 だ"
- AIが反復的で日常的な 80%の作業を処理 し、人間は最も難しい 20%の問題 に集中
-
プログラミングの変化
- ボイラープレート作成は減り、AIの出力にある ロジックエラー・セキュリティ欠陥・要件不一致 をレビューする比重が増加
- 中核能力: ソフトウェアアーキテクチャ、システム設計、性能チューニング、セキュリティ分析
- AIはWebアプリケーションを素早く作れるが、専門エンジニアは セキュリティのベストプラクティスに準拠しているか、レースコンディションが起こり得るか を点検
- 2025年の開発者コミュニティでは議論が2つに分かれる
- 手でコードをほとんど書かないのだから、コーディング面接も変わるべきだという立場
- 基礎を飛ばせば、AIの結果が壊れたときにより多くの問題対応に追われるという立場
- 業界全体で AIの速度と、それを制御するための基礎的な知恵 を同時に備えたエンジニアを期待する流れが形成
-
ジュニア開発者への助言
- AIを依存手段ではなく 学習ツール として活用
- AIが提案したコードがなぜ動くのかを分析し、潜在的な弱点を特定
- 定期的にAIの助けを切り、主要アルゴリズムを最初から実装
- CSの基礎能力 に集中: データ構造、アルゴリズム、時間・空間計算量、メモリ管理
- プロジェクトを2回実装し（AIあり、AIなし）、比較
- プロンプト設計とツール利用能力を体系的に習得
- 厳格なテスト習慣を身につける: 単体テストを書く、すぐにAIへ尋ねずスタックトレースを読む、デバッガの活用に慣れる
- AIが複製できない補完的能力を強化: システム設計感覚、ユーザー体験への直感、並行性の問題に対する思考力
-
シニア開発者への助言
- 品質と複雑性に責任を持つ役割 として位置づける
- 中核的専門性を強化: アーキテクチャ、セキュリティ、スケーリング、ドメイン知識
- AIコンポーネントを含むシステムをモデリングし、失敗シナリオ を継続的に点検
- AI生成コードで頻出する脆弱性や問題タイプについて最新の認識を維持
- メンターおよびレビュアーの役割を受け入れ、AI利用を許可する範囲と手動レビュー必須領域（決済や安全コード）を定義
- 反復的なAPI接続作業はジュニア+AIの組み合わせに任せ、どのAPIを設計するかを決める創造的・戦略的役割 に集中
- コミュニケーション能力やクロスドメイン理解などのソフトスキルに継続投資
- 人間の開発者を代替不可能にする要素に集中: 健全な判断力、システムレベルの思考、メンタリング
3. 役割の問題
- 開発者の役割がAI生成コードを監督する限定的な監査役へと縮小する可能性と、AI主導システムを設計・調整する中核的なオーケストレーターへと拡張する可能性が共存している
- 極端なシナリオ1:
- 開発者の創造的責任が縮小し、ソフトウェア構築よりもAIの出力物の監査と監督に注力
- AIシステム（またはノーコードプラットフォームを使う「市民開発者」）が本番運用を担当し、人間の開発者は自動生成コードのレビュー、エラー・バイアス・セキュリティ問題の確認、デプロイ承認を行う
- 作り手が点検者へと変わり、コード創作の喜びがリスク管理の不安に置き換わる
- 一部のエンジニアは、最初からコードを書く時間よりも、AIが生成したプルリクエストの評価や自動化パイプラインの管理により多くの時間を使っている
- あるエンジニアの言葉: 「AIが投げてくるものを片付けるコード清掃員で終わりたくない」
-
代替的な未来: 高水準オーケストレーター
- 開発者が技術的・戦略的・倫理的責任を組み合わせた高水準オーケストレーターへと進化
- AI「ワーカー」によって、人間の開発者はアーキテクトまたは総合請負人の役割を担う:
- システム全体の構造を設計
- どの作業をどのAIやソフトウェアコンポーネントに任せるかを決定
- 複数の構成要素を組み合わせてソリューションを構築
- エージェント型開発環境では、エンジニアはAIエージェントとサービスのアンサンブルを指揮する作曲家に近い役割を担う
- すべてのコードを自分で書くわけではないが、アーキテクチャ・インターフェース・エージェント間相互作用というメロディーを定義する
- ソフトウェアエンジニア、システムアーキテクト、プロダクトストラテジストの役割が結合した形
- 楽観的な見方では、AIが単調な作業を処理することで、開発者の役割は必然的に高付加価値の活動へ移行する。仕事はより面白くなる可能性がある
- どちらの方向に進むかは、組織がAIをどう統合するかに左右される
- AIを労働代替の手段と見る企業: 開発チームを縮小し、残ったエンジニアに自動化の維持を求める
- AIをチーム増幅の手段と見る企業: 人員は維持しつつ、各エンジニアがより大きな問題や野心的なプロジェクトに挑戦
-
ジュニア開発者への助言
- 単純なコード記述の範囲を超えて役割の拡張を模索
- テストケース作成、CIパイプライン構築、アプリケーション監視など、監査役・管理者的な性格のスキルを身につける
- 個人プロジェクトを通じて自ら作る経験を維持し、創造的な動機を保つ
- システム思考を養う: コンポーネント同士の通信方式を理解し、よく設計されたAPIの特徴を学ぶ
- エンジニアリングブログやシステム設計のケーススタディを継続的に学習
- コード生成だけでなく、オーケストレーションフレームワークやAI APIなど自動化ツール全般への理解を広げる
- 文書を他人に説明するように明確に書く習慣をつける
- シニアに「コードが動くか」を超えて「重要な要素を見落としていないか」を尋ねる
- 単なるコーダーではなく、検証者・設計者・コミュニケーターとして成長する準備をする
-
シニア開発者への助言
- リーダーシップとアーキテクチャ責任を積極的に引き受ける
- AIとジュニアが従う標準とフレームワークを定義
- コード品質チェックリストと倫理的なAI利用ポリシーを定義
- AIが生成したソフトウェアに関するコンプライアンス・セキュリティ課題について最新の認識を保つ
- システム設計と統合の専門性に集中し、サービス間のデータフローをマッピングして障害ポイントを事前に特定
- オーケストレーションプラットフォーム（Kubernetes, Airflow, サーバーレスフレームワーク, エージェントオーケストレーションツール）に慣れる
- 技術メンターとしての役割を強化: より多くのコードレビュー、設計議論、技術ガイドライン
- 他人（または何か）が書いたコードを素早く評価し、高水準のフィードバックを与える能力を磨く
- プロダクトとビジネスの感覚を養う: なぜ機能が作られるのか、顧客が何を重視するのかを理解する
- プロトタイプ、ハッカソン、新技術の探求を通じて創作エネルギーを維持
- コードを書く人からシステムを指揮する人への転換
4. 専門家 vs ジェネラリスト問題
- 狭い領域にのみ特化した専門家は、自分のニッチが自動化されたり、急速に価値を失ったりするリスクがある
- 急速に変化するAI環境では、T字型エンジニア（広い適応力 + 1つまたは2つの深い技術）が有利
- モデル、ツール、フレームワークが素早く台頭しては衰退する状況では、単一の技術スタックにキャリアを賭けるのは危険
- レガシーフレームワークの専門家は、新しいAIツールが最小限の人間介入で同じ作業を処理できるようになった瞬間、需要が急減する可能性がある
- **「特定のスタック・フレームワーク・製品領域」**にだけ狭く特化した開発者は、その領域が衰退したり重複したりしたとき、方向性を見失う可能性がある
- COBOL開発者、Flash開発者、業界が移った際に転換しなかったモバイルゲームエンジンの専門家のように
- 過去との違いは変化のスピードであり、AI自動化によって特定のプログラミング作業が一瞬で些末な仕事になり、その作業中心の役割が弱体化する可能性がある
- 1つしか知らない専門家（SQLクエリの微調整、PhotoshopデザインをHTMLにスライスする作業）は、AIがその作業の90%を処理する状況に直面する可能性がある
- 採用市場は最新のニッチを追う。数年前はクラウドインフラの専門家が求められていたが、今ではAI/MLエンジニアの需要が急増している
- 昨日の技術に狭く特化した人材は、ニッチの魅力が失われることでキャリア停滞を実感する
-
T字型開発者: 代替的な結果
- 「多才な専門家」またはT字型開発者: 1〜2領域の深い専門性（縦の棒） + 他の多くの領域に対する広い親和性（横の棒）
- こうしたエンジニアは学際的なチームで**「接着剤」**の役割を果たす。異なるタイプの専門家と意思疎通し、必要に応じてギャップを埋める
- 企業は、浅すぎる開発者でも狭すぎる開発者でもなく、強い中核能力 + スタック全体を扱える人材を好む
- T字型エンジニアはハンドオフ待ちなしで問題をエンドツーエンドに解決できるため、効率性が向上する
- 異なる領域の知識が結びつくことで、イノベーションの可能性も広がる
- AIツールは実際にジェネラリストをさらに増幅する。1人で複数コンポーネントをより簡単に扱えるようになる
- バックエンドエンジニアがAIの助けで基本的なUIを実装できる
- フロントエンド開発者がAIでサーバーのボイラープレートを生成できる
- AIが豊富な環境では、1人がより広い範囲を扱うことが容易になる
- 逆に、深い専門性しか持たない人材は、ニッチが部分的に自動化された場合、拡張の道筋が制限される可能性がある
- 現在、**エンジニアリング職の約45%**が複数ドメインの熟練を要求する
- プログラミング + クラウドインフラの知識
- フロントエンド + 基本的なMLの理解
-
ジュニア開発者への助言
- キャリア初期に広い基盤を意識的に構築する
- 特定の役割で採用されても、そのサイロの外側にある領域を継続的に観察する
- モバイル開発者はバックエンドの基礎を、フロントエンド開発者は簡単なサーバー実装の経験を確保する
- Docker、GitHub Actionsなどのデプロイと運用ツールを学ぶ
- 個人的に興味を感じる1〜2領域を選んで深く掘り下げ、縦の専門性を形成する
- ハイブリッドなブランディングを構築する
- 例: クラウドセキュリティ重視のフルスタック開発者
- 例: UXの専門性を備えたフロントエンド開発者
- AIツールを活用して新しいドメインを素早く学ぶ
- バックエンド初学者の段階で、AIで基本的なAPIコードを生成し、構造を理解する
- 継続的なリスキリングを日常的な習慣として定着させる
- ハッカソンやクロスファンクショナルなプロジェクトに参加し、半ば強制的にジェネラリスト役割へ拡張すること
- マネージャーに、プロジェクトの他の領域にも参加したいと伝えること
- キャリア初期には、適応力そのものが最も強力な競争力である
-
シニア開発者への助言
- 自分のスキルグラフを明確に把握する
- 自分が深さを持つ専門領域
- 表面的にしか触れていない隣接ドメイン
- 隣接領域を1〜2つ選び、対話できるレベルまで引き上げる
- データベースの専門家なら、最新のフロントエンドフレームワークに慣れるか、MLパイプラインの基礎を学ぶ
- AI支援を活用して、自分が弱い領域で小さな実験プロジェクトを行う
- 既存の専門性を新しい文脈に結びつける
- Webアプリのパフォーマンス専門家なら、その技術がML推論の最適化にどう適用できるか探る
- 役割をよりクロスファンクショナルに設計する、またはそのようなポジションを積極的に提案する
- 複数領域が絡むプロジェクトで**統合チャンピオン（責任者）**の役割に自ら手を挙げる
- 他者をメンタリングして技術を広めつつ、彼らから新しい観点や何かを学ぶ
- 履歴書に多才さと拡張性が表れるよう更新する
- 蓄積した経験をもとに、繰り返し現れるパターンと転用可能な知識を整理する
- T字型のロールモデルになること: 専門分野に深みがあり（権威と自信を与える）、同時に横方向へ積極的に広げる
- 自分のスキルグラフを明確に把握する
5. 教育問題
- コンピュータサイエンス（CS）の学位が引き続きゴールドスタンダードであり続けるのか、それともブートキャンプ・オンラインプラットフォーム・雇用主主導の訓練といったより速い学習ルートがそれに取って代わるのかは不確実
- 数か月単位で変化する業界のスピードに、大学が追いつきにくい構造に置かれる可能性もある
-
シナリオ1: 大学は依然として重要だが、関連性の維持に苦戦
- 学位は基本資格として残るものの、カリキュラム改訂の遅い周期と官僚的な承認手続きのため、変化の速度に後れを取る
- 学生と雇用主は、学界が産業界と断絶しており、職務スキルに転換されない理論や古い実習を教えていると感じる
- 最近の卒業生は、学位課程でクラウドコンピューティング、現代的なDevOps、AIツールについて学んだことがないと報告している
- 大学が高い時間的・金銭的投資を求めながら関連性の低い教育を提供すれば、高価な門番のように見える危険もある
- 多くの企業が慣性で依然として学士号を要求しているため、その負担は学生に転嫁され、ブートキャンプ、オンライン講座、独学プロジェクトでギャップを埋める
- 学生ローン負債は莫大であり、企業は新卒者の訓練に数十億ドルを費やしている（職場で必要なスキルが不足しているため）
- 大学がAI倫理の授業やクラウドコンピューティングの選択科目を追加できたとしても、実際の導入時には業界ツールがすでに変わっている可能性がある
-
シナリオ2: 伝統的教育は新しいシステムに徐々に置き換えられる
- コーディングブートキャンプ、オンライン認定、独学ポートフォリオ、雇用主が作る訓練アカデミー
- Google、IBMのような主要企業が、特定の技術職で学位要件を撤廃
- 2024年時点で、企業の約45%が一部ポジションで学士号要件の廃止を計画
- ブートキャンプは成熟段階に入り、CS専攻者とともに上位企業に採用される人材を輩出
- これらのプログラムはより短期間（12週間集中）で、実用的なスキルに集中: 現在のフレームワーク、クラウドサービス、チームワーク
- 採用基準は学位よりも、実際のポートフォリオ、マイクロ資格、検証済みスキルへと移行
- 充実したGitHubポートフォリオや信頼性の高い認定が、学位要件を回避する手段として機能
- 雇用主主導の教育が拡大: 企業が独自の訓練パイプラインを作る、またはブートキャンプと直接的なパートナーシップを結ぶ
- 一部のビッグテック企業は、非伝統的な人材向けの社内教育（大学）プログラムの運営を開始
- AI自体が新しい学習方法を提供: AIチューター、対話型コーディングサンドボックス、大学外で提供されるカスタム学習環境
- モジュール型の学習エコシステムは、高コストの4年制学位よりもアクセスしやすさと柔軟性で優位に立つ
- 強力なCS大学がない国の学習者でも、シリコンバレーの人と同じCoursera講座を受講し、同じポートフォリオを構築できる
-
志望者/ジュニア開発者への助言
- 伝統的なCS課程にいても、それだけで十分だと考えないこと
- 実際のプロジェクトで授業を補強する: Webアプリの構築、オープンソースへの貢献
- インターンシップや産学連携プログラムを積極的に活用
- カリキュラムに欠けている最新トピックはオンラインプラットフォームで補完
- GCP、AWS、Azureなどの業界認定を取得し、実務能力を明確にシグナルする
- 独学やブートキャンプ中なら、説得力のあるポートフォリオに集中: 少なくとも1つの実質的なプロジェクトを適切に文書化
- 開発者コミュニティで活動する: オープンソースへの貢献、技術記事の執筆
- LinkedIn、ミートアップ、開発者イベントなどを通じたネットワーキング
- 経験ある開発者からの推薦と信頼を得る
- 継続的な学習を前提に考える : 技術スキルの有効期限は短い
- AIを個人チューターとして積極的に活用
- 具体的な方法でスキルを証明する: ポートフォリオ、認定、自分の仕事について知的に語る能力が扉を開く
-
シニア開発者およびリーダーへの助言
- 過去の資格や学位だけで永遠に持ちこたえることはできない
- 継続教育に投資: オンライン講座、ワークショップ、カンファレンス、認定
- 新しい方法でスキルを検証; 実際の問題を通じて現在の能力を評価する面接に備える
- 新しい技術を活用したサイドプロジェクトを継続
- 職務要件を再評価する: 本当にCS学位が必要なのか、それとも特定のスキルと学習能力が必要なのか?
- スキル中心の採用を推進し、人材プールを拡大
- 社内訓練プログラムや徒弟制度スタイルの役割を支援
- 正規の経歴を持たないジュニア開発者向けのメンターシップサークルを支援
- 学界および代替教育との交流 : 諮問委員会、招待講演、カリキュラムギャップに関するフィードバック
- 自身のキャリア成長にも反映する: 実際の成果と継続的学習が追加の学位より重要
全体を貫く核心
- 提示されたシナリオは互いに排他的ではなく、現実は各シナリオの要素が混ざり合った形で展開する
- 一部の企業はジュニア採用を減らす一方で、他の企業は新しいドメインで開発人材を拡大
- AIが日常的なコーディングを自動化するほど、人間が直接扱うコードに対する品質基準はむしろ上昇
- 開発者は午前中にAIが生成した成果物をレビューし、午後には高水準のアーキテクチャを設計するといった業務フローもあり得る
- 全体を貫く文脈は、変化だけが唯一変わらない要素だという認識
- 技術トレンドとそれに対する懐疑的な視点の両方を持ち続けるほど、過度な期待や悲観に巻き込まれる可能性は減る
- 技術を継続的にアップデートし、能力を拡張し、創造性・批判的思考・協働のような人間固有の強みに集中するほど、流れから取り残されない
- コーディングのルネサンスが来ようと、コードが自ら書かれる時代が来ようと、全体を見て継続的に学び、実際の問題解決に技術を適用するエンジニアへの需要は常に存在する
- 未来を予測する最良の方法は、それを積極的にエンジニアリングすること
10件のコメント
Fortranが登場し、C++が登場し、Javaが登場し、Next.jsが登場しても、SWEにはCSの理解が必要だったように、AIが登場してもCSに関する基礎知識は必須だと思います。結局、変わるのは道具だけで、本質は同じです……。IT業界にいる限り、学び続けなければならないのは宿命です……
とてもいいですね。ジュニアからシニアまで、みんな読むべき文章です。
去年から来年までが、ソフトウェアエンジニアリングにおける最大の転換期になりそうです。
ここで時代の流れを見失うと、かなり後れを取ってしまうかもしれません。
自分もたまに同じことを考える。終わりがない。
「たまに、ソフトウェア開発を選んだのは間違った決断だったのではないかと思う。
シニアになっても、相変わらず勉強やサイドプロジェクトを求められる。
いつになったら趣味や社会生活を持てるのか分からない」
今、AIを仕事に十分取り入れられていないなら、FOMOを感じるのも悪くなさそうです。
本当に洞察に富んだ文章だと思います。
私は現場24年目のシニア開発者で、2024年下半期からLLMを通じた開発とバイブコーディングを極限まで活用してみています。AOS/iOS、Webサービスのフルスタック、バッチ、モデルのファインチューニングまで本当に幅広く活用しており、5つほどのエージェントを立ち上げて作業しています。
時間がたつのも忘れて開発し、そのまま寝落ちするような体験を2000年代初頭以来またすることになるとは思いませんでした（笑）。
閑話休題、最近の私の考えでは、開発の領域はすでに誰でもできるものになりつつあります。
コーディングエージェントの進化はさらに加速し、開発はますます簡単で楽になるでしょう。ExcelやWordの文書を作成するくらいのレベルになるはずです。
アンドレイ・カルパシーの言うとおり、最高の開発言語は「英語（言語）」だという意見に同感です。
個人的には、AI論文をもっと読み、論理的に表現するために文章をもっと書くようにしています。（AIと対話することももっと増やそうと努力しています）
本当にとてもワクワクする毎日ですね。
翻訳記事があったので共有します。
https://rosetta.page/post/…
洞察に富んだ文章ですね。何度も読み返しています。
アーキテクチャ、QA Engineerが生き残る時代になるだろう。これが合っているのか間違っているのかを判断する……
Hacker Newsの意見
正直、今はすべてが巨大な賭けのように感じられる
技術、学歴、人脈、仕事のどれも、人生の安定した基盤を保証してくれない
借金を返し、家を買い、家族を築いた人は、これからの安定を賭けているようなものであり、学生ローンと不安定な社会的基盤を抱えた新人は、人生そのものを賭けているようなものだ
今は家族ができて、簡単に引っ越したり節約モードで暮らしたりできないので、ずっと不安だ
プログラマーであろうとなかろうと、誰もがもうすぐ代替されるのではないかという不安の中で生きている
アメリカ経済もめちゃくちゃで、今は暮らしにくい時期だ
経済面もあるが、社会的スキルが乏しくても得られた安定した仕事を失うのではないかと怖い
あと4年半で基本的な経済的自立が可能になるはずだが、そのときどんな気分なのか気になる
25歳ならやり直せるが、42歳で家族がいたら本当にストレスだろう
一番良い時期はキャリアの初期で、次に良い時期はまさに今だ
私の経験では、LLMはコーディングを自動化するというより、速度を上げるツールだ
欲しい解決策を頭の中で描き、LLMにブロック単位で説明しながらコードを積み上げていく
ライブラリ関数や文法を検索する必要が減ることが一番大きい
問題は、悪いコードでもしばしば十分に収益性があることだ
プロトタイプや概念実証には向いているが、保守可能なコードには適していない
ベンチとダムのたとえのように、誰でもベンチは作れるがダムはそうではない
LLMは低品質なコードを簡単に作らせるが、高品質なコードは依然として必要だ
なのにHNでは「vibecoding」のような大げさな話ばかりで、実質的な議論が難しい
LLMはますます自律的に働けるよう発展しているが、その速度は漸進的だ
むしろ非開発者が初めて自分たちの仕事を自動化できるようになったことこそ、本当の変化だと思う
これは業界全体に大きな影響を与えるだろうし、結局はコンピュータ本来の目的に近づくことでもある
AIでコード行数を増やすのは達成ではなく、むしろ技術的負債を積み上げることだ
Rustが特に役立つ
システムが大きくなるほど、むしろ開発がしやすくなるという逆説的な経験をした
AIがジュニアの仕事を自動化するなら、それは単に**「ジュニアの定義」が変わる**ということだ
ジュニアが消えるのではなく、役割が変わるのだ
2024年に14人いたインターンが、2025年には4人に減った — 予算を60〜70%削減
昔はチームの半分が新人だったのに、今では全員シニアのチームになっている
私は、AIが各業界で開発者需要を爆発的に増やすというシナリオには共感する
ただし、その役割が必ずしも「開発者」である必要はないと思う
各業界の既存職種が、AIをうまく扱う方向へ進化していくだろう
結局重要なのは、特定ドメインの知識を学びながら同時にAI活用能力を身につけることだ
ただ、CTOたちがSaaSを置き換えられると気づいた瞬間、社内ソリューション開発ブームが来るだろう
AIがコードを代わりに書く時代なら、重要なのは検証の速度だ
自分でコードを書けば理解度が高まり、理解があってこそ検証できる
結局、速度と正確性の間のトレードオフを受け入れなければならない
コードが一気に流れ込み、速さへのFOMOのせいでレビュー品質が落ちる危険が大きい
ツールのUXそのものが油断を誘う
AIがあらゆる業界で開発者需要を増やすという主張には懐疑的だ
すでにソフトウェアはあらゆる業界に深く入り込んでいて、残っているのは完全自動化だけだ
しかしそのボトルネックは技術ではなく、政治的・現実的な問題だ
自動車革命のように新しい職種群を生み出すわけではない
ソフトウェア依存からの脱却が必要で、特にドイツはこれから本格的にコンピュータを使うべきだ
元記事の筆者は、AI関連の核心的な問いへの理解が不足しているように見える
たとえば「専門家は自動化される危険がある」という話は逆だ
専門家はツールを監督し、非専門家はツールの指示に従う
大学も同じで、理論を知っている人が機械を制御する
ああ、もう全部投げ出したいという冗談を言うだけだ
面白いことに、筆者がCOBOLの話をしていたが、私の隣人もいまだに銀行でCOBOLの仕事をしている
14年前もそうだったし、今もそのままだ
ときどき、ソフトウェア開発を選んだのは間違った決断だったのではと思う
シニアになってもなお勉強やサイドプロジェクトを求められる
いつになったら趣味や社交生活を持てるのかわからない
JSフレームワークが変わるたびに、キャリアが賭けのようだった
Angularに全振りしたらReactに変わるのを見て、いつもどこに投資すべきか悩んでいた
結局、一生不安の中で賭け続ける気分だった
しかし卓越性を望むなら追加の努力が必要だ
どちらも正当な選択だ
会社の目的は利益を出すことであり、個人の生活は自分で守るしかない
安定した会社でゆっくり学びながら働くこともできるし、トレンドを追って速く成長することもできる
結局は自分の目標と価値観次第だ
しかしお金が目的で、それを達成したなら問題はない
ただし最高を目指すなら、仕事そのものを愛する必要がある
とても参考になりました 👍👍