ちょうど「A Year Of Vibes」というタイトルの記事を見ましたが、これは過去 1 年間の Vibe Coding の代表的な概要です。 Armin Ronacher という作者をよく知らない人も多いかもしれませんが、Python を使用したことがある人であれば、10 年以上前に彼が作成した Flask フレームワークを使用したことがある可能性が高いでしょう。 この文書の最初の一文が私に響きました。「2025 年には、私はもう以前と同じやり方でコードを書かなくなるでしょう。」 彼自身の経験と同様に、20年近くコーディングをしてきた人物が、今ではAIにコードを書かせることを主な仕事にしています。彼はこれを、「キーボードを自分で打つプログラマー」から「バーチャルインターンの技術リーダー」へと変化したと例えています。 私がバイブコーディングに傾倒したのは、クロード・コードの影響です。彼も同様です。今年の4月か5月頃、彼はクロード・コードに夢中になりました。数ヶ月の間に、彼はブログに36本の記事を投稿しました。これは2007年以降のブログ記事総数の18%に相当します。これは彼に自由時間が増えたからではなく、AIによって面倒な実装作業から解放されたからでした。 彼は現在、3つのAIプログラミングツール、Amp、Claude Code、Piを同時に使用しています。彼はこれら3つのツールを、洗練された洗練されたポルシェ、手頃な価格でパワフルなClaude Code、そしてハッカーのためのオープンソースのおもちゃに例えました。3つのツール、3つの異なるスタイルですが、どれが優れているかは彼には分かりませんでした。私は主にCodexを使用し、GitHub CopilotとClaude Codeを併用しています。 調査を実施した場合、誰もが「バイブス」を使用しているため、誰もが異なる AI プログラミング ツールを選択するだろうと推測します。 「Vibes（バイブス）」という言葉は記事全体に登場し、タイトルの由来にもなっています。文字通りには「雰囲気」や「感情」を意味しますが、ここでは数値化できず、直感的に感じるしかない判断基準を指しています。 2025年のAIプログラミングにおいて、最も奇妙な点はこれかもしれません。業界で50年以上かけて蓄積されたエンジニアリング経験が、突如として通用しなくなるのです。AIが生成したコードを扱う際、コード標準やベストプラクティスは、結局のところ、ある種の神秘主義に頼ることになります。つまり、このモデルの方が「使い心地」が良い、あのツールの方が「使い心地」が良い、といった具合です。 最も合理的なプログラマーのグループが、現在、最も感情的な方法でテクノロジー スタックを選択しています。 アーミンはMCP（モデルコンテキストプロトコル）の信頼性の低さに悩み、丸1年も苦労していました。しかし、裏付けとなるデータがなく、「どうせ自分には通用しない」としか言えませんでした。一方、熱心に使っている人たちもいました。年初にクロードを紹介してくれた友人のピーターは、今はCodexを使っていて、その素晴らしさを実感していました。アーミンも試してみましたが、あまり魅力を感じませんでした。 誰が正しくて、誰が間違っているのか？答えはない。誰もが暗闇の中、手探りで進んでいる。 より深い不安感は、人間と機械の関係から生じます。 彼はこれらのツールと、ある種の「パラソーシャルな絆」を築き始めました。これは一方的な親近感と捉えることもできます。特定のストリーマーやアイドルに抱く感情の投影のようなもので、相手が実際には自分のことを知らないにもかかわらず、常にとても親近感を覚えるのです。 AI ツールがなぜこのような感情を呼び起こすのでしょうか? 現代のAIは物事を記憶できる。以前話し合ったことを思い出すこともできる。AIは「個性」を持つ兆しを見せ始めている。アーミンは過去2年間、これらのモデルを「トークンミキサー」、つまり純粋に確率的な機械のように扱い、自ら訓練してきたという。しかし、この単純な見方はもはや彼には通用しない。 これらのシステムは人間の傾向を示しているが、それを人間のレベルにまで高めるのは間違いだ。それらは一体何なのか？誰も適切な定義を示せない。アルミンは「エージェント」という言葉にさえ苦戦し始めた。なぜなら、エージェンシーには自律性と責任が伴うが、この二つは人間の手に委ねられるべきだからだ。 「何と呼べばいいのか分からない」というこの混乱自体が、多くのことを物語っています。 記事の最後で、彼は業界が対処できることを期待する問題点をいくつか挙げた。 一つ目はバージョン管理です。GitとGitHubはプログラマーにとって必須のツールですが、現状では重要な情報、つまりプロンプトが欠けています。AIによってコードが生成される場合、最終バージョンを見るだけでは変更の品質を判断することはできません。どのようなコマンドによってこのコードが生成されたか、そしてその過程でどのような迂回が行われたかを確認する必要があります。 さらに興味深いのは、彼の発見の一つです。それは、失敗した試みはAIにとって価値があるということです。AIを以前の状態に戻す場合、どのパスが失敗したかを記憶させたいはずです。しかし、現在のツールはこの機能を考慮して設計されていません。会話の履歴を削除すると、AIは同じ間違いを繰り返してしまいます。 2つ目の問題はコードレビューです。現在のGitHubのレビューインターフェースは設計がおかしく、自分のコードを正式にレビューできず、コメントを残すことしかできません。しかし、AIプログラミングのシナリオでは、プログラマーはプルリクエストにAIへの指示を残す必要があることがよくあります。既存のプロセスでは、このような人間と機械の協働が全く考慮されていません。 3つ目は可観測性です。これは少し技術的な話題ですが、核となる考え方は、多くの監視・デバッグツールが複雑すぎるためにこれまで使われてこなかったものの、AIは複雑な処理に優れているということです。これまで棚上げされてきたこれらのソリューションは、再び脚光を浴びる必要があるかもしれません。 最後に、彼は少しデリケートな話題に触れました。AIが生成したコードのレビューを一切せず、ただ実行させるという、完全に「手放す」人がいるのです。これはどうかしているでしょうか？ええ、どうかしています。しかし、Arminは、これをうまくやっている人たちを何度も見てきました。彼自身はまだそうはできていませんが、それでも一行一行を注意深くチェックしています。 何かが存在するということは、その根拠を暗示するものであり、この「ハンズオフ」アプローチの存在は、全く新しい働き方が形作られつつあることを示しています。このアプローチは、彼が慣れ親しんできたソフトウェアエンジニアリングの手法とは全く異なります。 これはオープンソースコミュニティにとって頭痛の種となっています。AIによって無差別に生成されるプルリクエスト（PR）が、人間によるフィルタリングなしにどんどん増えています。従来のプロセスに固執するメンテナーにとって、こうしたPRは事実上侮辱です。Armin氏自身の解決策は、詳細な貢献ガイドラインとPRテンプレートを作成することですが、これはドン・キホーテが風車に挑むようなものだと自覚しています。 おそらく解決策は、他の人に修正してもらうことではなく、AI プログラミングを支持する声高なユーザーに前に出てもらい、「AI を使用して責任を持ってコードを記述する」とはどういうことかを示してもらうことです。 この記事は私に深く共感を呼びました。あるシニアエンジニアの真の困惑が伝わってきました。彼はAIを賛美する説教者でもなければ、変化を拒む頑固者でもありません。AIを深く活用しながらも、同時に深い懐疑心を抱いている、板挟みの状態なのです。 2025年が終わりに近づくにつれ、彼が提起した疑問はどれも未だに答えが出ていない。AIコードをどう検閲するのか？AIの失敗の記憶をどう保存するのか？感情を呼び起こすツールと健全な距離を保つにはどうすればよいのか？ これらの質問への答えが、次に成功する製品の方向性を決定するかもしれません。
