私も非喫煙者なので知らなかったのですが、少し前に近所にできた無人カフェに使い捨て電子タバコの自販機があるのを見て知りました。下の Hacker News のコメントも、半分はあきれるような資源の無駄遣いについての内容ですね。はは。

 

2000年代末に車載ナビゲーションソフトウェア企業で働きながら経路探索モジュールを開発していた思い出(?)がよみがえりますね。
Dijkstraはナビゲーションの経路探索には遅すぎて使わず、ヒューリスティックを改良したバージョンであるA* (A Star) 探索を使います。調べてみると、A*はSSSPではなくSPSP (Single-Pair Shortest Path) アルゴリズムなんですね。

 

これを実際に作ってみた立場から言うと、個別化のためには多ければ2ギガバイト以上の情報量が必要です。

 

markitdown はフォーマット間の変換には便利ですが、PDF では絶対に使ってはいけませんね…。

すでに文書抽出では Gemini のようなマルチモーダル LLM を使う方法がたくさん出ており、ベンチマークでもかなり良い結果が出ています。ただし、問題はコストです。

docling のようなものも良いです。

 

機能やアプローチは Atlas と同じように見えますね: https://atlasgo.io/

 

3つの主要な落とし穴にはとても共感します。ゲートキーパーが1人いるだけでも、よくない現象がいくつも起きるんですよね。

 

低レベル……というには……フォームを実装するなら htmlinput タグだけ使えば済むことなのに、state だの JSX だの非制御/制御コンポーネントだの、あまりに無駄に知っておくべきことが多く、たくさんのコードを生成しなければならないし、そういうことが本文の動機になったのではないかと思いますね

 

私はたばこを吸わないので何の話かと思ったのですが、使い捨てであるにもかかわらず、あまりにも多くの資源が使われているということなのですね

 

karma -47の貫禄ww

 

別の方法が新たに1つ増えたからといって、既存の方法が死んだと言っているように聞こえます。
本当に既存の方法は使えなくなり、新しい方法を使わなければならないのでしょうか?

 

コンセプトにはとても共感したので、新規プロジェクトで週末に少し試してみたのですが、思ったほどうまくはいきませんでした。まだ多くの改善が必要そうです。ひとまず大まかな動作はこれまで何度も紹介されているとおり、次のような流れです: 仕様原則の作成 → スペック作成 → タスク作成 → 実装

問題は、

  • constitution.md ファイルは「どう開発するか」に関する中核ガイドですが、「このアプリが最終的に何になるのか」は含まれていません
  • spec.md は1つの機能を説明する文書です
  • 「このアプリは何か」についてのマスター文書はありません
  • GitHubで行われている議論を読んでみると、chain of specs が最終的に source of truth になる、ということのようです。首をかしげたくはなりますが、だいたいの意図は理解できました
  • /specify/tasaks コマンドを通じて多くの文書を成果物として生成するのですが(望んでいた結果です)、そのせいかコンテキストをすぐ消費します(Claude Codeを使用中)
  • いったん実装に入ると、Spec Kitからはしばらく離れて、普段どおりClaude Codeとの対話を通じて実装を仕上げることになります
  • コンテキストを使い切って compaction したり、新しくセッションを開始したりすると、Spec Kitが生成した文書の存在を忘れてしまいます
  • tasks.md に定義された作業を進めていると、先にちゃんと作っていたものを上書きしてしまうこともありますし、バグ修正の過程で新しい機能を作ることもあって、tasks.md からだんだん離れていきます。tasks.md を永続保存する意味がよく分かりません

ひとまず私が出した結論は次のとおりです

  • 最初に考えていたものと違う結果が出ても、ひとまずスペックを最後まで仕上げて、新しいスペックを作りながら少しずつ直していくべきだ
  • 最初のスペックはどうしても大きくなるので、アプリの機能についてはあえて説明せず、ボイラープレートだけ作るほうがよさそうだ
  • PoCレベルで作るときは、Spec Kitは使わないほうがよさそうだ
 

とても共感します。どれだけうまくできていても、干渉されるのは不快です。存在感を出さずにいて、必要だと思ったときに現れて助けてくれるのが理想ですが、その状況判断がどれだけ適切かが鍵になりそうです。人間でも上手な人とそうでない人がいますが、人工知能がこれを克服できるようになれば、革命が起きる気がします。

 

Vulkan について正確に言うと、「Pi 5 の iGPU がサポートする Vulkan API は、llama.cpp ではまだサポートされていない」が正しいですね。これがサポートされていたら、どれくらいの性能が出たのか気になりますね。

 

docling もいいですね

 
joyfui 2025-09-21 | 親コメント | トピック: 超音波シェフナイフ (seattleultrasonics.com)

わあ!超音波カッター!

 

markitdown は PDF パースのために https://github.com/pdfminer/pdfminer.six を使っていて、テキストや埋め込み画像はファイルからそのまま抽出します。OCR だなんて、くらくらしますね……

 
kuber 2025-09-21 | 親コメント | トピック: Grok 4 Fast (x.ai)

gpt-oss より高くて遅いようですが、なぜこんなに多くの人が使っているのか気になります..

 

韓国語のプロンプトが必要な方へ、こちらに韓国語訳されたプロンプトがあります。クリックするだけで、そのままChatGPTとClaudeに入力できます。

https://gongbuhow.com/posts/chatgpt-students-100-use-cases/

 

5秒の広告を1〜2本流す程度なら共生する気持ちで最後まで見ていましたが、終わりのない連続広告や動画の途中途中に広告を入れるというやりすぎに出たので、すぐにAdBlockを入れました。ははっ