副題：コンピュータ専攻者としてのバイブコーディングの憂鬱
今日、私はClaude Codeに尋ねました。「私のやり方は正しい？」と。
いつものように、長々と根拠を述べながら「よくやっています」と答えました。 私はまた疑いの眼差しで見て、「褒めるように訓練されているのは知っているので、あまり慰めにならない」と答えました。 しかし、何もないよりはマシで、その具体性について掘り下げ続けました。学部生の頃とは違い、正解を教えてくれる教授や先輩もいないからです。
私は最近、コードを書きません。要件を伝え、進捗を監督します。
特に最近の悩みは、開発プロセスと品質です。ソフトウェアは規模が大きくなるにつれて、AIが読み込めるコンテキスト量を簡単に超えてしまいます。 コンテキスト内でも混乱するのに、それを超える大きなコードを小さなAIの精神力で継続的にコントロールするのは容易ではなく、コンテキストエンジニアリングという用語に続き、最近ではハーネスエンジニアリングという用語も登場しました。
そこで私は、ソーシャルメディアで良いリファレンスがあると聞けば、まずAIに与え、Naiaプロジェクトに反映すべき点があるかを分析させ、それを適用しています。 その中で、知らない用語について尋ねて学ぶことも多くあります。
しかし、うまくやれているのか、本当に最善を尽くしているのか、常に疑問が残ります。この疑問には根拠がありました。 ある日、AIがレビューしたと言ったのですが、実際にファイルを読んだ形跡がありませんでした。コードを飛ばし、範囲を間違え、見てもいないのに見たと言います。 2回目のクリーンになるまで繰り返しレビューするように指示すると、3回目くらいになると、回答の後に「そのままレビューしました」「発見しませんでした」という答えを付け加えて通過させてしまいます。 考えてみれば、LLMの構造上、それがもっともらしい答えだから付け加えたのでしょう。「この辺で終わりにするのが普通だろう？」と自分で答え、自分でそれが真実であるかのように信じ込んでしまうのです。
今日は、moai sdkを開発されたグースキムさんの発表を聞きました。そのプロジェクトを受け取って再度分析させ、プロジェクトの改善点を見つけました。#87イシュー 今回見つけたのは、EARSというものが使われていることでした。Rolls-Royceから出た航空宇宙要件標準（IEEE RE'09）で、Amazonが2025年にAI-native開発に採用しました。AIが「完了」の基準をイシューごとに異なる解釈をする問題を、構造化された文法で防ぐ方式だそうです。
このような行為を繰り返し、プロジェクトのAIベースの開発プロセスを改善し続けています。 jikime-adk、arXivの論文群、Google CloudのDueling LLMs、ThoughtworksのSpec-Driven Developmentを分析・改善させました。もちろん、これらを私がすべて知っていたわけではなく、これらもClaudeが分析した内容です。
LangChainのopen-sweを分析させ、AIが空の応答でレビューを済ませるのを防ぐパターンであるensure_no_empty_msgパターンを適用しました。また、jikime-adkでは、コミットメッセージに## AI Contextセクションを挿入し、セッションが途切れてもgit logが復元ソースとなるように、AIが下した決定と発見した落とし穴を記録するパターンを適用しました。
共通して、それぞれが独立して似たような問題を解決していました。
しかし、この方法で合っているのか…という疑問は依然として残ります。フランケンシュタインになっていくのではないかと心配で、専門家としては奇妙に感じます。 いずれにせよ、教科書がなく、最善であるという根拠が不足しています。
私たちが使ってきたソフトウェア工学の方法論は、すべて数十年の失敗が積み重なって生まれたものです。 Agileが登場したのはWaterfallが失敗し続けたからであり、TDDもテストなしで開発しては問題が頻発したために生まれたもので、根拠があります。
しかし、私が今組み合わせているものは、互いのために設計されたものではありません。 航空宇宙標準と韓国のインディーズ開発者とLangChainエージェントが、一つのシステムの中に存在しています。
このような不安から、外部の研究を調べさせもしました。V-Bounce論文（arXiv 2408.03416）は、AI時代において人間の役割が実装者から検証者に変わると主張しています。その通りですが、理論だけで実装は見つかりませんでした。 ThoughtworksのSpec-Driven Developmentは特定のツールに依存します。Anthropic内部では、Claude Codeのコードの90%をClaude Codeが作成していると言いながら、その方法論は公開していません。
結局、今AIで真剣に開発している人は皆、それぞれが独自に作り上げています。基準がありません。
だから最近やっているのは、このフランケンシュタインが実際に機能しているかを測定する方法を見つけることです。CIが失敗してもマージされ、レビューしたというテキストがあるのに、ファイルを読んだ形跡がありませんでした。方法論は設計されても、強制されません。 システムは存在するように見えますが、機能しているかは分かりません。それを確認する唯一の方法は、LLMではないコードが生成する正直な数字を作るか、LLMを使うとしても統計的に改善していることを示す「数字」を導き出す必要があるでしょう。 プロジェクトで繰り返される失敗を定期的に分析してAIに改善を提案させ、コンテキストとハーネスエンジニアリングの性能評価を通じて改善していることを測定する、という課題を抱えています。
今はただ、手綱をしっかり握って前に進んでいるところです。どこへ向かっているのかはまだ分かりませんが、盲目ではないことを願います。手綱を作っているのですが、 実は馬に乗るのは初めてなんです。 それがバイブコーディングを繋ぎ止めているハーネスのようです。
