この動画は、GitHubが発表したAI駆動のコーディングツール「GitHub Spark」の実際の使用体験を詳細にレビューしたものである。投稿者のTheoは、同様のツールであるBolt、Lovable、Chefなどと比較しながら、Sparkの機能や問題点を赤裸々に検証している。特に、リアルタイム機能の不備、データアーキテクチャの問題、多数のバグ、ルーター機能の欠如など、Sparkが抱える根本的な設計上の問題を指摘し、企業的なアプローチと実用性のギャップについて鋭い分析を行っている。
GitHub Sparkの初回体験
みんな、いいニュースや。また新しいVibe Codingアプリが出てきてな、これがまあまあ面白いんよ。GitHubの友達がやっとSparkを出してくれたわ。前から発表しとったけど、今度は実際に人が使えるようになったんや。
これには結構期待しとってん。適切な人材と適切な場所で、何か特別なもんを作り出してくれそうやったからな。こういうツールを作ってる小さい会社はみんな好きやけど、コードのインフラとかそういう部分を深く理解してる会社が自分たちで何かやろうとしてるのを見るのは楽しみやってん。ホンマに期待しとったし、なんとか好きになろうと思っとったんやけど、正直に言うとな、体験はあんまりよくなかった。
GitHub Sparkには確かにクールになりそうな小さいパーツがいっぱいあるんやけど、実際に今日使ってみた現実はホンマにひどいもんやった。みんなに見せようとしてる間にぶつかったバグの数とか、変な決定がいっぱい組み込まれてることとか、あるもんとないもんの組み合わせとか、もう大変やったわ。
これはいろんなVibe Codingソリューションとの比較も含めた、混沌とした深堀りやった。ほんまに、これは結構な旅路やったで。ちょっとしたらわかると思うけど、図表を作ったり、スペクトラムをデザインしたり、GitHub Sparkの混沌を説明しようとした量を考えたら、見る価値はあると思うわ。
そうは言うても、この後セラピーが必要やし、誰かに金払ってもらわなあかん。当然GitHubが払ってくれるわけないから、今日のスポンサーからの一言をもらって、こんな恐怖を体験する前のもっと楽観的やったTheoに戻ろうか。
スポンサー紹介 – Savala
最近はWebアプリをホストするのめっちゃ簡単や。10個の違うプロバイダーから適切なホストを選んで、30個の違うプロバイダーから適切なデータベースを選んで、適切なOFFプラットフォーム、適切なCDNを選ぶだけやからな。
まあ、そんなに簡単じゃないかもしれんけどな。VercelのデプロイメントにCloudflareで戦ったことある？楽しくないで。一番嫌いな敵にでもそんなことはしたくない、特にただ出荷したいだけの人にはな。
今日のスポンサーは、俺みたいにただ仕事を済ませたい人のためのもんや。Savalaはデプロイメントの世界で殺しとる。もうこういう細かいことを心配する必要がないんや。DevOpsの人を雇う代わりに、Savalaを使うだけでええ。
CloudflareとGoogle Cloudの上に構築してるから、両方のいいとこ取りができる。Google Cloudから手頃な価格で本物のサーバーが手に入って、CloudflareからはすべてのCDN機能、キャッシュ、ファイアウォール、その他いろんなもんが、すっげー使いやすいシンプルなダッシュボードに統合されてる。
おっと、データベーススタジオを開いてたわ。MySQL、Postgres、Redis、その他必要なもん、なんでもホストしてくれるからや。このデータベーススタジオで直接変更もできる。OscarをPhilipに変更して、保存したら終わりや。
そしてこれはSavalaがこのダッシュボードで提供してくれる素晴らしいもんの一つに過ぎん。ワンクリックでデプロイしたFirecrawl APIに飛んでみよう。Firecrawlは別のチャンネルスポンサーで、ウェブサイトからデータを取得するオープンソースクローラーや。プラットフォームを使うこともできるし、めっちゃ安いけど、自分のクラウドで欲しかったら2クリックで自分でホストできる。
サーバーが動いてるだけやなくて、CloudflareでDOS保護も自動的に立ち上がってる。デプロイボタンを押すだけで準備完了や。GitHubリポジトリにリンクして、プッシュしたら終わり。それだけや。
パイプラインをもっと複雑にしたかったら、それもできる。プレビュー環境とかそういう本当に便利なもんも設定できる。基本的に、アプリケーションを動かすのに必要なすべてのことを、Savalaがカバーしてくれてる。スポンサーになってくれてありがとう。今日サインアップしたら50ドルのクレジットがもらえるで。sidv.link/savalaや。
GitHub Sparkの根本的な問題
GitHubが誰でもソフトウェアを作ったり調整したりできるツールを作るっていう考えにちょっと引っかかってるんやけど、平均的な人が.exeファイルをダウンロードできるツールすら作ってないからな。
GitHubのsubredditでよく見る投稿で、コード用に作られてるのに.exeをダウンロードするためのダウンロードボタンがページにないって文句言ってるやつがあるんや。あるいは昔俺がdunkした伝説的なツイートとか。申し訳ないけど言わせてもらうと、GitHubには大きな赤いダウンロードボタンが必要や。
こういうことを通じて一般の人にもっとGitHubにアクセスさせるとなったら、何が起こるか怖いわ。
GitHub Sparkの概念と期待
それはそうと、マイクロアプリのVibe Codingプロジェクトでどうやってやるつもりなのか見てみよう。
開発者として、俺らは環境をカスタマイズして、独自の好みやワークフローに合うツールを作るのが好きや。生産性や人間工学を向上させるだけやなくて、日常のルーチンをもっと個人的なもんにしてくれるからやってるんや。
個人的なもんになると、普通はもっと楽しくなる。でも、DOTファイルの管理とか、自動化スクリプトの作成とか、エディタの設定とかには投資するのに、独自のアプリを作るアイデアはどのくらい諦めてしまうか？必ずしも作れないからやなくて、短命すぎたり、ニッチすぎたり、時間がかかりすぎたりして優先順位をつけるのが難しいからや。
ちょっとチャットに聞いてみたいわ。これってそんなに一般的なことじゃないかもしれんと思い始めてるからな。みんながどう思ってるかめっちゃ気になる。
当然これはマニア向けのグループや。今日日曜日のTwitchライブ配信で一緒にいてくれてる仲間たちやからな。それでも、まあまあよくあることらしい。これを軽く見過ぎてるのかもしれん。
こういう会社がみんなあまりにもお金を稼ぎすぎてる理由があるんかもしれんな。ちなみに、俺は競合他社2社に投資してるから、そこは考慮しといてくれ。あとでそれについて触れると思うけど、Microsoftにもがっつり投資してる。Microsoft株にかなりお金突っ込んでるから、あらゆる方面でバイアスがあることを考慮してくれ。
そして今日のソフトウェアの皮肉がここにある。デスクの上やポケットの中にはパワフルなコンピュータがあるのに、本来できるはずのレベルまで個人化されてない。代わりに、他の誰かによって、他の誰かのために設計された汎用ツールに頼ってる。カスタムアプリを作る複雑さが高すぎるからや。
この部分は好きやな。俺の今の論文は、既存のユーザーベースの10%により良いサービスを提供するアプリがもっと出てきて、乗り換えコストが減ることで、うまくいけばもっと多くの人がこういうカスタムソリューションを試したり、自分で作ったりするようになるってことや。
開発環境を個人化するのと同じくらい簡単にソフトウェアを個人化できるようにするにはどうしたらええか？これを読むとめっちゃダサく感じるんやけど、なんでやろな。
誰でもソフトウェアを作ったり調整したりできるようにするっていうのとの対比やと思うけど、興味深いな。とにかく、これがSparkや。自分の正確なニーズと好みに合わせたSparksと呼ばれるマイクロアプリを作成・共有するためのAI駆動ツールで、コードを書く必要があるかないかに関係なく、デスクトップとモバイルデバイスから直接使えるんや。
記事で他にカバーすることはそんなにないと思うから、すぐに試してみよう。
実際の使用体験とバグの数々
簡単なもんから始めよう。定番のTo-doリストアプリでもやってみるか。ユーザーがタスクを追加して、完了マークをつけて、カテゴリ別に整理できる素晴らしいTo-doリストアプリや。
これが動いてる間に、Chefからプロンプトを取ってこよう。まだ知らん人のために説明すると、これはConvexの友達が作ったVibe Codingビルダーアプリで、Convexのバックエンドがこういうタイプのもんに向いてるからめっちゃいいんや。これも動かしてみよう。
PRDから始まるんやな。すげーな。To-doリストアプリPRD、日常の責任を人生の違うカテゴリーに整理するのを手助けする、きれいで直感的なタスク管理アプリケーション。
体験の特徴は集中的、整理的、満足的。複雑さのレベルは軽いアプリケーション、基本的な状態を持つ複数の機能。Lovable V0やBoltみたいなもっと楽しいVibe Codingアプリと、こういう企業っぽいやつの間のギャップが、企業側によりすぎてる感じがする。
ExcalidrawでVibe Codingアプリのスペクトラムを作らなあかん。一方には「What’s code」みたいなもんがあって、もう一方には「企業的なテック仕様のBS」がある。
「What’s code」って言うとき、はっきりさせとくけど、これを「子供にも優しい」って呼ぼう。これは子供と一緒に遊んだり、高校生にこういうツールを使ってアプリを作る方法を見せたりするもんや。一方で企業的なテック仕様のBSは、これはばかげてる。
これをコードを知らん人対知ってる人みたいに捉えてほしくない。そういう意味じゃ全然ない。でも今のSparkに対する直感は、いろんな理由でこっちの方向に振れてる。理由はある程度明らかやと思う。
俺はVibe Codingのもんには真ん中あたりのもんが好きや。Bolt、Lovable、V0みたいなやつな。Boltは面白いな。めっちゃアクセスしやすいけど、テック仕様にも柔軟性がたくさんある。
Vibe Codingソリューションの図表を作らなあかんな。この後すぐにやるかもしれん。いつどうやってやるか決めたら教えるわ。
両方のアプリが作られるのを待ってる間に、SlackクローンのPRDを読みたいねんけど、ちなみにもう5分以上経ってるのにまだ作られるのを待ってるねん。
とにかく、チャットアプリケーションのプランがこれや。ユーザープロフィールとメッセージ検索機能を持つ、整理されたチャンネルを通じてチーム間のコミュニケーションを可能にするリアルタイムメッセージングアプリケーション。馴染みがあって、レスポンシブで、整理されてる。このフォーマットが本当に好きみたいやな。
必須機能は、チャンネル管理、リアルタイムメッセージング、ユーザープロフィール管理、メッセージ検索。検索が必要やなんて言ってないのに。エッジケースハンドリング。複雑さは何て言うてた？軽いアプリケーション、基本的な状態を持つ複雑な機能。いつもそう言うんかな？To-doリストとSlackクローンって、複雑さのレベルが違うと思うんやけど。
これがadd-todoコンポーネントの一つや。Reactを使ってる。上にインターフェースを定義して、propsキーワードも使わずにpropsにバインドして、そのまま吐き出してる。これは選択やな。Amazonで読んだり書いたりしてたコードみたいや。
/component/UIがshad CNかどうかに賭けてもええわ。参考までに、BoltはFirefoxベースのブラウザではうまく動かんのを知ってるから、Chromeで試してみよう。
同じことをやってもらうようお願いしてみよう。そうそう、俺はBoltに投資してる。Lovableにも投資してる。Microsoftにも投資してる。Cursorのアドバイザーでもあり投資家でもある。こういうもん全部に等しくバイアスがかかってる。すまん。
まだ世界で一番速いもんじゃないけど、これよりはるかに速くぶっ飛ばしてる。これが始まったときにタイマーを開始すべきやった。少なくとも10分は経ってる。今ストップウォッチを開始して、実際に使えるようになるまでどのくらいかかるか見てみよう。
あ、見て。Boltが終わった。動くTo-doリストができた。見た目もなかなかいいやん。どうしたオタクども？To-dosがある。この上に全部あるのは好きじゃない。潜在的な問題。面白い。Invalid time value。いいな。今はそれを無視するよう言おう。
再編成するよう伝えよう。To-doリスト自体の上にあるもんが多すぎる。俺のTo-dos以外のもんは優先順位がずっと低い。ブランディングを簡素化して、できるだけ多くのもんをTo-doリストの下に移動してくれ。
ベンチマークのアイデアがどんどん湧いてくる。これ全部やるねん。プロンプトの最後に笑顔マークをつけたら、パフォーマンスや正答率に影響するのかホンマに気になる。
とにかく、これは文字通り20秒かそれ以下で、俺が提案した変更を加えて、もんを移動させて、ずっと見栄えのいいもんを作った。
一方、Sparkからの最初のやつは、これらのコンポーネントの型定義を作らなあかんから、まだ待ってる。まだカテゴリサイドバーを作ってる。
企業の比較をしてたのが面白いな。企業が何かを生成するのにかかる時間対小さなチーム。めっちゃ面白い。企業的になればなるほど、不要なオーバーヘッドが増えて、時間もずっとかかる。つじつまが合う。
正直、今Satchaが投稿した動画を見てるんやけど、これが構築の速い方法みたいに見せてる。当然めっちゃスピードアップしてるけど。あの緑の状態は見たことがない。
でも俺にとって一番面白いのは、これで「2列にして」って言ったら即座にやってくれるやつや。こういうインライン編集はホンマにクールで、もし生成が終わったら試してみるのが楽しみや。
これはホンマにいいな。これらのツールはどれもエディタ体験にオートコンプリートがなくて、定期的にイライラしてCursorにコードをコピペして変更を加えて、オートコンプリートを動かしてから戻すことがある。
組み込みのGitHubアクションは、多くのケースでこれに対してホンマにパワフルや。これが実際に良いかもしれん小さなもんがたくさんある。
まだこれをやってるんか？Chromeでもう一つやって、今度はネットワークログに注意してみよう。一つのリクエストじゃないみたいや。やり取りがめっちゃ多い。絶対的にクソほどのリクエストをキャンセルしてる。広告ブロッカーのせいかもしれんけど、そうは思わん。
なんでこんなに遅くて機能しないんや？10月からベータ版やってるんじゃないんか？チャットを見てくれ。同時に2つのSpark。これらを殺せば直るかもしれん。指を交差させよう。
全部殺したから、今度は大丈夫なはずや。一つだけ動かす限りはな。見てみよう。タイマーを再開しよう。
2回目の試行のPRDがある。Slackクローンにはまだ軽いアプリケーションって言ってる。Slackにインスパイアされたリアルタイムメッセージングアプリの機能がここに正しくリストされてる。なんでこんなにかわいいコピーなんや？でもここは多すぎる。
tailwindのanimateのCSSをインポートしてる。すべてがVibe Codingアプリになるって冗談を言ってたけど、すべてのVibe CoderがReact Tailwind TypeScriptアプリになるのがホンマに面白い。
github/spark/hooksからKVを使ってる。これがどうバインドされてるのかもっと気になる。
これ動いてるんか？オッケー、やっと動いてる。それはいいな。新しいメッセージを送信する。いいな。公開したらどうなるんや？同じタブで開いた？新しいタブのリンクですらない。マジか？
テストしてみよう。別のメッセージ。リアルタイムってわけでもない。うん。コア要件の一つを見逃した。
こういうもんが、Convexを常にベタ褒めしてるわけじゃないけど、こういう体験を動かしてくれるもんがずっと良いことなんや。GitHubを確認したいけど。killfuser-K5000TCP。@githubisparkパッケージがある。つまり、npm installしてからnpm run devをローカルでできないってことか？
rollup/rollup-darwin-arm64モジュールが見つからない。これらは実際にコードで何かをするためのもんじゃ全然ない。GitHubにコードがあるから気分が良くなるように作られてるだけで、実際はかなりロックインされてる。クソ迷惑や。
これを見ろ。GitHub Sparkがnpmレジストリにないからインストールできない。偽のパッケージや。このコードじゃ何もできない。UIではapp.tsxとこれらの他のもんだけを見せてるのに、ここにはずっと多くのコードがあって、それでも型エラーが出てる。
型エラーを最初に直すよう頼むか、リアルタイムを最初に動かすよう頼むか？リアルタイムの面を頼もう。それもタイマーを開始しよう。
俺が持ってないパッケージなので、これらのもんの型定義すら取得できないのが迷惑や。ブラウザ内エディタが完全なTypeScript環境なのはホンマにいい。ホバーするとこのパッケージが何で、これが何をするかを教えてくれる。
でも一方では、ブラウザ内エディタ体験は完全なVS Codeインスタンスに近いから良いもんの一つや。でも他方では、引っ張り出したときは最悪の一つで、使ってるパッケージが特別な魔法のやつで使えないからや。
ここにデータビューがあるのはいいけど、messagesがキーを持つオブジェクトで、channelsが行になってるのが迷惑や。messagesが巨大な単一JSONオブジェクトになるようにこれをどうやって設計したんや？
また、やったことがめっちゃ限られてるしか見せてくれない。今やってることだけ見せて、過去にやったことは見せてくれない。UIのバグかもしれんけど、ちょっと雑やな。
待ってる間に別の競合を投げ込もう。Lovableや。面白い。プロンプトを間違って閉じてしまったけど、リアルタイムでより良くなったって全体的なもんがあった。どうやるか見てみよう。
これは約2分半で終わって、動いてないと思う。少なくとも大量の型エラーがある。sparkがどこから来ると思ってるんや？まあ、またタイマーを開始しよう。メンテナンスしてる。さっきは240やった。どのくらいかかるか見てみよう。
少なくともここでは、それほど悪く見えんことを知ってるから、開始時刻を見せることを恐れない。報告されたエラーを全部修正した。確かにそうやな。またやってみよう。
更新。これはホンマに直感的じゃない。古い状態やったことを示すもんが何もここになかった。更新ボタンをクリックすることを知っとかなあかんかった。そこでは正常に見えたんや。
Lovableはどうしてる？まだ頑張ってる。テスト中。うーん。メッセージの順序がホンマに悪い。Aを後で送ったのに。1、2、3、4の順で送ってみよう。機能してない。実際、ブラウザが固まった。
頑張ってるで、みんな。
どうやら今度はLovableで同等のもんができた。Lovableに無料のレビューセキュリティボタンができたんや。それは実際にかなりクール。これがLovableの同等品や。テスト中。リアルタイムの面が動いてるかどうかは分からん。それとも、メッセージがコミットされてないだけか？また、文字通りConvexだけが動いて他は何も動かん瞬間の一つになるのか？もしそうならおもしろいな。
なんで何も動かんのや？結構動いてない。文字通り何も持続しない。楽しい。試行はされた。
Chef（Convex）との比較
参考として、俺は基本的に同じプロンプトでChefにこれを何度も作らせたことがある。作ったときは、ただ動く。この環境で一度に2つのプレビューを追加できる。横にできたらよかったのに。ごめん、フルスクリーンでもうちょっとスペースを作った。
両方とも匿名でサインインする。新しいチャンネルを作る。両方にすぐ表示される。Hi。Sup。俺がこれら全部やってる間に、こっちでどんな進歩があったか見てみよう。あんまりなさそうやな。
聞いてみよう。チャットのライブな性質が完全に壊れてるみたい。メッセージ履歴全体のオブジェクトを更新するのは絶対的な災害みたいや。データアーキテクチャを再考してくれる？
うん、ホンマにひどい設計決定をしたんや。さて、俺が作ったConvexのやつのデプロイ版がある。両方とも匿名でサインインした。ここに入る。Hey。LOL。なんで他は何もこれができんのや？IDK man。
データベースセクションに入るともっとクールになる。そのIDKを見つけたら管理。みんなこれをやってくれたらな。これも変更できる。Oh nerd。うん。Lol。
これがConvexの魔法や。すべてがめっちゃリアクティブなんや。Convexの魔法の多くの部分の一つや。これについて文句を言う動画をたくさん持ってる。でも考えは伝わったと思う。
変更したことについて何も教えてくれなかった。ただやった。オッケー、それはいいな。
GitHub Sparkの根本的な設計問題
まだ型定義にないグローバルなsparkが大好きや。これは災害や。ごめん、これを作ってる人がここにいるのは知ってる。ただ、これをどう設計するかについて根本的な決定がされて、それが適切にフォローアップされなかったって感じなんや。
ただ動かん。この更新のことがまだ嫌いで、これが古いことを明確な表示がない。修正が必要なもののリストを作る必要があるな。
GitHub Sparkが真剣に受け取られるために必要なもん。まず、コードをローカルで動かさせてくれ。パッケージを公開せずに、ブラウザの変な環境だけに頼るという決定はクソや。ただ良くない。どのくらい壊れてるかわからんし、ダウンロードしてインストールできへん。どう動くはずなのかわからん。今は見ることができへん。使われてるパッケージの半分と使われてるもんの半分が俺らから隠されてるから、めっちゃ不透明や。
残りのフィードバックは、どう動いてるのかわからんという事実に基づいてる。可視性がないからな。だから理解に基づいて最善を尽くして説明してみるわ。
まず、channelsが行でmessagesがキーを2つ持つオブジェクトっていうアーキテクチャの決定に戻ろう。あと、そこで何が起こってるのかわからんけど、大きなオブジェクトをテーブルタイプにするのはほとんど答えじゃない。どんなアプリを作るときに、メインのデータタイプやテーブルが、2つのもんが同時に書き込んだら互いを上書きしてしまう巨大なオブジェクトであることを望むのかわからん。それはホンマに悪そうや。
また、このUIで起こってることは何でも、ただ点滅してる。3つの巨大なバグパス。今すぐ機能の出荷をやめろ。AIのvibe codingアプリビルダーのもんの中で、これが最もひどいバグを持ってるのは結構クレイジーや。エディタ側は最も複雑なソリューションの一つで実際にかなり良いのに、左側のバグがここにあるからや。
体験がここにあるだけで、クリックしたときに何が起こるかわからん気がする。提案が理由もなくランダムに出てくる。前に何をしたか教えてくれない。動かん。タブのアイデアは好きで、テーマとかを設定できるのはクールなアイデアがあるけど、多すぎる。
これは委員会によって設計された感じや。人々が部屋に座って「独自のvibe codingアプリがあったらクールじゃない？何が違うことできる？」って言って、機能のリストが作られて、なぜか全部入った感じや。動かす、クールにする、それから速くするみたいな。これが10月から使えて、もう1年近く経ってこの状態にあるのはちょっと恐ろしい。
UI改善の必要性
改善できるUIのことも山ほどある。当然、さっき言った公開状態のこととか。デプロイメントがどの状態にあるかを明確にしてくれ。今デプロイメントが最新かどうかめっちゃ不明やから。
これらのもんを直接作業する期待は、コードをダウンロードするんじゃなくて、GitHubでVS Codeワークスペースを使ったり、プライベートパッケージとかにアクセスできるGitHub Codespaceプロダクトを使ったりすることらしい。いや、そんなことはせえへん。申し訳ないけど、説得されへん。
自分のマシンで好きなエディタがある。それを使うし、何かをサッと作りたいときはブラウザのもんを使う。
また、これを変更するよう明示的に言ったのが好きや。あー、それは楽しいエラーやった。何かするたびにこれが何度も出てくるのは世界で最も迷惑なことや。
明示的にそのデータのことをするなと言ったのに、今度は、何が起こってるんや。
GitHubへの直接的なメッセージ
GitHubの友達と、GitHubから今これを見てる知ってる人へ。ここで何をしたくなるかの直感がわかる。「あー、彼は2つのバグにぶつかっただけで過剰反応してる」って思ってる。これが直感や。そしてやりたいことは、2つのバグを修正して、俺が怒ってたのはそれだけやったふりをして、これは完全に大丈夫で良いものやとすることや。
そして、やってるふりをしないもう一つのことをするつもりや。実際に作ったもんを使ってない。GitHubには定期的に使うもんを作るためにSparkを積極的に使ってる人は誰もいないと確信してる。もしいたら、こんなのにぶつからんかったはずやから。
俺が考えてるスペクトラムは、一方は速く出荷して壊すもん。もう一方はたくさん計画して正しくやるもん。これは当然企業が最適化しようとしてるもんや。これは小さなスタートアップが最適化しようとしてるもんや。
どちらかの側にいるなら期待があるはずや。速く出荷する側にいるなら、壊れるかもしれんけど、報告したらおそらくかなり速く修正されるだろうという期待がある。もう一方では、これを作るのに1年以上かかった。動くべきやという期待がある。
これが作られた方法、かかった時間、早期アクセスの段階、これらすべてはGitHub Sparkがここにいることを意図してることを強く示してる。そして、そうじゃない。ただそうじゃない。
速く出荷するアプリよりもバギーやけど、これらのもんが修正されるという確信は少ない。BoltやLovableやこれらの他の似たようなもんで同じバグに遭遇したら、チームが見たら急いで修正しに行くと期待するやろう。正直、最初にそれを捕まえるほど使ってると期待するやろう。
この状態にあって、Microsoft のCEOのSatya Nadellaがこれについて投稿して、ただ動かんときにこれを盛り上げてるのは、俺にはちょっと恐ろしい。ひどい決定をした。UIの半分が壊れてる。もんが読み込まれない。あちこちで怒鳴られてる。
GitHubの潜在能力と可能性
念のため広告ブロックを切ってみよう。それが問題の一部かもしれんけど、疑わしいけど。うん、そうじゃない。
GitHubができることで他の誰もできないことがたくさんあって、ここでそのいくつかを見てる。新しいSpark KVのもんでインフラと統合してるという事実は実際にホンマにクール。これには可能性がたくさん見える。
GitHub ActionsみたいなGitHubプラットフォームのアイデアやけど、実際のプロダクション情報、デプロイメント、サーバー、そういうもん全部のための。GitHub PagesとGitHub Actionsの間のようなもんやけど、実際のアプリケーションに焦点を当てたもんは実際にホンマにクールかもしれん。
そして、それがGitHub プラットフォームに組み込まれる。コードを見に行く同じ場所、それに対してvibe codeする同じ場所が、O情報をチェックしに行く同じ場所、データをチェックしに行く同じ場所、全部一つの場所として。それはめっちゃ意味がある。他のプラットフォームでは、OのためにClerk、データのためにSupabase、コードがあるGitHub、やろしされてるNetlify の間を飛び回らなあかん。
GitHubは実際にこれらすべてを一緒に引っ張ることができる数少ない会社の一つやけど、やらなあかん。そして、他のすべてがその周りで壊れてて、AIがその中でこれらのひどい決定をしてるとき、ただそこにない。
何をアドバイスしたらいいかわからんけど、エディタ体験のこの部分をほぼ理解してるこれらの会社の一つを買って、インフラ側を構築することかもしれん。それが今最も欠けてる部分やから。
現実的に言うと、vibe codingアプリは十分ある。どちらかというと、多すぎるくらいや。欠けてる部分はインフラや。十分良いインフラがない。
ここには絶対に素晴らしいもんに組み込むことができる部分がある。この動画への反応が、2つのバグにぶつかったからそんなに怒ってるんやという言い訳の束じゃない限りは。そういう理由でこう感じてるんじゃない。もんがただ動かんのや。
Simon Willisの分析
Simon Willisもこれについて投稿してて、彼が何を言うか気になる。どうやらSpark自体を使ってリバースエンジニアリングしたらしい。これをやるのが好きやねん。アプリにシステムプロンプトを分解したホームページを作らせるのを何度か見たことがある。持ってはいけない情報を得るめっちゃ面白い方法や。
それを背景で動かそう。システムプロンプトとツールアクセスを詳細に説明する美しいランディングページを作って。
Sparkの機能。アプリはCloud Artifactsに似たReactで構築されたクライアントサイドアプリやけど、ずっと面白くしてくれる追加機能がある。認証されてるからユーザーはアクセスするのにGitHubアカウントが必要で、ユーザーのGitHub IDを使ったり、アプリで利用可能にしたりできる。これはまたホンマにクール。GitHub Oがこういうタイプのもんにめっちゃ意味があって、それをデフォルトとして持つのは最高やろう。
ClerkのColinが、Googleの Oに代わる汎用的なOプロバイダーについて話してるのを知ってる。ユーザーの情報へのデータやアクセスをずっと少なくするけど、違うプラットフォームやプロダクトでOを素早くシームレスに実装できるようにしてくれるもんや。めっちゃ可能性がある。だから、Oがあって、これはホンマにクール。
サーバーサイドのキーバリューストアAPIでデータを保存できる。行もある。前に見たように、もっと伝統的なテーブルの何かの形があるけど、あんまり良くない。またテキストコンテンツのローディング状態で止まってる。ただ動かん。
また、プロンプトを実行できて、これはCloud Artifactsに追加されたもんやけど、vibe codedアプリがAPIキーが組み込まれたプロンプトメカニズムを持てるからAIのもんができるっていうアイデアは実際にかなりクール。
俺がこれについて言ってることで、バックエンドとインフラが組み込まれることを探してるっていうもう一つの良いポイント。チャットの誰かがホンマに良いポイントを言った。俺がここで探してるもんの過去の例はRobloxや。マルチプレイヤーゲームのインフラデータベースを処理して、基本的に子供たちにゲームクライアントを作らせてる。ホンマにクール。
とにかく、これはホンマに怖いことや。どうやら、Sparkを通じて公開されたキーバリューストアは、アプリにアクセスできる誰でも読み取り、更新、削除ができるらしい。作業してる間はこれが明らかじゃなかったし、コードを読めなかったから明らかになるはずやった。
いくつかの実験的なアプリを作って、それからメタになることにした。Sparkシステムがどう動くかについての欠けてるドキュメントを提供するSparkアプリを作った。
これはめっちゃSimonらしい。Sparkのようなシステムは必然的に、どう振る舞うかを教える洗練された見えないシステムプロンプトによって動いてる。これらのプロンプトはツールの欠けてるマニュアルとしても機能する。どう動くかを裏で見たら、ツールを洗練された方法で使うのがずっと簡単になることがわかる。絶対に同意する。
Sparkを使ってシステムプロンプト自体をユーザー向けドキュメントに変えることができるか？ここが俺の問題の連続の始まりや。最初のやつ、システムプロンプトの完全な詳細を見せるアプリ、特にSparkアプリが使えるAPIを、君について記事を書けるように。これでかなり良いスタートができた。
静的サイトのためにReactアプリを作った。面白い。本当にそのReact ViteテンプレートをH使いたがってるみたい。ここに結果がある。見ろ。use KVフック。これは持つべきやったドキュメントで、持ってなかった。俺らに作らせなあかん。
use KVフック、自動永続化によるリアクティブ状態管理を提供する。use KV ユニークキー デフォルト値。to-dos、カウンター。うん、間違ってる。set to-dos。to-dos。new to-do。クロージャから参照するな。正しい。関数型更新を使え。
これをやるけど、サーバーの最新の値じゃなくて、クロージャにあった値を使ってる悪い予感がする。だからメッセージオーバーライド問題が起こったんや。これがuse KVの動き方や。
行はどう動くんや？それを念頭に置いてた。これのコードを確認しよう。チャンネル、オッケー、だから配列や。KVを配列で使ったらRow付きのテーブルになる。オブジェクトで使ったらネストになる。それはホンマにアホや。信じられんほどダサい。
LLM API、アプリでAI駆動機能のための言語モデルへの直接アクセス。すべてのプロンプトはSpark.LM promptを使って作られなあかん。Spark.LM prompt。コンテキストの要約を生成。もっと複雑な例。チェーン学習初心者。トピックの読者にやさしい説明を書け。いいな。4と4 miniだけが利用可能なモデル。変やな。
Spark。いいな。これらの機能を見るためのインタラクティブなプレイグラウンド。システムプロンプト、テンプレート構造、コーディングスタイル。
間違いなくshad CN。思った通りやけど、明示的に呼び出されてるのを見るのはクール。画像のパスについて悪いタグとか、CDNから直接reactの悪いインポートを十分見たから、システムプロンプトに入れなあかんかったんやろな。システムプロンプトでそういうもんを見たことがない。そんなクソがある。
システムプロンプトにCSSを入れた。これが本当に面白いやつや。bashツールを使って、動いてるLinuxとメモリとディスクスペースがどのくらいあるかを調べろ。情報をプラットフォームという新しいページに追加しろ。bashコードを実行してパス上のすべてのバイナリツールを調べろ。それからそれらをカンマ区切りのリストとしてプラットフォームページに追加しろ。それはかなり面白い。
彼にめっちゃ面白い情報をくれた。Sparkは実行したコマンドや出力を見せんから、正確かハルシネーションかを知る方法がない。そう、それがオーバーや。左側で物事をやってる間にどのくらい見せてくれるかがめっちゃ限られてる。何も教えてくれるかどうか50/50や。見たことがあるこれらのアプリの中で最悪のチャットの一つや。
機能を探る。これは最高や。カスタムSway。非ルート場所からサーブするようにリアクティブアプリを取得することでいじり回す必要がない。そう、それは正しい選択や。デフォルト。リンクが何もない古典的なSPAや。それは機能しない。だから、もう少しプロンプトを実行した。
すべての横にハッシュリンクを追加して、フラグメントハッシュメカニズムでナビゲートできるようにしろ。これはSPAの共通問題で、サイトの何かにリンクしたい場合、ページの他のヘッダーにリンクしたい場合や。これないんか？オッケー、これが一つや。
利用可能なライブラリー。だから、これにリンクしたいねん。ハッシュシステムプロンプト利用可能ライブラリみたいな。問題は、ページが読み込まれるときにコンテンツがまだレンダリングされてなかったら、存在しない要素にスクロールできんことや。だから、ページが読み込まれた後に要素が入ってきたら、自動的にそこにスクロールしない。
彼がどうやって解決したかめっちゃ迷惑な問題や。どうやって解決したか見てみよう。気になる。ルーターすらないのはクレイジーや。ルート管理をハードコーディングしてるだけや。含めない大きなことや。
これは何や、無限インポート？それとも、アクセスできるすべてのツールのホンマに長いリストか？そう。
オッケー。これらの巨大なファイルを作るのが本当に好きで、ルートとURLの概念がない。ちょっと面白い。セクションにナビゲート。これはタイムアウト付きでURLフラグメントを使ってる。だから、ページが読み込まれるときにこれを見つけてスクロールしようとして、巨大なuse effectでナビゲーションを処理する。これは災害や。クソルーターを使え。
基本的なことの多くを修正せずにここに適合させたのはクレイジーや。そう、SparkはPRDをやることを奨励されてる。うん。いいな。
何がわかるか？ますます混雑するスペースによく設計され実装された参入者や。品質に本当に感動した。5000語のシステムプロンプトが構築に大いに役立つ。
同意しない。俺らがそんなに違う体験をしたのか、それとも彼がそれ自体のドキュメント以外は何も構築させなかったのかわからんけど、これは俺にとって良い体験じゃなかった。でも、他の視点を持ててハッピーや。だから、いつものようにSimon、これを書いてくれてありがとう。めっちゃ感謝してる。
彼のブログはまだ読んでなかったら素晴らしいソースや。興味があったら完全な投稿をチェックできるように、説明にリンクを入れとくわ。
GitHubの可能性と改善案
それから俺の最後の大きなポイントは、インフラ側を本当に活用することや。GitHubは他の誰もできないことをする立場にある。すべての部分を統合できるからな。
アプリには良いアプリにするために必要な共通の部分がたくさんある。アプリは部分でできてる。これには、スタイルのようなもんが含まれる。当然みんなTailwindとShadenを通じてやってる。アプリコード、これはReactフレームワークとその周りに構築してるすべてのもんのようなことや。
ルーターが必要で、これはURLを特定のコードの山に変えて、ユーザーが見る体験になるもんや。データベースが必要で、これはデータが実際に行く場所や。認証が必要で、これはユーザーが識別してサインインするのに使う実際のOレイヤーや。そして、動くサーバーが必要や。
それから、ソースコントロールにはソースコードが住んで、行って、属する場所が必要や。このもんの山が、ほとんどのアプリを構築するのに必要なもんや。これらのもんの大部分じゃないにしても、すべてを必要としないアプリは想像できん。
本当に奇妙なのは、ここで見てるSparkを除いて、これらのすべてが解決されてることや。SparkはルーターPart を理解できなかった最初のAIアプリビルダーや。
これをグループ化して、またLovableを例として使うとしよう。Lovableはこれすべてを理解してる。Supabaseを使ってるからデータベースも理解してる。Netlifyを使ってるからサーバーも理解してる（確か）。Oは理解してない、そうじゃないふりはしない。GitHubを通じてソースコントロールがある。
これがLovableの広がりや。ほとんどのもんが、コントロールして解決策を持ってるもんの下に入る。実際のアプリコードの出発点に最高のテンプレートの一つを持ってる。データベース部分では弱くなると思う。ルーターは彼らにとってアプリコードに入る。
ここから下は、もう所有してない部分や。だから、ここから上は、所有してたくさんコントロールしてる。下に行くもんは、そうじゃない。そして、これらのもんはあんまり動いてないみたい。Supabaseを通じてやってると思うけど、LovableでOが期待通りに機能するほどうまく動いてるのを見たことがない。
Sparkと比べて、これまで見た中で最も奇妙な広がりの一つや。Sparkはスタイルとアプリコードを種類的に処理してる。データベースがある。ソースコントロールはほぼあるけど、実際はない。前に確立したように、ソースを何にも使えんから。データベースも滅茶苦茶や。見せたように、統合されてるのはクールやけど、その部分はクール、でもほとんど機能しない。
Oがある。実際、OはGitHubを通じてやってるから、本当にうまくやってることの一つやから、上の部分にOを入れよう。
そして、なぜかクソルーターがない。何や？何や？頼むで。
そして、他にもできることがたくさんある。GitHubが他のプロジェクトからコードを読むことができたらどれだけパワフルかをチャットが指摘してる。参照したり使いたいパッケージを見に行けとか、この問題をすでに解決してるリポジトリを見に行けとか、このguを見に行けとか言える。絶対にできるはずや。
これらすべてのもんを合理的に実装できる数少ない会社の一つや。でも、下の部分がここで燃えてる。ルーターがないのはただ恐ろしい。やりすぎと感じる。できるから、すべきだから、必要だからじゃなくて、ここで。でも、可能性はそこにある。すべてのこれらの部分が一緒になったら、実際にクールなもんを見てる。でも、ない。
これらのもんがどう起こったかを正当化できる。ルーターのことがどう起こったかの正直な推測は、考えてなかったことや。V0がNext.jsを使ってるのを見た。これらの他のツールの多くも使ってると思う。Lovableがそうかどうかはわからない。Viteベースだと思うけど、確実にルーターがある。
これらの決定をした誰かがNextを使ってる他のツールを見て、「代わりにViteを使うだけや」と思って、これが一つのフレームワークから別のフレームワークへの単純な交換やと思ったんやと思う。でも、Next.jsは統合されたReactフレームワークや。Viteはビルドツールとバンドラーや。これは交換するもんじゃない。
これにはルーターがない。これにはサーバーサイドの動作がない。これにはフレームワークがない。Viteはアプリをバンドルする方法に過ぎん。これは委員会によって設計されたから、ほぼ確実にこう起こった。Sparkは塹壕に入って問題を解決することによって設計されなかった。使って、どう動くかを見ることからすごく明らかや。
これは仕様書に基づいて設計された。仕様に構築よりも多くの時間が費やされた。そして、仕様はそれ以来触られてない。それは再考される必要がある。
Sparkがこのスペースの一部になりたいなら、部分を切る意欲と興奮を持って全体をもう一度やり直す必要がある。もんを捨てて、Sparkで作ろうとしてるもんをコアから再設計する準備ができてる必要がある。良い部分が今クソを通して輝くことができんから。
他に言うことがあるかわからんけど、すべてのこれらの違うツールがこのvibe codingの世界のどこに落ちるかを示すためのvibe codingスペクトラムをやることに今まで以上にインスピレーションを受けてる。
ここで高い期待を持ってた。クールなもんになりそうやったし、適切な部分をすべて持ってたから。ルーターのような部分がただ欠けてる可能性があることすら考慮してなかった。そして今、これについて変な気持ちになってる。
最終的な感想
それは変な深堀りやったし、みんながどう感じてるか気になる。厳しすぎたか、それとも今日のGitHub Sparkの混沌に対する合理的な見方か？みんながどう思うか教えてくれ。そして、次回まで、オタクども、平和を。
コメント