#ターミナル

端末を「本物の shell の代用品」ではなく、画面の変化そのものを予測する世界として学習させた実験が出てきた。しかも裏ではシェルもファイルシステムも動いていないのに、ファイル作成、vim、tmux、snake までそれらしく振る舞うという。見た目の派手さだけのデモではなく、どこまで一貫した状態を保てるのか、そしてその弱点をどう埋めたのかが面白い。LLM の次の使い方を考えるうえでも、かなり示唆のある内容だと思う。 筆者の Simon Edwardsson は、360M パラメータの言語モデルを微調整して、ターミナルそのものを演じさせた。ベースにしたのは Qwen2.5-Coder-0.5B で、そこに real terminal の操作記録を学習させている。重要なのは、実際の shell や filesystem は背後に一切ないことだ。毎回のキー入力を入れると、モデルが「画面がどう変わるか」を予測する。つまり text を継ぎ足していく普通の LLM ではなく、画面上の行をどう書き換えるかを出力する仕組みになっている。 この設計にした理由はわかりやすい。terminal は pix

読んでまず思ったのは、ここまでやるのか、という驚きでした。単に「Enter を自動送信する」だけなら雑に見えてしまいそうなのに、この記事はむしろ逆で、誤爆しないことにかなり神経を使っている。その慎重さが面白かったです。 特に引っかかったのは、AppleScript で画面を見に行く方法が、思った以上に壊れやすいことです。launchd から起動すると TCC まわりで静かに固まるとか、tabs を素直に回しても欲しい値が取れないとか、普段「自動化」と聞いたときに想像するよりずっと面倒くさい。macOS の権限周りって、失敗したときに派手に怒ってくれるとは限らなくて、黙って止まるのがいちばん厄介なんだなと改めて思いました。 もう一つ印象に残ったのは、この記事が「押せばいい」で済ませず、カーソルが本当に Allow 側にあるかまで確認しているところです。人間なら目で見て判断している部分を、雑に置き換えると危ない。自動化って便利そうに見えて、実際には「何を信用していいか」をかなり細かく設計しないと事故るんだな、と感じました。地味ですが、その地味さこそが実装の本体なのだと思います。 --- >

プログラミングの世界では、大きな設計力や深い理論だけでなく、ちょっとした「知っていると得をする技」が仕事の速度を決めることがあります。今回の文章は、その小さな知識の価値をあらためて見直した短いエッセイです。派手な新技術の話ではなく、ターミナル、SQL、git、正規表現、Node.js といった日常の道具をどう使いこなすかに焦点を当てています。読み終えると、経験の差はコード量だけでなく、こういう断片的な知識の蓄積にも表れるのだと分かります。 著者の主張はかなり明快です。日々のエンジニアリングの生産性は、巨大な知識体系というより、細かい「知っているだけで助かる」断片の積み重ねから生まれる、というのです。たとえば言語の機能が存在することを知っているだけで作業は楽になりますし、説明のつかない TCP の遅延があったときに、それが TCP_NO_DELAY の設定や Nagle’s algorithm と関係していそうだと見当がつくだけでも、切り分けはずっと早くなります。git で詰まったときに抜け出すための定番コマンドや、sed でファイルを書き換える小技も同じ扱いです。 そのうえで著者は、特