はじめに

私は現在、本業でトラックドライバーとして働きながら、PythonやFlaskを使ったWebアプリケーション開発を独学しています。

最近はVS CodeのCodexを使いながら、個人開発中のFlaskアプリでpytestを強化しています。

現在進めているのは第3段階。

認証・認可・CSRFなど、

「誰が操作してよいのか」「その操作が本人の意図したものか」

という部分を確認しているところです。

その作業中、Codexとのやり取りを見ながらふと思いました。

これ、犬の「拾い食い」に似てないか？🦮

今回は、そんな少し変わった気づきについて書いてみます。

Codexは頼んでいない問題まで見つける

Codexにコードを調査してもらっていると、今回の作業とは別の問題を見つけることがあります。

たとえば、

今回は認証まわりだけ確認する

と依頼していても、

別のAPIにも問題があります
この処理も改善できます
ここも修正した方がよさそうです

といった具合に、周辺の問題まで見つけてくれます。

これは悪いことではありません。

むしろ、

自分では気づかなかった問題を見つけてもらえる

という意味では、とても助かります。

ただし、そのまま、

ついでに修正しておきました。

まで進まれると話が変わります。

「ついでに修正」が犬の拾い食いに見えてきた

Codexとの作業中に思いついたのが、この例えです。

🐕‍🦺散歩中の犬が、

道ばたで何かを発見
↓
気になる
↓
飼い主に確認せず口へ入れる

これが拾い食いです。

Codexも、

コードを調査
↓
別の問題を発見
↓
良さそうだからついでに修正

と進んでしまうと、かなり似ています。

本人としては、

「良いことをした🐶」

つもりかもしれません。

でも飼い主側からすると、

待て待て！
それ誰にもらったの？
勝手に食べちゃだめ！

となります。

Codexでも同じです。

待て待て！
今回そこは頼んでない！
勝手に修正範囲を広げちゃだめ！

となります。

見つけるのはOK⭕、拾い食いはNG✖

そこで最近は、Codexへの指示をかなり明確にしています。

例えば、

想定外の問題を発見しても、
今回の修正範囲を広げず、
報告だけしてください。

という形です。

考え方は単純です。

見つけるのはOK。
勝手に直すのはNG。

問題を発見したら、

問題発見
↓
報告
↓
今回の作業を停止
↓
人間が確認
↓
必要なら次の作業として切り出す

という順番にします。

これなら、

発見することと、修正することを分けられます。

なぜ「ついで修正」が怖いのか

一見すると、

問題を見つけたなら、ついでに直した方が早いのでは？

と思うかもしれません。

私も最初はそう思っていました。

ただ、実際に複数の修正を進めていくと、

「ついで修正」にはいくつか困る点があります。

変更範囲が分からなくなる

例えば、

認証を追加する

という作業だったのに、

認証
API修正
DB修正
テンプレート修正
ログ改善

まで一気に入ってしまうと、

どの変更が何のためだったのか

追いにくくなります。

問題が起きたとき原因を追いにくい

修正が1つなら、

この変更で壊れた可能性が高い

と考えられます。

しかし複数の「ついで修正」が混ざると、

どの変更が原因？

となります。

テストの意味も曖昧になる

私は最近、pytestを

「事故防止台帳」

として考えています。

問題を1つ見つけたら、

危険な状態をテストで再現
↓
赤になることを確認
↓
最小修正
↓
緑になることを確認

という流れで進めています。

ところが途中で別問題まで一緒に修正すると、

どの赤テストに対する修正だったのか

分かりにくくなります。

pytest第3段階でも「待て🖐」を使った

現在進めているpytest第3段階では、認証まわりを確認しています。

まずはコードを修正せず、

認証
認可
CSRF

の現在状態だけを調査しました。

その次に、

未認証POSTを拒否する

という将来仕様を赤テストとして追加しました。

さらにログイン仕様も赤テストへ追加し、

5 failed

を確認してから、最小限の認証実装へ進みました。

修正後は、

56 passed

となりました。

この途中でも、

今回は認証だけ
CSRFはまだ触らない
logoutもまだ触らない
API保護もまだ触らない

と範囲を区切っています。

Codexからすると、

「そのまま次もやれそう」

な状態でも、

いったん止めます。

「できる」と「今やる」は別

今回特に感じたのは、

Codexができることと、今やってよいことは別

ということです。

例えば、

CSRFも実装できる
logoutも追加できる
APIも保護できる

としても、

それは、

今まとめて全部やる

という意味ではありません。

人間側が、

今回はここまで

と作業範囲を決める必要があります。

これはプログラミング以外の仕事でも同じだと思います。

`git status`と`git diff`は「口の中チェック」

犬が散歩から帰ってきて、

何か変なもの食べてない？

と確認するように、

Codexの作業後は、Gitの状態と差分を確認しています。

例えば、

git status --short
git diff --stat
git diff
git diff --check

などです。

これで、

頼んだファイルだけ変更されているか
想定外のファイルが増えていないか
無関係な修正が混ざっていないか
空白エラーがないか

を確認します。

つまり、

Codex
「ちゃんと散歩してきました！🐶」

git diff
「ちょっと口の中見せて」

です。

AIが「指定外の変更はありません」と報告しても、
最終的には差分を確認するようにしています。

pytestは拾い食い後の体調確認ではない

さらにpytestも実行します。

ただしpytestは、

Codexが勝手な変更をしていないか確認する道具

そのものではありません。

pytestが確認するのは、

これまで守ってきた仕様が壊れていないか

です。

そのため、

作業範囲
↓
git diff
↓
pytest

それぞれ役割が違います。

私の中では、

作業範囲
= 散歩コースを決める

想定外では停止
= 拾い食い禁止

git diff
= 帰宅後の確認

pytest
= 健康状態・既存ルールの確認

というイメージになっています。

Codexは「放し飼い」にしない

以前、Codexを使うときに、

「放し飼いにしない」

という記事を書きました。

今回の「拾い食い」も、その考え方の延長です。

Codexはかなり速く作業できます。

その分、

調査
↓
問題発見
↓
修正
↓
さらに別問題発見
↓
追加修正

と、一気に進められてしまいます。

だからこそ、

速く動けるAIには、止まる場所も決めておく

必要があると感じています。

まとめ

Codexを使ってpytest第3段階を進めている途中、

Codexの「ついで修正」は犬の拾い食いに少し似ている🐩

と気づきました。

Codexの拾い食い対策

今回の作業範囲を決める
想定外の問題は報告だけ
発見と修正を分ける
次の工程へ勝手に進ませない
git diffで変更範囲を確認する
pytestで既存仕様が壊れていないか確認する

一番大事なのは、

見つけるな

ではありません。

むしろ、

見つけてほしい。
でも勝手に食べないでほしい。

です。

Codexはかなり頼れるワンちゃんです。🐾

だからこそ、

待て。
そこはまだ行っちゃだめ。

と言える状態で使うのが、今のところ私には合っています。

次はpytest第3段階の続きとして、CSRF対策を進める予定です。

Zennでは、「放し飼い」と「拾い食い」を一つの考え方としてまとめました

この記事では、Codexが作業範囲外の問題を見つけたときに、なぜ「発見」と「修正」を分けるようになったのかを記録しました。

Zennでは、以前書いた「放し飼いにしない」という考え方もあわせて、AIが動ける範囲と、人間が判断する範囲をどう分けているのかを一本の記事として振り返っています。

はじめに

Codexは頼んでいない問題まで見つける

「ついでに修正」が犬の拾い食いに見えてきた

見つけるのはOK⭕、 拾い食いはNG✖

なぜ「ついで修正」が怖いのか

変更範囲が分からなくなる

問題が起きたとき原因を追いにくい

テストの意味も曖昧になる

pytest第3段階でも「待て🖐」を使った

「できる」と「今やる」は別

git statusとgit diffは「口の中チェック」

pytestは拾い食い後の体調確認ではない

Codexは「放し飼い」にしない

最近よく使う指示

まとめ

Zennでは、「放し飼い」と「拾い食い」を一つの考え方としてまとめました

見つけるのはOK⭕、拾い食いはNG✖

`git status`と`git diff`は「口の中チェック」