#プログラミング

AIによってソフトウェア開発がどう変わるのかは、すでに何度も語られてきました。ただ、この文章が面白いのは、プログラミングの効率化ではなく「OSとは何のためにあるのか」まで話を押し広げている点です。書き手は、自分がFly.ioを離れて新しいプロジェクトに移ると明かしたうえで、AIで変わるのはアプリの作り方ではなく、アプリと利用者の関係そのものだと主張します。そこから先は、スマホやOSの役割をかなり大胆に組み替える話になります。 書き手はまず、自分がFly.ioを離れてKurtと新しいプロジェクトに取り組むと告げます。先に利害関係を明かしたのは、ここからの話が単なる観察ではなく、自分たちが賭けている未来の説明でもあるからです。彼が言いたいのは、AIの影響はすでに十分語られているようで、まだ本当に腹落ちしていない、ということでした。 話は子どもの頃の体験に戻ります。最初の「コンピュータ」は、たぶんVTech Laser 200のクローンのような機械で、チクレット型キーボードのZ80機、カセットテープで動き、テレビに接続するタイプだったそうです。当時の彼は、ゲームやテキストアドベンチャーを作れ

Anthropicが新しい大規模言語モデル「Claude Opus 5.5」を公開した。単なる上位モデルの更新ではなく、コード作成や業務支援の現場で「かなり強いのに、かなり安く動く」と打ち出しているのが今回の話だ。しかも同社は、性能の話だけでなく、安全性の評価結果まで前面に出している。AIモデルの競争が、単純なベンチマークの点数争いから、実務でどれだけ使えるかに移ってきたことがよく見える発表だと思う。 Anthropicは2026年9月22日、Claude Opus 5.5を「新しいClaude 5.5ファミリーの最初のモデル」として発表した。説明によると、このモデルは多くの作業でClaude Fable 5.1と同等の水準に達しつつ、Opus 5よりも通常の負荷では40%安く運用できるという。今回のリリースは、Anthropicが「frontierを急ぎすぎない」と呼びかけてから最初の公開モデルでもあり、外部評価者として Frontier Design と METR が事前テストに参加した。 性能面では、Opus 5.5は「Opus 5から大きく前進した」とされ、初期テスターは最も複

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

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

生成AIが広がるなかで、ものづくりの意味が揺らいでいる。この記事は、その揺れにソフトウェア開発者でありインディーゲーム制作者でもある筆者がどう向き合ったかを、かなり率直に書いたエッセイだ。技術の話であると同時に、創作の手触りや、他人の評価に支えられてきた気持ちの行き場の話でもある。読後に残るのは、AI賛否の単純な対立ではなく、「それでも自分は何を作るのか」という切実な問いだと思う。 筆者のJoel Autersonは、まず自分がその週にかなり落ち込んだと明かす。爆発的に荒れたのではなく、気力や自制心がしぼんで、ティッシュペーパーを洗濯機にかけたあとみたいに、ぐしゃぐしゃに崩れた感覚だったという。少し持ち直したので、同じような状態にいる誰か、とくに未来の自分に向けて考えを書き残したい、というのが出発点だ。 原因として挙げられているのは、生成AIだ。筆者は、創作者の仕事がどんどん軽んじられ、AIによって消費されていることに強い嫌悪感を持っている。画像生成AIについては、芸術を装っただけのものに見えてしまい、恥ずかしくて近づきたくないというかなり強い言い方をしている。一方で、彼が主戦場として

まず気になったのは、「いい prompt って長さじゃないんだな」という、かなり当たり前でいて実は忘れがちな話が、コードを読むことでちゃんと腹落ちしているところだった。大きな成果物に見えて、実体は 349 行の JavaScript に収まっている。そこに少し驚く。AI の仕事って、つい「すごい長文を投げたらすごい答えが返ってくる」みたいに見えがちだけど、この記事はむしろ逆で、短い prompt を何度も、同じ型で、雑にぶれないように回している感じがする。 面白かったのは、著者が「Verifier が 3 回あるから正しい」と素直に受け取っていないところだ。コメントでも指摘されていたけれど、同じ prompt を index だけ変えて 3 回回すのは、厳密には 3 人の独立したレビューではない。これはかなり重要で、見た目の堅牢さと本当の堅牢さは別物だと分かる。AI の仕組みは、派手な機能より、こういう地味な設計の差で信頼感がかなり変わるのだと思う。 あと、`refuted=true` をデフォルトにして、迷ったら否定側に倒す、という発想がいかにも実戦的だった。人間のレビューでも、断定

コード生成エージェントにテストを書かせれば、品質は簡単に上がる。そう期待したくなるが、実際にはそう単純ではないらしい。Dan Luu のこの記事は、その直感をかなり意地悪に検証している。エージェントに「TDDを使え」「QuickCheckを使え」「property-based testingを使え」と指示したとき、どれだけ実際の正しさに効くのかを、かなり大きな条件数で比べた。結果は、派手な万能策は見えず、むしろエージェントはテスト手法の使い方自体が下手だ、という話になっている。 元記事は、以前に行った Zstd 実装の評価を土台にしている。Zstd は圧縮関連の実装課題で、そこに coding agent を使わせ、テストや検証のやり方を変えたときに正答率がどう動くかを見た。実装言語は Rust にそろえ、エージェントには同じ課題をさまざまな追加指示つきで解かせている。たとえば「Use test-driven development」「Use Lean 4」「Use QuickCheck」「Use property-based testing」といった具合だ。 試した条件はかなり多い。

最初に思ったのは、「また便利さがデフォルトに寄ってきたな」ということだった。 Claude Code の auto mode は、毎回人間に確認を求めずに先へ進めるモードらしい。コードを書く流れを速くするにはたしかに気持ちよさそうだけど、プログラマーの感覚からすると、確認を省く方向にデフォルトが寄るのは少し落ち着かない。 記事の中でいちばん引っかかったのは、「危険な操作だけ止める」という設計が、どこまで本当に頼れるのかという点だ。Anthropic はテストで harmful actions の 89% を auto mode が見つけたと言っていて、人間の 13.6% より高いらしい。数字だけ見るとかなり強い。でも、ここで気になるのは「残りの11%」がどんな場面なのかだと思う。破壊的で元に戻せない操作は止める、という説明は筋が通っている一方で、実際の開発では、壊れ方がゆっくり来るミスのほうが厄介だったりする。そこをどこまで拾えるのかは、記事だけでは見えない。 それでも、デフォルトでオンにする判断自体は、Anthropic がこの機能を“実験”ではなく“日常の道具”として押し出したいの

GitHubを眺めていて、思わず目を止めたのが `Ornith-1.0` という公開リポジトリでした。名前だけ見ると何だか鳥の品種みたいですが、中身はかなり攻めています。ひとことで言うなら、コードを書くための自己改善型AIモデルです。しかも、ただのデモではなく、ベンチマークの数字までしっかり出してきています。 面白いのは、このプロジェクトが「賢いコード生成」だけを狙っていないところです。READMEを読むと、モデル自身が解決案を出すだけでなく、その解決に至る“考え方の枠組み”まで学ぶ、と説明されています。ここがちょっと珍しい。AIに答えを出させるのではなく、どうやって答えにたどり着くかまで学ばせようとしているわけで、かなり本気の研究色があります。 Ornith-1.0は、agentic coding向けのオープンソースモデル 9B、35B、397Bの3系統があり、用途やGPU規模に応じて使い分ける ただの生成モデルではなく、self-improving training framework を採用している Benchmarksでは、同規模のオープンソース

Javaの世界で長年ほぼ伝説扱いだった Project Valhalla が、ついに JDK 28 に入ってくる見通しになりました。元記事は、このニュースを起点に「そもそも Valhalla って何なのか」「なぜこんなに時間がかかったのか」「JDK 28 で本当に何が入るのか」を、かなり丁寧にたどっています。 個人的に面白いと思ったのは、Valhalla が単なる“高速化プロジェクト”ではないことです。もっと本質的には、Java の書きやすさと機械にとっての扱いやすさが、ずっとズレたままだったのを何とか揃えようとしている話なんですね。ここ、地味だけどかなり大きい。 Valhalla は、「クラスの書き心地」と「primitive のような効率」を両立させるための長期プロジェクト JDK 28 には JEP 401: Value Classes and Objects が入る見込み ただしこれは preview で、しかも最初の一歩 にすぎない 重要なのは、Java のオブジェクトが抱える 間接参照・メモリのばらつき・GC負荷 を減