Archive of posts from 2026-3
たしかに原作のほうが面白いけど、それぞれが原作でイメージしてたことが共通化された感じで、大変良かったのではないでしょうか。
ザンドラ・ヒュラーのカラオケのシーンは直前に決まったとimdbに書いてあった。これは「ありがとう、トニ・エルドマン」のオマージュらしい。
追記
町山さんがキリスト教徒の関係を論じている。
- ルール1. プログラムの実行時間がどこに集中するかを事前に予測することはできません。ボトルネックは予想外の場所に発生するため、速度改善のためのハックを施す前に、まず実際にボトルネックが発生している箇所を特定することが重要です。
- ルール2. 計測しましょう。速度のチューニングは、コードの特定部分が他の部分を大幅に遅延させていることが確認できてから実施してください。それまでは一切、行わないでください。
- ルール3. 複雑なアルゴリズムは入力サイズnが小さい場合には非効率ですが、nが小さいケースがほとんどです。複雑なアルゴリズムには無視できない定数項が存在します。nが大きくなることが確実でない限り、複雑なアルゴリズムを採用するのは避けましょう。（たとえnが大きくなる場合でも、まずルール2を適用してください）
- ルール4. 複雑なアルゴリズムは単純なものよりもバグが発生しやすく、実装も困難です。単純なアルゴリズムとデータ構造を優先的に使用してください。
- ルール5. データが最重要です。適切なデータ構造を選択し、適切に設計できていれば、アルゴリズムは自然と明らかになるものです。プログラミングにおいて重要なのはアルゴリズムではなく、データ構造なのです。
ルール1と2は、トニー・ホーアの有名な格言 「早期の最適化はすべての悪の根源である」を言い換えたものです。
ケン・トンプソンはパイクのルール3と4を「判断に迷ったときは、力任せの方法を採用せよ」と言い換えています。
ルール3と4は、設計哲学「KISS（Keep It Simple, Stupid）」の具体例です。
ルール5は、以前フレッド・ブルックスが『人月の神話』で述べたものです。このルールはしばしば「賢いオブジェクトを使用する単純なコードを書け」という簡潔な表現で語られます。
https://www.cs.unc.edu/~stotts/COMP590-059-f24/robsrules.html
いろいろ詰め込みすぎ。でも、そういう雑多なことこそ描きたかったのだろうな。「人生で大切なのはこれ（例：卓球）だけ！」みたいにはなかなか言い切れない。あれもこれも大事。
にしても、この作品のシャラメはかなりいいな！
ウィリソン氏が提唱するエージェンティック・エンジニアリングは、非エンジニアがLLMを使って「なんとなく（Vibe）」アプリを作り上げる「バイブ・コーディング」の対極に位置する。これは、プロのエンジニアがコーディング・エージェントを使いこなし、自身の専門性を何倍にも増幅させ、より速く、かつてないほど堅牢なシステムを構築するための手法である。
エージェンティック・エンジニアリングを導入する上で、私たちが受け入れなければならないのは「コードを書くコストが劇的に下がった」という事実である。熟練したエンジニアでも1日で書けるコード量には限界があった。したがって、私たちは「この機能を作る価値はあるか？」「設計に時間をかけすぎていないか？」と、常にコストと時間のトレードオフを考えなければならなかった。
しかし、エージェントを使えば、初期のプロトタイプは数秒で、ほぼゼロコストで生成できる。とはいえ、「動くコード」を作るコストは下がったが、「良いコード」（バグがなく、テストされ、安全で、保守性が高いコード）を届けるコストは、依然として高いままである。エージェントという「超高速なタイピスト」を手に入れた人間の役割は「タイピング」から「品質の保証と意思決定」へシフトした。
このような状況において、どのようなパターンが有効なのか。ウィリソン氏は、いくつかの重要なプラクティスを提示している。
解決策を「貯蔵（Hoarding）」し、再結合する
エンジニアの資産はコードではない。「何が技術的に可能か」を知っていることである。ウィリソン氏は、過去に解決したトリッキーな問題や、小さな実証コード（PoC）を膨大にストックしている。エージェントへの最高の指示は、「このOCRの実装例と、このPDFを表示するコードを組み合わせて、新しいツールを作れ」というものである。ゼロから考えさせるよりも、「信頼できるコード」をインプットとして与えることで、エージェントは驚くほど正確に、かつ自分のスタイルに合った成果物を出してくれる。
レッド/グリーンTDDの徹底
エージェントは時に「嘘」をつく。これを防ぐ唯一の方法は、テスト駆動開発（TDD）の規律をAIに適用することである。「まず失敗するテストを書け、それからそれをパスする最小のコードを書け（レッド/グリーン）」と指示することで、エージェントの暴走を防ぎ、不要なコードの混入を最小限に抑えることができる。
まずテストを実行しろ
新しいセッションを始めるとき、必ず「First run the tests（まずテストを実行しろ）」と指示するといい。エージェントにプロジェクトの構造を理解させ、テスト環境を認識させ、そして「テストを壊してはならない」という意識を植え付けることができる。
認知的負債を支払う：インタラクティブな解説
AIが書いたコードをブラックボックスにしてしまうと、「技術的負債」ならぬ「認知的負債」を生み出してしまう。ウィリソン氏は、エージェント自身にコードの挙動を詳細に解説するドキュメントを書かせたり、アルゴリズムの動きを視覚化するアニメーション（たとえば、単語が渦巻状に配置されるワードクラウドの生成過程など）を作らせたりすることで、この負債を解消している。
人間が提供すべき「価値」
エージェンティック・エンジニアリングにおける最大のアンチパターンは「未確認のコードを他人に投げつけること」である。エージェントが数千行のコードを生成したとしても、それを一行ずつレビューし、動作を確認し、自信を持って「これは正しい」と言える状態にする責任は、常に人間にある。
私たちはタイピングから解放された分、「より良い設計とは何か」「このコードは本当にユーザーを幸せにするか」という、本質的な問いに向き合う時間を手に入れたのである。
- 生意気な感じ（笑）の教授がぞんぶんに楽しめる
- 「音楽図鑑」のレコーディングの様子らしい
- ずっと「M.A.Y. IN THE BACKYARD」のループが続いていて眠くなってくる笑
- コンピューターにペンで波形を描くとその音が鳴る！？えー何そのコンピューター（下図）
- 検索したところ「フェアライトCMI」らしい
- 80年代の東京が描かれていて、当時を知る人は懐かしいんだろうな（新宿、渋谷、原宿）
- YMOのライブ映像と矢野顕子さんとのピアノ連弾（東風）。素晴らしいなあ。
- 「戦場のメリークリスマス」のたけしさんやデヴィッド・ボウイのシーンも流れる
- ラストのピアノによる「SELF PORTRAIT」が本当に本当に素晴らしい
