6 ポイント 投稿者 GN⁺ 2023-11-15 | 3件のコメント | WhatsAppで共有
  • プロのプログラマーである筆者は、子どもにコーディングを教えようとしていた確信が GPT-4 を体験して揺らぎ、子どもがタイピングできる年齢になる頃にはコーディングの職業的価値が変わっているかもしれないと考える
  • 最新のコーディング経験がほとんどなかった友人のBenは、ChatGPT Plus と GPT-4 でコマンドラインツール、iPhoneの単語評価アプリ、マイクロコントローラーとFirebaseを連携するコードをすばやく作り上げた
  • コーディングは長らく忍耐、反復的なデバッグ、機械の限界を感覚的に理解する mechanical sympathy を必要としてきたが、AI支援は詳細実装や難解な知識の一部を自然言語での対話に置き換え始めている
  • GPT-4 にはまだプロのプログラマーに及ばない部分があり、一般人が同じように扱うのも難しいが、プログラマーとAIが組み合わさった centaur 型は、人間単独やAI単独とは異なる生産性を見せる
  • コーディングそのものの重要性が下がるほど、何を作るべきかを判断し、ユーザーが好むものを理解し、技術的にも人間的にもコミュニケーションする力がより重要になる可能性がある

GPT-4が揺るがせたコーディングの職業的確信

  • 筆者は、親が読み書きを教えたように、自分の子どもにもコンピュータープログラミングを教えようとしていた
    • コーディングは映画制作から物理学までを包み込む新しい技術であり、必須の能力だと見なされていた
    • プロのコーダーである彼は、子どもがタイピングできるようになる頃には コーディングの価値 が失われているかもしれないと感じた
  • 転機は、友人のBenと一緒に Times 風の クロスワードパズル をコンピューターで作る趣味のプロジェクトだった
    • 2018年にはソフトウェアの助けを借りて土曜版のパズルを作り、人間は少し趣味や好みを反映させる程度だった
    • 今回は人の手を介さずにパズル作成プログラムを作ろうとした
  • Benはハードウェアには強かったが、プロとしてのコーディング経験は短く浅く、ほぼ20年前の水準にとどまっていた
    • しかし ChatGPT Plus に加入し、GPT-4 をコーディング補助として使い始めた
    • プロジェクトに必要な小さなツールを驚くほどの速さで自力で作り出した

趣味プロジェクトで見たAIコーディング補助の性能

  • 辞書ファイルからランダムな100行を出力するコマンドを作るとき、筆者は問題を考え、検索し、試行錯誤を重ねた
    • Benは GPT-4 にやりたいことを伝え、動くコードを得た
    • 筆者は、こうしたコマンドはもともと厄介で誰でも調べる領域なので「本当のプログラミング」ではないと考えた
  • 数日後、Benは辞書の単語を評価する iPhoneアプリ を作りたいと言った
    • 筆者は、Appleのプログラミング環境、新しい言語、UIコンポーネント、パッケージ化の工程を学ばなければならないため、iPhoneアプリ制作を負担に感じていた
    • 翌日、Benは望んだ機能を正確に実行し、かわいらしいデザインまで備えたアプリを送ってきた
    • Benは数時間で作ったと言い、難しい作業の大半は GPT-4 が処理したと話した
  • Benは、チャールズ国王の肖像フレームに小さなスピーカーと赤いLEDをつなぐプロジェクトも進めていた
    • Webサイトにメッセージを入力すると、スピーカーが音楽を再生し、LEDが王冠の宝石のように モールス信号 で点滅する装置だった
    • 新しいメッセージを取得するコードにはマイクロコントローラーとFirebaseの知識が必要で、Benには難しかった
    • GPT-4 はFirebaseの適切な機能と、マイクロコントローラーで使えるコードを提案した
  • Benは GPT-4 で Nokia 携帯電話の Snakeゲーム のようなものも作った
    • 短いやり取りのあと、負けたときに最適経路からどれだけ外れていたかを表示する機能まで追加させた
    • 筆者は、その修正作業を自分にもできるか確信が持てなかった
    • GPT-4 はそれを約10秒でやってのけた

コーディングが与えていた魅力と熟練の形成

  • 筆者が初めてコンピューターに魅了されたきっかけは、1990年代初頭のモントリオールで兄と Mortal Kombat をしていた体験だった
    • 兄は MS-DOS ターミナルでFTPサーバーに接続してコマンドを入力し、ゲーム内のすべての fatality の指示が書かれたコードを出力した
    • 筆者は兄をハッカーのように見なし、隠された場所や知識を見つけることに魅力を感じた
  • 「The Hacker’s Manifesto」の「私の犯罪は好奇心だ」という一節と、1995年の映画「Hackers」は、知識こそが力だという感覚を強めた
    • 映画の中のDade Murphyは、コンピューター本の表紙を見ただけで内容を見抜き、キーボード入力で学校のスプリンクラーやタンカーのバランスを制御した
    • 筆者にとってハッキングは破壊よりも 隠されたものを学ぶ行為 に近かった
  • 高校時代に買った Ivor Horton の “Beginning Visual C++” は、1,200ページに及ぶ最初の入門書だった
    • 序盤はやさしかったが、「Dynamic Memory Allocation」の部分で行き詰まった
    • 彼はこれを、中世の学生たちが最初にぶつかる難所に付けた言葉 pons asinorum、つまり「ロバの橋」にたとえた
  • “Hello, world” を実行するまでの体験は、プログラミングが知識や技術というより 忍耐と執着 に近いものだと感じさせた
    • Borland C++ コンパイラーを動かすために何日も苦労し、1つのエラーを直すと別のエラーが現れた
    • ついに “Hello, world” が表示されたとき、コンピューターが自分の声で目覚め、あいさつしたように感じられた
  • 大学時代には、小さなプログラムを作りながらコーディングの楽しさを広げていった
    • 2006 Masters Tournament で Tiger Woods がバーディーやボギーをするとSMSを送るプログラムを作った
    • “Ulysses” の文をランダムに抜き出して音節数を数え、俳句を組み立てるプログラムも書いた
    • 友人たちと楽しんだ「Jimbo Jeopardy!」を14時間かけて作り、誰かが自分の作ったものを楽しむ体験の強さを感じた

ソフトウェアエンジニアの全盛期と自動化の逆説

  • 2009年の金融危機のさなか、GPA 2.9 で卒業したが、プログラミングの実務経験のおかげで最初の正社員の仕事は簡単に得られた
    • 当時、企業は優秀なプログラマーをめぐって競争し、経験あるプログラマーには積極的に声をかけていた
    • コンピューターサイエンス専攻の人気は爆発的に高まり始め、コーディングブートキャンプは1年以内に初心者を高給プログラマーにできるとうたった
  • 低金利とテック業界の成長のなかで、ソフトウェアエンジニアの待遇は高まった
    • Google のような企業は、無料のエスプレッソ、ケータリングの食事、手厚い医療福利厚生、育児休暇、社内ジム、自転車置き場、カジュアルな服装、20% time のような慣行を広めた
    • コーディング作業はいつバグが見つかるかわからないため、期間見積もりは愚かだと見なされ、締め切りはタブーのように扱われた
    • プレッシャーが強ければ、「burnout」という言葉ひとつで数カ月の猶予が得られるような空気もあった
  • こうした待遇がこの先も続くのかという疑問も大きくなった
    • かつてWebデザインも、週末の作業だけで数千ドル稼げるほど需要が大きかった
    • Squarespace のようなツールが登場すると、ピザ店の店主やフリーランスのアーティストでもクリックだけでWebサイトを作れるようになった
    • プロのコーダーにとっては、高収益・低労力の仕事の一部が消えた
  • プログラマーコミュニティの反応は、より難しい技術を学び続けるべきだという方向に近かった
    • ソフトウェアエンジニアは自動化を好み、優れたエンジニアは別種の仕事を不要にするツールを作る
    • 1つのコードが何百万人もの仕事に影響を与えられるという レバレッジ が、プログラマーの待遇の根拠だった
    • その同じ自動化への本能が、プログラマー自身の仕事の一部も置き換える

AI時代のプログラマー、centaur と残る能力

  • 会社でAIチャットボットをプログラミング補助として使えるようになったあと、筆者は最初は意識的に避けていた
    • ほどなくして同僚の画面で、AIチャットとの質疑応答のパターンを頻繁に見るようになった
    • 同僚たちは、こうしたツールが生産性を高め、場合によっては問題を10倍速く解けるようにしてくれると言った
  • 筆者は、AIがパズルを解く楽しさや、自力で解決したという満足感を奪うのではないかと心配した
    • 一般的なプログラミングの成果物はたいてい面白くなく、ときには笑ってしまうほど平凡だ
    • たとえば重要な文書の表に、複数列にまたがるヘッダーを追加する作業は、結果だけ見れば単純だった
    • しかし、ユーザー向けAPIをどう作るか、データのない列が抜けたときにどう処理するかを考える過程こそが楽しさの核心だった
  • 結局、彼は業務中に検索結果でユーザークエリと一致する部分を強調表示する小さなツールを作りながら GPT-4 を使った
    • Edsger W. Dijkstra は1978年の「On the Foolishness of ‘Natural Language Programming’」で、自然言語はコンピューターが与える精密さを捨てる方法だと見ていた
    • 実際の GPT-4 の利用は、「問題を解いて」と言うだけの水準ではなく、初心者に話すように欲しいものを慎重に指定しなければならなかった
    • 失敗を見ながら、プロンプトをより控えめに変え、問題を具体的で、抽象的でなく、曖昧でない下位問題に分解しなければならなかった
  • その後、仕事のあちこちに GPT-4 がぴたりとはまる大きさの隙間が見え始めた
    • クロスワードの出力結果を見やすいWebページに変える作業でも GPT-4 と対話した
    • 各文字を横と縦の単語に結びつける細かな問題があったが、以前のように数字、パターン、ループを頭の中でシミュレーションしなかった
    • Geoffrey Litt が似た経験のあとに書いたように、「細部を扱うプログラマーの脳」を使っていないという感覚が残った
  • 囲碁のLee Sedolやチェスの事例は、AIの後でも技術の文化が消えてしまうわけではないことを示している
    • Lee Sedol は2016年に AlphaGo に敗れ、数日にわたる対局の末に1勝したことを誇りに思い、3年後に引退した
    • チェスはAIに征服されたあともさらに人気が高まり、学習者はAIコーチから自分の実力より少し上の問題や敗因を受け取れる
    • 最上位のグランドマスターたちは、コンピューターが提案した手を神の石板のように研究している
  • GPT-4 は現時点では筆者より劣るプログラマーであり、一般人にもプログラマーのように扱うのは難しいが、centaur 的なやり方はすでに現れている
    • Ben単独では筆者よりはるかに劣るプログラマーであり、GPT-4 単独でもまだ筆者に及ばないが、Benと GPT-4 の組み合わせは脅威的な生産性を見せる
    • ソフトウェアを作りやすくなれば、ソフトウェアはさらに広がり、プログラマーは設計、設定、保守を担うようになるかもしれない
    • コーディングそのものの重要性が薄れるほど、何を作る価値があるのか、ユーザーは何を好むのか、技術的にも人間的にもどう伝えるかがより重要になるかもしれない
  • 子どもに教えるべきなのは、特定の技術より ハッキングの精神 かもしれない
    • 未来には、C++ や Python を直接打ち込むプログラミングは、パンチカードで2進命令を与えるのと同じくらい滑稽に見えるかもしれない
    • コンピューターにしてほしいことを正確にさせることが、丁寧にお願いする行為になる可能性もある
    • 農耕時代のコーダーは水車や作物の品種をいじり、Newton の時代にはガラス、染料、時間測定に執着していたかもしれない
    • 次の世代は、親がブラックボックスとして見ていたAIの内部を掘り下げて夜を明かすかもしれず、コーディングの時代が黄昏を迎えてもハッキングは続く

3件のコメント

 
xguru 2023-11-15

記事の後半が少し切れて要約されていますが、最後の一文が重要です。

"I shouldn’t worry that the era of coding is winding down. Hacking is forever."
「コーディングの時代が終わりつつあると心配する必要はありません。ハッキングは永遠なのですから。」

 
kuroneko 2023-11-15

Bardも統合機能が提供されるや否や、すぐにプロンプトインジェクションで情報漏えいさせたりそういうことができるのを見ると、
ハッキングは永遠になくならないもののようです。

 
GN⁺ 2023-11-15
Hacker News の意見
  • GPT-4 は本当に印象的だが、私にとってソフトウェア開発の核心はコーディングそのものではなかった
    GPT-4 はよく失敗するし、失敗の仕方も明確ではなく、学習資料が乏しい分野ではさらに大きく崩れる
    たとえ20倍よくなったとしても、良いソフトウェアをより安く簡単に作れるなら、世の中にとって良いことだと思う
    コーディングを本当に趣味として楽しむ人なら AI がそれを妨げることはないし、たとえコーディングが消えるとしても、ソフトウェア工学の核心はもともとそこにはなかったと感じる

    • オンライン上に前例のない複雑な高レベルの問題の解法を、ツールが自力で考案する段階までは、まだかなり遠いと思う
      LLM は速くてかなり優秀ではあるが、エラーの多い Stack Overflow の代替に近く、プログラマーの能力を補完するツールとしては短期・中期的に正味の効果が大きそうだ
    • GPT-4 が私の専門的なエンジニアリング領域で有用な解法を作ったことはない
      行き詰まる問題はたいてい範囲が広すぎて複雑で、人間の頭にも収まりにくいものだが、GPT はほとんど使えない解法を出してくる
      コードについては広く知っているが深さは浅い万能雑用係のようで、ジュニア〜中級開発者にとっては違うのかもしれない
    • GPT-4 が複数のバグを巧妙に隠したコードを何時間もデバッグするのは、かなりつらい
      一見すると明らかに正しそうなコードをデバッグするのが、プログラミングで一番楽しい部分だという人はほとんどいないだろう
      それでも、LLM をテストスイートに通るまでループさせたり、証明支援系が検証した正しさの証明と一緒にコードを出させたりする形で、より良い活用法を見つけられると思う
    • 私もおおむね同意する。生涯にわたって楽しみながらコーディングしたプロジェクトは多かったし、自分の机に望まず降ってきたプロジェクトでも楽しむ方法を見つけてきた
      ただ、私の好みはサイクル数やレイテンシのような定量指標で価値を測る、より学術的なコードよりも、ある程度芸術的な裁量のあるプロジェクトだった
      キャリア初期に楽しんでいた種類のコーディングは ChatGPT 以前からすでに減っていて、エンジニアが店番をしていた時代に始められたのは、今から見れば特権だったように思う
    • 20年は仕事として、それより10年以上は趣味としてやってきたが、コーディングは全体のプロセスで最悪の部分だ
      コードは好きではなく、ただ何かを作りたいだけだ
  • 時間がたつほどLLM に感心しなくなっているのは自分だけなのかと思う
    2021年に Copilot が初めて出たときは、私にも「もうすぐ自分は役に立たなくなるな」という瞬間があった
    だが実際に使った経験や研究を見ると、現代の LLM には根本的な欠陥があり、汎用知能への道の上にはないように見える
    GPT-4 は 3.5 より優れているが、根本的に別物ではなく、5 も似たようなものだと思う。将来、本当に強力な AI が出てきたら、私たちがこの技術に注いだ関心を見て笑うことになりそうだ

    • まったく一人ではない
      最初は非常に印象的だったが、今ではかなり高レベルの概要以外は信じられない
      たとえばサウンドシンセサイザーをゼロから実装してオーディオサンプルを作り、wave ファイルとして保存しようとしたとき、概念を理解するには概要が役に立ったが、コードは微妙に間違っていた
      構造体の長さを計算するときに何が長さに含まれるのかといった細部を特に外しがちで、初心者の立場では正しいかどうか確信も持てなかった
      確認を求めると謝罪して、こちらが聞きたがっている方向へ答えを変えるので信用できなかった
      ただし、一人でプログラミングするときの孤独感を減らすツールとしてはかなり良く、アイデアを投げて反応を見るだけでも役に立つ
    • Jaron Lanier は、チューリングテストと Blade Runner の間にある空間について似た考えを持っている
      初期の映画観客は単純な白黒映画でさえ不気味だと感じ、画面に向かって走ってくる列車を見て身をかがめた
      蓄音機を初めて聞いた人たちも、ライブオーケストラと区別できないと言った
      技術に慣れると、その技術を見分ける方法も学び、限界と強みに対する感覚が生まれる。だから時間がたつほど印象は薄れる
      もともとできないと思っていたことをやってのければ感心しやすいが、後になってできるはずだと期待したことができないからといって、すぐに無視するわけではない
    • GPT-4 が GPT-3.5 より根本的に優れていないと断定するのは難しい。私にとっては夜と昼ほど違う
      GPT-5 が同じような飛躍をするなら、それを使わずに競争するのは難しくなるだろう
      どちらも GPT モデルで、単純な自己回帰型言語モデルとして学習されたものだが、GPT-4 がさまざまな文脈でリクエストに合わせて情報をきちんと統合する瞬間には、個人レベルでも劇的な変化を実感する
      LLM は結局、大量のテキストに対する確率的推論だが、十分な計算量とデータがあれば、大きなモデルはデータを最適に理解するための構造を学習中に作り出せると考えている
      データがマルチモーダルになれば、各モダリティが誤った世界表現を消し、明確にしてくれるため、効果は単純な足し算ではなく掛け算のように大きくなる可能性もある
      テキスト・画像・動画・音声・味覚センサーで学習した GPT-10 がどれほど優れているかを見て笑うことになるだろうが、GPT-4 も人類が踏んだどの段階より大きな前進だったと思う
    • 私も似た感じだ
      「2 と 2 を足す式を書いて」とプロンプトを入れて必要な 2+2 を得て、それを魔法のような効率だと主張するのを真面目に使っている人たちを見る
      正直、長い文章を書くのはあまり好きではなく、私にとってコードは普通の言葉で説明するより常に短く速い。そもそもだからコードが必要なのだ
    • 最初の印象が過大評価で、今の印象はそこから下がった補正のように聞こえる
      高い期待から見れば「根本的に欠陥がある」と言えるが、多くの人が考えるような「役に立たない」という基準点から見れば、驚くべきツールとも言える
  • ジュニア開発者に出す簡単なフロントエンドテストを、数か月ごとにChatGPTにもやらせているが、まだ合格したことはない。惜しいところにも届かない。
    自信満々に答えるが微妙に不正確で、生成するコードは、8ページの履歴書に50個の技術を「マスター」したと書く最近のブートキャンプ出身者が出してくるような、筋の通らないコードに似ている。
    良くなっているのだとしても、私は実感していない。
    10年前にも、自動運転トラックが10年以内にトラック業界をひっくり返すと言われていたし、LLMをめぐる報道もそれと同じだ。
    すごいとは思うが、左折させるたびに時速100マイルまで加速して壁に突っ込むような状態を、いつまで繰り返すのかと思う。
    AIは、人間には到底つなげられない点の星座を結び、専門家が結果を検証してから先に進む、という形で使いたい。gpt installで新しいCLIツールやアプリを入手できる日がいつ来るのかは分からないが、すぐではない。

    • 数年前、厳しいスケジュールで公共安全の中核システムを作っていたチームで、管理者向けバックエンドのワイヤーフレームをCSSに落とし込む必要があった。
      それなりには作ったがピクセル単位では一致しておらず、チームリードにやり直すよう言われた。ビジネス価値はゼロだったが、私たちのチームはピクセルパーフェクトを誇りにしている状態だった。
      その出来事は、私がフロントエンド開発をやめるきっかけの一つになった。
      最近、練習としてChatGPTに似たようなCSSを作らせてみたら、完璧にやってのけた。
      私はCSSでは中程度の腕だが、ChatGPTがあればCSSの達人が出す品質に近い成果物を作れる。記事でも述べているように、中級のジェネラリストが今や専門家と競えるようになっている。
    • どんなテストをさせているのか気になる。今なら合格できそうに思う。
      私の経験はかなり違う。私は必要なら形式的検証も使う、実際に手を動かすうるさいバックエンド開発者で、論理的に動かないものにはいら立つ。
      コンピュータを扱っているのだからすべてが論理的であるべきだが、フロントエンドの多くの部分は私にはまったく論理的に見えない。
      フロントエンド担当者に「テキストをどうやって中央揃えにするのか」と聞くとtext-alignだと言うが、当然それは最初に試していて、うまくいかなかった。
      フロントエンドの人たちも、簡単な質問に即答するより、自分で試して失敗してみる必要がある場合がある。
      今ではCopilotがすぐ答えを出さなければ、ChatGPT-4や、私たちのコードベースを知っている個人向けカスタムGPT「front-end hacker」が直してくれる。毎日、一日中うまく機能している。
    • TeslaのAP/FSD実装とLLMの両方で似た経験をした。
      初めて見ると、未来から来た異星人の技術のように感じる見事な曲芸だ。
      しかし時間がたつと穴が見えてきて、数か月・数年使ってもその穴があまり埋まらないことが分かる。
      改善速度はマーケティングやレトリックに比べると、埋めるべきギャップに対して中程度で、結局、使わないより使うほうが仕事のように感じられることもある。
      純粋にデータ駆動の機械学習アプローチは、80%をはるかに超える精度が必要な問題には向かないのかもしれない。
      55%当たれば利益が出る取引アルゴリズム、スクロールする映画・音楽のリストを見せる推薦エンジン、ざっと眺める検索結果、受信箱のノイズを減らすスパムフィルターには問題ない。
      しかし「これが正解だ」と言ったり、「人を殺さずに車を運転する」という問題は、はるかに難しい。
    • ChatGPTにPythonで動作する滑らかな補間関数を書かせようとして2時間を費やした。
      ほとんどは、補間すべき2点すら通らず、それを指摘すると、点は通るがもはや滑らかではない関数を出してきた。
      何度も新しく始めて、本当に試してみた。
      こういうものが機械を制御するコードを書くと完全な混乱になるので、機械学習のある世界とロボット配送ドローンのある世界のどちらかを選ばなければならないと思う。
      ただし、変数から関数パラメータを作るような些細な作業は、そこそこうまくやった。
    • 最近の実際のコーディングベンチマークでは、上位のLLMがひどい性能を示している: https://www.swebench.com/
      ただ、この課題も最終的には克服されるだろうし、そのとき残る疑問は、それが本物の能力なのかデータ漏洩なのか、ということになるだろう。
  • 人々が本当に今をこの技術の黄昏期だと見ているのか、理解できない
    私の見方では、まもなくコーディングの量子的生産性の時代に入ると思う
    AI支援は、自分が書くものを改善してくれるだけでなく、作業しながら学ぶ助けにもなるので、とても期待している。この1年ほどソフトウェアを書くのが楽しかったことはない
    何十年もソフトウェアを書いてきたが、今では行き詰まりを乗り越え、選択を理解するのを助けてくれるコーチが、ほぼ常にそばにいる
    同僚の席まで行って問題を尋ねる程度ではなく、実際に成果につながるひらめきを与える生産的な解決策をくれる
    本当に驚くべきことだ
    なぜコーディングが終わりつつあると見るのか分からない。AIコーディング支援がまともな開発者を置き換えるという証拠は見当たらない。何かを作る能力が本当にひどいなら別だが
    誰かが「これからは基礎工事は無料だが、家は依然として建てられる」と言ったような感じだ
    私は依然として家を建てなければならないし、設計し、デザインし、作り、人々に知らせ、サポートし、擁護し、説明しなければならない。ただ基礎を自分で作らなくてよくなったので楽になっただけだ

    • 本当に驚くべきことだという点には同意するが、この新しい開発体験をどれだけ多くの人が享受できるかを決める経済的な問いが抜けている
      AIが開発者を2倍生産的にした場合、追加された開発能力は既存・新規の需要に吸収されるのか。開発者の数が半分になるのか。それとも同じ人数の開発者がはるかに低い賃金を受け取るようになるのか
      既存の開発者の仕事がAIに完全に置き換えられることが一つもなかったとしても、こうした問いは生じる
      また、どのような種類の仕事がAI自動化に向いているのかも重要だ。狭い文脈の中で多くの小さな技術的詳細を知っていなければ、成果物に小さな変更を加えられないCSSのような作業が思い浮かぶ
      こうした種類のコーディングをしているなら、より広い責任を含むようにスキルの範囲を広げる時期だと思う
    • 「基礎が無料になったが、その基礎がどう動いているのか誰も分からなくなる」という理由で、技術が黄昏を迎えていると見ることはできる
      かつてのコーダーが理解しなければならなかった複数の層を、最近参入した人たちは理解しておらず、その層はいまも微妙に挙動へ影響を与え得る
      過去数十年で最も広く普及したWeb技術分野で13年以上プログラミングしてきた人なら、Webが依存するスタック全体を年々理解しにくくなっていると感じ、技術が黄昏を迎えていると見るかもしれない
      フロントエンドでは、誰かがやったことをコードだけ見て学ぶのがますます難しくなっている。現代のビルド技術のせいでサイトのコードを見ることはあまり役に立たず、こうした不満はすでに13年前にもあった
      子どもがいたり、仕事以外の責任があったりすると、ソフトウェアがますます多くの領域を飲み込んでいる状況と相まって、学校の外にいる人たちは意図的な鍛錬によって技術を磨くのがさらに難しくなる
      生産性の向上が、そのまま職人技の向上を意味するわけではない。工業化は生産性を高め、多くの製品を普及させたが、職人の技術にとっては有益ではなかったという点に似ている
    • ハードウェアで起きたことが、ソフトウェアでも起きるように思う
      昔は基板に部品をはんだ付けし、複数の集積回路を接続できる人をよく見かけたし、私も大学でやった
      今ではそうした職人層は消え、コンピュータハードウェアの動作原理を極めてよく知る専門家か、単にハードウェアを買って魔法のように扱う人に分かれている
      伝統的には、中間段階を経て興味を示し、訓練を受けて専門家になり、趣味が職業につながることもあった
      今チップ工場で働くには、「はんだごてを持っていた子ども」だったからではなく、長い学問的過程を経たからだ。はんだ付けが石器時代のものに見えるほど高度な内容を学ぶことになる
      ソフトウェアにはまだこうした中間的な職人層がいるが、LLMのせいだけではなく、急速に消えつつある
      Webサイトをざっくりつなぎ合わせて動くようにする人、ExcelやPythonのスクリプトで日常業務を処理するが高度な概念は知らない人は多い
      GPT系が登場すると、専門家はジュニアの助けをあまり必要としなくなる。システムアーキテクトが骨組みを描いて小さな作業をジュニアに分け与えるより、LLMから必要なものを得られる
      結果として、最高水準まで訓練される人は減り、その少数ははるかに生産的になるだろうが、多くの人は中間で取り残されるだろう
    • 最近のソフトウェア悲観論者は、業界の変化に対する視点が不足している経験の浅い人か、そもそも基本的なCRUDやデータ受け渡しアプリ以上のものをうまく作れなかった人たちのように感じる
    • 筆者はプロのプログラマーではない。いくつかのサイドプロジェクトがあり、コーディングが得意そうにも見えない
  • AIが良いコードを書け、時間とともにさらに良くなり得ることは否定しないが、大半の開発者をAIが置き換えるワークフローがどう機能するのかは分からない
    ジュニアプログラマーがCRUDエンドポイントを書くような仕事を例にすると、自分が望むものと正確に合う要件を説明する時間のほうが、Copilotのようなツールの助けを借りて自分でコーディングする時間より長くなるかもしれない
    非技術系ユーザーがAIでAからZまで開発すると想像できるだろうか?生成されたコードにバグがあった場合、どの時点でも人間が介入しなくてよいと言えるだろうか?
    バグが出たときに技術者が介入するとしても、AIが書いたものを調査し、後から何が起きたのか理解するのに時間がかかるなら、コード作成コストの削減分はすぐに消えてしまう
    結局、コードを書くことは仕事の小さな一部であり、LLMはコード生成には向いているが、本質的には問題解決者ではない
    この技術は驚くべきものだが、開発者の道具箱に入るもう一つの道具になるのだと思う。優れたチューターでもあり、Webページの内容をスクレイピングするスクリプトのような独立した問題では、開発者を呼ばなくても済むようにしてくれる

    • 現状では開発者を完全には置き換えられないという点には同意する
      しかし多くの開発者のワークフローをはるかに楽にし、より少ない人数で足りるようにしたり、同じ人数でより多くの仕事をこなせるようにしたりできる
      このスレッドの別の場所でも書いた: https://news.ycombinator.com/item?id=38259425
      基本的に、普段時間を大きく取られる作業に対して、非常に強力な汎用アシスタント兼ブレインストーミング相手のように感じた
      コードに限らず、粗い情報を渡して一貫した文書に整理させたり、フィードバックを受けたりするなど、ドキュメント作成にも使った
      新しいプロジェクトにオンボーディングするとき、理解しにくい文書の断片を入れて説明してもらうのにも役立つ
      経営陣まわりの雑務でも、依頼内容と自分の観点を入れ、特定の視点に合わせた回答を作らせることで、精神的エネルギーをあまり使わずに済んだ
      もちろんチームの他の人たちともできるが、彼らがいつもそばにいるわけではなく、彼らにもやることがある。ChatGPTのようなツールは疲れないので、納得するまで「なぜ?」と問い続ける内なる幼児を思う存分出せる
      他の人に聞ける場合でも、ChatGPTは質問を磨くのに役立つ
    • 今の段階ではジュニアに近い
      ボイラープレートや退屈な作業、人が説明したアルゴリズムをコードに落とし込むことにはかなり有用
      コードの言語変換も得意で、きちんと指示すれば仕事をこなす
      雇用の見通しには大きな影響を与えるだろう。まだエンジニアを置き換えることはできないが、特定技術の実装専門家として特化した人たちは危ない。生産性の向上だけでも需要は減るはずだ
    • デンマークの公共部門のデジタル化に長く携わってきたが、プログラマーは不要だと主張していたノーコード/ローコードツールはことごとく失敗した一方で、GPTは成功している
      98の自治体で見た逸話的な経験では、そうしたツールが長く機能したことはなかった
      一方で今では、デジタル感覚のある職員たちがChatGPTの助けを借りて何かを作り、自動化している
      長期保守の観点では、以前のRPAやワークフローツールのようにひどいものも多いが、今回は人々が自分で保守できる可能性もある
      ただし彼らはソフトウェア開発者ではないので、スケーラビリティ、リソース使用量、ドキュメント化、エラー処理のようなことはできない
      それでも大半は月に数時間を「節約」する程度のものなので、実際の開発者を付けるほど重要ではなく、90%程度で十分な場合もある
      SharePoint Onlineのようなツールの改善と組み合わせれば、以前なら社内開発者や外部コンサルタントが必要だった仕事を内部で処理できる
      これはソフトウェア工学の死ではない。スケールせず、長期的にはアマチュアのアーキテクチャ同士が噛み合わなければならなくなって問題が起きるだろう
      しかし、辞書から任意のテキスト数行を取り出す方法をGoogleで調べなければならないなら、危険ではないとは言いにくい
      GPTは「ググれば書けるプログラム」をかなり簡単に、しかも十分な品質で処理するので、業界ではますます多く起きるだろう
      私の記録を見れば、LLM、正確にはGPTに感心しつつも失望していることが分かる。他のモデルは正直いまいちだ
      日常業務で実際の開発にはあまり役に立たなかったが、文書はほとんど書いてくれ、怖いほど上手い
      Excelのデータマッピングシートから型やクラスなどを作り、CRUD機能を生成するコード生成も多くやっている。以前は短いCLIスクリプトでやっていたが、今ではGPTが大半を処理する
      ただし効率性が必要なビジネスロジックを、よく設計されたコードで扱うことはひどく苦手で、これまで少しも良くなっていない
      欧州の非技術系大企業と、それを支える巨大なIT・コンサルティング産業には、GPTが得意とする仕事をしている開発者が多く、ツールが良くなるほど、ソフトウェア開発者は全体としてはるかに少なくて済むようになるだろう
      特に心配なのは、私たちが今でもCSの学生にGPTが得意な内容を多く教えていることだ
      私はアカデミー水準のCS学生の外部試験官だが、GPTはカリキュラムでほぼ満点を取れる。主に企業向けの「簡単な」コードを大量に作ることに重点が置かれているためだ
      LLMが本格的に定着すれば、多くの学生が厳しい時間を過ごすことになるのではないかと恐れているし、カリキュラムは間に合うようには変わらないだろう。デンマークの高等教育は現実への適応が遅く、すでに10年前からやや時代遅れだった
  • 「プログラミングは知識や技術というより忍耐、あるいは執着に近い。プログラマーとは、果てしなく続く退屈な障害物の行列に耐える人たちだ」という言葉は、AI 支援プログラミングに楽観的でいられる理由をよく捉えている
    プログラミングの入門曲線はひどく急だが、それは難しいからではなく、腹立たしいからだ
    実際に何かを作り、前に進んでいると感じるまで、奇妙なエラーメッセージや抜けたセミコロンの中で6か月耐えなければならない
    たいていの人は諦めて、自分は「十分に賢くない」と考えるが、実際にはその泥沼を通り抜けるだけの忍耐力がなかっただけだ
    LLM はその初期学習曲線に大きな影響を与えると思う。より多くの人が基本的なプログラミングを学び、生活の中の退屈な反復作業をコンピュータで自動化できるようになるのは良いことだ

    • コンピュータは無礼で正直であり、人間は醜い真実より美しい嘘を好む
      プログラマーは日常的に、どんな職業よりも醜い真実を受け入れなければならない。物理エンジニア、建設作業員、修理工にもこの徳目は必要だが、フィードバックサイクルが遅いため、求められる頻度はそれほど高くない
    • 正直、一歩後退だと思う
      Google Translate が誰もをスペイン語に流暢にしたと言うのに似ている
      結局 ChatGPT を効果的に使うには、依然としてコードをレビューし、その動作原理を理解しなければならない
      コードを実際にタイプすることは、ソフトウェア開発の難しい部分ではなかった
      このツールが開発者を6か月前倒しする程度なら、学校でコンピュータサイエンスの授業を提供するほうが、計算資源に対して割がよく、はるかに強い世代のエンジニアを育てられる
    • その通り。LLM には生活の質を改善する別の方法もたくさんある
      多くのユーザーを抱える複雑なソフトウェアプロジェクトには、事実上放置された果てしないバグチケットのバックログがある
      数か月前、Firefox で25年前のバグが修正されたように思う
      ほとんどのコンパイラやフレームワークには「X が発生したときのエラーメッセージを改善する」といったチケットが積み上がっているが、プログラマーの時間が高すぎるため優先順位に上がらない
      時間が経つにつれ、シニアとジュニアの差は、知能や実際の経験というより、製品の寿命が尽きる前には解決されないバグやユーザビリティ問題をかき分けてきたことで積み上がった傷跡になることが多い
      AI がプログラマーを完全に置き換えるには、まだ大きなブレイクスルーが何度か必要だろうが、バグトラッカーに放っておき、一日中細かな修正を作らせることは十分に視野に入っている
      そうなれば、人間によるプログラミングはもっと楽しく、学びやすいものになるだろう
    • この話は本当に気分よく聞こえる
      使っているアプリの制約に縛られて暮らす普通の人々や、『Python で自動化する』系の本の人気を思い出す
      この新しい技術のおかげで、人々がもうそうした制約に縛られなくなるなら、かなり素晴らしいことだ
    • LLM を使っても、依然として汚く退屈な仕事は残る
      コードは依然として複雑で壊れやすい成果物だ
      LLM がコードを書くことは始まりにすぎず、ほとんどの人にとっては、LLM 支援付きのローコード/ノーコードのほうがより理想的だ
  • AI とニューラルネットワークをやっている友人と、こんな議論をしている
    友人は、コーディングはまもなく時代遅れになり、ChatGPT 式のコード生成ですべて置き換えられると言っている
    私は「シニアエンジニア」として、自分の仕事の圧倒的多数はコミュニケーション、組織内のリーダーシップ、プロダクト要件を実際に理解し、それが自分たちのシステムとどうかみ合うかを把握することだと見ている
    コードは書くが、その大半がコード生成で補強されても、私がしている仕事の大部分はほとんど変わらないだろう

    • ここにジュニアエンジニアを入れると話は変わる
      ジュニアの仕事はそういうものではなく、登録された issue を受け取って実装することだ。難しい問題は任されず、タスクと受け入れ基準を一緒に渡される
      未来の CodeGPT のようなものが彼らのプログラミングスキルを完全に置き換えたら、10年後に彼らがシニアになる道筋はどうなるのか
      今のシニアたちは10〜20年後には引退するだろうし、自動コード生成の恩恵を実際に受けた人々に置き換わると、「コーディング」は機械がやってくれる前の老人たちがしていた仕事になるかもしれない
    • コミュニケーション、組織リーダーシップ、プロダクト要件の理解は、人々と一緒に働くから生じる問題のように聞こえる
      AI のおかげで、より小さくてもより有能なチームが可能になれば、リーダーや会議の必要性は減り、すべてがはるかに効率的になるだろう
      ジュニアエンジニアのメンタリングに使っていた時間にも別れを告げることになるかもしれない。まもなくジュニアはいなくなるだろうから
    • 私も同意する。プロの開発者としての自分の経験もかなりの部分でそうだ
      組織を探り、他チームとつながり、何をすべきかを理解しようとする
      自分が書くコードは、実際にやっている仕事の副産物のように感じる
    • もしそうなら、変化は残酷なものになるだろう
      第一に、関わる人が減って調整が単純になる
      第二に、より多くの人が調整役にアクセスできるようになり、通常は「コーディングが得意」な人ではなかった職種や性格タイプがその役割を担う可能性が高い
      機械が、たとえば作られるものの一般的な動作の仕組みを説明できるなら、彼らに卓越したコーディング能力は必要なくなる
      そのため、雇用領域は大きく揺さぶられ、賃金は大幅に下がると予想している
    • コーディングを「ハンマーを打つこと」に置き換えると、この話に似ている: https://www.buzzmaven.com/old-engineer-hammer-2/
  • この記事はプログラマーが書いたようには見えず、コメントの一部もプロのエンジニアには見えない
    近い将来、AIはプログラマーの業務のうち現実的にどの部分を置き換えられるだろうか?
    議論のために、コーディング部分は費用対効果よく置き換えられるとしよう。では、他の部分もできるのだろうか?
    あいまいな要件を受け取り、デザイン・プロダクトチームなどと明確化すること、複雑な機能を作れるだけAIに十分に指示すること、コードレビュー、任意のビルド失敗への対応、他のプログラマーやステークホルダーが理解できるように機能を文書化すること、本番環境の問題をデバッグして修正することなどがある
    現実的には、AIがそれなりに優秀なプログラマーを効果的に置き換える可能性が出てくる前に、プログラマーがAIを活用してより効率的になる長い段階があるはずだ
    より抽象的に考えるエンジニアに有利になり、低レベルのプログラミング作業から先に取り込まれていくだろう

    • 自動コードレビューと高品質な自動ドキュメント化は、まもなく完全にLLMの能力範囲内に入ってくると思う
      任意のビルド失敗の修正も、その次についてくる可能性が高い
      そうなると、プログラマー業務の何パーセントを持っていけるのか、残る部分が別のスキルの組み合わせを必要とするのかが問題になる
      コーディングは得意だが、ビジネス側が少しあいまいな要件を出すと大声で文句を言うプログラマーがいる。自分の仕事をビジネスルールを明確にすることではなく、コーディングだけだと見ているからだ
      このグループは、あいまいな状況でもビジネス要件を理解しようと進んで取り組むプログラマーよりも大きな影響を受けるだろう
    • その記事は明らかにプログラマーが書いたように見えるが、なぜ違うと言うのかわからない
    • GPTの特徴は、ほぼあらゆることについて大まかな知識を持っていることだ
      誤りは作るが、その誤りは人間の誤りとの相関が低いように見える
      特にGoogleがどんどん役に立たなくなっている状況では、自分が何時間も検索しなければならない内容を知っていることもある
      個人的には、スクリプティングと実行機能の補助に使っている
    • Figmaのモックアップとあいまいな要件を受け取り、既存のコードベース内で人の助けなしに実際のコードへ変えるAIツールはまだ見たことがない
      現在のツールを見る限り、まだかなり先は長そうだ
  • タイトルが本文とあまり合っていない気がする
    タイトルはプログラミングという技術が置き換えられるかのように言っているが、本文は結局大きく変わると主張しており、自分の直感もそちらに近い
    結局、参入障壁が下がっている。これは悪いことなのか? 自己中心的な観点ではそうだが、社会的な観点ではそうではない
    カナダと、ある程度アメリカが直面している問題の一つは不平等だと思う
    より「平均的な」サービス職で働く人たちはエンジニアよりはるかに少ない収入で、この数年それはかなり居心地の悪いことだった
    生成AIの社会的価値は、法律、医療、ソフトウェア工学のような知識労働を「平均的な」人々にとってはるかにアクセスしやすくすることにある
    欠点もあるだろうが、権力を均等に分けるほうが、誤ったエリート主義よりユートピアに近い道だろう。後者は専制政治への道のように聞こえる

    • 法律、医療、ソフトウェア工学が賃金不平等の主な原因だとは思わない
      最低賃金が最も低い賃金で、プログラマーの給与が最も高い賃金だとしたら、アメリカは非常に平等な経済ということになる
      アメリカに残った中産階級への道を自動化すれば、自動化インフラを所有する資本家と、縮小していく非自動化領域へ押しやられる人々との格差がさらに広がるだけだろう
    • ソフトウェア開発がそこまで単純になり、挙げられた職種の人々でもできるようになるなら、賃金も急落するだろう
      そうなっても彼らの状況が良くなるわけではない
    • ソフトウェア開発者たちが恐れているのは、自分たちが低賃金層に加わることだと思う
  • 毎日コーディングするわけではない白髪頭の立場からすると、ChatGPTはプログラミング助手として印象的だった
    月20ドルのオンコールのジュニア開発者がいるような感じだ
    先月、手早く雑なユーティリティが必要になり、問題を自分で4〜5段階に分けてから、ChatGPTに各段階の関数を書かせ、自分でつなぎ合わせた
    大半は順調だったが、一箇所は望む結果が出るまでに過剰なほど多くの誘導と手直しが必要だった