はじめに

最近、「AIを使えばコードが書ける」という話をよく聞く。実際そのとおりだし、私自身もその恩恵を受けてきた。

ただ、AIが書いたコードを自分のコードとして扱っていいのかという問いがずっと頭に引っかかっていた。この記事では、自作OSSの開発を通じてAIとの付き合い方を見直した話を書く。同じような悩みを抱えている人の参考になれば嬉しい。

きっかけ：「動くコード」と「わかるコード」は別物だった

自作のOSSである NanaSQLite を開発していたとき、AIが提案したロジックに明らかな嘘や欠陥が含まれていることに気づいた。これ自体はすぐ指摘して直せる。問題はその先だった。

開発が進むにつれ、こんなことが増えてきた。

こうなると、自分が理解していない大量のコードの差分を追いながら、その中からバグを探し出すという非常に非効率な作業を強いられる。

問題は薄々感じていた。でも「めんどくさい」という理由で先送りにしていた。今回の開発で痛い目を見て、ようやく正面から向き合う気になった。

自分の開発フローを振り返ると、AIへの依存はこんな状態だった。

通学に往復3時間かかる上に、部活があれば帰宅が22時を回ることもある。「設計だけ考えて、あとはAIに任せる」スタイルは、当時の自分には合理的な選択に見えていた。

しかし結果として、自分のリポジトリに自分が把握していないコードが積み上がっていた。これは開発者として、OSSの作者として、正直まずい状態だと気づいた。

問題が「すべての工程をAIに委ねること」にあったなら、解決策は工程ごとにAIの役割を明確にすることだ。

技術選定や設計の初期段階でのAI活用は、引き続き有効だ。

ただし、出力は必ず自分で確認する。AIが嘘をついていないか、自分の意図と合っているかを検証する責任は自分にある。

実装をまるごとAIに渡すのをやめた。代わりに以下のフローに変えた。

テストは「自分の意図した設計になっているか」と「バグがないか」を保証する最後の砦だ。ここをAIに委ねることは、その保証を放棄することと同じ。テストこそ、自分で書く。

方針を切り替えてから、1つのタスクにかかる時間は確かに増えた。しかし結果として開発効率は上がった。理由はシンプルで、自分が理解しているコードが圧倒的に増えたからだ。

一方で、過去にAIに書かせたコードには今も把握できていない部分が多く、バグのたびに解読を強いられている。これは自業自得だと思っている。

目先の効率を取るか、未来の保守性を見据えて今に投資するか。

これはなかなか難しい問いだ。ましてや勉強や部活と開発を両立する学生にとっては余計に悩ましい。

ただ今回の反省で改めて実感したのは、自分でコードを理解し、判断することの重要さと、その過程の楽しさだ。AIは強力なツールだが、主導権は自分が持つべきだ。

「AIが書いた」ではなく「自分が作った」と胸を張って言えるOSSを、これからも作り続けたいと思っている。