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 は、一年くらい前に流行りかけたけどモデルの高性能化で影を潜めてしまった。安弱モデル活用チップス、また復活してほしいもんです。
3.5 Flash が実用の閾値を超えたのと、潤沢にトークンが使えるのもあり、世間から一年遅れくらいで AI pilled ぽく仕事をしている。
- 4 つウィンドウを並べるのをやってみている。気が散る。並列度は最大が 4 だが、４つ埋めきることはなかなかできない（そんなに並列の仕事がないし、やりたくもない。）エーアイ相手にティーエルごっこ乙・・・という気持ち。
- 社内謎 DSL で書くちょーニッチな A/B テストの一部部門固有 ACL に使われている infra-as-code ペーパーワーク、という全然わからん代物をいじる必要があり、わからん助けてーといったらバーっと社内サーチを駆使して正解を見つけてコードを書いてくれた。あたしより仕事できるじゃん・・・この deep research 的なスキルとコードの組み合わせは純粋なコーディング仕事よりエーアイの恩恵を受けやすい。
- こまめにスキルを作る、というのを試している。こういうの、チームでシェアした方がいいんだろうなと以前は思っていたが、$HOME/local/bin のシェルスクリプトみたいなもんだと思うと別にシェアしなくていいかな、という気がしてきた。めんどくせーし。一方、諸事情から社内共通 skill のひとつにパッチを送ったところ unit test (というか eval) があって感心した。こうやって品質管理すんのね。
- とかなんとかやっていたら、アプリチーム内のエーアイリーダーボードで三位につけていた。tokenmaxxer じゃん。(いちおう勤務先の名誉のために書いておくとリーダーボードの上を目指すことを勧められてはいない。存在すら社内 pilled チャットで聞くまで知らなかった。)
- 手でコード書いてない。というか Android Studio 起動してない。
- そういえば「メモリリーク見つけて」と java heap dump の入ったトレースを渡したらちょーデタラメな数字をよこしたので根拠を問いただしたところゴミ Perfetto SQL を書いていた。これを直したときは手で SQL 書きました・・・。しかし Perfetto SQL 一応知ってるんだな・・・。
- しばしばエーアイが勝手にコードをアップロードする (PR みたいなもんです) ため、あるとき修正でレビューアプリ上でレビューしてしまった。やむなく「レビューしといたから見て直して」といったら直しつつ返事をしてきた。Antigravity のチャットでレビューするより無駄に人間味があり、不気味。ただ他人から見た透明度が高い利点もあることに気づいたので、しばらくはこのフローでやってみようかな。ややターンアラウンドが遅くなるが。
- 金曜。エーアイ氏には手の負えないコードがあり、諦めて AS 起動し半月ぶりに手書き。すると、動く動かない以前にアブストラクションがダメだな・・・などと色々発見があり進展する。手で書く大事さを肌で感じる。全てを手で書く必要はないと思うが、手で書いた方が良いものはある、しかしその判断基準はいまいち不明。これはエーアイ時代のスキルの一つなのかもしれない・・・し、過渡期の現象なのかもしれない。
最近会社のラップトップで Obsidian Android が動かなくなってしまったため、この日記（特に脊髄反射ダンプ）をかけなくなってしまった。息抜きにインターネットして見つけたものを書く場所がないとソーシャルメディアで失言したりしがちなので、失言をバッファする場所がほしい。
ということでマークダウンエディタ的なものを適当につくって Cloud Run に置く。漢字プリントアプリと違い機能強化する気がほぼゼロなのでコードもろくに読んでいない。Claude Code Opus に比べると DS4 Pro は若干危なげあるが、この手の CRUD を作るだけなら許容範囲に思える。ただし毎ターン監視する前提。AGENTS.md とかスキルを強化すればいいのでしょうが、まあおいおいやってきます。
結局 Opus のような真の frontier model が必要かどうかは、どのくらい手放しで仕事できるか、すなわちしょうもない凡ミスをしないか＋ミスに気づいて復帰できるかが重要で、それは仕事でめちゃマルチタスクさせるときには大事だが個人がマイクロマネッジする分にはそこまで重要でない。コードの質以前に、インクリメンタルに作らせながら開発中の画面を見てほしいものを考えるので、手放しにはできない。自分の開発スタイルがぜんぜん oneshot/waterfall になってない。
とか書いていてコードをあまりに見てないことを反省し、ちょっとレビューすっかという気になった。直します・・・。
直してながら思うこととして、コード (TS/JS まわりの細々した選択)は DS4 (on Pi) より Opus (on CC) が良い気がするな。素人判断だが。
あと “best practice” 類を知らない素人 (=自分) のレビューは限度があるね。特に JS だとサードパーティライブラリ持ってきて終了〜みたいのが多いが、DS4 は自分で書きがちである。Opus/CC の判断がこなれている理由の一つはおそらく裏でウェブ検索をしていることで、DS4 にはそれがない。せっかくコマンド作ったんだから使って調べていいのよ、と背中を押すと調べるが、板についていない。
Vibe Stack とはつまり Hobby Stack のことで、私用小物アプリをホストする要素技術の意。最近はしょーもない自分専用実用品を一瞬で作れるようになったので必要性が増した。下手なスタックを選ぶと Ops が重荷になってしまう。
で、わたくし Vibe Stack は Cloud Run + Firestore + TS Server(Hono) + TS Web (Vanilla React) で行くことにしました。
ここ十年くらいは Cloud Run + Firestore + Python (Flask) + oauth-proxy + Vanilla JS だった。何がいいかというと別に良くはないが個人の都合による:
- Cloud Run = Pay as you go なので個人アプリだとほぼタダ.
- Firestore = 同じく Pas as you go.
- Python + Flask = ウェブ素人に優しい。
- oauth-proxy: 素人なのでログイン画面すら作れないんだよ!!
- Vanilla JS: 素人なので React とかわかんねーんだよ! だいたい plain HTML で足りてますからッ
という状態だったのが、エーアイの力により以下のようになった:
- TS (Hono): なんかいい具合に書いてくれる。ログイン画面も作ってくれる。Firestore も SDK で普通に使える。
- TS (Vanilla React): なんかいい具合に同上。SSR とか必要ないのとエーアイ頼みでもなお難しすぎるので Next.js はパス。
- TS は普通に JS よりいいが、以前はビルド環境とかを作るのが無理だった。今はお任せできる。言語としては static-typed python より 10x マシ。
大きな不満は Firestore で、できれば Postgres 的な SQL を書ける RDB がいいなーと思っているのだが、GCP には pay-as-you-go で安心して使える RDB がないのだった。AWS の Aurora DSQL が羨ましい。Spanner でも AlloyDB でもいいのでがんばって追従して scale-to-zero 課金のサービス作ってくださいたのむ。Cloud Run + SQLite のハックも何種類か試したが、いまいち心許せるアプローチに出会えず諦めた。
Firestore, ロックインなのはイヤだけど、単一プロジェクト内に複数データベースをつくる機能が三年くらい前に百年の時を経て実装され、私用零細アプリ乱立用途ではかなり使えるものになった。SQL ないのは、いいです。諦めます。(いつかたのむ！)
銀行のウェブサイトからPDFをダウンロード・バックアップしたいが、やたらたくさんあってかったりー・・・ということでエーアイにがんばれせてみた記録。
最初は Claude For Chrome + Claude Code を試してみた、が、銀行のサイトは denylist されていて Claude には見えなかった。しかし健気に “この JS を devtool に貼り付けて結果を教えて” とかいうので言うがままに従ったところ、まあまあ自動化できた。ダウンロードは <a download> を click() するらしい。なるほど・・・
denylist されずに触る方法はないかと考え、そういえば DevTools MCP とかいうのがあったなと試すが、頑なに Incognito かつ別プロファイルののウィンドウばかり開くので、だめ。
別に MCP なくてもあんたたちプロトコルの JSON 知ってんじゃないの・・・とやらせてみたら、今度は localhost:9222 からデータが帰ってこないという。なぜだ・・・と調べたら、去年から 実ユーザのプロファイルで 9222 は禁止されたらしい えーケチクサじゃないですか? でも最近は npm supply chain attack とかで Linux にもカジュアルにマルウェアがやってくるようになったのを思い出し、自制。
そういえば Gemini For Chrome とかあったよね？ Linux でも無理やり動かせちゃう？ と試したら、途中で謎の無限ループにはいり同じ PDF を何度もダウンロードしはじめたので頓挫。
というわけで結局いちばんちゃんと動いたのは Claude Code いいなり JS コピペであった。なおこのときは節約のためモデルには Sonnet を使っており、特別賢くない。一方で途中頓挫した Gemini for Chrome は Flash 3.5 で、特段アホではない。どちらかというと Gemini for Chrome は画像ベースなのが厳しく、Claude Code は DOM 相手なのがよかったのではないか。もちろん DOM だと画像の中身は見えない以上できないこともあるわけだが、アクセシビリティとか真面目にやってあるちゃんとしたサイトなら画像よりよっぽど効果的なんじゃないの？
去年 LLM にソースコードとそのコードの実行中スタックダンプを交互に渡して動作の理解を深める Code World Model なんてのがあったけど、似たような感じで DOM World Model … というと響きがよくないな。大風呂敷で Web World Model, みたいのをどこかの frontier lab にやってほしい。まあやって成果でなかったのでお蔵入りになっている可能性もある自明なアイデアではありますが、DOM の解釈は諦めないで頑張ってほしいなあ。スクレイピングだってみんな DOM じゃん？
Google I/O を見ていてわかったこととして、仕事で使わされていた Gemini はこの Flash 3.5 で、使わされていた Antigravity は 2.0 だったらしい。
ここ二週間は、仕事の内容のせいもあるが、ほとんど自分でコードを書いていない。唯一書いたのは微妙な集計が必要な Perfetto SQL で、しかも雛形を書いただけで仕上げは Gemini 任せだった。世の中から半年一年遅れではあるが仕事における Agentic Coding がようやく実用的になった。他の会社のモデルと比べてどうかは知らないが、三ヶ月前は全然使えねーとか書いているので、大した進歩である。九ヶ月前 も同様（というか、もっと悪い)。
Flash 3.5, 賢さはさておきとにかくメチャ速い。去年使わされていた 2.5 Pro は論外として、DeepSeek ・・・と比べるのもどうかと思うが DeepSeek Flash すらカタツムリみたいに見える異常な速さ。しかし値上げと組み合わせるとあっという間にカネを溶かしそうである。仕事だと気にしなくていいのだが、趣味だとどうかな・・・。
賢さも実はそこまで不満はなく、自分のマイクロマネジメントな使い方だと現状はスイートスポットに近い感じがする。もうちょっとくらい賢いとそれは望ましいが、大幅に賢くなっても人間側の能力・仕組みがついていけない。コミット単位で同僚にレビューとかしてもらってたらアムダールの法則的に律速されてしまう。もっとバーンとでかい単位で投げてエーアイとかにレビューされてハンコ押す・・・みたいにならないとエーアイ全然本気だせない。
来月は 3.5 Pro をだすとか言ってるし、まあ Pro は使わせてもらえないにせよ過去のペースから類推するに年内もう一回くらいはバージョンアップが予想されるわけで、この人間律速問題はもはやカッティングエッジな人々に限らず大企業にとってすら明白だと思うんだよね。会社の賢い人々がどう舵取りするのか見ものであります。
あと Antigravity 2.0 は普通に良い。もう CLI 不便じゃよ・・・といいつつ遊びでは引き続き Pi+DS4 を使ってまいります。ホビーでは便利さだけがすべてじゃないのでね。
CC で作っていた漢字練習プリントアプリを Pi + DS4 Pro で直してみる。なんかフツーに動くな。難しいことをやらせていないので賢さ的には問題なし。強いて言えば (token generation が) 遅いのが不満。ただ 75% 割引で激安＋コードが小さいのでまったく $5 の予算が減らないのは良い。
世の中的には Qwen の評判がいいのでつついてみたいと思い調べるも、Pi 公式 provider はなくサードパーティの provider もあまり使いたくないので保留とする。
多くの中国企業は Claude を distill していると言われているが、そうだろうなーというかんじ。文体・口調が全く同じ。Gemini とかだと毛色の違いを感じるので、トレス疑惑を問われるのもやむなし。
コーディングの RL 環境作って色んなコードをガンガン書かせるとか、エンジニアリング体力（カネ・人材）が必要そうなので中国どうこう以前に小さい企業には難しいと思うのだよね。完全な素人談義ですが。一方で distill させるにもコードは書かせる必要があるので、環境づくりが下手というのは過小評価な可能性もあり、彼らは（少なくとも環境づくりは）ちゃんとやってるのかもしれない。
エーアイの書いたコードは、書かせた人以外はレビューしなくていいし、もっといえばしない方がいいと思っている。今の職場は人間レビューが必須になっているけれど、他人のエーアイコードをレビューするのって外部性バリバリで全然フェアじゃない。自分のエーアイコードをレビューさせるのも気の毒。この無神経さに慣れたくない。
目先の実現可能性はさておき、自分にとって納得できる落とし所はどのへんかと考える。
まず Super-lint としてのエーアイコードレビューは必須。現状多かれ少なかれ皆なにかしらのエーアイコードレビューは使っているので、チーム開発ならそれを標準化し、ローカルルールや価値観を埋め込んでいく。
自分のコード
という前提で、まず自分の「所有」しているコード。エーアイと、エーアイに書かせた本人がレビューしたら、第三者のレビューはなしでいいんじゃね？ゴミ化して困るのは当人なわけだから。そもそも従来のレビュアにしても、自分で書いてない他人のコードのレビューは表面的になりがち。エーアイと大差ない。労に合わない。
その当人がゴミを残しチームや会社からいなくなってしまうリスクはある。ただそれは別にエーアイに限ったことではない。ゴミのスケールが桁違いなのは事実かもしれないが、人が書いてレビューすればゴミにならないわけでもない。チームが一丸となって作り上げたゴミの山をみたことないですか。
他人のコード
他人のコードを変更するときはどうか。あるいは逆に、他人が自分の所有するコードへの変更を送り付けてきたときはどうか。所有者に強い権限を与えよう。
従来は送られてきたコードにはある程度丁寧に付き合うのが礼儀だった。組織に閉じたコードでは特に（同僚に失礼なことしないよね）。が、エーアイコードでこれをやると所有者が外部性の被害に合う。
そこで一旦この文化・不文律を捨て、 Pi Coding Agent のように 拒否をデフォルトにする。他人からのエーアイコードは「貢献」ではなく「押し付け」だという新しい常識を広める。めんどくさそうな匂いがするなら「いらないです。さようなら」でいい。所有者がチラ見でアイデアを把握したのち自分のエーアイに書き直させてもいい。とにかく「有り難いもの」という感覚を捨てる。皆で捨てる。エラいエンジニアが strategy memo とかいってバーンと明文化する。
他人のコードを頻繁に書き換えている自分のような人間にとってはかなり不都合な世界だが、仕方ないと思う。コードを書くことより、コードの後ろにいる人間を説得するのに労力を割けということだろう。というか書いてないからなコード。エーアイが書いてるわけで。
コードは読まない→なにを読む？
この世界に「チーム共有コード」のようなものはない。すべてのコード片は誰かが所有する。そして人々は助け合わず、自分の身を守ることを優先する。楽しくない。この世界に楽しさを取り戻すには何らかの発明が必要。「オープンソース」や「コードの共同所有」は発明だった。同じようになにかが発明されないといけない。
具体的な発明の姿は見えないが、世の過激派の主張を見ると「コードは誰もレビューしない」勢力が今は一番元気に見える。Pandas の作者 Wes McKinney に至ってはエーアイレビューツールを自作し「もう全然コード読んでないよ」と言っていた。自分のコードを書いてないし、読んでない。
過激派が目指す世界では: 自分のコードは自分のエーアイレビューに任せる。他人のコードに踏み込んだら相手のコードのエーアイレビューに従う。共有コードは共有エーアイがレビュー。
進んだ先にある疑問: 人間同士はコードを読まずにどうやって「コードが実現したいこと」を伝え合うのか。この「意図」がエーアイコードの世界の「人間の読むコード」に相当するわけだが、素朴に「仕様」とか言い出すとエーアイのそれっぽい slop に侵略される。意図のやりとりでも受け手の外部性に対しては断固とした態度が必要。わかりにくい sloppy な意図はがんばって汲み取らずただ断って良い。
けれど今は人間にも「意図を伝える、明快で簡潔なコミュニケーション」すなわち anti slop が欠けている。つまり発明が必要なのは人間による読ませるコミュニケーション手法なわけだ。
個人的には「エレベーターピッチ」や「ラブレター」みたいな渾身のコミュニケーションが普通になったら面白いと思う。魂の叫びで slop に勝つ。
自分はコードを読み書きしない時代が来たら残念だけど、もし避けられないならかわりに形式的で官僚的なコミュニケーションも流れ去ってほしい。そしたら人類の進歩に数えたい。