AIの時代にプログラマーを解雇するのは大間違いだ！
引用元：https://news.ycombinator.com/item?id=43010814
見出しを読む人と、実際に日常的にAI使ってる開発者の間に大きなズレがあるんだよね。AIは得意なことと得意じゃないことがあるって分かってるし、成熟したコードベースに大きな変化をもたらすには遠い気がする。少しの単純なコードや説明、ちょっとした変更は得意だけど、それ以上は難しいと思う。
LLMは本物の技術やプログラミングスキルを持つ人をより求められるようにすると思う。若いプログラマーはプロンプトエンジニアリングに直行して、技術的なスキルを薄っぺらにしか持たなくなるだろう。現実的に考えれば、LLMがあるからといって全てが解決するわけじゃなく、実際にシステムを作る人間は必要なんだ。
私たちテックの人は、新しいツールが新参者に影響を与えて、結果的に私たちが得をするって妄想にふけってるところがある。実際は、新しく入った人はまず手っ取り早くものを作るために手を抜いて、後から知識を補填するものだよ。
LLMの使い方は少し違うと思う。Ruby on Railsはハイウェイみたいなもので、それを覚えたらどんどん探求できるけど、LLMはGPSみたいなもので、指示に従うだけだと全体の理解が薄いと思う。自分だけで道を覚えようとしないと本当に身につかない。
LLMは人間が書いたコードを元に訓練されてるけど、その情報に対する注釈がないから問題があって、他人が指示を受けた結果をただ模倣する可能性があるんだ。
実際、そういうことは起きてると思う。Google Mapsの「代替ルート」って、他の人が予期しない道を通った結果が反映されてるし、その結果、余計な情報を増やしちゃうんだ。
Google Mapsは変なフィードバックループを持ってるね。特定のルートが混んでると別のルートを提案するけど、今度はそのルートが混雑するってパターンになってしまう。
Google Mapsを使う人が多い場所なら、交通パターンに影響を与えるって考えもしなかった。車もスマートフォンも持ってないから、全く違った視点になるね。
君はテオドール・カジンスキーのゴーストなのか？マジで、スマートフォンなしでどうやって仕事してるの？
OPじゃないけど、私もスマートフォンは使ってるけど仕事では使わない。雇用主が特定のアプリを使わせたければ、ノートパソコンのように提供してくれればいいと思う。
スマホがないってのは苦労するよね。今はほとんどのことをスマホなしでやるのが大変だし、仕事もその一つ。銀行の口座にアクセスするのにも携帯が必要だしさ。
スマートフォンじゃない携帯電話もあるし、2FAに使うコードを“ダム”フォンに送信するのも全然問題ないよ。結局は電話番号だけだから。
うちの銀行はSMSコードの利用を認めてないんだ。アプリを使って認証済みの電話番号でPINを入力するのが必須になってる。
ナビアプリが更新されてないと、運転手が通れなくなったルートを通るようになっちゃうのは困るよね。
LLMを使う前からOsmAndは変なルートを指示してたよ。Palo Altoを通る時に渋滞するオフランプを勧めるのが全く意味不明なんだ。
オーストラリアでは、街を出るとルートがトラックドライバーに影響されすぎてると思う。地図が変な町のバイパスを勧めるとこもあったり。
その左折して待つのを指してるの？スタンフォードのラウンドアバウトから高架に行く方が速いのにな。
OsmAndで同じようなことを見たことがある。地図を描くときに誰かが間違えたんじゃないかと思ってるけど、まだ確認はしてないよ。
OsmAndは交通データを使ってないからさ。逆エンジニアリングしたURLを使えば交通地図を表示できるけどね。
交通データの話ではなくて、もし世界に唯一の車の持ち主だったら、そのルートは絶対に悪い選択だと思うんだ。安全性は下がるけど、あのルートを通る理由はないよ。
交差点とか道の合流地点が一番危ないと思うけど、やっぱり安全に関する懸念が増えるかもね。
大都市のインターステートでは、GMが出口で降りて迂回するように勧めてくることが多いんだよね。特にラッシュアワーの時に多く見かける。デンバーで特に気づいてるけど、他のエリアでも同じことがある。
実際にそれはもう起こってるよ。地図アプリが変な迂回を指示することが多くて、機械を無視した方がいい結果が出ることもあるから。ネット検索の方向に向かってるよね。
確かに面白い考えだね。検索が悪化する明らかな要因はあるけど、ナビゲーションにそういう力はないはずなのになんで悪化するんだろう。
多分、ちょっとイヤな想像かもだけど、店舗に多くの車が通りかかるほど、立ち寄って何か買う可能性が高くなるんじゃないかな。
その通り！素晴らしい観察と比喩だと思う。
今のLLM GPSは、平均して1日に1回は間違った場所に誘導するから、その都度地図を確認するか、目的地を再設定しないといけないって感じ。たしかに良い比喩だね。
インターネットが普及する前のインドの道案内に似てる気がする。道を尋ねて自信満々に教えてもらうけど、正確な指示にはならないから、新しい人に聞いては進むを繰り返す、って流れ。プログラミングに似てて思わなかったな。
インドでは人々がフレンドリーで親切だから、知らないことでも手助けしようとする。それってLLMのユーザー体験とも近いよね。
シカゴのLのWestern blue lineの停留所をGPSに聞いてみて。2つあって、ランダムに1つを選ぶから。
ここで言う”自分のGPS”ってなんのこと？Google MapsやApple Mapsはいつも近い方を選ぶし、合理的だと思うけど。忙しいときとかスーパーのチェーンで迷ったりすることはあるけど、ランダムには感じないな。
ちなみに、さっき言ってたのはLLMsのことね。Google Mapsを15年使ってるけど、リアルGPSでランダム感は感じたことない。99％の確率で目的地にうまく到達できたし、周りの道路工事や渋滞も問題なし。人によっては全然違う経験をしてるのは不思議だね。
この件については少し改善されたのかも。ただ、UberやLyftが目的地を知ってるのを選ぶのはランダムみたいな気もする。
俺は地図が好きで、行くところを注意深く見て、GPS（Google Maps）を使う前後で意識してるんだ。これが地理を覚えるのに役立つ。だから、LLMsを使って勉強せずにただコピペしてる人はスキルを学べないけど、ちゃんと回答を見て自分で調整してるなら、オンラインコードスニペットと同じ位の学びは得られると思う。
俺はGoogle Mapsを使って道を覚えるのに助けになってる。いや、友達と話してたけど、車のナビで地図を北が上になるようにロックするのが簡単じゃないって驚かれたんだ。相対的な進行方向での判断はちょっと面倒だけど、こうすることで道の位置を学ぶのが楽になると思ってる。
俺もこれをやってる人がいるって聞くと嬉しい！北を固定してると、広いエリアでの自分の位置がわかるんだ。逆にしないと、外を見てる景色との関係が全く理解できないよ。
LLMsはGPSであって、高速道路じゃないって言えるね。この例えすごく好きだし、的を射てると思う。家具を作るなら、LLMsは電動工具で、フレームワークはIKEAのパックみたいな感じ。
このアナロジーが今月のベストだね。昔のタクシー運転手みたいに、今の運転手ってその街を暗記してるわけじゃないし。皆さんと一緒にアプリをゼロから作れたことは貴重な経験でした。
LLMsはGPSで、高速道路じゃない。何をするか、どこへ行くか教えてくれるんだ。それでもコードを見れるから、ブラックボックスじゃない。好奇心のある人は常に好奇心を持ち続けるよ。
見ることができるコードは、地図上の指示に似てる。ここでみんなが言ってるのは、地図の指示が場所を学ぶのに役立つってことだけど、俺は全然役立たない。好奇心がないわけじゃなくて、自分で進むことで学ぶことが多いんだ。
地図を学ぶには、周りをズームイン・アウトして、知らないランドマークを見たりしないと。GPSを使ったり、コードをコピペしてばかりだと学べないよね。
このアプローチを取るコーダーは、関連スキルがない人がほとんどって問題がある。
今までずっとStack Overflowからコピペしてた人たちのことだよ。
今のLLMはコードを書くためのGPSみたいなもので、実際のGPSではない。指示をもらってその通りに進む感じで、時には素晴らしいコードも生成するけど、技術的負債の沼って時もある。一昔前は全く不可能だったのに、今は可能性が無限大だ。
昔はRuby on Railsの情報を学んでいたけど、今のプログラマーは何も学んでない。LLMから情報をコピペするだけで、自分で考えない。何かがうまくいかないと、コードをデバッグせずにLLMのせいにする。実際の知識は頭に残らず、未来での学びも無理になるよ。依存しすぎる開発者がいると、コードを元に戻すことすらLLMに聞かなきゃいけない。人間がゾンビみたいに見えるのが怖い。説明を求めても沈黙。考えてないから。
依存しすぎな開発者がいて、コードを戻すのにLLMに聞いてた。それに、LLMに書き直しを依頼することで、微妙に変わってしまったり、コメントが失われたりすることもある。
昔はコンピュータの知識を学んでいたけど、今のプログラマーは本当に何も学んでない。ただ機械的に打つだけで、コンパイラの文句ばかり。知識が抜け落ちて、学ぶことも進化も無理になっちゃうんだ。ある開発者は、機械コードをトレースすることすら知らなくて、デバッガに聞いていた。ゾンビのように見えて本当に怖かった。メモリのセグメンテーションについて説明させても、何も返ってこない。考えないからね。
それはちょっと違うよ（スレッド内の他のやり取りからもわかるけど）。高級言語を使う人は、自分の考えでその言語でコードを書くことができる。間違いが出てもコンパイラのエラーメッセージを元にデバッグするけど、LLMからコードを得る人は間違った時にどうしていいかわからないことが多い。デバッグは学べるスキルだけど、求めるものが違ってる人もいる。
抽象化がさらに抽象化されて…。AIブームからどんな新しいツールが出てくるか見ものだね。新しい抽象化の階層が何になるのかまだわからないけど、その段階で使える道具がまだ未完成って感じ。
正直、分かる気がする。良いジュニア開発者が成長してるのが見えるし、悪いジュニア開発者には大変なビジョンが見える。楽観的に見ると、これによってジュニア開発者がより深く複雑な技術スタックに進む余地が増えるかも。これから必要になるSW開発者はもっと増えるだろうし、ツールが進化するにつれ、今まで不可能だったことが可能になるはず。
ソフトウェア開発者はもっと必要になるはずだよね。コードは単なる負債で、我々が本当に気にするのはその結果。AIツールがコードを生成するのはいいけど、その生成されたコードをメンテナンスできるのかはわからない。いきなりレガシーコードだらけになる可能性があるけど、誰も理解してないから大変だよ。
結局、クソみたいなコードも普通のコードも、LLMが出すまぁまぁ書けてるボイラープレートも見るだろうね。最終的に、結果はオペレーターの経験とスキルに依存するから、ツールや言語と変わらないよ。
君が理解してると思ってるけど、AIがシステムを完全に作っちゃう世界では、誰もそのコードを理解してない可能性がある。今まで人間が設計してたから、管理すらしたことないシステムを維持するのは超難しいと思うよ。
人間はデザインに必ず関与しないと無理。AIに現実の制約を説明する必要があるから。AIがホントに賢ければ、生成されたコードを平易な英語で説明できるようになるはず。いまでも、LLMsはコードの要約が得意だよ。
哲学的な質問だけど、誰も理解してないLLMが生成したコードは、今の人間が理解できないレガシーコードと何が違うのか？解決策として高額な人材を雇うことも無理だし、理解できる開発者が見つからないリスクもあるよ。
コードは負債だってよく言われる。どのコードも技術的な負債だって表現する人もいるし、これは共感できる。
一人のHNerが言ったように、コーディングはSWEに対する手術の切開みたいなもんだよ。
これらのAIツールは、彼らが想像したコードのせいで発生したプロダクションの問題に対してPagerDutyを受けても解決できないと思うよ。
コードは負債だってホントにその通り！コードを書くことは、ビジネスやプロジェクトの運営全体に対して小さなステップでしかなく、できるだけ控えた方がいいんだ。
もっと高度な技術スタックはやめてほしい。つまらない技術スタックを選んでよ。高度なスタックは大きな無駄だから、実際に必要な時だけ使ってほしい。
スタートアップのエッジケースって競争優位性をもたらすものだよね。他の人と同じやり方だと同じ結果になっちゃうから、運営のどこかは最先端である必要があると思う。
洗練されてることが「退屈さ」を増減させるわけじゃないよ。
『洗練された』の辞書定義は『欺瞞的に変わった』みたいな意味で、テクノロジーの文脈では『退屈』とは真逆だよ。
それは『辞書』の正しい定義じゃないよ。Wiktionaryを見てみて。
その定義は超古臭いよ。今の使い方には合わないから。
どの辞書見たのか知らんけど、それは全然言ってることじゃない。
シンプルなCRUDアプリを作るときは人がやってる方法を使うのが良いよ。でも、退屈なテクノロジーの限界に来たらどうするの？洗練された技術がコストを下げたり、エンジニアの時間を節約したりすることもあるし。
『退屈』な技術スタックはスケーラブルだよ。流行りの新しい技術は期待外れになりやすいから、退屈な選択肢を選ぶのが一番だと思う。
俺は何も反論じゃないから。時には新しい技術を使うのが必要だってこともある。Linuxカーネルの例を挙げると、パケットの処理がうまくいかないとき、 boringな選択肢にだけ頼るのは良くない。
これらはそんなに『流行』とは思わないね。流行を気にするなら、もっと新しいユーザースペースとカーネルスペースの解決策があるはず。
他のプロジェクトのio_uringやaf_xdpの例もあるけど、2020年にebpfを決定したときはまだ新しくて流行りだった。選んだ機能がメインラインカーネルに入るまで待たなきゃいけないこともあった。新しいことが必ずしも良いとは限らないし、選択肢をきちんと評価するのが大事。
今日は技術スタックが高度だってことを知った。リッチな開発者向けのものなのかな。
この意見には賛成。若い開発者は前の世代より早く学んでて、それを嬉しく思ってる。多くの人にとっては受け入れられないことかもしれないけど、自分の経験の価値について考える方が良いと思う。
若い開発者が早く学んでるとは思えない。今の学生はLLMで宿題を出して、学ぶ意欲が育たない気がする。努力せずに諦めちゃう若者が増えるのは嫌だな。
若い開発者が早く学ぶとは思ってたけど、彼らの質問を見始めて考えが変わった。
”無知でいるのはあまり満足感がない”って言っても、危険だし、雇い主を破産させる可能性もある。例えば”S3のアバターアップロード”システムなんか、ちょっとコードを書いただけじゃ意味がない。攻撃者に悪用される危険があるし、そんな自信で工程を進めるのはおかしい。
今のLLMは基本的にStack Overflowの無限回答版だけど、その質は堕落してる。プロンプトが新たなGoogle検索になっても、十分じゃないと思う。大規模なコードベースにはスケールしないから、若い開発者はまるで秘書のようになってしまう。
私もツール開発を重視してるけど、LLMが私のAPIの特定の部分で手助けするってことは、そこの改善が必要ってことを示してるんだね。
LLMと他のフレームワークのインタラクション方法が違うから、学べないんだと思う。LLMを使って問題を解決するには、自分から学ぼうとしなきゃいけない。やる気がないと人から教えてもらえないから、学ぶ環境が整ってない感じ。
記事の通りで、基本的なスキルは将来には重要だけど、プログラマーの多くは最初から小さなことから始めるから、将来的にはコーディングの文法をあまり悩む必要がなくなると思う。今はハードウェア特化型のコードを書く人がいまだに需要あるの？
この記事は業界の問題をズームインして見ると正しいと思う。AIが助けてくれるおかげで、コードの修正が心理的に楽になったんだよね。例えば、Twitterがその例だし、優秀なタレントをキープするインセンティブが減ったのも大きい。会計業界が電子スプレッドシートで変わったように、ソフトウェア開発も大きな変化が訪れると思う。
いいポイントだね。俺のオフショアのアプリサポートからエンジニアへと移った旅も色々あった。業界は今、いろんな人がいて、成長している人もいれば、停滞している人もいて、移動したりリストラされたり退職したりしてる。
同意するよ。俺もPHPのころからの経験があるけど、技術が金儲けになってからは、満足するためじゃなくて金のためにやってる人が多い。そうなると手を抜いたり、基礎を学ばずに安易な修正ばっかりするようになるのが心配だ。
今の市場で、基本的な技術を理解してないエンジニアを雇おうとする企業なんてあるの？結局、サポートしきれないことになりそうだよ。
この数十年、会社は「誰かがジュニア開発者を育ててくれるだろう」と思ってた気がする。その結果、良い候補者を見つけるのが難しいと気づくんだよね。ジュニア開発者がLLMを使っても状況が変わるとは思えないな。
いいポイントだと思う。初めてのプログラミング授業で、先生が「とりあえずこれを覚えとけ」って言ったのが印象的だった。基本の重要性を理解するまで時間がかかったけど、実際はコンピュータの挙動を知るために良いアプローチだったと思う。
その通り。でも、やっぱり一度プログラミングを始めてしまうと、自分が成長するのをあまり考えない人も多いよね。古いアプリを無理にブラウザアプリに移行して、無駄な苦労をすることになったり。
長い間プログラミングを続けていると、金目的で入った人も多かったけど、今でも本当に好きな人もいるから、ジュニアからエキスパートへの道は完全には失われないと思う。LLMが増えるけど、それでも情熱を持っている人は残るはず。
確かにお金のために入ってくる人はいるけど、それでも技術を愛する人がいる限り、ジュニアからエキスパートへの道は大丈夫だと思う。技術者の中には、本当にものを作るのが好きな人がまだいるはずだ。
教育を受けたい人はいるけど、やっぱり医者のように不足している分野があると大変だよね。これがコミュニティ全体に悪影響を与えることもあるし。
テクノロジーの業界にいる私たちは、新しいツールが新人を困らせて、結果的に自分たちに利益になるって考えがちだよね。でもこれは別の分野でも同じことで、熟練技術者がどんどん引退して、新しい人が入ってこないんだ。結局みんなが困るし、業界全体が影響を受けるんだよ。
ちょっと疑問だけど、うちのチームのジュニア開発者はAIに助けられすぎてる気がする。彼は使い方は上手いけど、基本的な部分で苦しんでいるみたい。AIはすごく簡単に説明できるけど、やっぱり基本を学ぶことも大事だと思うな。
私は、最初は簡単なツールを使って、徐々に知識を積み上げていく感覚がすごく共感できる。Excelから始まって、AccessやDjangoを使ってきて、様々な技術を学んできたんだ。
ああ、確かに無知のままいるのはあまり満足できないよね。でも、実際にはそれで満足な人も多いんだと思うよ。多くの人は、コードの深い理解は求めていないから。
それはそれで良いと思うけど、ナンドゲートの技術者も仕事がないわけじゃないでしょ。
ソフトウェアが特定の品質を求められるとは限らないよね。15年前のエンジニアなら、デスクトップアプリにフルブラウザを同梱するなんてありえないと思ってたはず。今ではそれが普通。無駄かもしれないけど機能してるんだ。
テクノロジーの進化ってこんな感じじゃないかな？PythonやJavaが出てきて、昔のCエンジニアが、新しい世代がメモリ管理を理解していないって嘆く。ウェブ開発も同じで、新しい世代がNPMパッケージを使って簡単に作っているのを見て、昔のJavaエンジニアが不満を感じるんだ。実際、理解していないことが重要でないことも多いけどね。
シニア開発者の価値は、知識が多いことではなく、複雑なシステムを設計して作るスキルにあると思うんだ。この知識はほとんど文書化されていないから、AIには学べない。AIは見たものをコピーするだけで、それが何故そうなったか理解していないから問題なんだ。これはソフトウェア開発だけでなく、他の仕事にも言えると思う。
過去に抽象化の層があったからといって、これからもそうなるとは限らない。例えば、ノーコードツールは期待通りに普及しなかったし、結局は開発者のための適切なツールも必要なんだ。最適な抽象化レベルがあると思っていて、ある程度のレベルのHTMLやJavaScriptやサーバーサイド言語が必要だと思う。
ノーコードツールの話が出たのは面白いな。実際にはあんまり上手く機能しなかったと思うけど。たとえば、SquarespaceやWixがサイト作りを楽にしているけど、純粋なウェブ開発者にとっては難しい時代になってきているよね。
Excelってノーコードシステムだけど、たまにデータをありえない方法で弄っちゃうこともあるよね。例えば、何かを入力したり他のところからインポートしたりしたら、なんか日付っぽく見えちゃうことがある。そういうの、結構困る。
Excelの達人って多くがVBAに費やしてるんじゃない？ そうじゃない人を見つけるのはなかなか。
20年間金融で働いてるけど、Excelはあちこちで使われてるよ。Excelの達人はいるけど、VBAを使ってるのはめったに見たことないな。
多くの会計士や弁護士がExcelを活用してるけど、基本的な関数だけ知ってればいいって感じだね。マクロを書く人は少数派で、金融モデルの監査が難しくなるからあんまり使わない。
Excelは純粋な関数や命令的なコード（最近はVBAやPython）、データベース（セルのグリッド、シートなど）、可視化ツールを持ってるから、ぜんぜんノーコードじゃないよ。
技術的には正しいけど、間違ってる部分もある。Excelのノーコード面は、ユーザーが開発について知らなくても必要なものを作れる点だよ。
Excelはほとんどノーコードじゃないよ。重い使い方なら、公式を使うから普通にコードだよ。
ノーコードアプリでも結局コードが裏にあることが多いから、同じようなもんだよね。
確かにノーコードってプログラムしないことを示すけど、Excelはそうじゃない。プログラミングするか普通のスプレッドシートアプリケーションだから、ノーコードって言うのは無理があると思う。
反対だな。セルに公式を書くのはコードだし、複雑なワークシートならVBAが必要になるよ。
最近のWeb開発では、昔のJavaの人たちが新しい世代がNPMパッケージを組み合わせてポリフィルを使ってるのにイライラしてるのが感じられる。実際の問題は、今の技術スタックがクソだってことだよ。JavaScriptはブラウザで唯一使える言語だったから人気になったけど、本当はひどいところがある。Pythonも大規模プロジェクトには向いてないのに、小さなプロジェクトから始めてだんだん大きくなると、それを使い続ける人が多い。良い言語を開発して、特にブラウザで動かせるものを提供しないと、悪循環は続く。
Web Assemblyを使えば、C++など他の言語でも書ける。でも、DOMにアクセスできないから、結局JavaScriptが必要なんだよね。
今、息子がCSの専攻で勉強してるんだけど、彼のカリキュラムを見てると、基礎から教えてくれてる。システムアーキテクチャやアセンブリ言語、オペレーティングシステムの授業もあるみたい。みんなテストのためだけに暗記してる気もするけど、少なからず何かは覚えると思う。
確かにしっかりしたCSのカリキュラムは今でも存在するよ。でも、息子はブートキャンプ出身の人たちと一緒に働くことになるだろうね。息子は深い理解を持ってると思うけど、ブートキャンプ出身者でも結構やれてる感じ。
自分の教育は、実際に後で学ぶことの目次みたいなものだと思ってる。
彼らはほとんど概念を覚えてるけど、細かいところはあまり記憶してない。でも、それがあるだけでも高レベルの問題を考えるのには役立つよ。
昔のC出身の人たちの給料は、ハードウェアやパフォーマンスを気にしない普通のWeb開発者よりも大きく変わらないみたいだ。
給料は労働の供給と需要によって決まるから、仕事の難しさだけではない。ゲーム開発は企業のWebサービス開発よりも大変だけど、誰がより多く稼ぎますかって話だよ。
こっちでは彼ら（C出身者）は給料はいいし、普通のWeb開発者が作る混乱を片付ける時間が多い。
本当の専門家はライブラリを書くべきなんだよ。自分の専門に特化して、それを多くのプロジェクトで活かすことで、大学での学びのコストを分散できる。Cライブラリを呼び出すのが簡単になったしね。誰かがPythonインターフェースを書けば、Numpyが多くのFLOPをBLASライブラリに提供してくれるし、Cから最適化されたライブラリを呼ぶのに誰が気にするかって思う。
LLMに依存しすぎて、プログラミングの基盤を支えるライブラリを書く専門技術が失われつつあるのが問題だと思う。
プログラマーは自分の好きな言語でCPUエミュレーターくらいは作るべきだよ。ホントに貴重な経験になるから。
俺は大学でコンピュータエンジニアリングを学んだから、自分たちでCPUを設計してFPGAに実装したよ。さらに進んで、ロジックゲートから設計したりVerilogで書いたりして最適化を考えればいい。
パイを焼くためには宇宙を作る必要があるって言うけど、あるレベルまで下に行くことはあんまり役に立たなくなることもある。
年配の人は、若い人が自分たちの学んだことを知らないって不満を感じがちだよね。俺が1997年に卒業したときも、教わってなかったことに驚かれたことがある。新しい知識が常に生まれているから、4年のカリキュラムに全部詰め込むのは無理がある。
パイの下の宇宙は守らなきゃいけない法律でできている。OSやライブラリ、ウェブブラウザのバグを知ることでエンジニアとして成長できる。多くの若手は、呼び出している関数が完璧だと思い込むから問題を調査できない。これがPythonやRustのような基盤にも当てはまる。
正直、宇宙を作るのはかなり役立つ。
子供の頃、TI-99/4aで4ビットCPUエミュレーターを書いたことがあって、それがCPUの仕組みを理解するきっかけになった。大学でCを学び始めたときにはポインタも直感的に理解できたし、すごく価値のある経験だった。
特に、大量の古いCプログラマーが解雇されたわけじゃないと思う。みんな違うことに取り組んでいるだけだ。
歴史的な変遷と今回の変遷の間にどんな違いがあるのか気になる。このツールを使って学ぶ新しい開発者が増えるにつれて、機械の理解や問題解決能力が完全に失われる閾値があるように思う。
新しい開発者がAIツールを使って学ぶようになると、機械の仕組みが理解できなくなってしまうんじゃないかな。Spring Bootのコードを扱ったとき、何をしているのかまったく分からないやつらが適当にやったコードを見て、修正できなくなった経験があるよ。
PythonやJavaが登場したとき、古いCエンジニアたちは今の若者が物事を理解していないって愚痴っているけど、使う言語にはちゃんとした使い道があるからね。難しいシステムを制御するのにはLLM生成のコードを使わないだろうし、簡単なアプリにはそれで十分だと思う。
ペンを１ドル、１本の線には１０００ドル。重要なのはその５％。
みんなはこう思いたいけど、実際にはそうでもないよね。
最後の５％こそが、その価値の部分なんだよ。
自分の職場を見回しても、昔からCコードを書いていたのは多分自分だけ。誰も自分にメモリバグのことで聞いてこないし、同僚と同じ給料。知識は個人的に嬉しいけど、実際の利益は思ったほどじゃなかった。
悪いアイデアを排除したり、ループを最適化することで価値を提供してるけど、その結果は評価されてないんだよね。雇用主にとって、知識を持っている人を雇うことは実際には価値をもたらしている。
今のあなたの強みは、LLMでは置き換えられない専門知識を持っていること。給料は同じでも、安定感はあるんだ。
自分の職場で使っている言語がメモリバグの問題を大きく隠しているからかな？もし組み込みシステムやコンパイラ、OSを作る仕事だったら、もっと高く評価されるんじゃないかな。
本当のシステムプログラミングの知識があれば、特定のツールチェインを革新したり、自分の製品を出す方が良いだろうね。ビジネスのことはあまり好まないかもしれないけど。
LLMは高水準言語への移行よりも生産性が大きく向上すると思う。
最近ChatGPTに行き詰まりの問題を聞いてるけど、まだ正しい答えをもらったことがなくて、生産性も上がってない。
全く知らないライブラリでもLLMに頼って早くコードを動かせた。最近新しい機械式キーボード設定もLLMとやり取りして簡単にできた。
LLMの性能がランダムすぎる。合成器やLinuxの問題では助けてもらえたけど、pyroの時はうまくいかなかった。経験の差はそのせいかも。
今やってるようなコーディングなら、高水準言語でLLM無しで続けるよりも、低水準言語でLLMありの方が選びたい。
低水準言語のアセンブリプログラミングにはLLMがいても無理。現状だと高水準言語の進化の生産性向上はLLMに近いものがないし、LLMも高水準言語の改善から恩恵を受けるだろう。
プログラミングは機械と対話する手段だ。今のAI、特にLLMやエージェントは多くの欠陥があるけど、大部分のプログラマーよりはマシだと思う。未来のプログラマーは皆使うようになる。使わない人には、質の悪いコードが山ほど生まれて、手直しが必要になるだろう。
多くのプログラマーの現実を反映してると思う、LLMがプログラマーよりマシってのは。
OSカーネル開発者は必要ないし、ビジネスロジックのCRUDアプリを書く人がほとんど。LLMがウェブアプリ開発で優れてる理由は学習データの量や質だと思う。
OSコードは需要が少ないから、CRUDのウェブアプリコードに比べてLLMの訓練データが少ないって理由だね。
OSのコードは質が高いから、無駄が少ないんだよね。
量の問題は否めないけど、Windowsのソースコードはひどいもんだし、TempleOSみたいなのもいるしね。
全てが崩壊する可能性が高いと思う。LLMが教育に投資したエントリーレベルの人を置き換えるから、昇進する機会がなくなる。このままだと知識が失われて、それを再構築するのは難しいよ。
昔の上司がPerl使いで、15年後にはWindstreamでパケット管理してたんだけど、もうそんな技術に詳しい人はあまりいないんだよね。
数十年やってきたけど、多くの開発者はOSも書けないし、複雑なSQLすら書けないんだよ。抽象化された開発環境で簡単なことしか考えてない。
多分、ORM使ってクエリを書くより簡略化する方向に行くんじゃないかな。ORMが書くSQLは最適化されてないことが多いから、スケールアップするとパフォーマンスが問題になるよ。
同意。今の世代は15年前のJavascriptフレームワークと似た状況にある。ちゃんとした技術を知っているエンジニアは必ず必要だけど、AIが低いレベルの開発者を仕事から失わせると思うな。
確かに必要なエンジニアはいるけど、面接がひどくて良い人材が見つからない。履歴書がすぐ捨てられることが多いし、苦労するよ。
数年後には、LLMが生んだコードを再構築・修正する必要が出てきて、開発者の雇用がブームになると思うよ。
でも、ジュニアの人たちがその修正作業に必要なスキルを持ってないと思う。エントリーレベルの市場は厳しくなると思うな。
プロンプトエンジニアリングって、無駄なシェルスクリプトや意味不明なクラスが増えるだけだと思うんだ。AIがそういうのを学んじゃったら、無知が強化されちゃうよね。
LLMが普及することで、本当に技術を持った人がさらに求められるようになると思う。若いプログラマーがプロンプトエンジニアリングだけで満足しちゃうのは危険だよ。
ジュニア開発者がChatGPTを使ってすごい成果をあげたんだ。成熟したコードベースは厳しいかもしれないけど、始めるにはいいよね。
確かにプログラミングは消えないけど、今は誰でもコードが書けるっていう印象が強い。でも、実際にはプロンプトだけじゃ何も作れないから。
リアルプログラミングって何だろうね。自分はスタートアップで高レベルのPythonとJSを扱ってるけど、大きなコードベースでの要求理解は大変だよ。
PythonやJSは柔軟だけど、OSカーネルみたいに動機づけられた開発があるところは全然違う。子供の遊び場と工事現場の違いみたい。
論理的バグに悩まされることが多いから、AIが大きなコードベースで問題を解決するなら、一般知能に近いんじゃないかな。
コードは現在の機能を説明するものだけど、なぜそれが必要かを理解しないと理由付けはできないんだ。それがプログラミングの肝だと思う。
AIがウェブ開発を完全にこなせるようになったら、明らかにAGIだと感じる。最初はできないかもしれないけど、長くはそのレベルには留まらないと思う。
今こそ低レベル言語を学ぶ絶好のチャンスだと思う。結局、テクニカルな人が大きな成果を持つ時代になるから。
LLMが動くオペレーティングシステムを書いたり、お金を安全に保存する銀行のシステムを作ったりするのはプログラマーだと思う。AIがこれを全部やるなんて想像は現実離れしてるわ。今のAIはマーケティングのバズワード的存在だから、誰が実際にデータを扱ってるのかはちゃんと知りたいね。
ソフトウェアエンジニアも最終的には厳しい状況に直面するかもしれない。多くの企業は株主のことしか考えてなくて、顧客のために投資するより、壊れた商品でも売上が上がればそれでいいって感じ。GoogleやFacebookも昔の基本的な機能を全く満たしてないし。
若いプログラマーがプロンプトエンジニアリングにすぐ飛びついて、技術的な成長がないって心配してる人もいるけど、逆にAIを使うことで早く学べる世代になると思う。技術を磨けるチャンスが増えるんじゃないかな。
今の教育現場でLLMを使って宿題をやる学生の現状は悲惨だよ。人は楽な解決法を求める生き物だから、努力を避けようとする。でも知識が浅くなる危険性があるから、バランスが大事だね。この傾向の中でも、真剣に学ぶ優秀な生徒はいるけど、平均的な人は抵抗を選ぶだろうね。
若いプログラマーがプロンプトエンジニアリングにすぐ飛びつくから、本当に技術スキルのある人がもっとうまくいくってことだね。たぶんPythonが新しいアセンブリ言語みたいになるかも。
技術的な深さが需要に影響を与えるかもしれないけど、AIを自動化ツールとして見ると、逆に需要が減るかもしれない。EE業界も技術スキルは深いのに需要はイマイチだしね。
トレーニングデータに関する比較があるけど、LLMの存在がスキル形成の障害になるって考えるのは面白いね。
これって、CTOの甥っ子の話のレベルだけど、コストが100倍になってる感じ。
“プロンプトエンジニアリング”が独立した分野にはならないと思うよ。結局、SEOみたいになって、いずれはそれに飲み込まれるんじゃないかな。プロンプトを作るにはサービスとして外注する方が理にかなってるよ。
新人がLLMを使ってもっと深く理解できるようになるってのは間違いだと思う。今の若い世代は熱心で、技術を学ぶツールもいいし、十分に競争力がある。
最近の若いプログラマーはプロンプトエンジニアリングに飛びついて、技術的な成長をあまりしない気がするな。ただ、これはLLMが登場する前からあったことだと思うけどね。結局、みんなJavaScriptのライブラリをまとめるだけになっちゃってる。
無コードなデザイナーがLLM使って自分のスタートアップアイデアをMVPにするって話を聞いてる。真剣になったら、実際のエンジニアが必要になるだろうけど。
車を運転できることと、エンジンの仕組みを理解することの違いの例が良いと思う。どちらも役立つが、整備士を雇って運転させることはないよね。
もし車がほとんどのソフトウェアみたいに信頼性がなかったら、運転にメカニックが必要になるだろう。
カリフォルニア州知事のGavin NewsomがAIエージェントを使って予算を管理する提案をした。AIが重要なコードを書くのは遠い話じゃないと思ってる。今実行するのは危険かもしれないが、数年後にはどうなるかわからない。一部の職業は本当に危険にさらされているのは明らかだ。
最近のAllInポッドキャストでAaron LevieとChamath PalihapitiyaがLLMがソフトウェア開発者をどうするかについて話し合ってた。Chamathは開発者への依存を減らしたがっているようで、AIがSaaS市場を90％縮小するって予測していた。ビジネスリーダーがこんなに率直に話すのは驚きだった。
そうだね。いいニュースは面接が楽になるかも、悪いニュースは資格のある候補者が減ること。われわれはLLMがOSを書くこともデバッグすることもできないことを知っているけど、雇う側はLLMがプローズや曲を書くのを見ると疑問に思ってしまうかも。
AIが進化する中で成果を上げるプログラマーの条件について議論してるのを見ると、One True Scotsmanが使われてることがよくわかる。もっと具体的にスキルや状況を論じてほしいと思う。才能がどれだけ重要かは愛情よりも大事かもしれない。
LLMがリアルな技術者をもっと求められるようにすると思う。若いプログラマーたちはプロンプトエンジニアリングに飛びつくけど、技術を極めていない人も多い。最近のStack OverflowやPythonフォーラムの傾向は、一部の人が問題が発生すると経験豊かな人に無料で解決を求めることだ。
航空機のミッションクリティカルなシステムがLLMで完璧に運用されるなんて考えるのは現実からかけ離れすぎてる。大企業の経営陣が短期的な利益で手抜きをすることが分かってるのに、これにはリスクがあるよ。
飛行機の重要なシステムを想像してみてよ。LLMが全て管理できるなんて現実と乖離しすぎだと思う。飛行機のメーカーは利益のために安全を犠牲にすることがあるのに、どうしてLLMを使うことをためらうと思う？
多くの開発者がAIを使う実験を許可されてないから、限られた経験しか得られないんだよね。最初の数万行のコードではいいツールがあっても、実際のプロジェクトでは厳しいってこと、気づいてない人が多い。
私の会社も使わせてくれたけど、周りの開発者がちゃんとした人に連絡してないから効果的に使えてない。便利なのは間違いないけど、大規模な変更は難しいね。毎回悪戦苦闘してる。
AIを使ってコードを書いてると、すぐに訳がわからなくなることが多い。完全に新しい領域だと特にそう。簡単なサーバーのコードを書いてみたら、まったく機能しない複雑なものができ上がった。
基本的なものを作るのには良いけど、改良を重ねるとすぐに幻覚を見始める。エンタープライズの大規模なコードベースを考えると、プログラマーの代わりにはならないと思う。
私もChatGPTを使ってゲームを開発してるけど、少しのプロンプトで全てを忘れちゃう。初めは強力なのに、複雑なシステムのスケッチを描くときには全体を把握できなくなる。
私も似たような状況で、最新のモデルでも簡単なプロジェクトでさえ安定しないことが多い。50-200行の短いスクリプトには便利だけど、大きなプロジェクトでは難しすぎる。
Claude 3.5 sonnettを使ってるけど、大きなコードベースでは不安だね。小さいプロジェクトはいいけど、実際のコードを書くときは自分でやった方が早いよ。
私も試してみたけど、きちんとした機能を指定して AI に頼むと失敗する。約300行の個人プロジェクトでも限界を感じる。今のモデルでは期待外れが多い。
大規模な変更を頼む時に準備が必要か気になった。コードベースに慣れさせるために何かステップがあったの？私はまだそのモデルを使ったことがないから、興味がある。
エンタープライズのコードベースの情報量を保持できるモデルは存在しないって。800,000行もあって、トイプロジェクトよりずっと大きいのに、普通のプログラマーの方が実装する方が早いって。
オープンソースのモデルで最大1Mトークンが扱えるって聞いたけど、30kLoCくらいなら多くの変更には対応できるんじゃないかと思う。でも、使ってるモデルのコンテキストウィンドウが小さいのかもね。
普段どれくらいのコードベースを扱ってるの？商用モデルを試したけど、補完やユーティリティ生成には使えるけど、あまり役立たないって感じ。大手は特別なトレーニングをしてると思うけど、俺らはそれができない。
数百万行のプロジェクトばっかりだよ。Devonはコードベースを事前処理するから、他のモデルと違うみたい。ただ、リアルタイムには対応してないから、能力を見たいなら複雑なコードベースでの例が必要だね。
そのモデルを使って大きなコードベースで有意義なコード生成ができたことあるの？生産性の向上が期待できるって言われてるけど、実際はそんなに効果的じゃないって。
そのモデルを使ったことないからどうかは分からないけど、君が観察している結果が最適じゃないかもしれないってこと。
Devonの能力については、賛否両論聞くよね。
コードベースを理解させた？いろいろ試したけど、数百行のゲームでも整合性がなくなったり、複数を変更するのができないことが多いんだ。
全体を学習させるチャンスを与えた上での話をしてると思うけど、AIモデルが複雑なコードベースを維持・開発するのに特化すれば、自動化できると思うよ。
自分の経験もそうだが、文脈を自動化できないならプログラマーを代替するAIツールはないって。10,000ファイルから関連するものを手動で選ばなきゃならんのじゃ、結局自分が動かなきゃならんってこと。
前の返事を削除したみたいだけど、それはちょっと皮肉だったと思う。どうして全コードベースをモデルに取り込まないんだ？Devonってツールなら出来るらしいし、他のプロバイダーもこの手順を自動化できると思う。それが大規模な変更に役立つのか気になる。
コメントを編集して、ツールについての無知から質問してた自分を説明したのか。前の文は確かに皮肉に見えたよ。Devonみたいに全コードを取り込んでも、選ばないと大きな文脈に気を取られるので、実際には役立たないって。
自分のコメントが皮肉に見えたとは思えんけど、即ダウン_voteされて驚いた。そんなことせんで議論を続けるほうが良いんじゃないか？Devonが全コードを事前処理できるなら、何かしらの作業をしてるんだろうし、気になる。
君のコメントにはダウン_voteできんよ、下のコメントだから。HNでは子コメントや孫コメントにはダウン_voteができないからね。君はダウン_voteの影響を考えて、逆に自分のコメントを上げてあげたよ。
一瞬議論してたのに、次の瞬間にはバーでAIに替わられるって嘆いてるかもよ。
全コードベースを取り込むって言うけど、それ何を指してるの？コードベース特化型の手法やモデルの微調整、システムコンテキストに全コードを注入することを言ってるのか？
実装詳細は非公開だから、正直分からないけど、Devonや1Mウィンドウコンテキストのqwenモデルは、他より「文脈の欠如」問題に対してもっと強いかもしれないってことがポイントだね。
AIの助けで成長したコーディングってかなり大きくなってるんじゃないかな。面白い指標として、時間と共にAI生成のコードがどれくらい増えてるかを追跡するのが良さそう。ただ、手書きで書くのにかかる時間はラインによって違うから、完璧な指標ではないけどね。
それ追跡するの、すごく助けになると思う。自分のプロジェクトでは大きくなるにつれて、モデルを使ったコード生成が難しくなってきた。確かに書かれたコードが便利になるけど、文脈のウィンドウが足りなくなるのは避けられない。Autocompleteはうまくいってるけど、エンジニアのサポートにはなるけど置き換えにはならないと思う。でも、今後一人のエンジニアがより多くのことをやれる可能性はあるけど、長期的にエンジニアの仕事が減るとは限らないね。
将来的にはAIが生成したコードの確認が必須になるかも。法的な問題次第だけど、企業はコードの出所や履歴を確認しなきゃいけなくなるかもしれない。例えば、うちの会社はオープンソースをレビューして、GPLのコードを使わないようにしてる。もしかしたら将来的には“AI監査”が一般的になるかもね。
ソフトウェアエンジニアが通常やってるプロジェクトの種類を考えてほしい。大きくて複雑なプロジェクトを前提としてるけど、逆に言うと90％のエンジニアはボイラープレートコードを書いてると思う。特にPHPみたいな言語はLLMツールが活躍する部分が多いね。
複雑さの話じゃなくて、コードが大きすぎてモデルの役に立つ文脈ウィンドウに収まらなかったり、見えない問題がたくさんあるかどうかがポイント。多くの人が扱ってるコードはこれらの条件に当てはまることが多い。マイクロサービスも文脈を外に出しちゃうから逆に悪化させるだけって思うし、ツールは役に立ってるけど誰かの職を脅かすほどじゃないと思う。
現状AIはプログラマーを置き換えられないけど、これから数年で実用的なプログラミングタスクにもっと適応するようになるんじゃないかって心配してる。AIの進展を見てるとこの脅威を無視できないんじゃない？OpenAIが今年、推論ベースのソフトウェアエージェントをリリースする可能性が高いと思うし、競技プログラミングではトップの人たちと同じぐらいのレベルになってきてる。1年前はそんなことなかったし、1年後はどうなってるかなんてわからないね。
未来の進展がどうなるかなんて誰にもわからない。人間は今の流れを未来に当てはめるのがすごく苦手だよね。80年代の映画が30年後について予測してたようなものだ。Back to the Futureでは2015年にはホバーボードがあるって言ってたけど、いまだに待ってる！
計算能力の向上とアルゴリズムの効率化は急速に進んでるけど、なぜBack to the Futureをドキュメンタリーだと思ったのかはわからない。
クリスタルボールを持ってない限り、この進展が同じペースで続くって確証はないよね。だから、コメントの後半を真剣に受け取った理由がわからない。
未来のことに関して誰も確定的なことは言えない。今のデータを基に最も可能性が高いことを考えるしかない。
こういうの見るとやっぱりこの分野はまだ根本的な問題があるんじゃないかって思うよね。
それが根本的な問題だと思う？問題解決できると思うけど、最近はそういう’根本的な問題’って実はそんなことないことが多いから自信ないな。
プログラミングでは出力をフィードバックループで検証できるから、こういうエラーは大した問題じゃないよ。
数値結果の話じゃなくて、考え方の問題なんだよ。テストは sanity check であって、プログラムの正しさを考えるのの代わりにはならない。
逆に、10年以内にプログラマーが正当に置き換わるとは思わないけど、企業は試してくるだろうし、その結果、プログラマーだけが苦しむことになると思う。
みんな期待値が高すぎるし低すぎる。モデルが人間のエンジニアを完璧に置き換えると思ってるけど、実際そうじゃない。進歩があったし今できることも多いのに、さらに進歩しないと思ってるのは悲観的すぎる。
ChatGPT 4 が出たのは2年前だけど、それ以降あんまり進展がないと思う。
本当に？コストがかなり下がって、全てのベンチマークで大きな変化があったのに。なんか色々起きてる気がするんだけど。新しい能力も増えてるし。
ベンチマークって、単体では意味がないんだよ。実際に役立つことの指標みたいなもん。色々使ってるけど、モデルの質が落ちてる気がするし、最初の LLM と比べると今はあんまり変わってない。
大きくなって、見た目が良くて、速いけど、やっぱり飛ばないんだよな。
そうだね。gpt5の違いを見たくて待ってたけど、gpt4の後は停滞感があるね。
表面的には奇妙な主張だと思うけど、詳しく見れば違うかも。
ソフトウェアの分野にもよるけど、現実ではLLMの文脈ウィンドウは小さいから大きな変更には長いこと対応できないよ。特にニッチな分野だと。もし小さなプロジェクトでLLMに全コードベースを与えられるなら、問題が起きるかも。LLMの出力はプロンプト次第で、実際的な使用には程遠いよ。
AIをよく追っているなら、この脅威を軽視するのは難しいはず。最新のLLMを実際のコードを書くために使ってみて。生産準備が整ったコードを書くには程遠い。
どうなるか見てみよう。モデルが十分に良くなるかもしれないけど、最後の数パーセントの改善を過小評価している気がする。
ちょっと逆説的だよね。十分に賢いAIがいたら、みんな仕事を失うかも。でも、AIがソフトウェア開発には秀でてるけど、他の仕事ができないって場合、みんな他の職業を学ばなきゃいけない。
バグを修正するには因果モデルが必要だけど、LLMにはそれがない。彼らは大規模なインデックスからのパターンマッチングでしかない。因果モデルは仮説を生成し、世界に関する主張を検証するための道具が必要だよ。
因果モデルにはシンボリックな機械が必要で、仮説を生成して検証できるものが必要。LLMにはその能力がない。人間の脳がシンボリック計算をしている証明が必要だ。
人間の脳が何をしているかはわからないけど、抽象的な世界や現実の世界のシンボリックな理論やモデルを作れるのは知ってるよ。
同意だ。AIによってソフトウェアエンジニアが解雇された実例はまだ見たことがない。それに、もし企業がAIに頼ってエンジニアを解雇するなら、その企業はすぐに潰れるだろうね。
