未来のためのコーディングパネル

パネルディスカッションではAIコーディングの未来について議論が開始される。Factory の使命は、ソフトウェアエンジニアリングに自動化をもたらすことであり、エンドツーエンドのソフトウェア開発エージェント「ドロイド」を構築している。ドロイドは単なるコーディングだけでなく、ドキュメント、テスト、レビューなど、ソフトウェア開発ライフサイクル全体の退屈な部分をカバーし、開発者は楽しい部分に集中できるように設計されている。このアプローチにより、開発者はやりたくない作業をエージェントに委譲できるようになる。

Codec チームは年初にコーディングエージェントをリリースし、Codec CLI でローカルに推論モデルの力をユーザーコンピュータに提供し、その後 Codec Cloud でクラウド上でタスクを配布・委譲できるようにした。最近数ヶ月で Dev Day で Codec SDK をリリースし、基本機能をできるだけ有用にすることに焦点を当てている。重要な方向性として、コーディングやコード実行エージェントを一般的な目的のタスクにも使えるようにしており、開発者が推論モデル、サンドボックス、Codec に組み込んだ機能の上に構築できる環境を整備している。V0 では、プレビュー駆動のエージェント的プログラミングにより、開発者がエージェントを実行して実行中のアプリに直接プロンプトを送ることが可能になった。

ローカルとクラウドのどちらが重要かについて、複数の視点から議論される。エージェントの目的は、できるだけ役に立つことであり、人間の協働に類似すべきである。短期的には、リモート（クラウド）環境が確実に委譲できる小さなタスクに適しており、ローカル環境はより大きく複雑なタスク、能動的に監視が必要な場合に適している。最終的には、これらのリソースは両方の場所に存在すべきであり、エージェントループはどこでも実行でき、ツール呼び出しがクラウドからローカルにまたはその逆にストリーミングできることが理想的である。すべては、実際に作用したいリソースの場所に依存している。

実際の開発での agents.md の例を通じて、ホワイトボーディングセッションから始まるコラボレーティブなアプローチが説明される。ローマンと話し合い、ホワイトボード上に描き、写真を撮ってからローカルで Codec CLI で起動し、Next.js アプリのワークショップのような形で作業を進めた結果、昼食後には核となる構造の大部分が完成していたという経験談が示される。このペアリングのようなブレインストーミングスタイルのエクスペリエンスにより、より小さなスコープで出力が明確なタスクに対しては「やり放し」のモダリティが適切であること、また GBD5 Codec では長時間実行でき複雑でより曖昧なタスクでも対応可能になったことが説明される。

「スロップ生成」の危険性についての議論が展開され、ドキュメント生成の例を通じて、最も丁寧に作られたものではないが価値を提供する場合があることが説明される。重要なのは、ツール活用をどこで見つけるか、そしてどの程度がスロップかはユーザーが提供するガイダンスのレベルに依存することである。単に「アプリを作ってくれ」と言えば一般的で有用性の低い結果になるが、非常に具体的で明確なガイダンスを提供すれば、より構造化された結果が得られる。エージェントを機能させるには高い下限があり、スキルのない人でもエージェントはできることが多く、スキルがある人はエージェントを使って自分ができることをレベルアップすることができるという「レバレッジ」の概念が強調される。主要エンジニアは手動で1日あたり5,000行のコードを書けるが、エージェントを使うと1日あたり50,000行のコードを書ける可能性がある。

エンタープライズでのエージェント採用に関して、初期キャリアの開発者と経験豊かなエンジニアの間に興味深い二峰性が存在することが指摘される。初期段階のエンジニアはエージェントネイティブな方法で構築することにオープンマインドだが、チーム管理の経験がなく、委譲の方法に精通していないため、詳細な指示なしに良好な結果を得られない。一方、シニアエンジニアは委譲の経験が豊富で、詳細な仕様書の作成が得意だが、構築方法を変えることに慎重である。実際には、シニアエンジニアが詳細なチケットを作成し、ジュニアエンジニアがそれをエージェントに与えることで、より効率的なワークフローが成立する。この動的により、ジュニアエンジニアがエージェント作業を仲介し、シニアエンジニアが仕様作成と建築上の決定に注力するというロール分担が自然に形成される。

オープンモデルの重要性について、持続可能な開発ライフサイクルにおける開放性の価値が強調される。Codec CLI はオープンソース化され、オープンモデルが地平線に現れることの理解、推論モデルの使用方法の説明、ツール、環境、リソースに関する混乱の解消が優先事項だった。Factory のベンチマーク「Terminal Bench」では、オープンソースモデル、特に GLM が思った以上に良好で、フロンティアモデルよりも低性能だが大きなマージンではないことが判明した。オープンソースモデルのサポートリリース以来、使用者の割合が劇的に増加し、1年前は5%、現在は10～20%まで上昇している。一方、クローズドソースモデルは推論が必要なオープンエンドな質問に最先端で、オープンソースモデルは専門的で目標関数が明確なタスクでのファインチューニングに有効である。Qwen、QWEN-32K などのモデルでも相応の成功が見られており、オープンソースモデルの追いつきが急速に進んでいる。

エージェントが来年までに実現できることとして、二つの主要な分野での進展が説明される。第一に、信頼性のあるエージェント実行ステップ数が1～3ステップから100ステップ以上に拡張され、複数時間の長時間実行タスクで最終的に有用な出力を得られるようになると予想される。第二に、消費できるリソースの観点から、MCP や API 呼び出しで外部接続を設定できる現在の方式から、エージェント自身がコンテキストソースを積極的に発見するようになることが期待されている。ユーザーが与えるべきコンテキストソースを知る必要がなくなり、エージェントがデフォルトモードで自動的にそれを見つけるようになる。ただし、信頼性と積極性はユーザーのアプローチにも依存しており、正しくハーネスと環境を設定すれば、より確実かつ積極的に実行できるようになる。