「職人プログラマー」と呼ばないでほしい——AI時代にエンジニアの定義が書き換えられている
Don't call yourself an artisanal programmer
LLMを使わずコードと深く向き合う開発者を「artisanal coder」と呼び、AI利用者を「software engineer」とする風潮に異議を唱える。かつて信頼性を重視する姿勢こそエンジニアリングの本質だったのに、今やvibecodingが唯一まともな方法とされ、丁寧な開発は遊び扱い。この用語の逆転はファシズムの手口に似ており、AI生成コードにもアート同様の倫理を求めるべきだと主張する。
誰もが電気を扱う人が電気技師になるわけではない。多くの人は電気工になる。そしてそれは問題ない。
HNでの議論
57- jlamberts
エンジニアリングとは、ある目的に資するものを作り出すことであり、同時に一連の制約の中で動くことでもある。その一部として、「あらゆる状況で100%正確/信頼できる」ことは非現実的な目標だと認識することも含まれる。なぜなら実装時間とコストも制約の一つだからだ。
優れたエンジニアは、堅牢性とコストのこのトレードオフを認め、それに応じて行動する。たとえば、安全性が重要なシステムやOS、医療技術など非常に基礎的なシステムに取り組んでいるなら、堅牢性を極めて重視すべきだ。そうでなければ、それは簡単に過剰設計になり得る。エンジニアの仕事は、自分が作っているものにとって、コストと正確性の曲線上の正しい地点を見つけることだ。
これは昔から常に真実であり、LLMは方程式の特定の部分を変えるにすぎない。たとえば、コードを書くことは以前よりはるかにボトルネックではなくなったので、「使い捨ての実装で試して、これが動くか見てみよう」ということが、突然経済的に実行可能になった。また、実際には多くのものが、私たちの一部が信じていたほど正確である必要はないということも分かってきた。
私たちは質の高いものを作ることを楽しみ続けられるが、そうすることはしばしばエンジニアリングというより職人技の行為である。
- cortesoft
奇妙なことに、私は用語が逆になると思っていた…私は職人とは量より質を重んじ、すべてを美しく長持ちするものにする人だと考えている。一方、エンジニアはどちらかというと生産性と公差と効率に関わる。職人はより良い品質を作るが、エンジニアや工場のプロセスのようにはスケールしない。ただし大量生産品は量のために質を犠牲にする。
- barrkel
エンジニアリングのかなりの部分は、信頼できない部品から信頼できるシステムを組み立てることだ。
セーフガード、冗長性、多層防御、復旧システムを組み込む。システムのモデルを構築し、その特性を証明する。
ソフトウェアは根本的に自動化である。LLMはソフトウェア自体の構築を自動化することを可能にする。彼らは人間よりはるかに速く安く、そしてより信頼できない。（人間も信頼できない！）
この時代の当面の課題は、長期的に、大規模に、信頼できるソフトウェアを信頼性高く構築する方法を突き止めることだ。これはエンジニアリングの課題であり、それを乗り越える唯一の方法は、やってみることだ。物事は荒削りになり、技術のカンブリア爆発が起こり、ほとんどのアプローチは失敗し、モデルが品質と能力を向上させるにつれてさらに多くが生き残らないだろう。しかし、私たちはそれを解明するだろう。
エージェントコーディング以前の時代のように手作業でものを作ることもエンジニアリングになり得るが、それはこの時代の核心的な課題ではなく、まもなく趣味、あるいは一種の贅沢品になるだろう。手作りの車を欲しがらないのと同じように、手書きのソフトウェアを欲しがることもなくなるだろう。それは機械製のソフトウェアのような精度、性能、信頼性を持たない。
- tibbar
私は「クラシックに訓練されたプログラマー」という言葉の方が好きだ。:-)
- spawrks
コードが行うこととコード自体の間には違いがあるのではないだろうか？私は、追うのが恐ろしく大変だが効果的なコードを伴う、本当に美しいソフトウェアを見たことがあるし、技術的には驚くべきものだが本質的に何も成し遂げていない美しいコードも見たことがある。ソフトウェアは木工のようなもので、あらゆるレベルの注意と製品の成果を含んでいる。