AIに頼りすぎることの副作用

そういえば忘れないうちに書いておかねばならない話題がありました。
それは今月初頭のブログ移転に伴う開発作業の反省。
「あまりにも突貫工事だった」という通り一遍な感想的なものは何度か書いていますが、
一方でこれを野放しにすると今後の開発スタイルに悪影響を与えそうな反省点が１つあります。
それはあまりにもAIに頼りすぎたことでメンテナンス性が悪くなったということ。
直感的には、設計から大枠を作るところはまだ人間がやった方がいいのではないかと思っています。
より実践的な関数なんかはプログラムを直に書くよりプロンプトを書いた方が絶対早いですが……。

今回はほぼ２日で本来４ヶ月かかる年間計画のひとつだった４代目本家ブログのフロント部分を完成させました。
確かにこのスピード感は全面的にAIを頼った結果できたことであって、
下手にこだわって人力開発していたらとっくに破綻していたと思います。
そういう意味ではやむを得ない部分もあった、
というのは言い訳でそもそも別作業に時間をかけすぎていたのが諸悪の根源であることは言わずもがな。

そもそも今回は大枠の部分からして自分がイチから考え設計したものではありません。
正確にはそれはAIに任せたのではなく、
フレームワーク開発元であるVerselが提供しているサンプルが元になっています。
初期段階でこのサンプルの中で自分が気に入らない部分は軒並み変えていたつもりでしたが、
構造そのものは（時間が無かったので）変えられなかったんですね。
それで、サンプルの改造はほどほどに中身の実装に取り掛かってしまった。
この改造する部分の実装はAIが書いた割合が多いです。

その結果何が起きたのかというと、機能追加がまともにできないという事態に。
先日のアプデで過去記事一覧をタブで切り替えるだけのボタンを作ろうとしたところ、
構造上の問題でまったく実装できず諦めることになりました。
Next.jsでは、ユーザーの操作に応じて動的に変数の中身を書き換えるためにuseStateという関数が用意されています。
昔のweb屋さんにわかりやすい例で言うとjQueryのようなものですね。
jQueryのようなものなので、これは当然ユーザーのブラウザ上で動作させなければなりません。
そこでコードを明示的にブラウザで動かすためファイルの先頭にuse client;という命令文を書くのですが、
サンプルを改造した元のプログラムは基本的に全部サーバーサイドで処理する設計になっていたため、
これを追加した瞬間に大量のエラーが出てきました。
辿っていくとかなり根本的なところから直さなければならないことが判明し、諦めたという次第です。

同じNext.jsでピクチャレ大会を設計したときはサーバーサイドの処理とクライアントサイドの処理を完全に分離し、
なんならサーバーサイド自体は別コンテナで管理するいわゆる疎結合の設計にしたため、
こういう問題は起こりようがありませんでした。
今回はその辺を曖昧にしたまま内部実装に取り掛かってしまったことで起きたトラブルです。
というか、リリースしてからこんなことが起きていること自体結構やばい。

このままだと本家ブログのフロントエンドがいじればいじるほど壊れて最後には破綻してしまうため、
ピクチャレ大会のような設計にするためにいずれ改めて大改造をすることになると思います。
とはいえブログの仕組み自体はごくシンプルなのでそれほど工数もかからないと思いますけどね。
まあ、とりあえずAI開発時代のいまも基本設計だけはちゃんとしようという教訓でした。
AIが複雑な処理は全部書いてくれるとはいえAIに任せれば勝手に完成品が出てくるのではなく、
あくまでも人間側にもスキルが求められるということは常に戒めておきたいところです。