Bun 1.4の書き換えはAIが100万行のRustコードを生成——プログラミングの終焉

これがプログラミングの終焉かどうかはわかりませんが、私の会社では専門性の終焉が徐々に進んでいるのをはっきりと観察できます。人々はアーキテクチャ、原則、物事の仕組み全般を徐々に忘れ、コードの納品速度を優先しています。そして、専門性がなければ、どんなに神のような存在でも、トークン生成マシンに愚かな質問をすることになります。外挿せずにはいられません...

これは強力な記事ですが、見出しが気を散らします。コメント投稿者への挑戦：見出しに惑わされずに内容について議論できますか？私のお気に入りの段落：> AIが100万行のコードを書き、その後数ヶ月かけてそれを洗練させ、現在何百万もの開発者のマシンで動作している信頼性の高いソフトウェアを生み出したという事実は、まったくもって驚異的です。そして、「彼らには比較対象となるオラクルがあったから、ある言語から別の言語への移行は簡単だった」と言うこともできますが、それはこの全体を過小評価していると思います。検証システムを構築し、適切な方向性を与えることができれば、AIは非常に複雑で高度なソフトウェアを生成でき、それが機能するまで洗練し続けることができます。私にとって、これはClaude Fable 5やGPT-5.6 Solクラスのモデルの特別な点を捉えています。問題を明確に検証可能な最終状態に還元し、必要なコンテキストを提供し、モデルに必要なツールを装備できれば、通常は良い解決策に到達できます。問題をその状態に還元し、その環境を設計することは、依然としてスキルであり、それが私たちに高額の報酬をもたらすだろうと期待しています。

私はこの主張に同意します。開発は、意図、整合性、ニーズの明確な理解へと向かっています。これらは常に重要でしたが、コードがほぼ無料になる未来では、顧客は自分のニーズが迅速に満たされることをより要求するでしょう。私たちのSaaS企業は、これまでほとんどの顧客にとってコストが高すぎて受け入れられなかった特注開発へ移行する計画を立てています。また、それはマルチテナントのコスト/ビジネスモデルにも違反するため、特注の未来においてホスティング、運用、サポート契約がどのようなものになるかを必死に模索しています。ここでの影響は開発をはるかに超えています。金融、コンサルティング、人事、会計、法律、デザイン、建築、医療、その他すべてでかなり大きな変化が起きているのを目の当たりにしています。知能の価値が事実上ゼロになったとき、人間はどうやって仕事市場で自分を売り込めばいいのでしょうか？一部のホワイトカラーは雇用の安定を求めて肉体労働に移ろうとするかもしれませんが、ホワイトカラー労働者のほんの一部が移るだけで、そこでも賃金は暴落するでしょう。私たちはこれに対する準備ができていません。社会的にも、経済的にも、政治的に。製造業の仕事が中国にオフショアされたときに、中間層のアメリカ人がどう扱われたかを見てください。ヒラリー・クリントンは彼らを嘲笑し、「コーディングを学べ」と言いました。私たちは、自分たちの仕事や産業が消えていくのを見ながら、自分たちにしがみつき、今日は自分たちではないことを祈るでしょう。UBI（ベーシックインカム）はすぐに避けられなくなるでしょうが、それもひどく不十分です。開発者に...を与えることは...

TFAより：「私が言いたいのは、コードを手動で書き、他の人間がレビューして有用で動作するソフトウェアを作るという行為は絶滅に向かっているということです。」「FORTRANはコーディングとデバッグを事実上排除するはずです...」-- FORTRANレポート、1954年 [1]。そしてFORTRANレポートは正しくもあり、間違ってもいました。当時「コーディング」と呼ばれていたもの、つまり高水準の仕様から機械語命令を慎重に作り出すことは、ほぼ完全に排除されました。それは別のものに置き換えられ、私たちは今それをコーディングと呼んでいます。[1] http://www.softwarepreservation.org/projects/FORTRAN/BackusE...

まさかプログラミングが自分の生涯で、ましてや生涯の早い段階で鍛冶屋の道をたどるとは思っていませんでした。

コーディングモデルの報道と、それらが生み出す出力の間には大きな乖離があります。スタイル、アーキテクチャ、クリーンさといったコーディングの純粋性に関する問題を捨てれば、彼らが生み出すものはバグだらけでエラーが発生しやすいものです。問題はアーキテクチャにあるようです。コンテキストウィンドウには限界があり、それを増やすにはより多くの計算能力が必要であり、さらにモデルが本当に過信しているという事実が重なります。しかし、コンテキストウィンドウを増やすとモード崩壊が発生します。Yann LeCunはスライドに非常に良い図を持っています。円（すべての可能な答え）と、中心から出て正しい経路を1つ示す赤い線です。モデルが誤った経路の部分列に入るのをどうやって止めるのでしょうか？それは不可能だと思います。私は仕事で何度も、誰かが（Claudeが彼らに言った）私のコードにバグがあると言ってきました。私はそれを見て、違う、それは単に正しいファイルを調べなかっただけだ、となります。そしてそれに反論すると、それは完全に崩れて謝ります。そんなことを何度も繰り返して学ばない従業員を私は雇い続けません。

> フロンティアの知能への、より広範で安価なアクセスが信じられないほどの速度でやってくる。OPの議論全体はこの前提に基づいています。そして、業界が確かにこの方向に向かっているように聞こえますが、プロトタイプの構築の成功を、業界横断的にミッションクリティカルな本番システムの維持の成功と同一視するのは、間違いなく時期尚早です。OPは次のように試みています：> プロトタイプは動作するソフトウェアです。そして、そのプロトタイプの改善とテストは、AIとのさらなる改善ループによって可能になります。それは、人間のコードレビューではなく、使用とテストを通じて改善されます。今日、使用とテストを推進しているのは誰でしょうか？「使用とテスト」からユーザーフィードバックを受け取り、それをマシンが改善に使用できる何かに変換するのは誰でしょうか？人間です。製品自体のレベルで管理するためのエージェント的なハーネスは存在せず、それが存在するとは思いません。なぜなら、それは根本的に政治的な関心事だからです。そして、タブとスペースのようなリスクの低いチーム内の種類ではなく、取引が成立するかどうかというリスクの高い種類です。たとえエージェントがそのレベルのリスクを処理できると仮定しても、彼らにはそのためのコンテキストが単に欠けており、少なくとも人間型ロボットの形でAGIが実現するまでは、コンテキストが欠け続けるでしょう。ソフトウェアエンジニアリングは死んでいません。専任の職種としての別の分野としては、それがProductロールの必須スキルセットになる世界では、おそらく死につつあると言えるでしょう...