前提の罠

オープンソースであろうと職場であろうと、若手プログラマーとのコラボレーションで私にとって最も難しいのは、前提条件の罠を回避することです。ここで、コードの最初のドラフトに組み込まれた基本的な前提条件は、実装の改善に非常に長い時間を費やすまで疑問視されません。 AIも同様です。なぜなら、現時点のAIは優秀なジュニアプログラマーのようなものだからです。構文と API について百科事典的な知識を持っている人もいますが、過度に複雑で微妙に欠陥のあるソリューションを作成する同じ傾向を抱えている人もいます。これは、AI プログラミングの将来に対する強気のシグナルと読むこともできます。現在の軌跡は人間のプログラマの成長ツリーに従っており、最終的には優秀な後輩と同じように、コードの美学、新しい問題の推論、アーキテクチャの一貫性の細部における能力の上級レベルに卒業することになります。そうであることを願っています。しかし、現時点では、私が過去 1 年間使用してきた AI モデルが、私がよく知っているドメイン内で優れたコードを生成しているのをまだ見ていないという事実は変わりません。有望な若手プログラマーの場合と同様に、時折、かすかな光が見えることもありますが、全体として見ると、ほとんどの場合、ソリューションにはかなりの量の手直しが必要です。そのとき、前提条件の罠が鳴り響きます。AI から生成される Ruby と JavaScript コードの両方でこれを繰り返し見てきたので、ある言語に別の言語に特有のものがあるとは思えません。しかし、不必要な依存関係を引き込む傾向、冗長すぎるプレゼンテーション、アーキテクチャ上の行き詰まりは常に存在します。これは、実際に有能なプログラマーではないのに、AI を使用してシステム全体を作成しようとしている人々から聞いた話です。プロトタイプがわずか数分で完成するのを見るのは信じられないほどの慌ただしさですが、実際にこれを確実に動作するものに移行させると、一歩前進、二歩後退のダンスになることがよくあります。 (Upwork で、かろうじて資格のあるジュニア プログラマーにナマズに遭ったという多くの話と似ています。)それはもどかしいことですが、これらのモデルを教えてきたトレーニング データを考慮すると、それは完全に理にかなっています。基本的なオンライン チュートリアルの無限の流れ、スタック オーバーフローの簡略化された回答、そしてインターネット プログラミング コンテンツのかなりの部分が盲人が盲人を先導して作成しているという残念な現実。人間の上級プログラマーは皆、同じ情報ダイエットに取り組み始めましたが、最終的には独自のコード ベースに取り組むことで、より高いレベルの理解と習熟を目指しました。ここでは、チュートリアル スタイルのコードには存在しないすべてのトレードオフが明らかになり、巧みな方法で比較検討する必要があります。現在のパラダイムの下でこれらのモデルが次の大きな飛躍を遂げるのは、おそらく、独自の企業コードに関する膨大なコーパスにさらされるまでは起こらないだろうと思います。そして、それがどのように起こるかは、現時点では完全には明らかではありません。したがって、それまでは、上級プログラマーとして、AI をジュニア プログラマーと同じように扱うのが賢明です。アーキテクチャや実装の最終的な品質を気にする場合、システム全体、さらにはサブシステムの作成を依頼しても、時間を節約できることはほとんどありません。なぜなら、そのパスに組み込まれた前提を検証するには、自分で作業を行うのと同じくらい多くの時間をかけて選択肢を理解する必要があるからです。私は AI が私たち全員のためにコードを書くことについては引き続き強気ですが、その現在の能力については現実的でもあります。同時に、私を含む上級プログラマーを誘惑して中途半端なサインオフに誘導する危険性も警戒していますが、その一方で私たちは方法を教えるよりも AI が書いてくれることに頼りすぎているため、継続的に学習するための体力を消耗してしまいます。この作品が数年以内にひどく老化しますように! #前提の罠