Yoshiya@kt3k・21h

「ソース読め」はもう人には言わない・要求しないけど、自分はやる気を出すためにソースを読む。


Yoshiya@kt3k・21h

ソースコードあまり読み書きしなくなってしまったけど、やる気が無くなってきた時にソースコードを読んでいると不思議とやる気が復活してくる感じがある。



Yoshiya@kt3k・Sep 29, 2026

AGI という定義が割とよく分からない。何が出来る事が AGI なのか、いまいち定義がピンとこない。その割に「AGI まで後何年」みたいな予測を各社が出していて謎な感じがある。

純粋に考える能力という意味での知能としては AI はもう人間を超えたように見える。working memory のようなものが AI は人間より圧倒的に大きいし、ロードのスピードが速い。ややこしい問題を考える能力は AI の方が圧倒的に高い。

一方で、AI は課題の建て方が上手くない。放っておくと価値のない課題をどこまでも追求するループに入って行きがちで、より価値の高い問いはこっちだ、という知見を自ら発見する事は少ないように見える。特に AI は見ているコンテキストに引きずられがちで、前提として見えていない情報から重要なファクターを拾って来るような動きはほとんど出来ていないように見える。

AI が数学の未解決問題を解くようなすごい成果を出せるのは、その AI に指示を出した人間にその問題の重要性が見えていた場合に限られて、AI が自らこの問題が重要であるという事を主張できるケースは稀であるように見える


Yoshiya@kt3k・Sep 25, 2026

リバースエンジニアリングに関していうと、OSS のリバースエンジニアリングが簡単になっていて、Bun の Rust port が一時期物議を醸していたけど、あういうソースコードがあるものの仕様を agent に解析させて、そこから作り直すみたいな事は本当に簡単に出来るし、これから当たり前になっていく可能性がありそう

agent にコードを読ませて仕様を抜き出させるとかなり正確なものが出せて、それを別の agent に食わせて実装を生成させれば、oneshot でめちゃくちゃ正確なものが出来たりする。OSS でちょっと気に入らない部分があったりしたら、PR 投げて修正してもらうよりも、SPEC.md を抜き取って、気に入らない部分を修正してから実装を生成した方が圧倒的に速い。

再生成する際に、使わない機能を SPEC.md 段階で落としてしまえば、オリジナルよりもむしろ性能が良いものが出てきたりするだろうし、OSS はそのまま使うより再実装してから使う方が best practice になる可能性すらありそう。自前再実装して仕舞えば supply chain 攻撃を受ける可能性も減るので、セキュリティ面でもそっちの方が良い。


Yoshiya@kt3k・Sep 25, 2026

要素技術に対する微視的な興味が格段に落ちた一方で、hyperframes みたいな事が出来るようになったり、リバースエンジニアリングみたいな事が簡単に出来るようになっていたり、今まで一部の専門家しかやっていなかった事が誰でも簡単に出来るようになっていたりして、エンジニアリングの主戦場が、全く違う場所に移った感がある


Yoshiya@kt3k・Sep 25, 2026

みんながもはやソースコードを手で書かないので、言語に対する不満も出て来にくいみたいな状況になりつつある気がする。文句が出得るとすれば「書きにくい」よりも圧倒的に「理解しにくい」事に対する不満の方が多くなって来そう。

理解できる事が、言語にとって一番大事なことで、尚且つもうコードを手で書かないので、人間が新しい言語を習得する事が困難になってくるとすると、もう今ある言語以外が大きく流行る余地は限りなく少ないかもしれない


Yoshiya@kt3k・Sep 25, 2026

This week in react (newsletter) の人が、もう React は死んだみたいなポストをするようになってしまったぐらい、もはや誰も React を書いてる人がいない状態・React の細かい話に興味がある人がいない状態で、個別のライブラリとか、言語とか、処理系とかがもはや割とどうでも良いと思われ始めている感じがある。


Yoshiya@kt3k・Sep 25, 2026

大上段に振りかぶったような OSS が毎日のように出てきては 10スターぐらいしかつかない(以前だったら100とか1000とか言ったレベルでも)のが当たり前になってきて、本当に世の中が全く変わってしまった感じがある。


Yoshiya@kt3k・Sep 16, 2026

プログラミング言語の役割がソフトウェアを作るためのものから、ソフトウェアについての精密な議論をAIとするためのものにシフトした感じがする。



Yoshiya@kt3k・Aug 27, 2026

千夜一夜あるある 「処刑する!」 「待って。こんな面白い話あるよ!」 「どれ、話してみなさい。」 「実は・・・」 「おもろいやん!OK 処刑無し!」

このパターン多い


Yoshiya@kt3k・Aug 18, 2026

千夜一夜物語、バグダッドの軽子と3人の女の話がやっと終わった。長かった。軽子が途中から何も言わずに居なくなってて草。

最後大団円風に終わってるけど、よく考えると全然大団円じゃなくて次の問題の始まりになってる。


Yoshiya@kt3k・Aug 15, 2026

もうコードは自分では書かないという前提で見ると ecma262 とか tc39 もちょっと違った見え方で見えてくる。

自分が書かないという以上に、自分以外の作業者もコードを自分では書かないという前提だと、言語の syntax がどうであるという情報の意味合いが結構軽くなってくるように思える。

代替手段が全くないレベルの大きな機能であればともかく、ちょっとした syntax の差分程度の新機能だと、あまり知っている必要がないという立場を取られても仕方がない。


Yoshiya@kt3k・Aug 15, 2026

claude, gcloud コマンドの、多分ドキュメントされていないだろう挙動についても細かく知っているのってなんでだろう・・・


Yoshiya@kt3k・Aug 7, 2026

千夜一夜物語、バグダッドの配達屋と3人の女の話、なかなか story in story 始まらないなと思いながら読んでてたら45ページ進んだところでやっと最初の story in story 始まった。こんなパターンもあるのか



Yoshiya@kt3k・Aug 5, 2026

千夜一夜物語、漁師と魔神の物語まで読んだ。個々の話はシンプルなお伽話という感じだけど、お伽話の中に別のお伽話が入れ子状になっている(今のところ最大で4重入れ子の話があった)ことで話の構造が非常に複雑で理解が追いつかないぐらい入り組んでいるところが面白い。