私は過去18年間、およそ8年間(Google、Uberを含む)プロとしてコードを書いていますが、私はそれを本当に愛しています。
そして何が愛されないのか? 僕は楽しいものを作るのに時間を費やさなければならず、報酬フィードバックループは緊張していて、僕のツールは数年ごとにかなり良くなった。 シンタクス強調、自動完成、IntelliSense、プロジェクトレベルの再構成、そして初期のGithub Copilotでさえ、僕のコードを書く経験がより喜ばしいものになった。
この最新の波は非常に、非常に異なるように感じます。エージェントプログラミング (*cough* vibe-coding)では、それは別の増加的なアップグレードのように感じません。
次に、私のコードベースでコードエージェントが1発でまた別の小さな、しかしまだいくつかの曖昧なタスクを目撃したとき、それは突然私に浮かび上がった。それは私はもはや「コード」しているような感覚ではなく、むしろ私は「委任」しているような感覚です。「Feel the Agi」種類の瞬間。
システムを「リダイレクト」したり「プログラミング」したりしているような気がしますが、異なったのは、私は今、その目標を達成するためにエージェント・コーダーの組織をプログラミングしているのではなく、コンピュータを直接プログラミングしているということです。
スーパー実現
私が「コード」する方法を知っているという経済的価値はゼロに達しました。問題の事実は、世界中の誰もが今、ポケットにますます優れたコードの軍隊を持っている(またはすぐに持っている)ということです。
It's a bittersweet realization. I empathize withアマサドツイッターで「もうあなたがコードを学ぶべきだとは思わない」と述べた。
Coding for the sake of art v/s ユーザの為のコーディング
ACM-ICPCアジアの地域で2回も行ったこともあり、一般的に爆発したことがあります。問題を発見し、それを解決するためのコードを書くことから来る一定の焦りがあります。それはクロスワードパズルやスドーカや数学の問題とはまったく異なります。確かに、あなたはそれを行うのに助けを得ることができます(herm. cheat!),しかしそれはその意味ではありません。これは芸術的な考え方です。
製品に取り組む際には、その考え方を窓から捨てなければなりません。ここでは、コードは主に製品とユーザーにサービスを提供するために存在します。それは目的への手段です。エンドユーザは、私がそれを書いたかどうか、またはエージェントにそれを書くように指示したかどうかを気にしません。ユーザは、それが機能することを大切にします。正しく、信頼性、安全性、速さです。彼らは存在を忘れ、彼らの日を続けることができます。
残念ながら、その答えは、私が学ばなければならないかもしれない...その道から抜け出すことだと思うが、もしかしたら私はもはやコードを書くべきではないかもしれない、なぜなら、そうすれば、ボトルネックになるだろう、あるいはさらに悪くても、障害になるだろう。
イン「Average Is Over」タイラー・カウエン氏は、チェスの「人間+コンピュータ」チームのダイナミクスについて話し、そのようなチームアップは(驚くべきことに)2013年までまだ優勢だったが、チームへの人間の貢献のトレンドラインは明らかだった。“What are humans still good for” (人間はまだ何のために良いのか): :
♪最も才能のある人々でさえ、非常に実際の貢献者であることから、厳密にゼロの限界製品になることへの転換点へのアプローチを観察することは興味深い。
♪
最も才能のある人々でさえ、非常に実際の貢献者であることから、厳密にゼロの限界製品になることへの転換点へのアプローチを観察することは興味深い。
同様のダイナミクスは、コード化においてここで起きているように見えます。今のところ、私はまだマシンの出力を見てその上に価値を加えることによって価値を追加することができているように見えますが、再び - どのくらいの期間ですか? 今日の迅速なプロトタイプのための良いものは、今日の改善し、明日の強力なシステムの構築者になるでしょう。
一方で、低レベルのものを抽象化することは、この分野にとって新しいものではありません。 コンピュータサイエンスは、他の分野よりも多くのモレッソは、コンポーネビリティの豊富な歴史を持っています。 あなたがしばらくの間、機械コードやアセンブリで書いたことがない可能性があります(コンパイラに感謝します!) あなたはほぼ確実に他の人が作成したビルドブロック(ライブラリ / API / プラットフォーム)を使用しています。
今のところ、コーディングはソフトウェアエンジニアリングプロセスの全体的な部分に過ぎません. そして、私がこのシステムに最も価値をもたらす方法は、私のコーディング能力ではなく、私のビジョンと能力で、私が望むものを表現し、その目標に向かってこのエージェントの組織を導くことです. それは、できるだけ曖昧さを排除し、ビジョンとスペクションの間のギャップを橋渡しすることです.ある意味では、この役割はソフトウェアエンジニアのコードを書くよりも「エージェントディレクター」に近いです.
では、ここからどこへ行くのか。
エージェント組織の管理に適用されるように見える、人間組織の管理のアキモは、代表組織の管理に適用されるように見える。
- ♪
- あなたのエージェントの限界を知り、それに応じて委任します. 彼らは常に彼らが咀嚼することができるより多くを噛むことを心から試みます. 彼らを許さないでください. ♪
- チェックとバランスのシステムをセットアップして、変更が破壊されるときをキャッチし、エージェントを良いコードを書く方向に導く。 ♪
- エージェントが成功するために必要な情報を得ることができる環境を設定する ドキュメントは良い 懸念の分離は良い よく組織されたコードベースは良い。 ♪
- パラレル化は良いことです。単一のエージェントを待つだけではなく、特に長いタスクのために。将来のエリートプログラマーは、エージェントユニットの軍隊の出力を指揮し、コレクションすることによって、熱狂的な高級APMスタークラフトのプレイヤーに似ている可能性があります。 ♪
- そして最も重要なことは、あなたのビジョンを明確にし、それを明確に伝えることで、エージェントがあなたのより広い枠組みに適した正しい決定を下す権限を得ることができます。 ♪
結局のところ、あなたがついに何かを届けたら、あなたはまだ品質の印でそれを印刷しています。あなたの名前と評判はあなたのブランドです。それらのエージェントの「リード」として、あなたはまだ彼らの結果に責任があります。
