AIに判断させる前に、事実を取り出す
最近、AIが書いたコードをどう理解するかについて、何本か記事を書いた。
AIは日常的にかなり使っている。設計について相談したり、コードをレビューしてもらったり、知らないことを調べてもらったりしている。 一方で、少し前から、AIに頼りすぎているんじゃないかという感覚もあった。要件を伝えて、設計してもらって、実装してもらって、レビューまでしてもらう。便利ではあるけれど、全部をそのまま渡していると、自分がどこで考えたのかが分からなくなる。それで最近は、少し使い方を変えている。
こういう考え方の種は、以前からあったのかもしれない。障害調査では、想像で数値を埋めず、まずログやメトリクスから事実を取ることを大事にしていた。 そのあと、Rustの勉強をきっかけに、調査で使う小さなツール群を作った。 ログの発生数を数えたり、時間で切り出したり、2つの時系列が近い時間に発生しているかを調べたり、複数の時系列を同じ時間軸に並べたりする。 作っていて気づいたのは、これらのツールは原因を判断してくれないということだった。「CPUが上がったからエラーが増えた」とは言わない。ただ、いつ何が起きたのかを数えたり、揃えたり、並べたりする。事実を見やすくするだけだ。
そのあと、コードレビューでも似たようなことを考えるようになった。 大きなdiffをAIに渡して「重要なところを教えて」と聞くことはできる。でも、その前に、変更されたシンボルは何か、参照箇所はいくつあるか、分岐がどれくらい増えているか、といったことは機械的に調べられる。 そこで、git diffからそういう情報だけを取り出す小さなツールを作り始めた。ここでも、ツールには「この変更は危険だ」と判断させないことにした。どこから読むかを決めるための材料だけを出す。 前の記事では、これを signals → prioritize → interrogate と書いた。コードレビューのために考えた流れだったけれど、もう少し広く捉えると、自分のAIの使い方にも同じことが言えそうだった。 大事なのは、どこまでが観測された事実で、どこからが解釈なのかを見失わないことだと思う。
AIは、曖昧な情報から意味を考えたり、複数の可能性を出したりするのが得意だ。でも、何件あったのか、どこが変わったのか、どのシンボルが参照されているのか、といったことまで推論してもらう必要はない。 機械的に取れるものは、小さなプログラムで取り出せばいい。もちろん、そこで取れる事実も完全ではない。実際、参照数が名前の一致を拾いすぎたり、変更していない関数を変更箇所として扱ってしまったこともあった。だから、出てきたものをそのまま正解とはせず、必要なら元のコードやログに戻って確かめる。 全部を自動化したいわけではない。人間が判断するために必要な事実を、できるだけ安く取り出したい。その面倒なところを小さなツールに任せる。AIには、その先を一緒に考えてもらう。
Rustの勉強をきっかけに始めた小さなツール作りだったけれど、思っていたより広い話になった。 AI時代にどういう技術を身につければいいのか、まだよく分からない。でも少なくとも今は、 事実を取り出す道具を作り、その事実をもとにAIと考え、最後は自分で判断する。 このくらいの距離感が、自分にはちょうどよさそうだと思っている。