#ソフトウェア設計

Vim と NeoVim をめぐる小さな出来事の話だが、ソフトウェアがユーザーのデータをどう扱うべきかという点では、かなり重い話でもある。元記事は、ある Mastodon 投稿を手がかりに、編集者が「このソフトは信頼できるのか」をどう判断するかを語っている。便利さや機能の多さより先に、積み上げた作業を壊さないことがどれだけ大事か、そこに目を向けさせる記事だ。しかも、単なるバグ報告では終わらず、設計思想そのものへの不信に話が広がっていく。 元記事の出発点は、コンピュータ科学者の David Chisnall が Mastodon に書いた投稿だ。彼は 2000年ごろから vim を使っていて、本を書き、博士論文を書き、何十本もの論文や 150本以上の記事も vim で書いてきたという。長年使っていると、よく使うコマンドは意識せずに手が動く。だからこそ、作業の途中で「うっかり消したものを戻せる」仕組みは、単なる機能ではなく生活の一部になる。 Chisnall が特に気に入っていたのは、persistent undo だった。これは、undo の履歴をファイルとして残し、ファイルを閉じたあと

図を作るための新しいテキスト言語「reladraw」のGitHubリポジトリが公開されている。見た目は地味だが、狙いはかなりはっきりしている。Mermaidのように文章から図を起こせる手軽さは欲しい。でも、配置をある程度こちらで決めたい場面では、MermaidやGraphvizの自動レイアウトでは足りない。そこで、その中間を埋める道具として作られている。図を手で引く面倒さに悩んだことがある人ほど、話が見えやすいはずだ。 リポジトリのREADMEによると、reladrawは「図について、どこに何を置くかを言葉で書く」ためのテキスト言語だという。作者は、draw.ioで毎回ドラッグして配置を詰めるやり方は手間が大きすぎる一方で、MermaidやGraphviz、D2のように箱と線だけを宣言してあとは自動配置に任せる方式では、頭の中にある絵をそのまま出しにくいと感じていた。そこで、見た目はきちんとコントロールしたいが、座標を一つずつ指定するのは避けたい、という欲求を満たす位置にreladrawを置いている。 READMEには、簡単な書き方の例も載っている。たとえば `node app "We

ソフトウェアは、ただ動けばいいわけではありません。自分のデータを自分で持てること、複数人で一緒に使えること、あとから形を変えられること。Ink & Switch は、そのあたりを真正面から追いかけてきた研究ラボです。今回のトップページは、創立10周年を祝うアート作品「Tenfold」を前面に出しつつ、同時にこの10年で彼らが何を考え、どんな研究を積み上げてきたのかをまとめて見せています。単なる周年の挨拶ではなく、ラボの思想と成果物を一度に眺められる更新だと受け取れます。 トップページの目玉は「Tenfold: Celebrating 10 Years of Ink & Switch」です。Ink & Switch は今年で10年を迎え、その節目を記念して、友人たちの協力も得ながらインタラクティブなアート作品を作った、と説明しています。画面はクリックやドラッグで触れるようになっていて、単に見るだけではなく遊べる作りです。作品名の Tenfold は「ten letters, ten years」という言葉遊びでもあります。しかも、これは見た目だけの記念品ではなく、自分たちの研究から生まれ

AIにコードを書かせる開発は、速い。けれど、その速さが「何を作るべきか」を見誤らせることがある。Liam Powell の記事は、Bend 2 という新しい言語を題材に、その危うさをかなり具体的に示している。面白いのは、彼が単に Bend をこき下ろして終わらせていない点だ。むしろ、AIで開発を進めるときに起きやすいズレを、別の言語と実例を使って説明している。 元記事が取り上げているのは、Bend 2 が「AI coding era」のための言語として打ち出されている、という話だ。人間は「laws」と呼ばれる仕様や制約を書く。AI は実装と proof を書く。コンパイラは、その proof が正しいかを検証する。見た目にはかなり野心的で、筆者も「そういうことをしたい人がいるのは分かる」と認めている。 ただし、彼の主張は Bend そのものの思想批判ではない。問題にしているのは、Bend が vibe-coding の罠にはまっているのではないか、という点だ。vibe-coding とは、十分に調べたり設計を詰めたりする前に、LLM を使って勢いよく実装を進めてしまうやり方を指している

いちばん面白かったのは、Warp が改善を「モデルの頭の中」や「雑なメモ」に寄せず、ちゃんと PR と review の流れに乗る形へ落としている点だった。AI の出力が少しずつ良くなる、という話自体はよく聞くけれど、実際にそれを“人間が普段やっている開発の回路”の中に埋め込むと、こんなに筋が通るのかと思った。 特に引っかかったのは、フィードバックが session の終わりと一緒に消えてしまう、という指摘だ。これは地味だけれどかなり本質的だと思う。普通のチャットだと、良い指摘があっても次回に自然には引き継がれない。そこで skills という file-based な単位に知識を残し、改善担当の agent が後からそれを読んで小さく直す。つまり「覚えておく」のではなく、「直すべき文書を直す」。この考え方は、AI を魔法っぽく扱わず、むしろソフトウェアの変更管理に寄せている感じがして好感があった。 もう一つ、地味に効いていると思ったのは「rules ではなく principles を書け」という話。AI に細かい禁止事項を並べるより、なぜそうするのかまで含めて書くほうが、たしかに汎用

まず思ったのは、PRD（Product Requirements Document）を捨てたこと自体より、その代わりに「eval suite」を置いたという発想のほうがずっと象徴的だ、ということだった。PRDは人間向けの説明書だけれど、eval suite はモデルや機能を実際に測るためのものだ。AI の会社では、きれいに要件を書き下ろすより、まずどう動くかを定義して測れる形にするほうが、たしかに筋がいいのかもしれない。 ここで面白いのは、これは単なるドキュメント文化の話ではない点だと思う。Anthropic が coding を戦略的優先事項にした、という話も同じ文脈にある。AI のプロダクトは、見た目の機能一覧よりも、どの場面でどれだけ役に立つかが本体になる。そうなると、PRDで「こういう機能を作ります」と書くより、評価用の問題を並べて、期待値を継続的に確かめるほうが、現実に近い。人間の会議で合意したつもりでも、モデルは平気で外してくるからだ。 ただ、少し引っかかるのは、これがすべてのチームにそのまま当てはまる話ではないことだ。eval は強いが、何を測るかを決めるのがそもそも難し