まずはじめに、あまり有益なことが書いてある種類の文章ではない。時間が惜しい境遇の人はこれを読むのを後回しにすべきだろう。書きたくて書いており、読ませるためには書いていない。
タイトルに Vibe Coding ないしは AI っぽい語句を並べた記事を書くこと自体に若干の抵抗感というか、後ろめたさというか、欲に抗えない自分への自己嫌悪感のようなものがあるのだが、まぁでもみなさんもタイトルに釣られて記事を開いたでしょ、ということでバーボン。
今回は、Vibe Coding で生産性が上がったとかできることが増えたとか、効率化のためにやっていることは何かとか、そういう話ではない。やっていることは特に変わりないのだが、Coding Agent という道具と向き合うことで既にあるものの捉え方が変わった、そういう話をしたい。実際のところ、私はあまり Coding Agent を活用できていない。仕事では多少使わないともはや職務怠慢だなと思って利用を試みているが、趣味では Copilot による補完すら使わないことも多いくらいである。
さて、Coding Agent によってソフトウェア開発の比較的簡単なタスクは既に人間のものではなくなり、ジュニアエンジニアがステップアップするための仕事が奪われる、あるいは既に奪われているのではないかと考えたことがある。当時はそれを単に悲観的に捉えていて、これからのソフトウェアエンジニアの成長機会はいったいどこからやってくるのだろうと未来を憂えていた。
私は新卒で入った会社で（もう8年も前か……）様々なコードに出会った。当時自分に飯を食わせてくれていた*1コードを悪く言いたくはないのだが、まぁいろんな背景と経緯を持ち、その時点で見ればまったく適切でないような、そういったコードに溢れていた。しかしそれらは新人の私にとっては悪いことばかりではなく、どういったコードを書くと何が起こるのかという因果を否が応でも知らしめてくれるよい教材であった。自分で書かずとも因果のカタログがそこにある、価値はつまりそこである。
ひとりだけで書いていると、因果のパターンをそう多くは学べない。書き手がひとりだとパターンが偏るからというのもあるが、いかんせん足りていないのは試行回数の方である。ひとりでできる試行回数はたかが知れているし、そもそもジュニアなエンジニアのコーディング速度は十分に遅いのである。新卒当時で既にプログラミング歴自体は20年弱ほどあった私であるが、そういった事情でソフトウェア設計に活かせるほどの見識はまるでなかった。設計と聞いてあのタマネギのような図に行き当たることしかできないくらいの、そういう未熟さである（これは比喩だけど）。
ところで LLM のコーディング速度は極めて速い。最終的な成果物にたどり着くまでの時間でいえば私の人力とまだ大差無いという負け惜しみはありつつ、生成1回あたりの時間はとても短い。一方である程度の試行錯誤が必要であり、一発で完璧な生成物が出てくることは稀である。2025年現在、どうにかこの往復回数を減らし、ターンキーで最終成果物が得られるようにと多くの人類が四苦八苦している。しかし翻ってみるとこれはよいことである。プロンプトという「因」を与え、極めて高速に中途半端な「果」が得られる。これこそがジュニアエンジニアの成長に寄与するものであり、post-LLM era の学習方法に他ならない。ふと客観的に見てみるとあまり特別なことは言っていない。既に現代のジュニアエンジニアはそのようにしてソフトウェア設計に活かせる見識を（自覚の有無に関わらず）ジワジワ溜めているのだろう。単に AI に疎い旧世代の人間が遠回りをして当たり前の見方に到達しただけである。読者の時間を浪費できて私は嬉しい。
みなさんの予想に反して（？）私は新しいモノへの適応が遅い方であるので、Coding Agent についても時間をかけてゆっくり適応していくのだと思う。思い返してみると、私が素の JavaScript を捨てて TypeScript に乗り換えたのは TypeScript 2.0 がリリースされてからのことだった。そのときついでにメインのエディタも VS Code に乗り換えたのだが、それまでは Emacs をメインで使っていた。Emacs と js2-mode を使えば十分に JavaScript を書けていた、あるいは書けていると勘違いしていた。TypeScript に乗り換えてからはより速くより良いコードが書けるように……というわけでもなく、書くコードの雰囲気が変わった。素の JavaScript を堅牢に書くためにはメタプロを駆使して EDSL を定義し、その EDSL を用いてロジックを小さく書くというのが基本の戦略だった。ロジックをベタでダラダラと書いていると一貫性を保ちづらいので、ある種のルールを enforce するために EDSL を定義してその範囲内で実装するというのが当然のテクニックだったように思う。オレオレフレームワークみたいなものなので初めて読む人にとっては最悪であり、これは主に書く人向けの仕組みである。TypeScript を書くようになってからはそういったことはあまりやらなくなった。EDSL というアイデア自体が無益だというわけではないが、それを型検査の代替とすることは不要になったのである。EDSL には、EDSL の価値がもっとちゃんと活きる使い方がある。
これもまた多くの人が言っており既に苔むした主張であるのだが、Coding Agent によるソフトウェア開発は今までの開発体験の延長線上ではなく、ちょっと別のパラレルワールドの開発体験としての発展をしていると思う。言ってしまえば従来の開発効率の改善手法、抽象化・再利用・なんちゃらかんちゃら、というのは人間がコードを書くことを前提にしたアイデアであって、型検査のない JavaScript で一貫性のあるコードを書くために ESDL を導入することと同様に局所解だった可能性がある。Coding Agent によるソフトウェア開発はその局所解から脱出し、新たな勾配を降る助けになるだろう。
「AI はゲームチェンジャーだから」というエクスキューズにかこつけて、今まで大切だと説いていたことをある日突然ポンと投げ捨てて別のことを言う、そういう都合のいいアンラーンをこれからも続けていきたい。
*1:多くの日本人に飯を食わせていたプロダクトの可能性もある
