インフラとか監視スタックとかも含めて全部 AI が勝手にやってくれるようになる日も遠くない感じがある。
去年ぐらいに「コードを書くのは AI で十分できる」になって、今年は「レビューも AI 任せで良い」になって、普通の web サービスの開発はほぼ指示出してマージするだけになってきている感じがある。ただし、それを載せるためのインフラをどこに載せるかの判断はまだ人間がしている事が多いし、細かいコントロールも人間がやっている事が多いと思う。
とはいえ、ここまで色々できている AI の様子を鑑みると、この辺りも含めてベストな選択肢とスタックを AI が勝手に提案実装できるようになる日もそんなに遠くない気がする。vibe インフラ運用で問題なくワークするようになる日が来るのも遠くない気がする。
Lambda が Cloud Run ぽく使えるサービスが出たらしい。便利そう
https://aws.amazon.com/jp/about-aws/whats-new/2026/10/aws-lambda-web-functions/
良い OSS を見つけたら、そこから自分が使いたい機能だけを抽出して AI で自分用にリライトしたものを作り(これ自体ほぼワンショットで出来る)それに依存すると言うのが正解になるような気がする。
こうすることで、依存の依存みたいなよく分からない依存性をシステムから排除できるし、自分の使う機能だけに切り出すことで、余計なオーバーヘッドを削除できる。
https://x.com/yusukebe/status/2109208169444675845
Hono のユーザーが人間じゃなくて AI になったので、Hono の提供価値を考え直さないといけないみたいなことを Hono も考えている。
良い OSS と思われていたもののほとんどが、良い Ergonomics と言うようなことを大なり小なり追求していたのは間違いなくて、その「良い Ergonomics」と言うのものが全部「どうでも良く」なりつつある現状があると思う。
Deno の提供していた「良い Ergonomics」も同じ理由で「どうでも良く」なったし、全ての OSS が同じ問題に直面していると思う。
あらゆる Ergonomics が今どうでも良くなりつつあるし、一方でライブラリに依存することでサプライチェーン攻撃リスクにさらされるという負の側面がどんどん目立つようになっていて、OSS は使わなければ使わないだけ良い、と言うのが正解になりつつあるんじゃないか・・・?
Deno と言うアイデアは今でも有効だし、それが JS runtime のあるべき形だという考えがある一方で、Deno が Node/Bun に対して正しくやっている部分は結局人間向け DX だったり ergonomics だったりと言う部分がかなりの部分を占めていて、そういった提供価値が AI で大幅に目減りしたと言うことも間違いなくて、Node/Bun は微妙だけど、その微妙な部分をもう人間は書かないので、別にどうでも良いんじゃない? と言うのが実際のところであるような気もする。
Deno に依存している会社がある; slack, netlify, supabase。こういう会社に売りに行けば、Deno をやっていた部分をプラスに評価してくれただろうし、Deno の開発をやめるなんていう条件をつけられることも無かったはず。
Deno を全く評価していない Cloudflare に売りにいくのは何かおかしくて合理的ではない。
最近 AI と人間の違いがだんだん分かってきたので、人間には絶対に頼めない内容の指示を AI に投げるようになってきた。
局所的な状況を切り取ると AI と人間は結構似てるように見える事もあるけど、AI は情報処理速度が圧倒的に速いので、量を読んだり、量を書いたりする事を平気で頼むと良いアウトプットを出してくれやすい。
最近 AI に 2D ゲームの続きを開発させている。単にこれやってとお願いすると、大体よく見るクソゲーっぽいアウトプットが出てくる。多分学習データの中に、ゲームチュートリアルみたいなのが沢山あって、それを作ってるんだと思う。
じゃあ AI はイマイチ使えないかと言うとそうではなくて、このゲームではこう言うデザインルールがあるとか、こう言う制限・ポリシーの中で作っているとか、自分が持っていたルールをどんどん指示として追加していくと、急速にアウトプットの質が高くなる。
ポリシーの明文化が難しい場合（例えばドット絵が持つべき雰囲気とか）は、AI の作業に対して違和感と、何を見本とすべきかのポインターを与えれば AI が勝手に文書化してくれる。それをベースに再度アウトプットさせて、違和感が解消しているかをチェックする。この作業を違和感が消えるまで繰り返す。
AI はポリシー分析・アウトプット修正のループをいくらでも回せるので、いつかは使えるアウトプットが出るようになる。
AI と喋るのは割と苦痛の方が多い。特に AI が言っている事を聞くのは苦痛だけど、AI について AI と相談せずにあれこれ考えるのは結構楽しい。
「ソース読め」はもう人には言わない・要求しないけど、自分はやる気を出すためにソースを読む。
ソースコードあまり読み書きしなくなってしまったけど、やる気が無くなってきた時にソースコードを読んでいると不思議とやる気が復活してくる感じがある。
AGI という定義が割とよく分からない。何が出来る事が AGI なのか、いまいち定義がピンとこない。その割に「AGI まで後何年」みたいな予測を各社が出していて謎な感じがある。
純粋に考える能力という意味での知能としては AI はもう人間を超えたように見える。working memory のようなものが AI は人間より圧倒的に大きいし、ロードのスピードが速い。ややこしい問題を考える能力は AI の方が圧倒的に高い。
一方で、AI は課題の建て方が上手くない。放っておくと価値のない課題をどこまでも追求するループに入って行きがちで、より価値の高い問いはこっちだ、という知見を自ら発見する事は少ないように見える。特に AI は見ているコンテキストに引きずられがちで、前提として見えていない情報から重要なファクターを拾って来るような動きはほとんど出来ていないように見える。
AI が数学の未解決問題を解くようなすごい成果を出せるのは、その AI に指示を出した人間にその問題の重要性が見えていた場合に限られて、AI が自らこの問題が重要であるという事を主張できるケースは稀であるように見える
リバースエンジニアリングに関していうと、OSS のリバースエンジニアリングが簡単になっていて、Bun の Rust port が一時期物議を醸していたけど、あういうソースコードがあるものの仕様を agent に解析させて、そこから作り直すみたいな事は本当に簡単に出来るし、これから当たり前になっていく可能性がありそう
agent にコードを読ませて仕様を抜き出させるとかなり正確なものが出せて、それを別の agent に食わせて実装を生成させれば、oneshot でめちゃくちゃ正確なものが出来たりする。OSS でちょっと気に入らない部分があったりしたら、PR 投げて修正してもらうよりも、SPEC.md を抜き取って、気に入らない部分を修正してから実装を生成した方が圧倒的に速い。
再生成する際に、使わない機能を SPEC.md 段階で落としてしまえば、オリジナルよりもむしろ性能が良いものが出てきたりするだろうし、OSS はそのまま使うより再実装してから使う方が best practice になる可能性すらありそう。自前再実装して仕舞えば supply chain 攻撃を受ける可能性も減るので、セキュリティ面でもそっちの方が良い。
要素技術に対する微視的な興味が格段に落ちた一方で、hyperframes みたいな事が出来るようになったり、リバースエンジニアリングみたいな事が簡単に出来るようになっていたり、今まで一部の専門家しかやっていなかった事が誰でも簡単に出来るようになっていたりして、エンジニアリングの主戦場が、全く違う場所に移った感がある
みんながもはやソースコードを手で書かないので、言語に対する不満も出て来にくいみたいな状況になりつつある気がする。文句が出得るとすれば「書きにくい」よりも圧倒的に「理解しにくい」事に対する不満の方が多くなって来そう。
理解できる事が、言語にとって一番大事なことで、尚且つもうコードを手で書かないので、人間が新しい言語を習得する事が困難になってくるとすると、もう今ある言語以外が大きく流行る余地は限りなく少ないかもしれない
This week in react (newsletter) の人が、もう React は死んだみたいなポストをするようになってしまったぐらい、もはや誰も React を書いてる人がいない状態・React の細かい話に興味がある人がいない状態で、個別のライブラリとか、言語とか、処理系とかがもはや割とどうでも良いと思われ始めている感じがある。
大上段に振りかぶったような OSS が毎日のように出てきては 10スターぐらいしかつかない(以前だったら100とか1000とか言ったレベルでも)のが当たり前になってきて、本当に世の中が全く変わってしまった感じがある。
プログラミング言語の役割がソフトウェアを作るためのものから、ソフトウェアについての精密な議論をAIとするためのものにシフトした感じがする。
千夜一夜あるある 「処刑する！」 「待って。こんな面白い話あるよ！」 「どれ、話してみなさい。」 「実は・・・」 「おもろいやん！OK 処刑無し！」
このパターン多い
千夜一夜物語、バグダッドの軽子と3人の女の話がやっと終わった。長かった。軽子が途中から何も言わずに居なくなってて草。
最後大団円風に終わってるけど、よく考えると全然大団円じゃなくて次の問題の始まりになってる。
もうコードは自分では書かないという前提で見ると ecma262 とか tc39 もちょっと違った見え方で見えてくる。
自分が書かないという以上に、自分以外の作業者もコードを自分では書かないという前提だと、言語の syntax がどうであるという情報の意味合いが結構軽くなってくるように思える。
代替手段が全くないレベルの大きな機能であればともかく、ちょっとした syntax の差分程度の新機能だと、あまり知っている必要がないという立場を取られても仕方がない。
claude, gcloud コマンドの、多分ドキュメントされていないだろう挙動についても細かく知っているのってなんでだろう・・・
千夜一夜物語、バグダッドの配達屋と3人の女の話、なかなか story in story 始まらないなと思いながら読んでてたら45ページ進んだところでやっと最初の story in story 始まった。こんなパターンもあるのか
celld っていうのが出てきた。なるほど
千夜一夜物語、漁師と魔神の物語まで読んだ。個々の話はシンプルなお伽話という感じだけど、お伽話の中に別のお伽話が入れ子状になっている(今のところ最大で4重入れ子の話があった)ことで話の構造が非常に複雑で理解が追いつかないぐらい入り組んでいるところが面白い。