Ask HN: シニアエンジニアの現在のキャリア軌道は？
Ask HN: What is the current trajectory of a senior engineer?
最近、ますます考えるようになった。設計ループに人間が必要とされなくなるのはいつか？ LLMがコードや数学など正誤を判定できるあらゆるもので最大限にRLされているなら、AnthropicやOpenAIなどが優れたアーキテクチャと悪いアーキテクチャのデータセットを内部で構築（そして買収）し、それをRLすることの何が止めているのか？ 2024年にはLLMは高機能なオートコンプリートだったのに、今ではエージェントを使った「ソフトウェア工場」の構築が話題になっている。この発展を止めるものは何だと思うか？ なぜソフトウェアアーキテクチャは1〜2年後もエージェントにとって難しいままなのか？ ますます多くのソフトウェア開発者がこれを無視して「人間にはエージェントを導き、アーキテクチャを設計する役割がまだある」と言っているのを見るからだ。ビジネス的には、実際のソフトウェアプログラマースキルの必要性は数年で90%なくなると思う。そして、より多くの人材スキルを持つプロダクトリードなどが優遇されるだろう。良い時代だった。
ソフトウェアアーキテクチャは、単に正誤が明確な問題ではない。要件、トレードオフ、組織の制約、進化するビジネス目標など、多くの文脈依存的な判断が絡む。LLMがRLで学習できるのは、明確な報酬信号があるタスクに限られる。アーキテクチャ設計にはそのような信号がほとんど存在しないため、エージェントが人間を完全に置き換えるのは難しいだろう。
私はむしろ、シニアエンジニアの役割は「コードを書くこと」から「エージェントを監督し、品質を保証し、ビジネス価値に結びつけること」へとシフトすると見ている。プログラミングスキルが不要になるのではなく、より高次のシステム思考やドメイン知識が重要になる。プロダクトリードが優遇されるというより、技術とビジネスの両方を理解するシニアエンジニアが重宝されるはずだ。
LLMは確かにコード生成やリファクタリングで強力だが、アーキテクチャの決定には長期的な保守性、セキュリティ、スケーラビリティ、チームのスキルセットなど、定量化が難しい要素が関わる。これらをRLで最適化するのは現実的でない。むしろ、エージェントが生成した設計を評価し、修正する人間の役割は増えるかもしれない。
「ソフトウェア工場」のビジョンは魅力的だが、現実のソフトウェア開発は予測不能な変更やレガシーシステムとの統合、ステークホルダーとの調整が絶えない。エージェントはこれらの曖昧で政治的な側面を扱うのが苦手だ。したがって、シニアエンジニアの需要はなくなるどころか、エージェントを効果的に活用できる人材として価値が上がる可能性がある。
私は懐疑的だ。LLMの能力は目覚ましいが、アーキテクチャ設計は創造性と経験に依存する。RLは既存のデータから学ぶが、真に新しいパラダイムを生み出すことはできない。シニアエンジニアは依然としてイノベーションの中心にいる。ただし、ツールとしてのAIを使いこなせるかどうかで差がつくだろう。
HNでの議論
74- dimbletimbers
開発者やHNの人々は、平均的な人がコンピュータについてどれだけ知っているか、気にかけているか、あるいはコンピュータと関わりたいと思っているかを過大評価しすぎていると思う。仕事がどう変わろうと、コンピュータと話すのが好きで、メールやYouTubeを見せる以外のことをコンピュータにやらせる方法を知っていれば、あなたは一歩先を行っていて、おそらくその地位に留まれるだろう。
- RugnirViking
パフォーマンス、テスト、オブザーバビリティにもっと焦点を当てることを提案する。
人間の理解と品質／保守性にお金が集まる。エージェントを使ってそれらを作れるようになろう。
エンジニアが完全に絶滅するとは思わないが、数はずっと減るかもしれない。「AIの使用はスキルである」という最近の議論（https://news.ycombinator.com/item?id=50063427）は私の感覚をよく捉えていると思う——これらのツールから最高の結果を引き出すために学ぶべきことはあり、おそらくこれからもあり続ける。つまり、それを行うために報酬を得る人々がいるということだ。自分がその一人になるようにしよう。
- bradfa
LLMが登場する前は、ソフトウェアエンジニアリングチームの役割としてプロダクトマネージャー、プロジェクトマネージャー、スクラムリーダーなどがいた。LLMを活用した開発が進むにつれて、これらの役割とエンジニアリングへの越境が融合していくのを見るだろう。
エンジニアが、プロジェクト管理、顧客の声、エンジニアリングとマネジメントの間の仲介者としてタスクを整理することが、できる／すべき／必要とされることだと知らなかったわけではない。単に、一人でできる以上の仕事があったため、以前はタスクの委任だったのだ。今では、これらすべての役割を部分的にLLMにオフロードできるが、それでもエンジニアリングを導き、ビジネス／顧客とインターフェースする人間がループに入っていることは依然として価値がある。
全体として何を作るか、次に何を作るか、後で何が来るか、そして製品がビジネス目標とどう関係するかを知ることは、依然として非常に人間的な営みだ。
- gregwebs
シニアエンジニアおよびすべてのSWEのポジションは、よりテックリードのようなものになっていくだろう。
AIを指示し、ソフトウェアエンジニアでない人がAIを指示してソフトウェアを開発するよりも、費やした時間／金額あたりより多くの価値を生み出せるなら、あなたは依然として多くの価値を生み出せる。
これはプロトタイプでないほとんどのものにとって、今すでに当てはまるはずだ。仕事は「コードを書くこと」から「ソフトウェアを出荷すること」に変わった。テックリードだ。
ますますインテリジェントなAIソフトウェア開発をアクセス可能にするソフトウェア製品は、ソフトウェアエンジニアの関与の必要性を減らし続けるだろう。しかし、ソフトウェアは1000倍にもなる。だから、適応する人々には機会が続くかもしれない。
- apimade
時には悪いアーキテクチャが正しいアーキテクチャであり、良いアーキテクチャが間違った選択であることもあるからだ。
「ベストプラクティス」でCarmackのDOOMが作れたと思う？まさか。
私は非常に才能のある人々の下で働いたことがあるが、彼らは予測したり予期したりできたはずの問題に対して、間違った技術、アプローチ、設計を選んだ——もし以前にその問題や類似の問題を見たことがあったり、提案されたソリューションを管理する組織、顧客、チームの規模についての文脈を持っていたなら。しかし、彼らにはそれがなかった。
AIは教科書的で「エンタープライズグレード」のソリューションを出すのが得意だが、コード生産コストが下がるにつれて、シンプルで消化しやすいソリューションの価値は高まると思う。TDDなども役立つが、ある時点で過度に抽象化され、複雑になりすぎ、一人では把握するのが難しくなる。
その時点で、ユーザージャーニーを理解するテストマネージャーは金の重さに値する存在になり、どんなソリューションでも本当の価値は、優れた、表現されたテストになるのだ。