建築家または建築家を目指す人が知っておくべき事柄を毎月まとめた概要です。
プロフェッショナルソフトウェア開発における知識とイノベーションの普及を促進
Git は、ソフトウェア開発におけるバージョン管理によく使われるツールです。複数の Git アカウントを使用することは珍しくありません。Git アカウントを正しく構成して切り替えることは困難です。この記事では、Git が提供するアカウント構成とその制限、およびプロジェクトの親ディレクトリの場所に基づいてアカウントを自動的に切り替えるソリューションについて説明します。
WebAssembly は、その範囲をブラウザからクラウドやエッジ コンピューティングなどの他のドメインにまで拡大しました。WebAssembly は、WebAssembly コンポーネント モデル (WCM) を使用して、Rust、Python、JavaScript などのさまざまなプログラミング言語のライブラリ間のシームレスな相互作用を可能にし、真の多言語プログラミング環境を推進します。
このポッドキャストでは、Michael Stiefel が Anthony Alford と Roland Meertens に、大規模言語モデルがソフトウェア開発に大きく貢献する世界におけるソフトウェア開発の将来と新しい開発者のトレーニングについて語りました。
このポッドキャストでは、Culture & Methods の主任編集者である Shane Hastie が Kyle Carberry に、開発者エクスペリエンスの重要性と、Copilot などのツールの登場によってそれがどのように変化しているかについて話を聞きました。
CI/CD パイプラインは、機密情報を公開する可能性があります。プロジェクト チームは、パイプラインのセキュリティ保護の重要性を軽視しがちです。この記事では、パイプラインのセキュリティ保護のためのアプローチと手法について説明します。
ソフトウェア開発の意思決定をレベルアップするための変革的な洞察を発見してください。限定オファーにはコード LIMITEDOFFERIDSBOSTON24 を使用してください。
上級開発者から実践的なアドバイスを得て、現在の開発課題を解決しましょう。限定オファーにはコード LIMITEDOFFERIDSMUNICH24 を使用してください。
注目すべき新たなトレンドを発見して、ソフトウェア スキルをレベルアップしましょう。今すぐ登録してください。
すべてのプロフェッショナルが知っておくべきすべてのトピック、テクノロジー、テクニックに関する月刊ガイド。無料で購読できます。
InfoQ ホームページ ポッドキャスト LLM が簡単なプログラミング タスクを実行する場合 – ジュニア開発者はどのようにトレーニングされるか? 私たちは何をしてきたか?
このポッドキャストでは、Michael Stiefel が Anthony Alford と Roland Meertens に、大規模言語モデルがソフトウェア開発に大きく貢献する世界におけるソフトウェア開発の将来と新しい開発者のトレーニングについて語りました。
アプリ開発者が顧客のために安全でスムーズなログイン エクスペリエンスを作成できるようにしたいですか? Curity を使用すると、ユーザー ID を保護し、アプリと Web サイトを保護し、API アクセスを管理できます。詳細はこちらをご覧ください。
マイケル・スティーフェル: 「What Have I Done Podcast」へようこそ。このポッドキャストでは、私たちが向かっているように見えるテクノロジーの未来を本当に望んでいるのか自問します。このポッドキャストは、映画「戦場にかける橋」の最後の象徴的なシーンにインスピレーションを得ています。イギリス軍司令官のニコルソン大佐が、技術的に優れた橋を建設することへの執着が敵を助けたことに気づき、橋を爆破する起爆装置を落として死ぬ直前に「自分は一体何をしたのか」と自問するシーンです。
最初のエピソードでは、大規模言語モデルがソフトウェア開発に与える影響についてお話ししたいと思います。ゲストは、InfoQ の世界でよく知られている Anthony Alford 氏と Roland Meertens 氏です。両名とも InfoQ の「Generally AI」ポッドキャストを主催しています。
アンソニーはジェネシスの開発ディレクターで、顧客体験に関連するいくつかの AI および NL プロジェクトに取り組んでいます。スケーラブルなソフトウェアの設計と構築で 20 年以上の経験があります。アンソニーはインテリジェント ロボット ソフトウェアを専門とする電気工学の博士号を取得しており、人間と AI のインタラクションや SaaS ビジネス最適化の予測分析の分野でさまざまな問題に取り組んできました。
ローランドは、自動運転車用の AI を組み込んだ企業である Wayve の技術リーダーです。ロボット工学のほかに、出会い系アプリの安全性にも取り組んでおり、人間の愛の刺激的な世界をコンピューターで読み取り可能なデータに変換しています。それができるまで、そして法学修士課程が揃うまで、私は参加できません。彼はピザもかなり上手に焼きます。
お二人とも、ポッドキャストへようこそ。
アンソニー・アルフォード：お招きいただきありがとうございます。
ローランド・メーアテンス：はい、ありがとうございます。
Michael Stiefel: まず、私たちは、おそらくそれほど遠くない将来、LLM を使用してコードを書く際の問題がほぼ解決されている未来に生きているという前提で始めたいと思います。お二人に最初にお聞きしたいのは、この世界でのソフトウェア開発ライフサイクルはどのようなものなのでしょうか?
Roland Meertens: そうですね、ボットがソフトウェア内の問題を自動的に見つけ、自動的に PR を発行し、他のボットが自動的に改善を受け入れるようになると想定しています。基本的に、コードはもう読み取れませんが、これは現在とそれほど変わりません。
アンソニー・アルフォード：それは非常にシニカルな見方ですね。でも、あなたはロボットをたくさん使ってきましたよね。ここでの私の一般的な原則は、実際に何が起こるかは、おそらく多くの人を驚かせるだろうということです。私は安全な賭けをするつもりです。そして、ロボットの目的という概念に賛成します。ロボットは、人々が危険で、汚くて、退屈だと感じる作業を自動化するためのものです。私はソフトウェア開発のキャリアで、危険や汚いことをあまり経験したことはありませんが、退屈なことはたくさんあります。自動化、LLMが退屈な作業を引き受けるという考えに賛成します。ローランドが言ったように、それは間違いなくプルリクエストやコードレビューです。しかし、テストの作成やドキュメントの作成など、変数の命名など、私たちが難しいと感じる作業もあります。
アイデアは、スペースとタブのどちらを使うかといった重要なことに集中できるように、人間のエンジニアの時間を解放することです。
Michael Stiefel: つまり、コーディング標準です。
Roland Meertens: 理想的には、これらは、通常インターン生に与えるべき決定のように、すでに自動化されているべきものです。少なくとも、すでに与えられているものだと思います。
現在、お二人のうちどちらが GitHub Copilot を使用していますか?
Anthony Alford: 楽しいサイドプロジェクトに使っています。悪くないですね。
Roland Meertens: でも、日常業務では使っていないんですか?
アンソニー アルフォード: 興味深いですね… このエピソードの前提の 1 つは、すべての問題が解決されているということです。私たちの会社にとっての専門的な問題の 1 つは、潜在的なトレーニング データセットにデータを送信したくないということです。また、返されるコードについても懸念があります。たとえば、そのコードの著作権は誰が所有するのか? いいえ、私たちは仕事で Copilot を使用していません。
ローランド・メーアテンス：しかし、それは技術的な能力の問題ではなく、法的な問題によるものなのでしょうか？
アンソニー・アルフォード： 多かれ少なかれ、そうです。
Michael Stiefel: そうですね、お二人とも、この技術を使って退屈な作業や簡単な作業をすべてやろうというアイデアにたどり着きました。これは伝統的に初心者プログラマーのトレーニングの場ではないでしょうか? では、簡単な作業をすべて自動化したら、プログラマーをどうやってトレーニングするのか、という疑問が生じます。将来のプログラミング クラスはどのようなものになるのでしょうか?
アンソニー・アルフォード：コパイロットは、実際に、その言葉を使うのであれば、かなり便利なパラダイムだと思います。
Michael Stiefel: リスナーの皆さんに、Copilot とは何かを説明していただけますか? リスナーの皆さんはそれが何なのか知っているかもしれませんし、知らないかもしれません。
Anthony Alford: はい、いくつかの意味があります。大文字の Copilot は GitHub の製品で、コード生成 LLM です。関数に実行させたいことを「この関数は実行します」というコメントを入力すると、おそらく関数のコード全体が出力されます。
Michael Stiefel: どの言語で伝えても構いません。
Anthony Alford: まさにその通りです。Copilot は、あなたを支援する LLM を意味することもあります。初心者のトレーニングには良いモデルになると思います。リアルタイムのコード レビューア、リアルタイムのデバッグ アシスタントといったほうが良いかもしれません。
別の見方をすれば、LLM によって上級プログラマーの時間が大幅に節約されるため、上級プログラマーは若いプログラマーを指導する以外に何もすることがなくなる、ということになるかもしれません。よくわかりません。
Michael Stiefel: そうですね、これは、あなたがおっしゃっていることだと思いますが、プログラミング技術全般に常に存在する矛盾の 1 つです。他のエンジニアリングとは異なり、たとえば土木技師であれば、一生をかけて同じ橋を何度も何度も建設することができます。
アンソニー・アルフォード: ビッグ・ディグです。
マイケル・スティーフェル: ええ、そうです。ボストンに住んでいない方のために説明すると、あれは長年にわたる非常に興味深い土木工学の経験であり、全米の納税者のお金で賄われていました。いずれにしても、エンジニアリングの世界ではそのようなプロジェクトはほとんどありませんでした。これまでに誰もやったことのないことをやるのです。
大学院生の頃、私は原子力工学を専攻していました。原子炉設計の最終試験の 1 つで、原子炉の冷却システムを設計することになっていました。物理学の第一原理からではなく、ASME 標準を採用してそれを設計に適用するのです。ソフトウェアはまったく異なります。ソフトウェアでは、何かのコピーが欲しければ、ビットをコピーするだけです。ソフトウェアでは、常に、これまでやったことのない新しいことをする傾向があります。そうでなければ、ソフトウェア プログラムを書く意味がないからです。
問題は、法学修士号や、過去に訓練された技術を、必ずしも私たちが知らない未来にどのように適用するかということです。
ローランド・メーアテンス：でも、あなたも同じことを何度も繰り返しているのではないでしょうか？
ローランド・メルテンス: 人類として。
Roland Meertens: Stack Overflow が人気なのは、誰もが毎日同じ問題を解決しているように見えるからです。
Michael Stiefel: はい。でも、問題は… たとえば、私が昔を思い出すとします。正確に何歳かは言いたくありませんが、カード リーダーや仮想メモリが登場する前のことを覚えています。確かに、繰り返しのことはありましたが、コンパイラ、リンカー、ローダー、デバッガーなどは忘れられがちです。これらはすべて、ある時点で発明されたもので、洞察力を必要とする新しいテクノロジーでした。ファイアウォール、ロード バランサー。LLM は、これまで見たことがないこれらすべてのことをどのように考慮するのでしょうか。
Roland Meertens: そうです。しかし、過去のことを知らないのにどうやって学ぶのかというところからこの議論を始めたと思います。この場合、私は最年少でまだ 33 歳で、残念ながらパンチ カード プログラミングの時代を逃してしまいました。
マイケル・シュティーフェル： 見逃したものはあまりありませんね。
Roland Meertens: 私が聞きたいのは、日々の仕事の中で、「ああ、パンチカードの時代からこれを思い出した。まさにこれが必要だ」と思うことがどのくらいあるかということです。
Michael Stiefel: しかし、問題は、コンパイラーを誰が思いついたかということです。言い換えれば、法学修士課程は何か新しいものを思いつくわけではありません。データを見て、「ああ、これができたら素晴らしい。これまで見たことのないことをこうやって実現するんだ」と言うのでしょうか。
Roland Meertens: 主に、これが将来の上級開発者にとって何を意味するのか疑問に思っています。彼らは、今日プログラミングを始めたばかりの人々です。問題は、必要な API コードを見つけるために多くのわかりにくいオンライン フォーラムを調べる必要がなくなり、コードに 100% 集中できるため、より速く学習できるかどうかだと思います。それとも、ChatGPT にすべての処理を生成してもらうだけなので、コードやマシンが実際に行うことを徹底的に理解することはできないのでしょうか。
Anthony Alford: はい。ソフトウェア開発者がこれまでに経験したことのない問題を解決しなければならないことは確かにあると言いたかったのですが、実際には、より一般的なユースケースは、ASME 標準についてお話ししたように、基本的に、すでに見たことのあるピースを組み合わせることだと思います。斬新な方法かもしれませんが、実際にはそうではない場合がほとんどです。「REST API を作成する必要があります。何かを保存する必要があります…」これが、Rails や Django などのフレームワークの仕組みです。これらのフレームワークは、共通のパターンがあることを知っています。LLM は、その次のイテレーションにすぎないと思います。
Michael Stiefel: つまり、次のイテレーションは、デザイン パターン、アーキテクチャ パターン、エンタープライズ統合パターンです。
Anthony Alford: おそらくそうです。もう 1 つは、先ほど言ったように、コード自体が仕事のすべてではありません。他にも多くのことがあります。DevOps モデルを考えてみましょう。私の会社では、コードを書くソフトウェア エンジニアが、そのコードを本番環境でオンコールで呼び出します。LLM をポケベルへの最初の応答者にして、自動的に修復するか、ノイズをフィルタリングするか、または行き詰まったときにそれを渡すようにしたらどうでしょうか。LLM は、API の設計、テスト ケースの生成、さらにはコードのデバッグや最適化など、他のことも行うことができます。
繰り返しになりますが、私は退屈な部分の自動化についてお話ししました。あるいは、必ずしも退屈ではないかもしれませんが、より困難かもしれません。LLM がすべてのコードを書くようになるとは思いません。そうなるかもしれませんが、それでも非常に重要だと思います。Roland が言ったように、LLM だけで完全に生成されたコードは欲しくありません。そうすると、誰もその仕組みを知らないからです。
Michael Stiefel: そうですね、私たちが手作業で書いたソフトウェアがどのように動作するのか理解するのは、時々十分に難しいと思います。
Michael Stiefel: 実際、2、3年前に書いたコードを見つけて、それを見て「これはどうやって動くんだろう？」と思ったことがあります。
アンソニー・アルフォード: そうですね。それがLLMの目的です
Michael Stiefel: ちなみに、時々、バグがあると自分に言い聞かせようとするのですが、結局、最初に考えていたことが正しかったことに気づくのです。ただ、何が起こっていたのかという複雑な部分を忘れていただけなのです。
Roland Meertens: 「To do: これを修正してください」というコメントが横にあると、状況はさらに悪くなります。
Anthony Alford: おそらく、それが LLM が私たちを助けることができる方法です。LLM はおそらくコードを説明できるでしょう。それは素晴らしいスタートになるでしょう。
Anthony Alford: このコードは何をするのですか?
Michael Stiefel: ポケベルのアイデアは気に入りました。私もポケベルを少しの間使っていましたが、何か他のことをしている最中にビープ音が鳴らないようにしてくれるものなら何でも、大きな改善になると思います。
新しいプログラマーをどのようにトレーニングするかについては、まだよくわかっていません。その点については後でまた取り上げたいからです。しかし、要件についてどう説明しますか。ソフトウェア開発で最も難しいことの 1 つは、要件が何であるかを把握することです。私は長年自営業をしていますが、人生でやっていることは 3 つだけだと言っています。間接レベルの挿入、スペースと時間のトレードオフ、そして顧客が本当に望んでいるものを把握することです。
アンソニー・アルフォード: 私も実際にそのことをメモしました。もし、LLM の資格を持つ人が、プロダクト マネージャーが書いたものを実際に実装できるものに翻訳してくれるとしたら、それは大きなことです。私自身もそうしなければなりませんでした。プロダクト マネージャーは、顧客が何を望んでいるかを知っているはずです。彼らは私よりもよく知っています。しかし、彼らが書いた内容については、彼らと何度もやり取りしなければならないことがあります。「本当はどういう意味ですか? これをもっと技術的な言葉で表現するにはどうしたらいいですか?」
Michael Stiefel: そうですね、ポイントは、彼らも顧客もテクノロジーを理解していないことが多いということだと思います。なぜなら、簡単な英語のステートメントを書けるからといって、それが簡単に実装できるとは限らないということがわかったからです。それは興味深いことです。LLM と連携して、どのように取り組んでいらっしゃいますか? つまり、製品マネージャーが、わからないけど、高速で応答性の高いものが必要だと言ったとします。LLM は、プログラム マネージャーに、それが本当に意味していることをどうやって説明してもらえるのでしょうか?
Roland Meertens: ここでも、2 つの選択肢があると思います。一方では、手動でプログラミングしているときに問題について考えると、洞察が得られることがあります。これは、コーディング方法を学ぶ必要がある初心者の開発者にも当てはまります。多くの場合、重要なのは結果ではなくプロセスです。ギター曲を自動生成することではなく、ゆっくりと楽器を学んで理解することです。
一方、特定の Web サイトを要求するプロダクト マネージャーがいる場合、ChatGPT で 5 つの例を生成し、それを特定して「はい、これが欲しいものです」と言うことができます。モックアップやアイデアを自動生成できる場合は、間違った製品の構築に 3 回のスプリントを費やすのではなく、最初から正しいものを作成できる可能性があります。
Michael Stiefel: LLM ですが、もう 1 つのアイデアは、高度なプロトタイピング ツールにすることです。
Anthony Alford: まさにその通りです。誰かがナプキンにウェブサイトの絵を描くデモを見たことがあると思います。
アンソニー・アルフォード: そしてそれを画像認識装置に渡します。
Michael Stiefel: 興味深いですね。プロトタイピング コード生成の試みは数多く行われてきたので、皆さんも過去に見たことがあると思います。それらには不満もありますが、大規模な言語モデルなら可能かもしれません… もう一度言いますが、そのようなプロトタイプをどのようにトレーニングするのでしょうか? サンプルをその前に置きますか?
機械学習全般に関して私が思うことの 1 つは、機械学習は曖昧さをあまり理解していないということです。言い換えると、機械学習アルゴリズムに何かを与えると、答えは出ますが、確率は出ません。プロトタイピングを行うときは、確率を組み合わせているので、確実性はありません。このような問題をどうやって解決するのでしょうか。私が言おうとしていることがおわかりいただけたでしょうか。
Roland Meertens: しかし、これは検索エンジンで以前あった問題と同じではないでしょうか?
Roland Meertens: 人々は検索エンジンで「ケーキのおいしいレシピを教えてください」と入力していました。今では誰もが「チョコレートケーキのレシピ 15 分」などと入力することを知っています。
Michael Stiefel: そうです。私たちはソフトウェアを扱う人間を訓練したからです。
Michael Stiefel: しかし、理想的には、人間とやり取りできるのはソフトウェアであるべきです。
Roland Meertens: そうです。父はすでに検索エンジンの使用をやめて、ChatGPT にのみ答えを求めていると思いますが、私はそれについてどう感じているかわかりません。
Michael Stiefel: ChatGPT に自分の経歴を書いてもらうよう依頼したところ、80% は真実で、20% は完全に捏造されたものが書かれていましたが、私にはわかりませんでした。自分の経歴は知っていたのでわかりますが、読んでも何が真実で何が嘘かわかりませんでした。
Roland Meertens: でも、GPT-4 にはお金を払っているんですか?
Michael Stiefel: これは GPT-3 でやったことだと思います。
Roland Meertens: はい。GPT-3 が私の名前も知っていることに気付きました。InfoQ のおかげで、GPT-3 が私たち全員の名前を知っているのだと思っていました。すると、確かに 80% は真実で、20% は私を実際よりも良く見せるようなものを生成しました。
Roland Meertens: それに満足しています。GPT-4 は実際に何らかの検索を行っているようです。
アンソニー・アルフォード: それはゲームじゃないですか。2つの真実と1つの嘘、あるいはそれに似た何かですか?
Michael Stiefel: はい、その通りです。しかし、それは一般的に大規模な言語モデルを使用することに対する懸念ではないでしょうか?
アンソニー・アルフォード: そうです。しかし、その問題は既に存在していると私は思います。開発者はバグを書いてきましたが、
アンソニー・アルフォード: それ以来、エイダ・ラブレスでさえバグを書いたのかもしれない、よく分からないけど。
Michael Stiefel: そうですね、バグという用語は、グレース ホッパーがハードウェアに虫を見つけたことから生まれたと言われています。しかし、ソフトウェア開発者にとっては救いになるのは、一般の人々と違って、LLM が意味不明なものを生成したときにそれを認識できるということだと思います。それはテストの原因に引っかかります。言い換えれば、1 つの LLM がテスト ケースを生成し、別の LLM がコードを生成するというように、機械学習システムと戦うのに好まれるようなやり方です。
Anthony Alford: そうです。おそらく、最終的にこれを逆転させる方法になるでしょう。人間がコードレビュー担当者になりますが、そうなるとは思えません…そこまでにはならないことを願います。誰もコードを読むのが好きではありません。
Michael Stiefel: ああ、いいえ。はい。コードレビューをするために、私はコードレビューをしました。なぜなら、このビジネスに長く携わってきた私にとって、コードレビューは大きな意味を持っていたからです。ある時点で、コードレビューはソフトウェアの品質問題を解決するだろうと人々は言いました。コードレビューをするのは本当に難しいことです。
Michael Stiefel: コードの前提を理解する必要があるため、時間をかけてコードを読む必要があります。LLM がコード レビューを行えることを期待しています。
Roland Meertens: そうですね、私は主に、バランスが取れていることを確認したいと思っています。製品マネージャーが自動的に要件を生成し、誰かが自動的にコードを生成するということではありません。そして、最後にレビュー担当者が、要件が最初から悪かったことに気付く必要があります。
Michael Stiefel: そうですね、興味深い点を指摘していただきました。なぜなら、今要件について話しているとき、プログラム マネージャー、プロジェクト マネージャーが要件を持っていると話しているときでさえ、要件はすでにある程度具体化されているからです。しかし、実際の要件分析を行ったことがある方、そして私も経験がありますが、クライアントと一緒に座って、彼らが本当に何を望んでいるのかわかっていないので、それを引き出さなければなりません。オープンエンドの質問をするという芸術があります。なぜなら、要件分析を行うとき、ほとんどの場合、クライアントに「A が欲しいですか、それとも B が欲しいですか?」と尋ねるからです。しかし、すでにフィールドを狭めており、質問する相手に誤った選択肢を与えている可能性があります。オープンエンドの質問に対応できなければなりません。LLM はオープンエンドの質問に対応できると思いますか? そして、答えが出てくるにつれて、絞り込んでいくのです。
Anthony Alford: LLM をラピッド プロトタイパーやシミュレーターとして使うというアイデアは、本当に気に入っています。たとえば、LLM を API として使うプロジェクトを見たことがあります。とても便利だと思います。
Michael Stiefel: その場合、ソフトウェア開発者のトレーニングは依然として従来の方法で行うことになります。
とりあえず、その考えでいきましょう。LLM はラピッドプロトタイパーです。再利用可能なコードを生成するかどうかはわかりません。プロトタイプでわかったことの 1 つは、すべてを捨てる覚悟が必要だということです。
Michael Stiefel: プロトタイプを構築して「このコードを救いたい」と思うと、トラブルに巻き込まれることがよくあります。すべてを捨てる覚悟が必要です。そこで、LLM を使用して迅速なプロトタイプを作成します。では、次のステップは何でしょうか?
また、次のステップを考えるとき、どのように機能させるかを考えます。セキュリティ、スケーラビリティ。アルゴリズムを設計することと、拡張可能なアルゴリズムを設計することは別のことです。
Anthony Alford: はい。そうですね、たとえばセキュリティの部分では、私たちの会社のセキュリティ チームは既に多くの自動化を行っています。これも LLM に最適だと思います。LLM ではないかもしれませんが、自動化はセキュリティ担当者がよく使用するものです。LLM はログなどの読み取りに適しているかもしれません。
Anthony Alford: たとえば、侵入を見つけるなどです。とにかく、その部分だけは私に答えがあります。スケーラビリティについては、何らかの方法で大規模な負荷を生成するのに役立つかもしれないということ以外、よくわかりません。Roland、何かアイデアはありますか?
Roland Meertens: いいえ、そうではありません。この場合、私は人間なので、InfoQ に行って他の専門家のやり方を見る以外に、常に物事のやり方を知っているわけではないとも言わなければなりません。LLM は皆さんが書いた記事をすべて読んでいて、私のために要約できるとしか思えません。
マイケル・シュティーフェル：記事の中で私が最初から正しかったと仮定します。
Roland Meertens: そうです。その意味では、コード生成の要件はブレインストーミングの良い方法になると思います。ChatGPT のようなものは、機能性についても考えるように思い出させてくれると思います。
Michael Stiefel: 開発されているものについて私が聞いているのは、LLM は基本的にアイデア ジェネレーター、つまり人間が「これについて検討しましたか? コードを確認しました」と確認するためのチェッカーとして使用されているということです。確かに、コードを見ただけでは多くの愚かなことが生成されるかもしれませんが、チェックリストは生成されます。「この API を使用する場合、これについて検討しましたか? ここで Mutex を使用する必要がありますか?」などです。これが、私たちが目指す方向ですか?
Roland Meertens: そうですね、このポッドキャストは「私が何をしたか」についてなので、私が楽しみにしていないディストピア的なことは、誰かが私をプルリクエストに追加する日が来ると思うことです。ジュニア開発者が私をプルリクエストに追加するのです。私は自分が正しく、彼らの AI 生成コードは間違っていると主張しますが、その後、おそらく彼らの ChatGPT 生成コードの方が最初から優れていて、彼らの AI 生成提案は私のコードよりも高速であることに気付くでしょう。
Michael Stiefel: そうですね、それは私たちにとって屈辱的ですが、必ずしも悪い未来というわけではありません。その考えでいくと、何が問題になるでしょうか? 事前分析をしていたとしましょう。事前分析の考え方はよくご存知でしょう。何かが成功したら、自分自身に「それで、何が問題になるだろうか?」と問いかけます。ここで何が問題になるでしょうか?
Anthony Alford: すでに触れたと思います。このようなコードを生成した場合の大きなリスクは、何か問題が起きたときに、誰も解決方法がわからないということだと思います。
自動運転車について、こんなアイディアがあります。この分野の専門家の皆さんは、私の意見を事実確認してくれるかもしれません。すべての車両が自動運転になれば、交通事故は全体的に減るのではないかという私の考えです。しかし、実際に起こった事故はとんでもないものです。それは、The Office で湖に突っ込むような、人間が決してやらないようなことなのです。
アンソニー・アルフォード：同じようなことが起こるのではないかと思います。
Anthony Alford: 生成されたコード。
マイケル・スティーフェル: あなたの例え話を取り上げましょう。これは非常に興味深いことだと思います。完全自動運転車についてお話しする前に、自動運転車に関して問題なのは、世界が自動運転車に近づいていくことです。人間と自動運転車が同時に存在すると、問題が発生します。2 つの例を挙げましょう。
1つは、ピッツバーグ レフトと呼ばれるものです。米国で運転する人にとっては、交差点では直進車が曲がる車よりも優先権があるというのが一般的な認識です。しかし、ピッツバーグでは、左折する車が優先権を持つという地元の慣習があります。問題は、他の都市でデータに基づいてトレーニングされた車がピッツバーグに来た場合、どのような状況になるかということです。あるいは、スウェーデンで、道路の左側を走行していたのが一夜にして右側を走行するようになったという状況があります。人間は見事にそれを実現しました。自動運転車がそんなことをできるとは思えません。
Roland Meertens: できるだけ早く状況から学ぶ必要があるということ、そして、実際にさまざまな領域ですべてを一度に捉えられるように、運転を習得する必要があるということだけを聞きました。
Michael Stiefel: はい。しかし、すべてが自動化されている場合は簡単なケースだと思います。Anthony さんがおっしゃるように、鶏が道路を横切るなど、予期しない事態に遭遇するケースがあります。しかし、すべてが自動化されていれば、すべてが予測可能になります。なぜなら、すべてが何をすべきかを知っているからです。問題は、半分は自動化されていて、半分は自動化されていない世界で、そこに問題が生じることです。ここで、自動運転車についてお話しされましたが、LLM を使用してコードを生成する場合、LLM が常にコードを生成しているかどうかわからないという状況との類似点があるかどうかはわかりません。
Roland Meertens: そうですね、私は依然として、問題は主に人間にあると考えています。コードについて考え、問題について考えることで、実際に達成したいことに対する洞察が得られます。一方、すべてを自動化すると、最終的にはすぐに Web サイトが完成するかもしれませんが、なぜこの Web サイトをもう一度作成したのでしょうか。ChatGPT が生成してくれたことに満足したのでしょうか。ChatGPT のようなものを使用したときに私が気づいたことの少なくとも 1 つは、最初は友人にメッセージを書くためによく使用していたということです。「友人にメッセージを書く機能を失いたくない」という感じです。10 桁の電話番号を携帯電話に保存したため、私たちはすべて 10 桁の電話番号を記憶できなくなったと思います。
マイケル・シュティーフェル： そうですね、今でもそれはできますが、それはずっと前にその訓練を受けたからです。
Roland Meertens: そうです。若い人たちは、もう 10 桁の数字を覚える方法を知りません。
Michael Stiefel: そうですね、レジで誰かがいるといつも驚かされます。私はクレジットカードではなく現金を使いたいときがあります。頭の中でお釣りの金額を計算できるのに、レジの相手は「どうやって計算したの?」と聞いてくるのです。
Roland Meertens: そうです。おそらく、ある時点で、「待ってください、実際にメモ帳を開いて HTML を自分で編集することができます」と言う人がいるでしょう。
マイケル・スティーフェル： そうですね、それは『バック・トゥ・ザ・フューチャー』ですね。
アンソニー・アルフォード: これを「今日の子供たち」にするつもりです。
Michael Stiefel: 実のところ、非常に興味深い点を指摘しています。なぜなら、先ほど、お二人が ChatGPT が何をしたかを把握することについて話していた点に戻りましょう。問題は、コードがどれだけエレガントになるかということです。なぜなら、ChatGPT が賢ければ、あらゆるところに go-to に相当するものが存在する可能性があるからです。スパゲッティ コードを生成して理解することはできますが、あなたが言うように、メモ帳を開いて HTML を見なければならない場合、それを見て「一体何が起こっているんだ?」と思うでしょう。これは危険ですか?
Roland Meertens: DeepMind の AlphaDev がより高速なソートアルゴリズムを発見したのをご存知ですか?
アンソニー・アルフォード：はい、その見出しは見ました。
Roland Meertens: はい。少し前に、ある種の強化学習エージェントを訓練してコードを生成するという実験が行われ、そのアルゴリズムによって、命令数が 33 から 32 に増えたことがわかりました。これは、人間が書いた最速のコードよりも少し速いものでした。
Michael Stiefel: しかし、問題はソート アルゴリズムにあります。古き良き時代を振り返ると、私たちは自分でアルゴリズムを選択して記述しなければなりませんでした。ソート アルゴリズムは、すべてのケースで普遍的に使用されるわけではありません。たとえば、バブル ソートは、私が覚えている限りでは、データがほぼ既に整列した状態である場合を除いて、非常に優れたソートです。そのように記憶していますか? わかりません。
問題は、先ほどより高速なソートを思いついた状況で、アルゴリズムはこのソートを使用するケースを認識しているかどうかです。それとも、あらゆる場所で盲目的に使用するだけでしょうか。
Roland Meertens: あるいは、このアルゴリズムを特定の展開に適用することもできます。
Roland Meertens: 「P99 レイテンシを最適化してください」と指示するだけです。その後、何が起きているのか、どのような AB テストが設定されているのかはわかりませんが、P99 レイテンシは徐々に低下します。それが AI が特定の国の顧客を拒否し始めたためかどうかはわかりません。結局のところ、何を最適化しているのかということが本当の危険だと思います。
Michael Stiefel: つまり、LLM の世界では、たくさんのことを記録しなければならないということですね。
Anthony Alford: そうです。実は、考えてみると、LLM がソフトウェア開発パイプラインの一部になるのであれば、プロンプトを Git にチェックインする必要があります。プロンプトをソース コードにコミットする必要があります。なぜなら、それがソース コードだからです。
Michael Stiefel: プロンプトのバージョン管理はできていて、… では、質問は… わかりました。少し考えさせてください。何年も前、私は軍のコンピュータ設計の世界で働いていました。軍はアプリケーションのユーザーの 1 つです。軍は設計をアーカイブするときに、設計の作成に使用されたソフトウェアもアーカイブしていました。そのため、設計を修正する必要がある場合、そのソフトウェアをそのまま使用できました。プロンプトをアーカイブするだけでなく、それらのプロンプトで使用された LLM もアーカイブすることを提案しているのでしょうか?
Anthony Alford: そうすべきだと思います。PIP が Python 環境の要件を凍結するようなものです。わかりません。使用しているモデルによって異なります。LLM が単なる Copilot であり、それが役立っている場合、それは基本的に Stack Overflow からコピーして貼り付けるのと同じです。
Michael Stiefel: そうですね。結局のところ、切り取って貼り付けたもの、入れたもの、生成されたものに対して責任があるのはあなたです。すると、ある時点で、LLM は、私たちが単に動作すると想定していたコンパイラになるのか、という疑問が生じます。
一度、コンパイラーにバグが見つかったことを覚えています。コンパイラーがページ境界に命令を配置し、実際にその原因となったページ フォールトを検出したのですが、これは非常に高度な処理で、舞台裏で何が起こっているかを理解する必要があります。人々は理解するでしょうか?
Roland Meertens: 理解はもっと早くできると思います。個人的には、皆さんが笑うかもしれませんが、SQL クエリの書き方や他の大規模データベースの操作方法がまったくわかりません。PySpark の操作方法もよくわかりません。しかし、最近ではこれらのツールにはすべて AI が組み込まれているので、私がすることは「このテーブルからこのデータを取得して、これを実行して、これらの特定のものを選択してください」と言うことだけです。これを初めて行う日は、何をしているのかまったくわかりませんが、自動的に生成されたコードが表示され、自動的に処理されます。これは素晴らしいことですが、数週間後にはパターンが見え始め、実際に学習し始めます。つまり、私にとってはよりインタラクティブな学習であり、AI が生成したコマンドを通じて API をゆっくりと学習します。何かがクラッシュしたときは、実際に修正するように依頼できます。これは非常に強力です。
Michael Stiefel: しかし、非常に興味深いことをおっしゃいました。SQL を書いたときに学ぶことの 1 つは、たとえば、特定の種類のクエリを実行する場合、列にインデックスを付けたい場合があるということです。これは、私も人生でかなりの数の SQL を書いてきました。
Michael Stiefel: ヒントや、パフォーマンスなどのために、再正規化や非正規化を行う必要があるかもしれません。学べないことや、やり方がわからないことがいろいろあります。繰り返しになりますが、私が言いたいのは、常に何らかのコンテキストやメタ問題が存在するということです。私が心配しているのは、LLM が盛んなこの新しい世界では、人々がメタ問題に関する知識を失ってしまうことです。変化を起こす能力、集中力を長く持続させる能力などを失い、コンテキストを失い、これらのものを信頼し始めます。すると、すべてを破棄する以外に抜け出す方法が見つからない状況に陥ってしまいます。
アンソニー・アルフォード: そこまで到達できるかどうかは分かりません。しかし、私はそう思います… 10代の子供を持つ者として、私は別の見方もできます。私たちの大部分がまだマシンコードを書いていないのには理由があるのです。
Anthony Alford: 知っている人もいます。ごく少数だと思いますが。しかし、コンパイラが登場したとき、誰もが「今の子供たちはマシンコードの書き方を知らない」と言っていたに違いありません。
Michael Stiefel: はい、そうでした。何人かはそう言いました。彼らは「アセンブリの書き方が分からない」と言いました。
Anthony Alford: でも、私はまだそれを学んでいて、そんなに昔のことではないと思います。でも、とにかく、私が言いたかったのは、Roland が言ったことと同じです。私たちがこれらのものをツールとして使って、物事を学び、生産性を高めることができれば、それは良い未来だと思います。確かにいくつかのスキルは失われると思いますが、時には… 実際、物事の全体像から見ると、マシン コードを書くことは、人々がまだ必要とするスキルなのでしょうか?
マイケル・シュティーフェル：いいえ、おそらく…
アンソニー・アルフォード：人々は今でも書くことはできますし、書くことは昔から存在しています。
Michael Stiefel: 携帯電話が初めて登場したとき、機械語コードを書く能力が非常に重要だったことは知っています。仮想メモリがなかったため、そのスキルが復活する必要がありました。メモリ マッピングなどについて心配する必要がありました。これは、全体的な状況に関係します。
Anthony Alford: 私の妻は 21 世紀になっても組み込みソフトウェア用のアセンブラを書いていました。
Michael Stiefel: 繰り返しになりますが、これはコンテキストの点、つまりツールがどこで機能し、どこで機能しないかを知ることに戻ると思います。人々が知らない世界では、それが失われてしまうのではないかと心配しています。ドナルド・ラムズフェルドが言ったように、「未知の未知があなたを困らせる」のです。あるいは、ツールの限界があなたを困らせるのです。自動化が進めば進むほど、そのリスクが高まります。中庸なところはどこにあるのでしょうか?
繰り返しになりますが、経済効率が私たちの原動力です。プログラミング プロジェクトで最もコストがかかるのは、おそらくプログラマーのコストです。
Roland Meertens: そうです。あるいは、最もコストが高いのは、インデックスの使い方をまったく知らないこの開発者が書いた非常に大きな SQL クエリです。
アンソニー・アルフォード: それは研究開発費だと思います。ソフトウェアが数時間、数日間停止した場合のコストはいくらでしょうか? 確かに、ある意味では愚かにも近視眼的な企業は常に存在しますが、生き残るのはそうではない企業だと私たちは願っています。
Michael Stiefel: しかし、プログラマーを生き残らせるための道筋は何かという疑問が残ります。進化の過程では、どれほどの苦しみがあったのでしょうか。恐竜は進化の過程で姿を消しました。生き残れなかったのですが、それには長い時間がかかりました。では、知らないことをどうやって知るかという疑問が残ります。経済効率の問題だと思いますが、私は何度もこの現象を見てきたので確信していますが、ほとんどのマネージャーはプログラマーは交換可能だと考えています。特に大規模な組織では、交換可能です。
Michael Stiefel: 代替可能、そうですね。これは、プログラマーを解雇してテクノロジーを利用する経済的インセンティブを人々に与えるでしょう。何年も前、LLM が登場する前でさえ、コードの自動生成が間近に迫っていると人々が言っていたことを覚えています。
アンソニー・アルフォード：はい、彼らはしばらく前からそう言っています。
Michael Stiefel: そうです。しかし、プログラマーは面倒でお金がかかるので、マネージャーがそう信じる強い動機がありました。彼らは、いや、だから解雇しろと言います。私はここである程度、悪魔の代弁者を演じていますが、これは LLM を持つ大きな推進力になると思います。あるいは、プログラマーを雇う余裕のないスタートアップ企業です。
ローランド・ミーアテンス：しかし、そうすると企業内の部族的知識の多くが失われることになります。
マイケル・スティーフェル：はい、そうです。でも、彼らは気にするでしょうか？このことについて考えれば考えるほど、私たちが向かうこの世界は、多くの技術が変化する世界だということに気づきます。たとえば、携帯電話を例に挙げましょう。集中力の持続時間の問題については誰も考えませんでした。TikTok については誰も考えませんでした。スパイウェアについては誰も考えませんでした。プライバシーの問題については誰も考えませんでした。
Roland Meertens: その意味では、優秀なシニア開発者とそうでないシニア開発者の違いは、LLM が生成した提案をすべて自動的に受け入れるか、実際に生成された提案をじっくり考えるために少し時間を取るか、どれだけ自制心を発揮できるかにあると思います。
しかし、コードを読んで何が起こっているかを素早く理解し、それを受け入れるか拒否するかを判断する能力は、はるかに重要なスキルになるでしょう。
Michael Stiefel: そうですね、おっしゃる通りだと思います。私がプログラミングのキャリアを始めて間もない頃に学んだことの 1 つは、コードは書かれるよりも読まれることのほうがはるかに多いということです。コードは、書き手ではなく、読者、つまり潜在的な読者の視点から書かれるべきです。言い換えると、ドナルド・クヌース (お二人ともこの名前はご存知だと思います) は、「文芸的プログラミング」という本を書きました。彼の考えは、説明的な方法でプログラミングするというものでした。
Roland Meertens: そうですが、どれくらいの頻度で、ちょっと時間を取って、素敵なコードを読んでいますか? いつも不思議に思うのですが、SF 作家で、「最後に読んだ本は何ですか?」と聞かれて、「本を読んだことがないんです」と答えると、「ああ、どうして彼が良い作家になれるんだ?」と思われがちです。しかし、プログラマーに「最後に読んだコードは何ですか?」と尋ねると、「ああ、楽しみのためにコードを読むつもりはありません」と答えられます。それが新しいスキルであるにもかかわらずです。
Michael Stiefel: 他の人のコードをデバッグしたり、コードを見たりしなければならなかったので、私はいつもコードを読んでいました。同僚のコードを理解できるようにコードを読んでいました。おそらく、私がコードの読み方を学んだのは、上司に睨まれたときでした。おそらく、それは将来の世界で再び必要になるスキルでしょう。
ここまででまとめとして、お二人にお聞きしたいと思います。私たちの会話とお二人の考えを踏まえて、この世界はどのようなものであり、私たちは本当にこの世界で暮らしたいと望んでいるのか、という疑問が湧いてきます。なぜなら、今こそ「やめろ」と言うべき時だからです。今、私たちは本当にやめろと言えるのでしょうか。それは、誰かが開発し、誰もが持たざるを得なくなる原爆のようなものでしょうか。それとも、これは良い考えではない、あるいは特定の地域に限定すべきだと言える現実的な可能性はあるのでしょうか。
アンソニー・アルフォード：もし誰かがそれを止められるとしたら、それは弁護士だろうと言おうと思っていたが、彼らが止められるかどうかは分からない。
マイケル・シュティーフェル：すでに始まっていますね。例えば、エア・カナダのボットの話はご存知ですか？
ローランド・ミーアテンス: エア・カナダのボットの話は知っています。約束できないことを約束したのです。
マイケル・スティーフェル: そうです。しかし問題は、エア・カナダが「いやいや、これはプラットフォームです。私たちには責任はありません」と主張しようとしたことです。裁判官は「いや、責任はあなたにあります」と言いました。
今のところ、そのほとんどは著作権訴訟だと思いますが、最終的には訴訟になると思います。それは確かに可能性の一つです。
アンソニー・アルフォード: この未来を明るい未来に変えるにはどうしたらいいかと言うとしたら、マシンにコードを書かせて、本当に良いテストを書こうと言うでしょう。これは私が現在開発チームに伝えていることです。本当に良いテストをしましょう。本当に良いテストがあれば、常にテストを実行し、スケールやセキュリティなどについてテストを実行すれば、素晴らしいことです。コードをデバッグしたり、コードを見て微調整したりできるベテランを雇います。しかし、それ以外は、好き勝手にやらせましょう。
Michael Stiefel: ベテランが引退したらどうなるのでしょうか? 次のベテランをどうやって獲得するのでしょうか?
アンソニー・アルフォード：心の底では昔からの人というのは常に存在します。
マイケル・シュティーフェル：私が正しく理解しているなら、あなたが提案しているのは分業のことです。
Michael Stiefel: それは、LLM がテスト可能なコードの書き方を学ばなければならないことも意味します。
アンソニー・アルフォード: そうです、それが鍵ですよね？私たち全員です。
Michael Stiefel: そうですが、それがポイントです。言い換えれば、分業が機能するためには、LLM はユニット テスト、シナリオ テスト、ユース ケース テストになる可能性のあるコードを生成する必要があります。LLM はそれを実行する方法を知っている必要があります。
Anthony Alford: 弊社のテスト方法は、API を使用することです。API を呼び出すテストを作成し、エンドツーエンドでテストします。ユニット テストは確かに重要ですが、エンドツーエンド テストは重要です。
Michael Stiefel: しかし、ユーザー インターフェイスもテストする必要があります。
アンソニー・アルフォード： そうです。それは素晴らしい人間のスキルです。
Roland Meertens: ベータ版の頃からずっと Copilot を使ってきた私にとって、この Copilot がコードに自動的にコードを挿入してくれるおかげで、プログラミングに関する新しい技をたくさん学ぶことができました。そのため、普段ならやるような API を探索し、物事をより速く実行できる新しい技を見つけました。ゼロから考えなければならなかったら、このような方法では実装しなかったでしょう。LLM のおかげで、より優れたプログラマーになれたと思います。しかし、人は自制心を持つべきです。すべての提案をただ受け入れてはいけません。
Roland Meertens: 自分が本当に達成したいことを常に考えてください。私にとって、この制約が最も難しいと思います。疲れたとき、提案されたものをすべて受け入れていることに気づくことがあります。その瞬間、非常に悪いコード、非常に悪いプロトタイプを書き始め、何も意味をなさなくなり、メンテナンスもできなくなります。責任を持って使用するには、少なくともある程度は意識していなければなりません。中毒性のある多くのものと同じように、責任を持って使用し続けなければなりません。
Michael Stiefel: 終わりまでにあと 2 つ質問があります。1 つは、新しい開発者をどのようにトレーニングするかということです。あなたは自制心を発揮することについてお話しされています。あなたはコードを書いてきた世界から来ており、自制心とは何かを知っています。次世代のプログラマーに、恐れること、尊敬すること、どんな形容詞や動詞を使ってもよいので、テクノロジーの扱い方を教えるにはどうすればよいでしょうか。
Roland Meertens: 最終的に問題が解決するまで、GitHub の「作業が必要」ボタンを押し続けます。
アンソニー・アルフォード: そうですね、その 1 つかもしれません… 私には答えがありませんが、答えがあるはずです。経験だと思います。Stack Overflow からコピーして貼り付けることもできます。そうすべきかどうか、どうすればわかるのでしょうか。経験もその 1 つです。若い世代の場合、彼らを深いところに放り込むことがあると思います。
アンソニー・アルフォード: もちろん、彼らを指導し、溺れさせないようにします。
マイケル・シュティーフェル：しかし、彼らは溺れそうになります。
アンソニー・アルフォード: 実際のところ、人は間違いをすることで学ぶので、間違いを犯せる環境を人々に提供する必要があります。今と同じですね。間違いを犯せる環境を人々に提供する必要がありますが、間違いが悲惨な結果にならないように、幸運を祈るしかありません。
Michael Stiefel: そうですね。ソフトウェア開発では、常にある程度の祈りが伴います。
最後に質問します。ニコルソン大佐について考えるとき、何があなたに「この技術で何をしてきたのか」と言わせるのでしょうか。また、何があなたに「この世界で何をしてきたのか」と自問させる恐れがあるのでしょうか。
Roland Meertens: 私にとって、以前は楽しいと感じていたことはたくさんあります。なぜなら、くだらないことについてのシンプルな Web サイトの作成から、クールなことについてのクールな技術プロトタイプの作成まで、ある種のチャレンジがあったからです。以前は楽しい週末プロジェクトだったものの多くが、今では ChatGPT で 5 分で作成できてしまうので、楽しさがまったくなくなってしまいました。手作業で作業を続けられる限り、私はとても幸せです。しかし、残念ながら、何かを自動化できることを知るだけで、楽しさが失われてしまうことがあります。
アンソニー・アルフォード: 制御を維持し、自制する必要があるという事実を見失っているだけだと思います。ロボットに支配されないようにする必要があります。それが私たち全員が抱いている恐怖だと思います。結局のところ、私たち全員が抱いている恐怖は、ロボットに支配されることです。それが生命を終わらせるとは思いませんが、何か悪いことが起こった場合、企業にとって非常に大きな損失になる可能性があります。そこで私は「私は何をしたのか?」と考えます。私は CTO ではありませんが、もし私が CTO で、これを実装して会社を破滅させたら、「しまった」と思うでしょう。
マイケル・スティーフェル: お二人とも、どうもありがとうございました。とても興味深い内容でした。リスナーの皆さんが何かを学んでくれればと思いますし、世界を少しでも良い場所にし、人々に物事について考えてもらう機会になればと思います。
アンソニー・アルフォード: はい、とても楽しかったです。お招きいただきありがとうございました。
ローランド・メーアテンス：お招きいただきありがとうございます。
オブジェクト指向 UX (OOUX) と Sophia Prater
安全のためには不幸な道を歩む必要がある – ロバート・ハールバットとの会話
AI、プラットフォーム エンジニアリング、Staff-Plus のナビゲート: InfoQ Dev Summit Boston プレビュー
コートニー・ナッシュがインシデント管理、自動化、VOID レポートについて語る
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
2024 年 6 月 24 日 – 25 日 | ボストン、マサチューセッツ州今日の重要な開発優先事項を明確にする実用的な洞察。InfoQ Dev Summit Boston は、InfoQ が主催する 2 日間のカンファレンスで、シニア ソフトウェア開発者が現在直面している最も重要な技術的決定に焦点を当てています。20 以上の技術講演を詳しく聞き、ジェネレーティブ AI、セキュリティ、最新の Web アプリケーションなどを扱うシニア ソフトウェア開発者から革新的な学びを得ましょう。今すぐ登録
InfoQ.com およびすべてのコンテンツの著作権は © 2006-2024 C4Media Inc. に帰属します。プライバシー通知、利用規約、Cookie ポリシー
元記事: https://www.infoq.com/podcasts/llms-programming-tasks-training-developers/