従来の「アプリ」は過渡形かもしれない。では、AIが主要なインターフェースになると何が置き換えるのか?(更新)

Reddit r/artificial / 2026/4/25

📰 ニュースDeveloper Stack & InfrastructureTools & Practical UsageModels & Research

要点

  • 著者は、AIが主要なUIになることで従来のアプリが「解ける(dissolve)」可能性をめぐる議論を続けつつ、次に何が来るのかを説明しています。
  • そのフォローアップとして、あらゆるLLMで使えるオープンなデータレイヤーを目指すオープンソース・プロジェクト「FlashQuery(FlashQuery/flashquery)」をGitHubで公開しました。
  • 日常的な利用はすでに著者の環境で動作しており、堅牢性を最重視してユニット/統合/E2Eに加え、シナリオ系のエンドツーエンドテストまで自動化・自前構築されています。
  • 著者は、アンドレイ・カーパシー氏の「LLM-Wiki」アプローチとターゲットユースケースが近く、ロードマップ上の多くの機能がその構想を支えるため、そちらへ開発方針を寄せていると述べています。
  • フィードバックや質問、実際に試してみたうえでの貢献を歓迎し、まずはドキュメント整備を最優先に進めるとしています。

数週間前に、AIが主要なUIになることでアプリが「溶ける」とはどういうことなのか、という仮説を投稿しました。その中で、私はあらゆるLLM向けのオープンソースなデータレイヤーを作っていると触れたのですが、コメントとDMの両方でとても良いフィードバックをもらいました(original post)。

その議論のフォローアップとして、GitHubで公開されたことをお知らせできて嬉しいです!

https://github.com/FlashQuery/flashquery

これは日々の実務で私自身が使えていて、まさに私が狙っていたユースケースです。つまり、私のような人たちです。以前から製品とテストをまたぐエンジニアリングキャリア(その昔には半導体での機能検証も含む)を積んできたので、頑丈に作ることには本当にこだわっています。「テストされていなければ、それは動かない」。だからユニット、統合、e2eに加えて、実際に本当にエンドツーエンドまで行く「シナリオ」テストのセットも増えています……すべて自動化されていて、最初から作り込んでいます。少なくとも私にとっては、ちょっとクールです。あと、全部パスしています :)

もちろん、私の最初の投稿と今の間に、Andrej KarpathyがLLM-Wikiのアプローチを説明していて、正直なところ、このプロジェクトはそれほど遠くないです。FlashQueryにとって、すばらしい目標となるユースケースです。調べてみると、ロードマップに入れていた多くの機能が、実際に彼の構想を支えるものになることが分かったので、そこへ向かって進めています。

ぜひフィードバック、質問、そして可能なら自分で試してみてください。もしそうする気になったなら、貢献(コントリビュート)も歓迎です。できるだけ早く返信するようにします。ドキュメントはまず最初のベストな取り組みで、さらに続く予定なので、どうか親切にお願いします。

submitted by /u/jetstros
[link] [comments]