開発速度が20倍にアップしました！ GPT Pilot スター プロジェクトが Github のホット リストに掲載され、AI をゼロから構築

新たなスタープロジェクトが誕生！

AI 開発者コンパニオンである GPT Pilot を使用すると、アプリケーションをゼロから構築し、コードを記述し、開発環境を構成し、開発タスクを管理し、コードを自分でデバッグできます。

開発上の問題を解決するために、いつでもチャットして質問することもできます。

写真

プロジェクトアドレス: https://github.com/Pythagora-io/gpt-pilot

リリースから3か月経った現在、Githubでの人気は高まり続けており、現在では19,000個のスターを獲得しています。

写真

コード開発の95%はAIに引き継がれる

プロジェクトのホームページによると、GPT Pilot の目的は、開発者が実装を監督しながら、GPT-4 を使用して完全に機能する、本番環境対応のアプリケーションを生成できる範囲を調査することです。

写真

基本的な考え方は、AI はアプリケーションのコードの大半 (おそらく 95%) を記述できるが、残りの 5% については、完全な AGI が実現するまで開発者が必要になるということです。

写真

それで、それは具体的にどのように機能するのでしょうか?開発者は記事で GPT Pilot ワークフローを詳しく紹介しました。

GPTパイロットワークフロー

まず、構築するアプリケーションの説明を入力する必要があります。

次に、GPT Pilot は GPT-4 と連携してアプリケーションの要件を明確にし、最終的にコードを記述します。多くの人工知能エージェントを使用して、開発組織のワークフローを模倣します。

写真

- アプリケーションについて説明した後、プロダクト オーナー エージェントがビジネス仕様を詳しく説明し、不明な点があれば質問して明確にします。

次に、ソフトウェア アーキテクト エージェントは技術要件を分類し、アプリケーションの構築に使用されるテクノロジをリストします。

- DevOps エージェントは、アーキテクチャに基づいてマシン上の環境を構成します。

- 「テクニカル チーム リーダー」エージェントは、アプリケーション開発プロセスを、それぞれに次の要件がある開発タスクに分割します。

最後に、開発者と Code Monkey エージェントがタスクを 1 つずつ解決し、アプリケーションの作成を開始しました。

開発者は各タスクをより小さなステップに分割します。これは、人間によるレビューや自動テストの使用を必要としない低レベルの技術要件です (いくつかのパッケージのインストールなど)。

写真

GPTパイロットの3つの柱

柱1: 開発者はアプリケーション作成プロセスに関与する必要がある

現時点では、CLI に接続して独自にアプリケーションを作成できる LLM の実現にはまだまだ遠い状況です。

したがって、AI が完全に機能するアプリケーションを作成するには、AI がコードの大部分を記述する一方で、開発プロセスを監督し、技術チームのリーダーとして機能する開発者と AI が緊密に連携できるようにする必要があります。

したがって、開発者はいつでもコードを変更できる必要があり、GPT Pilot はそれらの変更を継続的に処理する必要があります。

開発者が開発プロセスに介入できる領域は次のとおりです。

各開発タスクが完了したら、開発者はそれをレビューし、期待どおりに動作することを確認する必要があります。

テストやコマンドの実行が失敗するたびに、開発者が何かをデバッグしやすくなる可能性があります。

柱2: アプリケーションは段階的にコーディングする必要がある

写真

人間と同様に、AI コーディングでも間違いは必ず起こります。そのため、デバッグを容易にし、生成されたコードで何が起こっているかを開発者が理解できるようにするために、AI はコードベース全体を一度に吐き出すべきではありません。

代わりに、開発者と同じように、アプリケーションを段階的に構築およびデバッグする必要があります。

GPT Pilot が段階的にアプリを作成すれば、AI とそれを監督する開発者の両方が問題のトラブルシューティングをより簡単に実行できるようになり、開発プロセス全体がよりスムーズに進みます。

柱3: GPTパイロットは拡張可能である必要がある

GPT Pilot は、コードベース全体が LLM 環境に適合する小さなアプリケーションだけでなく、大規模な本番環境対応アプリケーションを作成できる必要があります。

重要なのは、LLM におけるすべての学習は文脈の中で行われるということです。おそらく、いつか LLM は特定のプロジェクトごとに微調整できるようになるでしょうが、現時点では、これは非常に時間がかかり、冗長なプロセスになると思われます。

GPT Pilot は、コンテキストの巻き戻し、再帰的な会話、TDD を使用してこの問題を解決します。

コンテキストバックトラッキング

コンテキスト バックトラッキングの背後にある考え方は比較的単純です。解決される開発タスクごとに、LLM に送信される最初のメッセージのコンテキスト サイズは比較的同じである必要があります。

たとえば、開発タスク #5 を実装する場合、大規模モデルの最初のメッセージのコンテキスト サイズは、開発タスク #50 を実装する場合の最初のメッセージとほぼ同じである必要があります。

したがって、各タスクごとに、会話を最初のメッセージまでさかのぼる必要があります。

基本的に、GPT Pilot はコードを作成するときに、記述するコード ブロックごとに疑似コードを生成し、作成する必要があるファイルとフォルダーごとに説明を作成します。

写真

再帰的対話

再帰的な会話は LLM との会話であり、GPT Pilot がエラーを検出した場合、それをデバッグする必要がありますが、デバッグ プロセス中に別のエラーが発生したと想定します。

GPT Pilot は最初の問題のデバッグを停止し、2 番目の問題を修正してから、再度開始して最初の問題を修正する必要があります。

開発者は、これが AI を大規模でスケーラブルなアプリケーションを構築するための効果的なツールにするために必要な重要な概念であると考えています。これは、コンテキストをバックトラックし、再帰内の各エラーを個別に解釈することによって機能します。

最も深いエラーが修正されると、再帰の上方に移動し、再帰全体が完了するまでエラーの修正を続けます。

TDD (テスト駆動開発)

GPT Pilot がコードベースを拡張、改善、要件の変更、新しい機能の追加を行うには、以前に記述したコードを壊すことなく新しいコードを作成できる必要があります。

これを行うには、TDD アプローチを使用するより良い方法はありません。

GPT Pilot が記述するすべてのコードに対して、コードが期待どおりに動作することを確認するテストを記述する必要があります。これにより、新しい変更が行われるたびに、すべての回帰テストを実行して障害がないか確認できます。

参考文献:

https://github.com/Pythagora-io/gpt-pilot