Roko's Dancing Basilisk

ボストンダイアリーズ ボストンに住んでおらず、ボストンが好きでもないのに、ウェブログ/ジャーナルに「ボストンダイアリーズ」と名付けたショーン・コナーの続く物語。 火曜日、2025年12月02日 Roko's dancing basilisk 義務的なサイドバーリンク 「K&Rスタイルのブレースを使うなと3回言っただろう！時代に追いつけ、Copilot！」 Roko's basiliskを避ける、パートII 「指摘してくれてありがとう。それは私の側の悪いアドバイスでした。」 DeepWikiというサイトについて言及されているのを見かけた。このサイトは、任意のGithubリポジトリの「ドキュメント」を生成してくれるという。 LLMがコードを生成するのには感銘を受けていないが、ドキュメントはどうだろうか？まだ試していない。Roko's basiliskがどれだけうまく踊るか見てみよう！ 当初、mod_blogから始めた。26年間このコードベースを扱ってきたので、「ドキュメント」の不正確さを見つけるのは簡単なはずだ。さらに良いことに、へつらうチャットボットとのやり取りはなく、リポジトリのURLを貼り付け、完了したら通知用のメールアドレスを提供するだけで、「あとはお任せ」という具合だ！ さて、メールが届いた。確認してみると、すぐに驚かされた！Nearly 30 pages of documentation、そして概要は印象的だった。tumblers、ストレージレイアウト、新しいエントリを追加する際の典型的なフローを捉えていた。cmd_cgi_get_today()が、ある月の特定の日付の全エントリを年ごとに返すという事実さえも把握していた。 しかし、一つだけ少しばかりおかしな点があった。それは「システムは3つの主要なレイヤーで構成されている」と述べていたが、続く図では5つのレイヤーが示されており、どの3つが「主要なレイヤー」なのかを示すものもなかった。 レイヤーが特定されたこと自体には問題はなかった。 Entry Layer Processing Layer Rendering Layer Storage Layer Configuration ただ、3を数えるのに問題があるように思えた。 内容のレビューに入る前に、ウェブサイトのインターフェースとしての私の意見を簡単に述べておこう。それは「まあまあ」だ。左側のメニューは、スクロールバーが古臭く見えることを考えると、見た目よりも長い（本当に！「ウェブデザイナー」に、昔ながらの3ボタンマウスと、色覚異常をシミュレートするように調整されたモニターを使わせたい。誰もがスクロールホイール付きのマウスやApple Trackpadを持っているわけではないのだ）。また、図は非常に一貫性がなく、選択したときでさえ、適切に表示するには小さすぎることが多い。そして、時折巨大な図が現れる。レイアウトは恣意的で、水平、垂直、L字型など様々だ。そして、過度に繰り返される。ページをまたいで、ユーザーの過剰なナビゲーションを節約するためだと理解できるかもしれないが、1ページ内でも繰り返されているのを見つけた。 それらの問題を除けば、ほとんど機能的だ。JavaScriptが無効でも表示可能だが、図は欠落し、コントラストは低い。 気に入った点は、各セクションの最後にソースへの参照リンクがあることだ。それは良いタッチだ。 さて、それはさておき、「ドキュメント」そのものだ。ほとんど正確だ。いくつか小さな不満がある。 コマンドラインでの実行例では、$BLOG_CONFIGが設定されている場合、–config openは不要だ。 $BLOG_CONFIGはmain.cではなくblog.cでチェックされる。 mod_blogはRSS 2.0ではなくRSS 0.91を出力する。 「システムは完全にCで書かれており、コアエンジン自体にはPerl、Python、その他のスクリプト依存関係はありません。」本当だろうか？Luaは使用しているが、設定ファイルにのみ使用している。 SUIDがどのように使用されているかを見落としている（rootで実行するためではなく、ブログのオーナーとして）。 posthookスクリプトが失敗を返しても、エントリが追加されなかったという意味ではなく、返されるHTTPステータスコードが変わるだけだ。 この「ドキュメント」をレビューしている際に、2つの問題のあるコードを見つけた。一つは実際のコードのバグ（ファイルロックの図はコードとしては正確だが、キャッシングの問題を浮き彫りにした）、もう一つは定義済みの定数ではなくリテラル定数を使用してしまった箇所だ。 これらの2つの問題を見つけられただけでも嬉しい。まだ実際に悪用可能なバグではない（mod_blogを使っているのは私だけだと思うからだ）。 全体的に見て、生成に10分もかからなかったかもしれないものとしては悪くない（確信はない。メールを待っている間に他のことをしていた）。しかし、リポジトリ一つでは傾向とは言えない。 そこで、次にa09、私の6809アセンブラで同じことをすることにした。サイズは似ている（mod_blogは7,400行、a09は9,500行、同じくらいの規模）が、ロジックは少し複雑で、26年間の継続的な改良は行われていない。 その結果、より深刻な問題が多数見つかった。 エラーは分類されない。エラーは必要に応じて、順次作成される。エラーコードを固定範囲にまとめる試みはしていない。 デッドコード検出の重要な要素を見落としている。これは、次の命令にラベルがない場合にのみトリガーされる。 エラーが発生した場合、リストファイルは保持されない。 生成された出力ファイルの削除も間違っている。パス1または2でエラーが検出された場合にのみ削除され、テストが失敗した場合には削除されない。 同じページで優先順位テーブルを繰り返している。 「Unsupported markdown: blockquote」や「Unsupported markdown: list」のような単項演算子はない。 なんてこった！このバックエンドマトリックステーブルがいかに悪いか言えない。すべてが間違っている。サポートされている/サポートされていないマーカーを逆にしているのではなく、単に結果を捏造したようだ！そして、別のページにある同じ情報も悪い。最初のものほど悪くはないが、それは気管支炎が肺炎ほど悪くないと言うようなものだ。どちらも悪い。 そして、両方のテーブルで異なるフォーマットを使用している。一貫性が勝つ！まったく。 様々なフォーマットで命令を書き込む例は、RS-DOSバージョンでは間違っている。タイプと長さはそれぞれ2バイトであるべきで、1バイトではない。 -tの出力フォーマットは間違っている。TRONディレクティブが使用されていない限り、コードの実行トレースを表示しない。 .ASSERTディレクティブのすべての例は間違っている。適切なレジスタ参照を使用しておらず、メモリ参照には@（8ビット）または@@（16ビット）プレフィックスが必要だ。 .TRONディレクティブを使用できる場所は間違っている。どこでも使用できる。.OPT TEST TRONだけが.TESTディレクティブ内でしか使用できない。 これは、私の考えでは、mod_blogよりもはるかに悪い仕事だ。おそらく、a09の方がmod_blogよりも巡回的複雑度が高く、コードの横断的な性質のためだろう。そしてそれは、LLMがコンテキストウィンドウに達するか、それを超えるまで実行され、その結果、混乱を引き起こすのだろう。 これは、ドキュメントがほとんど、あるいは全くないレガシーコードに使用されることを意図しているのではないかと恐れている。そして、中程度に複雑だが小さいコードベースでこれほどひどい結果を出すのであれば、より大きく、古く、そして厄介なコードベースで何をするのか想像したくない。 試してみたいが、90年代初頭に書かれた155,000行のCコードのコードベースを持っており、それは非常に厄介だ。しかし、コードベースにそれほど詳しくないので、明白なエラーのすべて、ましてやより微妙な問題をすべて見つけられると確信できない。 もう一つの問題は、リポジトリの更新だ。このサイトはウィキとして販売されているので、おそらくもう一つの側面は、生成された「ドキュメント」を時間をかけて見直し、エラーを修正し、コードが変更されたときに最新の状態に保つことだ。変更されたリポジトリでこれを再実行できるのか、そして更新は既存のドキュメントにマージされるのか、それとも完全に置き換えられてドキュメントの修正を再度行う必要があるのか、私には明らかではない。 この生成された「ドキュメント」は、コード内の悪いコメントよりもさらに悪くなるだろうと推測している。 mod_blogは何年にもわたって劇的に変化してきた。ストレージフォーマット自体は変わっていないが、内部での動作方法は変わった。長年にわたり、少なくとも3〜4回のメジャーリビジョンがあった。そのメジャーさとは？一つは、約18年前にカスタムI/OレイヤーをCのFILE *-スタイルのI/Oに置き換えるための、ほぼ完全な書き直しだった。もう一つは、約3年前にすべてのグローバル変数を削除したことだ。そして過去1年間、機能を取り除いてきた。