AIに機能追加を頼んだら、変更は14ファイル、追加439行になりました。便利です。でも、説明だけ読んでOKを出すには大きい。
どのファイルから読むか。呼び出し元はどこか。設計資料やテストと食い違っていないか。ここが毎回ばらばらだと、AIが速くても自分は速くなりません。
私はWindows上のWezTermからWSL2へ入り、Linux側のリポジトリでCodexを動かしています。変更を受け取った後は、zかYaziで場所を決め、rgで手掛かりを探し、Neovimで関係をたどり、Gitとテストで確かめます。全部を毎回使うのではなく、迷った場所で道具を切り替える流れです。
まず、プロジェクトへ入る
場所を覚えている時はzoxideのzを使います。
z example-app
cd ~/projects/example-appを毎回書かなくてよいので、よく触るリポジトリほど速くなります。
場所を忘れた時、または周辺のフォルダを見ながら選びたい時はYaziを開きます。
y
私のyは、Yaziを閉じたディレクトリへシェルも移動するラッパーです。Yaziで選んだ後にnvim .やgit statusを続けて実行できます。
ファイル名と中身の検索を分ける
ファイル名がうろ覚えなら、まず候補だけを出してfzfで絞ります。
rg --files | fzf
選んだファイルをそのまま開くなら、次のようにしています。
selected_file="$(rg --files | fzf)"
[ -n "$selected_file" ] && nvim "$selected_file"
関数名、画面文言、エラーなど、内容から探す時はrgです。
rg -n -C 2 "検索語"
rg -l "検索語" | fzf
前者は周辺を読むため、後者は候補ファイルを選ぶために使います。rgのオプションや、調査を進める順番そのものは、以前書いたAIに任せると調査能力が落ちる気がする。だから調査の型を整えるにまとめました。
Yaziの中では、sがファイル名検索、Sがripgrepによる内容検索です。ターミナルに戻らず、ディレクトリの雰囲気を見ながら探したい時はこちらを使います。
14ファイルの変更を、手掛かりから絞った
実例は、作成中のPython製FX研究アプリです。外部サービスの利用条件を記録し、期限切れや未確認項目があれば処理を止める機能をCodexに作成してもらいました。売買ロジックや認証情報を扱う変更ではありません。
最初に差分の大きさを見ます。
git status --short
git show --stat --oneline HEAD
この変更は14ファイル、439行追加、12行削除でした。実装だけでなく、テスト、設定ファイル、設計資料、Makefileまで変わっています。上から全部読むのはつらいので、機能名を手掛かりにrgをかけました。
rg -n "validate_manifest|external-dependency-check" \
src tests scripts docs Makefile
これで実装本体、CLIの入口、Makefile、4件の単体テスト、関連する設計資料まで絞れました。まず実装を読み、次にテストを見る。必要になった時だけ設計資料を開きます。
履歴も同じ名前で追えます。
git log --oneline -- \
src/fx_capitalism/operations/external_dependency_check.py \
tests/unit/test_external_dependency_check.py
今回は実装とテストが同じコミットで追加されていました。git blameで古い判断を探し回る必要はありません。変更の背景は同じコミット内の設計資料と照合すればよい、と判断できました。
Neovimで関係をたどって、小さく直す
候補のファイルが決まったらNeovimで読みます。ここからは文字列ではなく、コードの関係を追う段階です。
gd：定義へ移動するgr：参照箇所を探す-：Oilで現在のファイルの親ディレクトリを開く<leader>fy：Yaziを開く
今回ならvalidate_manifestにカーソルを置き、grでCLIとテストからの呼び出しを確認しました。実装を読んだだけでは、期限切れ、未確認項目、採用済み候補がゼロの場合まで止められるか判断できません。参照先のテストを見て、境界条件が4件あることを確認しました。
Oilは、いま見ているファイルの近くで名前変更や移動をしたい時に使います。Yaziはプロジェクト全体を見て探したい時です。両方があるからこそ、ファイル操作のために作業の流れが切れにくくなりました。
最後は差分とテストで確認する
AIの説明だけで正しいとは判断しません。まずGit差分を見ます。
git status
git diff --stat
git diff
その後、対象プロジェクトに合わせてテストや静的チェックを実行します。今回の変更では、対象テストだけを先に回しました。
uv run pytest tests/unit/test_external_dependency_check.py -q
結果は4件成功、0.28秒でした。ここで初めて、読んだ実装とテスト結果がつながります。問題があれば全体テストへ進む前に戻れるので、確認のラリーも短くできます。
言語が違えば、使うコマンドも変わります。
dotnet test
pnpm test
uv run pytest
go test ./...
すべてを同じリポジトリで実行するわけではありません。AIが変えた言語とプロジェクトに合う確認を選びます。差分を画面で追いたい時はlazygitを開きます。
まだ一つ、古い導線が残っている
Ctrl+Gには、fzfでGitリポジトリを選ぶ自作関数を割り当てています。ただし、この関数は~/devを検索するままで、今のリポジトリは主に~/projectsにあります。
つまり、導入したツールが全部きれいにつながっているわけではありません。このショートカットは現状のままでは使いづらい。次に直す場所として残っています。
AIがコードを量産するなら、自分はそのコードを読んで、必要なら一行だけ直し、テストで確かめる側に回りたい。zで移動して、rgで探して、Neovimでたどる。マニュアル車のように少し手間はあります。でも、その手間があるからPC操作が退屈になりません。
環境全体の役割分担はAIにコードを書かせる時代に、WezTerm・WSL2・Neovimを整えた理由、Yaziの導入で詰まった点はYaziをWindowsとWSL2で使い分けたら、file.exeでつまずいた、LSPの調整はNeovimのLSPが動かない原因はプラグインではなくPATHだったへ分けました。
コメント