責任を引き受けるプログラミング:提出した人が責任を負う
AIはコードを書くコストを下げた。しかし、そのコードに責任を持つコストまでは下げていない。
「責任を引き受けるプログラミング」とは、提出した人が結果に責任を持つことだ。
AIが生成したコードであっても、提出者は結果に責任を負い、自分が引き受けるべきコストを他人へ押しつけない。
これは道徳的なスローガンではなく、責任の境界線である。
mainに入るコードの責任は誰が負うのか
AI Codingについて語るとき、多くの人が注目するのは速さだ。より速く書き、より速く直し、より速く「動きそうな」状態へ持っていく。責任を引き受けるプログラミングが問うのは別のことだ。そのコードが共有のmainブランチに入ったあと、誰が責任を負うのか。
AIはコードを生成できる。修正もできる。チェックも実行できる。それでも、リポジトリに入り、他人へ影響し始めるのは、モデルとの対話記録ではなく、実際に動くコードだ。
だから、責任を引き受けるプログラミングは「もっと丁寧にPromptを書くこと」でも「AIの使用を減らすこと」でもない。決めるのは一つだけだ。コードを提出した人が、その結果に責任を持つ。責任をモデルへ外注することはできない。
反対するのは責任転嫁の自動化
「自分は生成するだけで、品質はツールの責任だ」という態度は現代的に聞こえるかもしれない。しかし実際には、自動化のプロセスの中へ責任を隠しているだけだ。
モデルはオンコールを担当しない。壊したインターフェースを修復することも、Reviewの場でその設計について代わりに説明することもない。そのコストは結局、下流へ流れる。Reviewする人、連携作業をする人、変更によって作業を止められた人が引き受けることになる。
責任を果たすとは、提出前に自分で一度確認し、下流へ流れるコストを食い止めることだ。完璧である必要はない。ただし、こう言えなければならない。このコードは自分で確認した。境界も理解している。問題が起きたら自分に言ってほしい、と。
コードが安くなるほど、責任を持つ人は希少になる
コードが安くなると、人と人の成果の差はかえって広がるかもしれない。Promptの巧拙だけが差を生むわけではない。結果に責任を持つ人と、対話を終えることだけに責任を持つ人がいるからだ。
同じ一時間でも、ある人が渡すのは「それらしく見えるもの」であり、別の人が渡すのは「Reviewの場で説明できるもの」だ。前者はチームの協働に使える余力を消費し、後者はそれを節約する。
だから、これは個人の心がけだけの話ではない。協働の倫理であり、エンジニアリングの効率でもある。自分が先に引き受けなかった確認、判断、修正は、最後には誰かが補わなければならない。
自動化しても責任は消えない
自動化が成り立つのは、意図が明確で、実行経路を制約できる場合だ。自動化は成果を届ける助けにはなるが、責任まで取り除いてはくれない。
コードの九割をAIに書かせてもよい。すべてを書かせてもよい。それでも、そのコードが共有空間に入り、他人へ影響しうる限り、提出者の責任は消えない。すべてを自動生成しても、誰も責任を負わなくてよいことにはならない。
そうでなければ、手に入るのは完全な自動化ではない。判断の負債と事故の負債をチームへ残す、半自動の生産ラインだ。
提出した人が責任を負う。他人に対する責任を持ち、自分のコストを押しつけない。
AIはペンにも、手にも、チェック役にもなれる。しかし、身代わりにはできない。
対話を終えることより、仕事を成し遂げることのほうが、昔からずっと希少だった。そして「成し遂げる」には、今風ではない一つの行為も含まれる。結果に自分の名前を添えることだ。