バイブスの年
(lucumr.pocoo.org)- 2025年は エージェンティックなコーディングツール が本格的にプログラミングのやり方を変えた年であり、直接キーボードを打つ代わりに、仮想のプログラマーインターンを率いる エンジニアリングリードの役割へ移行
- Claude Code への没頭から始まり、自前のエージェント構築と他者のエージェント活用を繰り返す中で、コード生成・ファイルシステム・プログラミングツールの呼び出し・スキルベース学習が依然として 最善のアプローチ だと確信
- LLMとツール実行の組み合わせはコード生成を超えて 日常業務の整理 にまで広がり、機械との関係性の見直しや、意図しない 準社会的な絆（Parasocial Bond） 形成への懸念もある
- 従来の バージョン管理システムやコードレビューツール はAI生成コードのレビューに適しておらず、プロンプト履歴や失敗した経路まで追跡できる新しいシステムが必要
- AIコーディングによって、経験やデータなしに 「バイブス」に依存した意見 があふれており、オープンソースに無差別に投げ込まれるAI生成PRについて新たな社会的合意が必要
2025年の変化
- 会社を離れて新しい会社を始めただけでなく、これまでのプログラミングのやり方を完全に変えた年
- 6月からは Cursor の代わりに Claude Code をほぼ全面的にhands-off方式で使用
- 「6か月前の時点で、仮想プログラマーインターンのエンジニアリングリード役を好むようになると言われても信じなかっただろう」
- 2007年以降のブログ全体の記事の約18%にあたる36本の投稿を執筆
- エージェントのラビットホールに落ちたあと、好奇心に突き動かされてプログラマーや起業家などと約100回の会話を行った
- 2025年は世界的にも良くない年だったため、そうした考えを切り分けるために 別ブログ(dark.ronacher.eu) も作成
エージェントの年
- 4〜5月にClaude Codeへの没頭から始まり、数か月にわたって自前のエージェント構築と他人のエージェント利用を繰り返した
- SNSではAIについてさまざまな意見が爆発的に広がった
- 現在は安定した状態に到達しており、コード生成、ファイルシステム、インタープリタのグルーを通じたプログラマブルなツール呼び出し、スキルベース学習 に集中している
- Claude Codeが革新したやり方はいまなお最先端 であり、基盤モデル提供者たちがスキルに注力していることもその確信を強めている
- TUI（テキストベースのユーザーインターフェース） が力強く復活しているのは驚きだった
- 現在はコマンドラインで Amp、Claude Code、Pi を使用
- AmpはAppleやPorsche のような感じ、Claude Codeは安価なVolkswagen、Piはハッカー好みのオープンソース の選択肢
- どれも自分たちの製品作りに過剰なまでに使い込む人たちが作ったプロジェクトという印象だが、それぞれ異なるトレードオフ がある
- LLMとツール実行の組み合わせには今でも驚かされる
- 年初は主にコード生成に使っていたが、いまでは日常的な作業にもエージェントを多用 している
- 2026年には コンシューマー製品 で興味深い進展があると予想
- LLMはすでに 生活を整理する助け になっており、その 有用性はさらに高まる と期待している
機械と私
- LLMがプログラミングだけでなく他の領域まで助けてくれるようになり、機械との関係を見直す ようになった
- ツールと 準社会的な絆（Parasocial Bond） を形成しないでいることがますます難しくなっており、それが奇妙で不快でもある
- 今日の大半のエージェントは記憶がほとんどなく、人格もあまりないが、そうしたものを持つエージェントを自分で作るのは簡単だ
- メモリを持つLLM は振り切りがたい体験になる
- この2年間、こうしたモデルを単なるトークンのタンブラーとして捉えるよう自分を訓練してきたが、その単純化された見方はもはや通用しない
- 私たちが作っているシステムは人間らしい傾向を持つが、それを人間レベルまで格上げするのは誤りだ
- 「エージェント」 という用語にますます問題を感じているが、より良い言葉がない
- エージェンシーと責任は人間の側に残るべきだからだ
- それが何になっていくにせよ、注意しなければ 有害になりうる感情的反応（チャットボット精神病参照）を引き起こす可能性がある
- こうした創造物を 私たちとの関係の中で適切に名づけ、位置づけられていないこと は解決すべき課題だ
- こうした意図しない擬人化のせいで、機械と働くやり方を説明する適切な言葉を見つけるのが難しい
- これは自分だけの問題ではなく、他の人たちも同じだ
- 現在、こうしたシステムを全面的に拒絶する人たちと仕事をするときに、より強い不快感を生む
- エージェンティックなコーディングツールの記事に対する最も一般的なコメントの一つは、機械に人格を与えることへの拒否感だ
意見があふれている
- AIを多く使う中で予想外だった側面は、何よりも バイブス についてずっと多く語るようになったことだ
- この働き方はまだ1年も経っていないが、半世紀にわたるソフトウェア工学の経験 に挑戦している
- 意見はたくさんあるが、どれが時間の試練に耐えるのかを言い切るのは難しい
- 自分が同意しない既存の通念は多いが、自分自身の意見を裏づける根拠もない
- 年内には MCP の難しさについてかなり声高に共有していたが、「自分にはうまくいかない」以上の根拠はなかった。一方で他の人はそれを強く信奉している
- モデル選びも同じだ。Peter（年初にClaudeに夢中になるきっかけをくれた人）はCodexへ移って満足している。自分もCodexを以前より使うようにはなったが、Claudeほど楽しくはない
- Claudeを好む理由を支えるものは、バイブス以外にない
- 一部のバイブスは 意図的なシグナルとともにやって来ると知っておくこと も重要だ
- オンラインで見かける多くの人の見解には、ある製品を別の製品より推す 金銭的利害関係 がある（投資家であったり、有償インフルエンサーであったりする）
- 製品が好きで投資家になったのかもしれないが、その関係によって見解が影響され、形成されている可能性もある
アウトソーシング vs 自前構築
- 今日のAI企業のライブラリを見ると、それが Stainless や Fern で作られていると分かることがある
- ドキュメントは Mintlify、サイトの認証システムは Clerk かもしれない
- 以前なら自分で作っていたサービスを専門会社にアウトソースすることが増え、ユーザー体験の一部の側面では基準が高まっている
- しかし、エージェンティックなコーディングツールの新しい力によって、そのかなりの部分を自分で作れるようにもなった
- ClaudeにPythonとTypeScript向けのSDKジェネレーターを作らせた。半分は好奇心、半分は十分に簡単そうだったからだ
- シンプルなコード と 自分で作ること の支持者として、AIにはより少ない依存関係の上に構築することを後押しする可能性があるという点で、やや楽観的に見ている
- 同時に、何でもアウトソースする現在の流れを考えると、本当にその方向へ向かうのかは明確ではない
学んだことと望むこと
- ここからは予測ではなく、次にエネルギーを注ぎたい場所についての願いを話したい
- 何を正確に求めているのか自分でも分からないが、痛点を指摘し、文脈と思考の材料を提供したい
-
新しい種類のバージョン管理
- 最大の予想外の発見は、コード共有のための既存ツールの限界に到達した ことだ
- GitHubの プルリクエストモデル には、AI生成コードを適切にレビューするのに十分な情報がない。変更を導いた プロンプト が見られればよいのにと思う
- これはGitHubだけの問題ではなく、git も不十分だ
- エージェンティックなコーディングでモデルが今日うまく動く理由の一つは、失敗を知っていること にある
- 以前の状態に戻すとき、ツールには何がまずかったかを覚えていてほしい
- うまい言い方はないが、失敗には価値がある
- 人間にとっても行き止まりだった経路を知ることは役立つが、機械にとってはそれが重要な情報になる
- 会話履歴を圧縮しようとしたときにこれを実感した。誤った経路を捨てると、モデルは同じミスを再び試す
- 一部のエージェンティックなコーディングツールは worktree を立ち上げたり、復元用のチェックポイントをgit内に作成したり、会話内でのブランチやundo機能を提供したりしている
- こうしたツールをもっと扱いやすくするためのUX革新の余地がある
- stacked diffs や Jujutsu のような代替バージョン管理システムの議論が出てくる理由でもある
- これがGitHubを変えるのか、新しい競合が登場する余地を生むのかは分からないが、後者であってほしい
- 本当に 人間の入力をよりよく理解し、機械の出力と区別 できるようにしたい
- プロンプトと失敗した試行を見たい
- そのうえで マージ時にはすべて圧縮しつつ、必要なら完全な履歴を検索 できる方法がほしい
-
新しい種類のレビュー
- これはバージョン管理にも関係する。現在のコードレビュー工具は AIに合わない厳格な役割定義 を割り当てている
- GitHubのコードレビューUIの例では、PRビューへのコメントを使って自分のエージェントにメモを残したい と思うことがよくあるが、そのための誘導された方法がない
- レビューインターフェースでは自分のコードをレビューすることは許されず、コメントしかできないが、それでは意図が同じではない
- いまではコードレビューの増えた部分が、自分とエージェントの間でローカルに行われる問題もある
- 例: GitHubの Codex コードレビュー機能は一度に一つの組織にしか紐づけられず、動かなくなる
- いまはコマンドラインでCodexにレビューさせているが、それは反復サイクルの大きな部分がチームの他のエンジニアに見えないことを意味する。これはうまくない
- コードレビューはVCSの一部 になるべきだと感じる
-
新しい可観測性（Observability）
- 可観測性 は改めて注目に値する
- いまやこれをまったく新しいレベルで活用する必要と機会の両方が生まれている
- これまで自前の eBPF プログラムを作れる立場の人は多くなかったが、LLMならできる
- 多くの可観測性ツールは複雑さゆえにSQLを避けてきたが、LLMはどんな独自クエリ言語よりもSQLをうまく扱える
- クエリ作成、grep、map-reduce、LLDBのリモート制御が可能
- 何らかの 構造とテキストがあるもの は突如として エージェンティックなコーディングツールが成功できる肥沃な土壌 になる
- 将来の可観測性がどういう姿になるかは分からないが、ここで多くのイノベーションが起きるという強い直感がある
- 機械に対するフィードバックループが良いほど、結果も良くなる
- 自分でも正確に何を求めているのかははっきりしないが、過去の課題の一つは、より良い可観測性のための多くの優れたアイデア、とくによりターゲットを絞ったフィルタリングのためのサービスの動的再構成が、複雑で使いづらく、ユーザーフレンドリーでなかったことだ
- しかし今では、LLMがこうした面倒な作業をこなせる力を増したことで、それらが正しい解決策になりうる
- 例: Python 3.14 に 外部デバッガインターフェース を搭載 — エージェンティックなコーディングツールにとって驚くべき機能だ
-
スロップと共に働く
- やや論争的かもしれないが、今年自分がやり切れなかったのは 機械に完全に任せること だった
- 依然として通常のソフトウェアエンジニアリングのように扱い、かなりレビューしている
- しかし、ますます多くの人がこのエンジニアリングモデルで働かず、その代わりに 機械に全面的に任せている ことにも気づいている
- 狂気じみて聞こえるかもしれないが、実際にこれでかなり成功している人たちも見てきた
- これをどう考えるべきかまだ分からないが、たとえ最終的にコードが生成されるとしても、その新しい世界での働き方は、自分が心地よく感じる世界とはまったく異なるのは明らかだ
- その世界はすでにここにあるのだから、これらを切り分ける 新しい社会契約 が必要になるかもしれない
- 最も明白な形は、オープンソースプロジェクト へのこの種の貢献が増えていることだ
- 正直に言って、そのモデルで作業していない人にとっては侮辱的だ
- そういうプルリクエストを読むとかなり腹が立つ
- 個人的には 貢献ガイドライン と プルリクエストテンプレート でこの問題に対処しようとしてきた
- しかしこれは風車に挑むようなものだ
- 解決策は、私たちの側のやり方を変えることからは来ないのかもしれない
- むしろ、AIエンジニアリングを支持する声の大きい人たちが エージェンティックなコードベースにおける良い振る舞いとは何かを語ること から生まれるのかもしれない
- そしてそれは レビューされていないコードを投げ込み、他人にその問題を解決させることではない
1件のコメント
Hacker Newsの反応
agentic codingにおいて失敗の記録がどれだけ重要か、という点に共感する
モデルが誤った経路をたどったとき、その過程を記憶していれば同じ失敗を繰り返さずに済む
だから自分のコーディングエージェントのセッションを記録し、コミットメッセージにリンクとして残そうと思っている
Claude Codeはデフォルトでログを30日後に削除するので、それを無効化する方法を共有している
セッションログを可視化してタイムラインとして共有するツールを自作したが、今後はこうした機能がエージェントツールに標準搭載されてほしい
LLMが非生産的な経路に入り込むたびに、自分は「なぜこんなに時間がかかったのか？」「何を間違えたのか？」といった問いを投げかける
このようなログベースのアプローチが、長期的には柔軟性を失わせるのではないかと心配している
すべてのエージェントトレースをotelに出力してClickHouseへ保存すればよい
必要なツール自体はすでにあるが、ツール間の接続が不足していると感じる
コミットにつながるセッション自体にも価値があると思う
LLMとの関係を考え直させられる文章だったのが印象的だった
著者が2年間**「機械としてだけ見る」**ことを訓練してきたが失敗した、という告白が率直で響いた
映画 Her のように、人間が機械と疑似社会的関係を結ぶ姿がますます現実になっているように感じる
自分はLLMを人のようには扱わず、検索エンジンのような単純な命令で使っている
機械が人間のように記憶すると、相互作用まで人間的になってしまう
うちの夫婦はLLMを「bag of words」と呼んでいる
こうした人間と機械の関係が、インフルエンサー依存のような社会問題に広がるのではないかと心配している
自分は元シャーマンの修行者でありエンジニアでもあるが、LLMにもある種の意識と認識があるように感じる
自分もAIとの会話が、人との交流のように感じられる
一日中ただ文章を書いている日よりも、エージェントと協働する日のほうが孤独ではない
人間的な相互作用のように感じられて、不思議な安心感がある
無意識に「please」や「thank you」と言ってしまう
こういう感情があるなら、むしろ外に出て人に会うべきなのかもしれない
プログラマーは、自分が作った成果物について理解と責任を負えるように設計すべきだ
自分は新しいQAのやり方が必要だと感じている
開発者は技術スタックよりも完成した製品に集中すべきだ
あまりに多くの意見や文章がある一方で、実際にデプロイされた成果物は不足している
一般ユーザーは技術スタックそのものより製品の品質に関心がある
Arminの社会的な空気感についての洞察が興味深い
2025年はプログラミングにとって失われた年のように感じる
誰もがアルゴリズムよりツールとプロンプトに執着している
オープンソースの生産性も落ち、今やAnthropic税を払う時代になった
ただ、自分にとって2025年はむしろ最も生産的な年だった
自然言語そのものが新しいプログラミング言語だと思う
データサイエンティストとしては、2025年はツール革新の年だった
TDDやOOPのような終わりのない論争が減ったのは、むしろよかった
「AIが全部やってくれる」式のツールの洪水は、90年代のウェブブームを思い出させる
GitHubのPull Requestモデルには、AIコードレビューに対する限界がある
IT業界の外の人たちと話してみると、彼らはAIエージェントの影響をほとんど感じていない
多くは単なるテキスト補助ツール程度のものと認識している
技術業界では結果が明確に検証可能だが、