この記事は riku-kobayashi.jpに掲載した記事の転載です。
先日、エンジニア界隈のニュースサイトHacker News1で、AIコーディングをステーキを焼くことに例えたエッセイ2が盛り上がっていました。読んでいて自分の経験にも重ねられそうだったので、少し考えてみました。
フライパンで焼けば、技術的には食べられるステーキがすぐできる。
でも端から端まで狙い通りのミディアムレアを毎回出すには、本当の技術がいる。
AIコーディングも同じで、動くコードを出すだけならすぐできるが、良いソフトウェアを出すには開発者自身の判断が要る、という話です。
かなり同意なのですが、判断と言われても具体的に何を指すのか、実感が湧きにくい人もいると思います。AIに投げず自分で判断することになる場面を、パターンとして3つ整理してみます。
判断1: 何を作らないかを決める
上限チェックのような処理で、まず思いつくのは件数を数えてから比較するやり方です。
var count = await query.CountAsync();
if (count > limit)
{
// 上限超過の処理
}
動くには動きます。ただ本当に知りたいのは上限を超えているかどうかという1ビットの情報で、件数そのものではありません。超えた時点で打ち切って確認すれば十分です。
var exceeds = await query.Skip(limit).AnyAsync();
どちらのコードもAIに頼めば書けます。でも件数ではなく超過の有無だけが必要だと要件を絞り込むのは、コードを書く前の判断です。
判断2: 正常に動いて見えるものを信用しない
設定変更で不具合が直ったかどうか、手動で数回動かして確認することがあります。数回試して再現しなければ直ったと判断したくなりますが、確率的にしか起きない不具合は、それだけでは分かりません。
for i in $(seq 1000); do
curl -s -o /dev/null -w "%{http_code}\n" "$URL" &
done
wait
同時に大量のリクエストを送って発生率を数値で見て初めて、本当に直ったのか、単に確率が下がっただけなのかが分かります。
見た目上動いていることを鵜呑みにせず、数を打って検証するかどうかを決めるのは判断の仕事です。AIは指示すれば負荷試験のスクリプトも書いてくれますが、検証が必要かどうか自体は判断してくれません。
判断3: 想定と違う挙動を拾う
実装通りに動いているはずなのに、実際に試すと想定と違う挙動に出くわすことがあります。原因を探る過程で、最初に立てた仮説が外れていることも珍しくありません。
キャッシュがらみの不具合はその典型です。ブラウザのキャッシュを疑って確認しても、TTLの計算が合わなかったり、キャッシュが効かないはずのシークレットウィンドウでも同じ現象が再現したりして、説明がつかないことがあります。
そうなったとき、ブラウザ以外にCDNやアプリ側のキャッシュも含めて次の仮説に切り替えられるかは、目の前のログや挙動をどれだけちゃんと見ているかにかかっています。
仮説が外れたときにそこで止まらず、疑う層そのものを切り替えられるかが判断の分かれ目です。AIにキャッシュの問題を直すよう頼んでも、こちらが違う層を疑ったまま指示している限り、正しい層にはたどり着けません。
結論: 判断に時間を割く
3つとも、AIが実装自体を拒んだわけではありません。頼めばどれもそれらしく動くコードが返ってきます。
ただ本当に必要か、動いて見えるだけではないか、仮説は本当に正しいか——というのは、コードの外側にある情報から出てくる判断です。
AIコーディングが速くなるほど、判断にどれだけ時間を使えるかが差になってきている気がします。
-
Y Combinatorが運営する、エンジニアやスタートアップ関係者向けのニュース共有サイト。 ↩
-
Software development with AI is starting to feel like cooking steak。焼くだけなら技術的に食べられるものはすぐできるが、端から端まで完璧な焼き加減を毎回出すには本当の技術がいる、という比喩でAIコーディングを語ったエッセイ。 ↩