昨今の「AI駆動開発」にはだいぶ前から否定的な感情を抱いていた。


○○駆動の「駆動」は、開発の推進力(モチベーション)が何かを定義していると聞いたことがある。例えばドメイン駆動であればドメイン(業務)が変化すればコードも変わる、みたいな。

となると皆の言う「AI駆動開発」って言いながらAIが開発を進めているわけではないだろ、AIで加速はするだろうがその原動力は「AIが」ではないだろ、と。


そんなら自分は何をモチベーションにして開発を進めているのか振り返ってみると2つ挙げられそうだった。

1つは「フラストレーション駆動開発」[^1]、Swizec Teller氏のブログが流れてきてちょうど知った。
それまでは「ストレス駆動開発」と読んでいた。ストレスだと快ストレスもあるのでフラストレーションの方がしっくりくる。

2つめは「AI論破快感駆動開発」、適当にそう呼んでるだけなので近い概念や良い命名があれば教えてもらえると嬉しい。

AIに全部やってもらって全部つくってもらって全部検証してもらうだけだと何も記憶に残らない。というか仕事のチームメンバーも「最近個々のタスクに思い入れがなくなってきて、忘れがち」と言っていた。空虚な仕事は飽きるのも時間の問題なので何とかしてあげたい。
全任せだと記憶にも残らないどころか自分の経験やスキルアップにもつながらない。この辺りはAI時代にジュニア層をどう育成するかみたいな話も最近多いので悩ましい問題。

とまぁ、じゃあAI論破快感駆動開発ってなんやねん、って話

仕事でなんかバグがあって調査してた時、ちょっと負債っぽいを見つけた。

共通設定(ドメインA)の変更を受けて2つの業務領域(ドメインB/C)を更新する処理があって、その二つの更新が一つのユースケースにまとめられているっていう負債。

イベント通知を受けて、似た設定を更新しているのでまぁ1ユースケースに束ねたくなる理由もわかるけど

- 片方のドメインBを更新する処理が失敗すると後続のドメインCも更新されない
- ディレクトリ階層も1つのドメインの配下（usecase/domain-B/...）なのに別のドメインCも更新している
- そもそも別ドメインなんだから分けろや…

という…、多分説明すればAIでも人間でもすぐわかる話ではある。

だけど当初話した通りAIは「とあるバグの原因調査」に視野狭窄しちゃっててこの負債には一切触れていない、話題にも上げていない状態だった。

お～。お前それ見逃がしちゃダメだろ～。とイキリ指摘をブチかます。人間相手には決してできないがAI相手なら許される。許されるならやったほうがお得である。

AIは「依頼されたことだけに絞って見ていた」だけなので、別に自分より賢くないわけではないとは思っている。(というか今はもうAIの方が賢いと言ってもいいと思う)
それでも、「ちゃんと指摘できた」ことによる快感は得られる。

快感を得ると人間は報酬系が働き、また快感を得たくなる。

その部分に詰め込むべき責務か？その処理を関数化して一つにまとめる理由は本当にある？DRY原則って、いや同じ内容でも責務が違うなら一緒にするのはダメだろ。って

そうしてボコボコにしていくほど筋トレのように経験が積みあがる、と。

あ、○○駆動って話なので「アプリケーションの開発が推進される」が主題で、「自信の経験値稼ぎが加速する」は副産物か…。

でも確実に仕事で作っているプロダクト、アプリケーションのコードは以前よりよくなっている。
溜まりにたまった負債へのフラストレーション×負債を指摘しまくり論破快感でバリバリ推進している。もちろん新機能は負債から学んでどんどんいい設計を取り込もうというモチベーションがメンバーにも広がってっている。今のチームは自分でも非常にいい推進具合だと胸を張れるくらいだ。

ということで、AI論破快感駆動開発、割とこの時代の筋トレとして適している気がしなくもない。

[^1]: https://swizec.com/blog/frustration-driven-development