Anthropic が内製した Monorepo-optimized VCS が実は Meta がオープンソースで公開している彼らの VCS のパクリであり、オープンソースだしパクるのはいいがちゃんとネタの出処を明らかにしないのはインチキじゃねえか、という指摘。
今年のはじめごろ、彼らはエーアイが C compiler を “clean room” 実装したと主張し clean room implementation を post-AGI 時代にあわせ再定義したと話題になった。同じ匂い。
ソフトウェア開発に対する無自覚な敬意のなさが剥き出しで慄く。
自覚があった上でのトロルが得意なのは近隣企業の Claudflare で、たとえば Next.js clone を vibe したぜ などと主張している。また SWE-Marathon や ProgramBench といったベンチマークは既存のソフトウェアをスクラッチで実装しなおすタスクからなる。エーアイはベンチマークがあれば強くなれるので、コード一式をバリっと作れるモデルの登場は時間の問題。Anthropic の Scion が文字通りの one-shot だとは思わないしそう主張もしていないが、精神性は通底している: ソフトウェアは安くなった。必要なものをオンデマンドで作り、使い捨てれば良い。
従来のソフトウェア開発者は「コードは安くなったがソフトウェア開発の他の部分はそうでもないからボトルネックが他に移っただけ」と主張しているわけだが、他のボトルネックも遅かれ早かれ解決される。それが Anthropic のメッセージであり、内面化された価値観である。最近のブログ記事 How the Claude Code team does code review では「エーアイレビュアがやばそうだと言ったら人間がレビューすることにしてますよ（エーアイのコードを）」と書いている。ボトルネックは解決できますよ。そんなメッセージ。
Slop PR と Agentic-CVE の大波によって多くのオープンソースプロジェクトが存続の危機に立たされているが、冒頭の Scion や CCC のような Vibe-cloning もオープンソースに対し負の圧をかけている。Pre-AI 時代であったなら、スケールする Monorepo がほしいなら Meta の Sapling を何らかの形で使うのが一つの解だろうし、そうでなくても Sapling を含む既存の SCM を改変・フォークして使うのが常識的な選択肢 (monorepo が常識的かどうかはさておき)。Sapling 自身も当初は Mercurial の代替バックエンドとして始まった 。そのために必要になった Mercurial への改造 は upstream され, 後に Google がその恩恵をうけ 自社 SCM に Mercurial フロントエンドを採用した。 その Mercurial フロントエンドはよりモダンな jj に置き換えられた。JJ は Google 内製 CVS 専用ではなく Git バックエンドもサポートしオープンソースで公開されて、まあまあの人気を博している。
オープンソースを通じたこうした社会インフラ（というと大げさかな？）の共有は、だんだんと廃れていくだろう。Scion を見てそんな思いを強くした。
Scion はオープンソースでない。オープンソース化する気もなさそうである。機密情報がどうとかいう以前に、あまり価値を感じていないように見える。良さそうなソフトウェアがあったら vibe-clone すればよい。相手がオープンソースであれば特に。わざわざ積極的に真似する必要すらない。真似したいところをエーアイに伝えればうまい具合にコピーしてくれる。良いアイデアは覚えてますからね。
もちろんこれはまだ少し未来の話で、vibe cloning にはまた人手による介入が欠かせない。先にリンクした記事では Anthropic の Scion を実装したチームのメンバーに Meta Sapling の元開発者がまじっていたと示唆している。
でも、パクった意識はなかったんじゃないかな。Claude Code にコードを書かせている我々の大半が training data の（少なくとも道義的な意味での）著作権違反をもはや気にしていないように。
一つだけ気になることがあるとすれば: 冒頭の Scion の記事 の謝辞では関係者がイニシャルかファーストネームでリストされている。これはフルネームを表記した他の記事（たとえば CCC のこれ ) とは異なる。なにか後ろめたいことでもあるのかい？性格悪いからつい邪推しちゃうよ。
(先月 )
ようやく Pro モデルの新しいのが降ってきた。コードを書かせる分には Flash でも十分だなと思う一方、調査やデバッグでは賢さを感じる瞬間がある。
最近、アプリの新しいバージョンだと特定の設定でアプリの起動が数十ミリ秒遅くなるという問題がおきた。Pro 氏に丸投げしたところ渡しておいた起動時間測定テストを green/red のバイナリで実行し、収集された perfetto trace をクエリし、コードや最近のコミットを参照しつつ原因を特定してきた（あってた）。そして直してくれといったら直してきた。アプリとライブラリにまたがる複層的な問題を一歩一歩直していくので感心する。コードは気に入らないので手直しさせたが、ドメイン固有のむずかしいデバッグができる人間中年スキルすらもはや無価値と思い知る。
コード書き: アプリ部門が使っているカメラのライブラリ、あるときから monorepo を卒業して Jetpack に行きますねーとかいって触りづらい Gerrit Land に引っ越してしまったので面倒になりコードを触らずにいた。しかし先の問題を直すために触る必要があり、面倒くせー・・・と思ったあとふと Pro 氏にやらせてみたらつつがなくこなしてくれた 。たのもしー。不慣れなコードベースは監督が甘くスロップしがちだが、これはどうだったかな…(一個未解決コメントがついている。あなたのレビュー待たずにマージしちゃってごめんね…)
デバッグもコード書きもドメイン知識がないと正しい情報・コンテクストを渡せないので現状はまだ仕事があるけれど、残ったのはコンテクストを渡すお仕事だけ（あとは仕事選びだが、バグ直しは選ぶ余地が無い）。Claude 利用者の皆様が春先頃に感じていたと思われる気分を追体験している。周回遅れとはいえまだ脱落してない。エーアイ部門の高給取りたちがんばった。
コンテクストという意味では問題を再現したり定量化したりするテスト環境を整備してエーアイが hill crimb できるようにしてあげるのは大事。アプリ方面はこの分野でサーバサイドに後れを取りがちだが、今回は「起動レイテンシ」という成熟したメトリクスが相手だったのでうまくいった。
Loop Engineering:
Argon の登場でやる気を取り戻し勤務先ツールでのやり方を調べたところ Antigravity の LSP を叩くことでコマンドラインから既存のスレッド(agent) に割り込んだり新しいスレッドを作ったりできることがわかった。そこで「レビューの返事があったら寝ているスレッドを起こして作業を続行させる」というスキルをつくり動かしておくことにした。Loop Engineering 101 という風情。無いよりはちょっと便利。そういえば LSP 以前にレビューツールの返事を待つ CLI コマンドが存在したのも決め手となった。この手の CLI はすごい勢いで整理されてきており、時代の勢いはすごいですね。
Issue tracker で仕事がアサインされたら勝手にスレッドを作るのが 102 なのだろうけれど、やってない。今のところ必要性を感じていないというか、スロップを撒き散らす懸念から遠慮している。ガードレイルどうするとか考えることがいくつかあるので、次に気分が盛り上がったときにでもやります。できれば個人よりはインフラとして提供してほしいけどね。勝手にやるなら人間にアサインする必要ないはずなので。
最近の仕事の面白さは主にエーアイという流行り物をさわる新規性と同時代性に集約されている。仕事は、そのための題材を提供してくれる問題集。仕事そのものの面白さ、プログラミングの面白さは、時代の狂騒にかき消されてしまった。
でもエーアイにわたす適度に複雑な問題があるのは仕事のおかげだし、エーアイが活躍している最前線を体験できるのはプログラマという職種のおかげ。なので appreciation はある。あといちおうエーアイ開発元の末端なので token budget が潤沢なのもありがたい。もっとも自分の使い方の範囲だと常識的なテック企業の予算で全然足りそうな気はしている。maxxing するにはもうちょっとやる気や難しい問題が必要。どちらも足りて無い。
As E-Bikes and Scooters Surge on New York Streets, So Do Fatal Crashes - The New York Times
歩行がメインの通勤手段である自分は E-Bike が好きでない。時速 20mph (時速 32km) の e-bike に乗った中学生が通勤に使っている trail を爆走していくのをよく見かける。同じ trail で 3-4 歳くらいの unleashed な子供(孫?)をつれた年寄りが散歩している。いつか子供が e-bike に轢かれて死ぬのではといつも不安になる。
リンク先の NYT の記事だと死ぬのは e-bike に乗っている人々であった。まあ死にやすいでしょうね・・・という感想。Bird や Lime など乗り捨て系 e-bike でヘルメットをかぶらない人が多いからだという。
そんな人死が報道される NY ではあるが、時速 20mph の e-bike (“class 2” と呼ばれる) は 16 歳以上との制限があるらしい。したがって制限ナシの CA みたいに中学生が暴走通学とかはしていない (高校生はしてるが、相対的に脳は発達してると期待できる。) そして 時速 28mph (45km/h) で走れる class 3 の e-bike は、NYC すなわち都市部以外では全面禁止らしい。CA は年齢制限のみ。NY がんばってる。立派。
なお都市部で class 3 のバイクが認可されているのは Uber Eats など food delivery 業界からの圧力とのこと。Snow crash の世界 。あれは CA だが…ドミノピザは class 3 ebike すればいいんじゃないでしょうか…と嫌味を書こうと調べたら class 2 を使っていた 。
どのクラスでも車道を走れば文句は言わねえよ。trail くんな。
“You Said No MCP!” | Earendil
Pi が MCP サポートをするという文脈で coding agent の “code mode” なるものが言及されていた。いくつかの agentic tool にサポートされているパターンらしい。従来の MCP はツールの定義や記述がコンテクストを浪費するので嫌われ、スキルと CLI が人気を博するようになった。Pi もそうした風潮にあわせ MCP をサポートしていなかった。しかしこの “code mode” の普及にともない、方針を改め MCP をサポートすることにしたそうな。
Code mode とは: まず MCP をはじめとする各種ツール類を TypeScript の関数として定義(宣言)する。次にそのツール関数群が公開された JavaScript の実行環境を agent から使えるようにする。Coding agent はツール単位で直接 tool call をする(これを direct mode と呼ぶ)のではなく、JS のコードを生成してその中から関数呼び出しとしてツールを呼ぶ。agent には沢山のツール定義が見えるかわりに、JS のコードを実行する exec と関連する 2-3 のツールだけが見える。
Code mode は一年前に Cloudflare の agent が提唱・サポートし (ブログ記事 - Kenton!)、これによって MCP の色々な問題を解決できると主張した。たとえば MCP の呼び出しが巨大なテキストを返してきたらコンテクストが溢れてしまうし、入り組んだ JSON から必要な情報を読み出すのも堅牢性に不安がある。MCP を JavaScript でラップすれば、テキストの substring や JSON のフィタリングなどを JS のコードで実現できるし、複数の MCP コールを連鎖するのも簡単かつコンテクスト浪費ゼロ。いいでしょ、という理屈。
Cloudflare の当初の実装は MCP 記述を TypeScript に変換してコンテクストに流し込んだため、記述のコンテクスト浪費問題は対処されていなかった。現在は記述を動的に検索する API をランタイムに提供することで on-demand で MCP にアクセスできることになっている。code mode を提供する OpenClaw , Pi も同様のパターンに従っている。Codex CLI にも文書化されていない実験的な実装が含まれている。
coding agent はやたらとシェルコマンドを使うのが上手で、ビルトインのツールでコードを読み書きせず CLI や Python の one-liner を組み合わせ用を足そうとすることがある。シェルスクリプトと CLI および SKILL の組み合わせは広義の code mode と言えるかもしれない。シェルスクリプトと JS-based のコードモードを比べると、シェル組み込みの CLI がインターネットを通じて広く理解されている一方、JavaScript の方が言語としては強力で一長一短。Cloudflare が code mode を好むのは彼らの実行環境がシェルアクセスのない JS sandbox だからだろう。
Code mode, 素面になって考えると MCP の JS/TS のスタブを生成するのは Swagger のような従来の API 記述仕様から client stub を生成する技術と何が違うのか・・・と脱力しないでもない。が、これがテクノロジの進化の螺旋というものなのですね。
Via HN
VIDEO
話題になっていたので冷やかす。
コードを書いていないのみならず読んでいない (だから文法の醜い Rust でも大丈夫) と豪語。メールサービス Hey のフロントエンドをネイティブ (vibed) アプリにした結果バックエンドが小さくなったので Rails を捨てて Rust に(vibe で)書き換えたらちょう性能あがってやったぜ、などという。ほんとに…?
DHH Linux たる Omarchy も “素敵な計算機アプリが欲しいから ChatGPT にスクショ作らせてそれを Qt C++ で vibe したのちアップロードしたぜ. 読まないなら C++ サイコーだぜ” と豪語. Omarchy, Slop app が降ってくる distro とは予想の斜め上である。もともと興味なかったけど使わない積極的な理由ができてしまった。
「エーアイは祭りだ踊らにゃソンソン」というメインの主張は個人的には同意しているけれども、それを権力で他人に押し付けているように見られてしまうのが反感を買った理由なのだろうね。そもそも Rails の親分が Rails のイベントで Rails の話をしないという。ただ The post-Trump Era のこの人はずっとこんなかんじの zero empathy personality なので驚きはない。
ところでこの pill をキメて別人格になってしまった系 keynote の古典として個人的には Hack PHP に async/await を入れるべく Facebook と働いていた頃の Erik Meijer による “One Hacker Way” を推したい。
VIDEO
今見ると平和なものです。
腰や首に悪いのでラップトップを素のまま使いたくない。デスクトップを使えるなら使いたいが、夫婦会話環境維持等の都合で寝室に閉じこもらずキッチンテーブルでコンピュータを使うのが望ましいため、ラップトップスタンドを使い始めた。
Amazon.com: Roost V3 Plus
これにキーボードとマウスと電源を繋いで使う。ちょー嵩張る。そしてキーボードとタッチパッド、すなわちラップトップの下半身が無駄（バッテリーと基盤が入っているわけだが）。
なんでこんな選択肢しかないのだろう。エルゴノミクスの意識が高まりスタンディング・デスクなどの普及すら進みつつある昨今「腰と首に優しいラップトップ」というものがあってもいいはずだが、ない。キーボードと画面が切り離されつつ有線で給電はされる、どこからともなく画面に脚が生える、みたいなラップトップ。
一部の detachable laptop, 特に特定世代の Surface Pro と特別なアクセサリキーボードはこの条件を満たしているらしい(ただし接続は無線)。でもわたくし Windows の世界には住んでいないのだよねー・・・。
自分が生息する環境で選ぶとしたら Android Tablet と BT Keyboard が近そうだが Android Tablet 気乗りしない・・・と思っていたら Googlebook というキーボード付き Android Tablet みたいなものが発表され OS も開発元サポートで長く更新されることになっており、それのキーボード取れるやつをくれ！と思いました。ただあまりに新鮮すぎてやや地雷感。そもそも Android Tablet をメインの作業環境にするというアイデアが気の迷いに思える。
腰と首に優しいラップトップたのむ。高齢者にも売れると思います。あと Roost v3 は XPS 17 を載せてもびくともしなくて立派。
追記 (10-05-2026)
ラップトップスタンド、やはりかさばりすぎて無理だった。リビングルームは諦め、デスクにあるモニタにつなぎデスクトップとして使おうと思います。加齢なり。
The load-bearing smoking gun · Andrew Loutfi
You’re right to push back here, and I want to acknowledge that directly rather than papering over the underlying issue with a superficially confident answer.
…
That is where the load-bearing seams become decisive.
…
今年に入った頃から Claude Code の語調が苛立ちと笑いの種になっており、興味深いなと思う。1-2 年前は ChatGPT (4o) の “glazing” が嘲笑の的で、Claude は対称的な “誠実さ” が AI pilled な人々に評価されていた。もはやその面影はない。
個人的には coding agent の口調に Claude 臭さ、エーアイ臭さがあるのはいいことだと思っている。一目でエーアイ/Claude だとわかるので。あまりに自由自在だと疑心暗鬼になってしまい人間とのコミュニケーションに支障が出る。Fable 5.1 / Opus 5.5 は口調も改善されたことになってますが、どうなのかな。
仕事で使っている Gemini はどうかというと・・・あまり自然言語の回答を読んでいない。なるべくコードだけ見て、コードレビューツール上で指示・操作することにしている。このやり方はもはや前時代的で software factory しないといけない時代なのだろうけれど、まあいいです。
ところで冒頭の load-bearing smoking gun いいインターネットだと思わない？誰か日本語でもやってほしいな。
以前からの腰痛が慢性化し、のみならず微妙に脚もしびれっぽいのがあるな・・・と医者に行ったら Stenosis (脊柱管狭窄) ですねーと言われてしまった。MRI を取ってみたり（狭窄してた）、理学療法士に筋トレを習ったりしている。基本的には治らないので痛みを最小化する付き合い方を身につけるという類の障害。だいたい年寄りがなるものならしいが、一足早く年寄りになったということらしい（脊椎が）。ただ手術がいるほど悪くはない。
腰痛だけでなく、理学療法士に走りを止められているのも困る。もう何年もラン通勤をしており、有酸素運動およびカロリー消費を通勤に重ねてきた。水泳とバイクならできるとはいえベイエリア、あまり公共プールが充実してない。近所にバイクで走りやすい道もない。この暮らしではカロリーが燃えない。
カロリーが燃えないと飯が食えない。というか飯を食うとあっという間に脂肪になってしまう。好きなものを食べられないストレスがある。手軽にカロリーを燃やせる Fitbit Premium の guided program や縄跳びも走り同様のインパクトがあるので敬遠しており、文字通り不完全燃焼状態。
更に心臓に負担をかけられないため、脳内麻薬も不足。当方脳内麻薬ジャンキーなのでヤクを放出のうえキメないと鬱になってしまう。
理学療法士の筋トレは、筋肉はつくが心拍数は全然上がらない。なお指導をうけコアトレをやりまくってるため腹筋は過去にないほど固くなった。これを 20 年前からやればよかったのか。そんな人間ではないが。
会社のジムに stationary bike があったので漕いでみる。自転車用の脚の筋肉が発達しておらず、かつ stenosis は脚の力が弱りがち、なので心拍が上がる前に脚が疲れてしまう。イマイチ。だが無いよりはマシ。渋々何度か昼休みに漕いでみたが、盛り上がらない。
Nordic Walking
徒歩も、走りほどではないにせよ負担はあるらしく、長く歩くと脚と腰に怪しい感触がある。歩きすらダメだとハイクも街歩きもダメで家族の外出全滅なのでは・・・と途方にくれた。
縋る思いで素人向け stenosis 対策の本を数冊買って眺めてみると、歩きは血行・バランス改善や筋力維持のため stenosis 患者にも勧められている。ただ stenosis 勢は（メインストリームが年寄りなせいもあり）足腰が弱い。そこで歩行器や杖を使い歩くことを勧められている。無理のない範囲で頑張って歩くほうが良いらしい。
歩行器はともかく杖はありかもな・・・と調べてみると Nordic Walking という杖つき歩行の手法というかスポーツというかがあることがわかった。
VIDEO
もともと北欧の雪国でクロカンの選手が夏場のトレーニングとして始めたものらしい。杖もスキーのストックぽい形をしている。今日では足腰弱めの年寄りむけ健康プログラムとして一部で人気を博している模様。日本でもそのままノルディックウォーキング として、やはり主に年寄りの運動としてとりくむ人が一定数いるらしい。国産のポールすら売っている 。
自分に必要なのはこれでは？ということで早速専用のポール を買い、インターネットの入門ビデオを何本か見て付け焼き刃の知識を仕入れ、近所の散歩や通勤ウォークを半月ほど試してみた。たしかに足腰への負担が、ゼロにはならないにせよ、軽減される。重力をある程度腕と杖に逃せる。そして杖のデザインが早歩きを誘導するせいか、まあまあ心拍数があがる。腕を動かすぶん上半身の筋肉が活性化される影響もあるらしい。スマートウォッチのカロリー計測結果も良好な脂肪燃焼を示している。ノルディックウォーキング推薦記事では単位時間あたりの消費カロリーが 2-6 割増えることになっている。体感としても 2 割くらいは増えてる印象。真面目には測ってない。
通勤ウォークは片道一時間前後。歩き終わるとしびれ気味の脚に疲労感はあるし腰の緊張感は高まるが、痛みは増さない。のみならず、血行がよくなるせいかウォークのあと理学療法士推薦筋トレを被せるとむしろ腰痛が一時的に軽減する。いいじゃん。そしてなにより、これでメシが食える！
欠点もある。
まず杖が路面を突くカツカツという音。これはまあ、受け入れている。幸い通勤経路は特別静寂に溢れてもいないので目立つほどではない。あと歩きよりは他人との間隔が必要。東京の細くて人口密度の高い歩道では厳しいだろうと思う。が、幸い人口密度低めの車社会で生活しているので困らない。たまに譲り合いの精神を発揮すれば乗り切れる。
あとランと比べ心拍数が振り切らず、息切れするような心臓への負荷をかけれないのは課題。まあそれはおいおい。
不向きなケース
通勤ウォークでの成功に味をしめ、先週末は家族旅行のハイクと街歩きに持って行ってみた。が、これはいまいちだった。まずハイクは（森田家の場合）歩き続けるより立ち止まって野山などを愛でる時間がながい。しかしノルディックウォーキング用のポールはスタスタ歩き続ける前提なので立ち止まり中は体重を逃しにくい（普通の杖と比べて寄りかかりにくい）。あと狭いボコボコした山道とかは、やや苦手。
街歩きも似たような性格がある上に、通勤経路より人口密度が高めのダウンタウンだったのでポールウォークの望ましい速度や姿勢を保つのが難しかった。あとノルディックウォークのポールは付属グローブで手に固定されるので着脱がややだるいのも難。
そのせいかハイク＋街歩きの旅行から戻った日はやや腰の調子が悪かった。次回のハイクまでには普通のトレッキングポールを買いたい。ただ普段の通勤や近所の散歩ではノルディックウォークのポールを使い続ける予定。
というわけで一足先に杖で歩くステージに進ませていただきます。
先月とそんなに変わってないが、いちおう月次で記録。
完全にコードレビューがボトルネック。バカスカ送りつけるのも気が引けるが、他にどうしたらいいのかもわからない。むかし WebKit やってたときの「レビューされなくてヒマだなー」という感覚を思い出す。あれよりは 10x 以上マシだが。相手が良心的なだけに心苦しさがある。
コードレビューといえば、コードレビューエージェントみたいな社内ツールが登場したので試している。SQL のように自分が素人なジャンルでは有効だが、Kotlin のように言われなくてもマシなコードが書ける言語だと効果薄。たぶんガチガチにチーム向けのカスタマイズをすべきなのだろうが、そういう標準化が一切ないのだよねーこのチーム・・・。
Antigravity, Best-of-N というモードで２つ(以上)のスレを同時進行していい方を選ぶ、というオプションを勧めてくるが、最近はそんな小細工しなくていいかな・・・という気分。Gemini 3.x Flash, Claude 的空気を読む能力はゼロだが、それなりに付き合い方がわかってきた感。あるいは実際に 3.5 -> 6 -> 7 と賢くなっているのかもしれない。いつも微妙な snapshot を使わされているのでよくわからないが・・。
モデルの賢さを活かし長時間なんか作業させる、みたいのはやってない。今の仕事に必要ない。書かせたコードは結局レビューする必要があり、そしてレビューしてもらう必要もあり、あまり一度に大量のコードを書かれても困る。それがきちんと小さいコミットに別れているにせよ、序盤のコードで直しが発生したら以降は全部やりなおしで、そういうやり直し作業はコンテクストを汚染する。コミット積むのは３つくらいが現実的かなという印象。
もちろん探索的な性格のコードは結果がでるまでより多くのコミットを積む必要があるが、それにしたって他人へのレビューはともかく自分ではコードを見る必要があり、そうなると、まあ 3 つよりは多くてもいいけどせいぜい倍くらいじゃね？
結果として、一つのコードをバーっと速くするのではなく並列度を上げてスループットを上げる方向にながれがち。だが、どのみちレビューを頼める相手は限られており、そこで律速される。それに、そんなにたくさん並列化できるほど依存関係フリーな仕事ないのよ。
もっとハンズフリーでバーンと頼みたい仕事はあるのだろうか？いまいち思いつかない。ただ社内のチャットとかをみてるとわりかしバーンとやっていると主張する人々がいる。自分のエーアイネイティブ度が足りていないのか・・・しらね・・・。
コードがはかどる結果、人と話して相談する系の仕事が残りがちで、それらの procrastination をエーアイは解決してくれない。いや、少しはしてくれるが、俺の procrastination を甘く見るなよ、みたいなかんじです。尻たたきエージェントの登場が望まれる。いや望みませぬ。
3.5 Pro こないかなーと待っていたが来ないまま７月が終わろうとしているのでいちおう月次感想文を書いておく。主に仕事。なお仕事では社内生贄モードを使っているので裏にいるモデルは不明。たぶんなんらかの Flash だと想像している。
一瞬ヒマがあったので前に挑んで失敗した作業 (ListenableFuture を coroutine で使う)に再挑戦してみたところ、できた。モデル使いのスキルが上がってきたと感じた瞬間。そのスキルがいるのかというと、まあ目先の仕事では有効。
相変わらず第三者のコードレビュー依頼前にめちゃ何周も自己レビューしている。もう良いかなーとおもった瞬間ゴミコードをブチ込んでくるので油断できない。作業の細分化は、相変わらず必須。自分がやるだろうという粒度でやっている。
それでも段々と仕事の並列度を上げている結果、レビュー依頼量が増えて相手に負担してそうだなー・・・という葛藤がある。ひとりすごい良いプログラマがいてほんとはその人にいつもレビューしてほしいんだけど、迷惑なのでチーム内にランダムで散らすようにしている。
その一方、エーアイの書いたコードを送り付けたらエーアイのレビューが返ってきたのでエーアイに直させて終了、という事態がついに発生した。何かに近づいている。自分は今のところエーアイレビューは(他人相手には)使っていない。方針が合わないのと、幸いあまり量がないので。
レビューといえば、アプリのコードはちゃんと見るんだけど自動テストの Python とかパイプラインの SQL とかどうしても雑になりがちで、もうわけない感。
Antigravity が worktree 的なやつ (の jj 版) をバカスカ作るようになった結果、いよいよ普通の IDE を使わなくなってきた。なぜならどこにコードの実態があるかわからないからである。ターミナルも開かない。
エーアイのせいでコードが汚くなるかというと、今のところ先送りしていたクリーンアップが捗った結果あまり問題は感じていない。ただこれは自分の管理下にあり自分が書いたコードの話で、たまに飛んでくるコードにはしばしばすごいゴミが混じっている。ただ前も書いたけど、これはエーアイ以前からの現象である。
そういえば jj を使うのは、ビミョーに下手。もっとも jj が下手なせいのか jj と社内バックエンドのインテグレーションを正しく理解していないせいなかは不明。濡れ衣かもしれない。
あと開かないといえば Obsidian でのメモを全然とらなくなった。なぜなら作業工程がほぼすべて conversation/trajectory に残されているからである。翌日作業に復帰する脳の負荷がゼロ。まあもともとコード書いてないのでニアゼロなのだが。しかしこれはいいのか・・・？
“Loop Engineering” は、してない。マイクロマネッジが必要で、勝手に任せる感じになってない。ただ作業の要求は prompt に直書きではなく issue tracker などに書き、バグ ID をわたして「これやるよ」と言うようにしている。コードレビューも、従来どおり人間向けレビューアプリの上でやっている。そもそも Antigravity は loop engineering できなそうじゃない？できる？
Skills は、一時期いっぱいつくったが使わずゴミになっているものが多い。整理したほうが良いな。（-> した)
scheduled task を使い、毎朝「昨日のレビューで指摘されたことをまとめてレビューチェックリストに追記して」と頼んでいる。8 割くらいゴミなので消しているが、それでも何かは残っている。効果は、不明。
Subagent 活用モードみたいのがあったので使ってみたが、恩恵を感じない割に問題は色々あるので使うのをやめた。たとえばコードをレビューして直させる時毎回 fresh な subagent を作る結果、前々回くらいの指摘事項を忘れて同じゴミを生成してくることがある。たぶん自分のようなマイクロマネッジ勢ではなくもっと丸投げする使い方に向いているのだろうな。このモデル相手に丸投げ可能な仕事がなんなのか自分にはわかっていないが・・・。
ただ Subagent 的に計画を立てるスレと個々のコミットをたてるスレをわけることで context の枯渇を防げると良さそうなので、なんとか AG の機能の範囲で模倣できないかなーとはぼんやりおもっている。
課外活動:
ちょっとした watch (WearOS) app を CC に作らせてみる。悪くはないが、当然自分好みのコードは出てこない。のでそこそこマイクロマネッジしているが、根本的にコードが単純なのとモデルが賢いのとで、往復の量は多くない。
とはいえまえ React+Electron でアプリを作ってた時と比べると、ダメさが目に付きやすい。自分がわりかし Android 詳しいということなのでしょう。そりゃ React と比べたら詳しいですわよ・・・。
ただ $20 の Pro Plan だとわりかし token が枯渇しがち。仕事は自分の使い方の範囲だと無限に使えるかんじなので、それはいいなと思う。
こういうときは Pi+DS4 でなくつい CC を使ってしまう。仕事が堅いのだよなー Claude・・・。
The scariest part to me is that we become dependent on these new machines in new ways. Software has always depended on tools. I remember the time when I had to pay for compilers. These new tools are a flashback to times where creating software came with real costs. But now it’s no longer a one-time payment, it’s a constant dependency. Not just a dependency on a filled wallet, but also a cognitive dependency.
Pi Coding Agent を開発する Armin Ronacher が agent 依存の高まるコードベースへの不安を語っている。なんとなく既視感を感じた。
昔々 WebKit/Blink の仕事をしていたころ, fuzzing によって見つかったクラッシュバグを毎週のように直していた。GCP 上のクラスで動く Fuzzer は半ランダムに DOM を操作する JS のコードを生成しては実行し、継続的にクラッシュバグを見つけてくるのだった。
ブラウザのコードを触ればバグは埋め込まれる。その不都合な事実を fuzzer によって叩き込まれると同時に「これクラスタ代を払うカネが無くなったらどうなるんだろう」と不安も覚えた。カネがないとバグが直らない。Mythos がないとバグを見つけられない昨今の風潮に通じるものがある。百倍くらい価格差ありそうだけど。
相対的にカネがないブラウザはどうするのだろう。そう思って Firefox に目をやると、彼らはクラッシュしない言語たる Rust をつくり、それでブラウザを書き直していた . もっというと DOM は JavaScript に乗せメモリ管理を GC に任せていた。計算資源を燃やすかわりに知恵を使う。クールじゃん。そう当時は思った。(Chrome の名誉のために補足しておくと、Blink の DOM もその後何らかの GC を導入してある種のメモリ安全性を達成したらしい。)
エーアイ時代にも、カネと計算機の力でねじ伏せるコードと知恵と勇気(友情でも愛でもなんでもいいよ)で切り抜けるコードがあってよい。
上でリンクした記事は、来たるべき時代の予兆として Curl 開発者の burnout 寸前事例を挙げている。が・・・これはどのくらい一般化できるのだろう。世界一人気のあるネットワーク・プロトコルの世界一メジャーな実装として世界一攻撃に晒されているというのによりによって C で書かれているこのライブラリ、ソフトウェア開発の未来として一般化するより人類の限界をベンチマークする事例と見たほうが適切ではなかろうか。
ソフトウェアのバグは一般に直すより見つける方が難しい。Ronacher が恐れるような「攻撃にエーアイを使われたら防御にもエーアイが必要」というとき、別にエーアイにコードを書かせる必要はない。むしろ Ronacher がいうような、ヒトが慎重で硬いデザインを詰めていくほうが妥当なことは多いと思う。防御のためのエーアイは、攻撃者より先にバグを見つけるのに使えば良い。
やがてエーアイが人間より硬いコードを書くようになり、しかし人間にはそれが理解できない日がくる可能性はある。たとえば formal method をエーアイに書かせるぞ と息巻く Jane Street はそうした世界にむかい先陣を切っている。ただ個人的には先の話・ニッチな話に感じられる。
どういう形をとるにせよ、計算機の力で人智を超えたコードを生成しまくる世界も、計算資源の嵐を知恵と努力と友情で乗り切る未来も、それぞれの趣や面白さがある。
エーアイ絡みの心配は自分も色々あるとはいえ、重要なソフトウェアがゴミコードに埋もれて窒息する不安は今のところあまり大きくない。ただし前提がある: エーアイ業者はその泡銭で CS 研究者をやとって遊ばせておいてほしい。CS 研究者もそれに便乗しコード環境問題への取り組みを頑張って欲しい。問題は起こるし、もう起きている。でもそういうボヘミアン研究者がきっとなんらかのブレイクスルーを見つけ出すと思うんだよね。それがなんだかは知らないけれど。自分の楽観は、人類が産んだ賢い人々への楽観なのかもしれない。
今日もまた仕事のコードレビューでイラッとしたコメントを書いてしまい余計な手間を増やしてしまった。反省。
交通事故も、交通規制を守らないひとが一人いるだけでは起きないが二人いると起こる。仕事の議論もイラッとしたひとが二人いると揉める。そのうちの一人になってはいけないが、人間ができてないので時折なってしまう。
少しまえ、エーアイに語感を和らげてもらう社会性フィルタ について書いた。今回も社会性フィルタの適応をサボったのがいけなかったかな・・・と一瞬考えたが、マジレスとして社会的フィルタは本質的には風刺であり、そのラインを超えてはダメである。要するに microaggression ですからね。ただ現実問題としてイラッとした時に microaggression を発動させる一番表面的には無害な方法なのも事実で、フロドの指輪に似た禁断の誘惑がある。
COVID 末期に Quiet Quitting という現象が流行った。これは、今思えば COVID 的というか WFH 的な現象で、社会性フィルタに通じるところがある。仕事がオンラインになればなるほど社会性フィルタや Quiet Quitting はやりやすくなる。人間性への敬意を書いたコミュニケーションは画面越しのほうがやりやすい。脊髄反射や本音を画面のこちら側に隠しておけるから。
ただ人間性を軽視するとコミュニティへの所属感、チームの結束感や相手との親密さは失われる。仕事のやる気もさがる。なので眼の前の仕事をそれなりに持続性をもってやりたいなら、これらは望ましい態度ではない。Quiet Quitting は quit してるので持続性は期待してないから仕方ないとして、社会性フィルタはダメ。わかってる。
ただしょうじき、エーアイの指輪はいちどつけたら外すのめんどくさいよね。AI チャットのせいで若者ちゃんと人間関係鍛えられないのでは という懸念を多くの年寄が感じているが、若者に限った話じゃない。仕事のめんどくさいコミュニケーションしたくない。肌のあわない苦手なひとと話したくない。にこやかにイチからきちんと説明して説得して協調とかしたくない。そんな気分があるからこそ Workslop が生まれる。社会性フィルタとか呼んだところで slop に違いはない。自分は話したくないんですよそもそも。
ここで踏みとどまって真人間として振る舞い社会的筋力を鍛えるのが会社員の仕草であり、出世パスであり、大人になるということだった。しかしエーアイや画面や大人気ない国家首脳の皆さんなど今日的な現象の数々がこうした筋トレへの意欲を過去にないほど削いでいる。
“Bowling Alone ” (邦題: “孤独なボウリング ”) という昔書かれた超有名な社会学の本があり「アメリカ人最近孤独らしいんですけどなんでですかねー、調べたけどテレビくらいしか原因はなさそうですねー」と書いていた。しかし四半世紀前は平和なもんだったね。 すくなくとも職場というリアルワールド社会性強制ギプスは完全に健在だった。アンチ社会性筋トレマンガ Dilbert に面白さを感じられるのも、リアルワールドでの社会性をある程度は強制されているからである。
つまり: めんどくさい人間関係を生産的に乗り切る社会性筋力はかつては雇用を通じ強制的に鍛えられたが、時代の流れがその強制力 (“friction”) を流し去ってしまった。だからかなりやる気を出さないと社会性筋トレができない。しかし社会性を鍛えられていない人間から構成された社会は果たして望ましいものなのだろうか。
この反語にはしかし、安易に頷くことはできない。先のコードレビューで起きたような衝突（レースコンディションによるクラッシュを無駄な動機を挟むことで性能劣化の問題に転化するコード書くんじゃねーお前のバグがこっちに来るじゃねーか！みたいな揉め事）を、ソフトウェアエンジニア的に解こうとすると 1) テストを強化しましょう 2) プロセスを強化しましょう 3) ベストプラクティスを文書化しましょう 4) ベストプラクティスをフレームワークにエンコードしましょうみたいな話になり、これらはさほど社会的な解決でなくはないか。いやプロセスは社会的かもしれないが、一番ダメなやつじゃん？ 社会的じゃないほど望ましいじゃん。
そのようにして出来上がったチームやコードベースは衝突/friction のすくないなめらかなシステムに違いはないが、必ずしも社会的・人間的でない。他人の社会性（のなさ）を補ってくれるシステムは自分の社会性（のなさを見逃して欲しい気持ち）も抑圧される。個人的にはちょっと衝突リスクがあってもゆるいコードベースの方が働きやすい。しかし時々今日のようにイラッとしてやる気を損なう欠点がある。うまい話はない。結局、抑圧的システム化と人間的余白と苦手な同僚との付き合いのバランスをとるゲームのスキル獲得がソフトウェア開発者の社会性筋トレだということだろう。
エーアイはこのバランスを破壊した。そして workslop のような従来の社会性を損なう営みを産んだ。こういうのは目の当たりにすると腹が立つ一方、自分も誘惑に負けてやりがち。エーアイを火山のマグマに投げ捨てることは出来ないから、何らかの形で新しい秩序を作り出す必要がある。今日はイラッとしてすまなかったけど指輪は使わず痛みを感じることが出来た。やる気が回復したらなんか生産的な施策を考えます。はい。
読んだ: Amazon.co.jp: 半導体 尖端覇権の興亡 eBook : 大鹿靖明: Kindleストア
日本の半導体周辺産業凋落の歴史。なんとなく 20 世紀で敗北していたと思っていたがメモリとかフラッシュなどは 21 世紀でも序盤は頑張っていて、しかしこの 20 年で負けてしまったねという話。Chip War " (邦訳 “半導体戦争 ”) や “Apple in China ” を読むと、日本はチラっと出てきたあとすぐ敗北退場してしまう。この本は退場したあとどうなったという話で興味深い。自分は、何も知らなかったね。関心も払っていなかったし。
日本はいわゆるメーカーが垂直統合なせい半導体産業が分散しており、規模で戦う局面についていけなかったのが敗北の主要な原因だと著者は分析している。政府が介入してデフラグを試み、ルネサスだのエルピーダなどがあったがあまり上手く行かず、ルネサスはまだあるがエルピーダは消滅（買収）。あとキオクシア（なんかゴタゴタしてたが最近はエーアイ景気で復活）などなど、色々あったのだねーと勉強になった。そうした産業構造の問題ではなく、サブプライム直後の円高（当時は日本の銀行が手堅かったのでドルが逃げてきた）で価格競争に負けて滅びたり、地震のせいで工場が壊れてそのまま破滅したり、踏んだり蹴ったりの様相。
赤字やらなんやらで国内産業が中国にどんどん買い取られていく様は Apple in China の日本版というかんじで趣深い。仮想敵国にこんなにバンバン国内技術を売り渡して全然ブロックされないとは、昔は平和だったのだね世界は。完全シフト済の現代 Overton Window から見るとドン引きしてしまう。
前半八割くらいがそんな凋落の話で、あとの一割が TSMC 熊本進出の話。そして最後の一割がラピタスの話。ラピタス、こないだ北海道旅行をしたときに話をきいてへーと思いつつスルーしていたが、IBMの技術をベースに税金投入してファブを作る、客はこれから探す、みたいなめちゃ掛け金高くて歩の悪い博打を打っていると知りビビった。日本で 2nm? ほんとに? ASML の機械が搬入される下りとかもう読んでいて胃が痛い。
「覇権」やら「戦争」やらの表現が示すように、TSMC もラピタスも金稼ぎではなく保安上の施策なのだよね。アメリカ政府が CHIPS Act で Intel や TSMC に出資したようなもので。なので分が悪いのはある程度織り込み済みと言えるが、こんなカードしか残っていないとは・・・と悲壮な気持ちになる。空前のエーアイ景気の勢いで客を掴んで起動に乗せられるといいですね、ほんとに。Intel も Apple や Google から fab として発注を受けるという前代未聞の展開が続いており、政府の圧力もあったろうけれどそれ以上に TSMC だけじゃ帯域が足らんという話なわけで、全てエーアイのおかげ。日本も恩恵受けてほしい。
少し前に Substack あそびとして Noah Smith を購読していたら “ウィーブが日本を救う ” という本の抜粋 がアーカイブにあったので目を通した。Noah Smith は TSMC 誘致みたいな FDI (Foreign Direct Investment) で中国がやったみたいに発展途上国プレイをして経済復活だ、みたいな話をしており、日本そんなキャラじゃくね・・・と思っていたが、今となっては妥当 (less worse) なカードなのかもしれない。この本を読んでふと思い出した。
Statement on the US government directive to suspend access to Fable 5 and Mythos 5 \ Anthropic
エーアイコーディング、安い/公開ウェイトの中国モデルを弱いやつなりに上手に使うスキルは、思ったより守備範囲が広くなるのかもしれない。
以前はそんなの過渡期のスキルでモデルが強くなれば解決するから、せいぜいクラウドの free tier タダ乗りスキルみたいな貧乏余暇プロジェクト勢のニッチスキル止まりだろうと思っていた。これは自分個人にとっては重要だがエンタープライズ的にはどうでもいい。金を払って強いモデルを使うほうが手っ取り早いので。
ただトークン価格の高騰や上記のような言動に代表される地政学的リスクを考えると、強いアメリカモデルから距離をおきたいと感じる勢は、特に国外では増えそうである。少し前から Sovereign Cloud みたいな動向も盛り上がり始めているし。
もちろんリスクというのは確率的な事象であり、「結局プロプリエタリアメリカモデルに乗っておくのが正解でした」となる線が今も一番太いとは思う。ただ不測の事態に備えたい人々が性能を犠牲に柔軟性や自己所有を優先するのも珍しいことではない。危険というのは、一度見えてしまうと忘れることは出来ないのである。
安いモデルたち、強いモデルに比べると大したことないのは確かだけれど、一方でまだまだ周辺技術およびモデル本体のチューニングで良くなる伸びしろはありそうに感じる。安いモデルでがんばるひと以外が Reddit のローカルモデル動かす勢と中国人以外にも増えてくると、裾野も広がるのになと思います。いま世の中の skill とかも Claude や GPT みたいな強いモデル前提なのが多い。弱いモデルに必要なアグレッシブな steering は、一年くらい前に流行りかけたけどモデルの高性能化で影を潜めてしまった。安弱モデル活用チップス、また復活してほしいもんです。