バックエンドに必要なのはGPTだけです

人々は、Github Copilotがプログラマーに取って代わると言っています。それは間違っていると思います。私たちはすべての強力なモデルを持っています、そして私たちはそれらをコードを書くことに制限したいですか?すべてのコードにはバグがあります!

コードは、ビジネス ロジックをエンコードする理想的な方法ではありません。コードはレビューする必要があり、それはあなたが望むものではなく、あなたがそれを言うことをします。ビジネスロジックの適切な形式は、人間の知性です。

だから私たちは、誰がPythonとec2sとbizロジックとpostgresを必要としているのかを考えました。

LLMを利用したバックエンド+データベース全体を構築しました。API 呼び出しの名前に基づいてビジネス ロジックを推論し、1 キロバイトの状態を保持できます。

これが未来の経験です:

1. バックエンドの目的についてLLMに指示します(つまり、「これはやることリストアプリです」)
2. データベース状態の最初の json BLOB を記述します (つまり、{todo_items: [{タイトル: "朝食を食べる"、完了: true}、{タイトル: "学校に行く"、完了: false}]}
3. API 呼び出しを開始してください。これで、独自のビジネス ロジックを推測し、永続的な状態を更新する無限のバックエンド エンドポイントができました。

なぜでしょうか

これが私たちが想像する未来です

1. バックエンドがどのように見える必要があるかを正確に知らなくても、フロントエンドを反復処理できます。
2. バックエンドはあなたに間違ったフォーマットを与えますか?

   https://backend-gpt.com/chess/get_board_state()

   ->

   https://backend-gpt.com/chess/get_board_state_as_fen()

3. API 名の入力を間違えましたか?かまいません！
4. コールドスタートなしのサーバーレス:サーバーと他の誰かの唯一の違いは、1KBの状態とLLM命令であり、これらはミリ秒単位で交換できます

それでもわかりませんか?

パーカーの言葉でそれがどのように機能するかは次のとおりです

基本的にはGPTを使用して、ToDoリストアプリのすべてのバックエンドロジックを処理しました。アプリの状態を json として表し、スキーマの定義に役立ついくつかの事前入力されたエントリを含めました。次に、プロンプト、現在の状態、およびユーザーが入力した命令/ API呼び出しを渡して、クライアントへの応答+新しい状態を抽出します。したがって、バックエンドルートを記述する代わりに、LLMは単純なアプリのすべての基本的なCRUDロジックを処理できるため、特定のルートを記述する代わりに、add_five_housework_todos()やdelete_last_two_todos()やsort_todos_alphabetically()などのコマンドを入力できます。コマンドが関数/擬似関数呼び出しとして表現されている場合、より適切に機能する傾向がありますが、最後のtodosを削除するなどの自然言語命令も機能します。