これは何?
0→1のVibe Codingでとりあえず動くものを作ってみた。
これを他人に使ってもらうためにコードを理解しようと思ったのだが、想像以上に辛かった。
Parallel AI Agents Are a Game Changerという記事でも今まで長時間かけてコードを書き、短時間でレビューしていたところが、短時間で生成されたコードを長時間かけてレビューするという働き方が一般化するであろうと予想されているため、辛くてもこなせるようになっておく必要がある。
そこで、これが少しでも辛くなくなるよう、割と良さそうなフレームワーク(進め方)を考えたのでこの記事では紹介する。
フレームワークをそのまま使わなくても、なにか役に立てば幸いである。
環境
別環境でも応用できると思うが一応書いておく
- VS Code: コードを読む用
- Claude Code: Vibe Coding用
Vibe Codingで作ったものを読むのはなぜつらいのか
自分は今回Burp SuiteのExtensionsを作ったのだが、辛いと感じる理由は概ね以下のとおりだった。
- そもそも他人が作ったコードベースを一度に理解する負荷が高い
- 動くことしか確認しておらず、人間が作ったコードに比べてクオリティが低い
- いらないコードや検証中のコードが混ざっていることが多い
- テストが機能していないことがある
- BurpのExtensionsの作り方など何も知らない状態でのスタートだったので前提知識が足りていない
- 読み終わるのにどれくらい時間がかかるかわからない
まとめると、とにかく脳への負荷が高かった。
解決策
自分の感覚的にはテストがないプロジェクトに対して後から自動テストを追加する感覚に近いなと思った。
そのため、TDD(テスト駆動開発)を参考に、ステップバイステップで進められる方法を考えた。
①AIに今回の開発での学びを書いてもらい、キャッチアップが必要な情報をざっと知る
今回の場合、自分はBurp SuiteのExtensionsを作った経験がなかったので、AIが詰まったところはほぼ100%自分も知らないと予想した。
そこで、claude -r等でセッション単位でlearn.mdに学んだことを書いてもらい、これに目を通すことで自分がキャッチアップすべきものの概要を知ることができた。
②トップレベルの部分のコードを軽く見る
以下を把握することだけに集中してみる
- 処理のだいたいの流れ
- 知らないキーワードや使用しているライブラリの名前
③公式ドキュメントなどで勉強
①と②および、コードを見ながら少しインプットする
④全ファイルをさっとみてTODOコメントをつける
ぱっと見て何をやっているか予想がつかない以下の部分にTODOコメントをつける。
- ファイルやクラスのトップレベル
- メソッド単位
手動でやるほうがコードベースの理解度があがるのでAIやツールでつけるのはおすすめしない。
package com.airis.burp.ai.core;
import burp.api.montoya.logging.Logging;
import com.airis.burp.ai.config.ConfigModel;
import com.airis.burp.ai.llm.LLMClient;
import com.airis.burp.ai.llm.OpenAIClient;
/** TODO */
public class AnalysisEngine {
private final ConfigModel configModel;
private final Logging logging;
private final RequestProcessor requestProcessor;
private volatile boolean isAnalyzing = false;
public AnalysisEngine(
RequestProcessor requestProcessor, ConfigModel configModel, Logging logging) {
this.configModel = configModel;
this.logging = logging;
this.requestProcessor = requestProcessor;
}
/**
* TODO
*/
public String analyze(String request, String response) {
// Prevent concurrent analysis
if (isAnalyzing) {
return "Analysis already in progress. Please wait...";
}
try {
isAnalyzing = true;
logging.logToOutput("Starting AI analysis...");
if (!configModel.isValid()) {
return "Configuration is incomplete. Please configure API settings.";
}
// Create LLM client based on provider
LLMClient llmClient = createLLMClient(configModel.getProvider());
if (llmClient == null) {
return "Unsupported AI provider: " + configModel.getProvider();
}
// Execute analysis
HttpRequestResponse requestResponse =
requestProcessor.createAnalysisRequest(request, response);
String result = llmClient.analyze(configModel, requestResponse, configModel.getUserPrompt());
logging.logToOutput("Analysis completed successfully");
if (result == null) {
return "No analysis result returned from LLM client.";
} else {
return result;
}
} catch (Exception e) {
logging.logToError("Analysis failed: " + e.getMessage());
return "Analysis failed: " + e.getMessage();
} finally {
this.isAnalyzing = false; // Reset analyzing flag
}
}
⑤自動テストの削減と実行を試す。
大量のテストコード(質がいいかも不明)を残しておいてもしょうがないのでファイルごとに、最低限の正常系を残して消してしまう。
削減後、まずはテストが通らなくても気にせず実行してみる。
⑥TODOコメントを一つずつ概要コメントに置き換えつつコードを読む
自分はTodo TreeというExtensionsを使ってTODO管理をしている。
このように後読むべき対象がどれくらいかわかると前に進んでいることが可視化され、やる気が湧いてくる。
TODOを概要コメントに書き換えながら、検証中の不要ファイル等も段階的に消していく。
リファクタは次ステップまで行わない。
⑦段階的にリファクタリングを行う
気に入らないコードがでてきたら一気に変更せずに、TDDの要領でリファクタリングを実施する。
- テストが通ることを確認(自動テストがないなら手動テストでも可)
- 変更を実施
- テストを再実施
- gitをcommit
Vibe Codingの最大の価値は最低限動く状態のものがあることなので、これが失われない用に変更は慎重に行う。
まとめ
Vibe Codingで作った0→1のアプリのコードを読むのが辛い理由は、本フレームワークにより辛さが低減されると考えられる。
- そもそも他人が作ったコードベースを一度に理解する負荷が高い
→慣れるしかないので数をこなす。No AIタイムを作って脳を負荷に慣らす(本フレームワークの対象外) - 動くことしか確認しておらず、人間が作ったコードに比べてクオリティが低い
- いらないコードや検証中のコードが混ざっていることが多い
→先に全部消そうとせずに段階的に進める。 - テストが機能していないことがある
→最小限の機能している正常系のテスト以外は消してしまう。
- いらないコードや検証中のコードが混ざっていることが多い
- BurpのExtensionsの作り方など何も知らない状態でのスタートだったので前提知識が足りていない
→AIに開発中の学びを共有してもらい、それを読んでから勉強することでAIの経験を無駄にしない。 - 読み終わるのにどれくらい時間がかかるかわからない
→TODOをつけることによる進捗の見える化