こんにちは、Vimmerのdondakeshimoです。
AIの進歩により、ソフトウェアエンジニアの開発方法に革命的な変化が訪れました。GitHub Copilotによる予測補完は現在の私の開発速度を支える重要な要素となっていますし、技術調査やidiomの確認などはAI以前の検索手法しかなかった時とは比べ物にならない速度になりました。
私が勤めているブルーモ証券株式会社ではスタートアップ企業の意思決定の速さを活かして、開発生産性を向上させるためにAIを活用できないか試行錯誤を続けています。一つのトライアルとして、CursorのPro planを経費として購入しても良い制度が導入されています。本記事はVimmerである私が、CursorでVibe codingをしてみて感じたことや学んだことを共有する記事です。
Vimは特にAI活用に取り残されているエディタではないものの、GUIのサポートが効きづらいエディタであることから最前線とは言い難い情勢です。社内では空前のCursorブームが起きており、JetBrains信者の同僚もCursorを使い始めているような状況でした。エディタを変えるだけで開発速度が上がるのであれば、会社のために好みを捨てることもやむを得ないと考えて、Cursorをインストールすることを決断しました。
オチを言うと今私はVimで開発を行なっています。ただ、Cursorを2週間ほどVibe codingをしてみたことで、より深くAIの活用について考えることができました。今はまだVimで良いと結論付けたものの、定期的な再検討や、AIフレンドリーなコードベースやドキュメンテーションなどの開発環境以外の準備を進めていく必要があると感じたので、その内容についてまとめます。
対象読者と記載内容
対象読者
すべてのソフトウェアエンジニアに読んでいただける内容です。AIを活用している自負があるエンジニアにも、AIをどう利用して良いか悩んでいるエンジニアにも楽しんでいただけるのではないかと思います。
記載していること
Vibe codingをした中で感じた現状のAIモデルと機能がどのように開発生産性に影響を及ぼすかを主観でまとめています。
また、これからの開発ツールの進化に合わせて、開発者が行なった方が良さそうだと感じたものについても書いています。
記載していないこと
AIの具体的な活用方法やCursorの使い方については触れません。
本記事の前提
普段の私の開発業務と環境
最初の前提は、本記事の内容が自身の業務領域に対しての開発を行なった結果の考察であることです。私はバックエンドエンジニアとして証券アプリケーションの業務ロジックをGoで実装しています。そのため、今回の記事におけるコーディング対象は金融領域のロジック実装という比較的複雑性の大きい箇所を対象としています。
私は特別な事情がない限りNeoVimを用いて開発を行なっています。NeoVimのAI関連のプラグインとして、以前よりGithub Copilotを使用しており、Cursorを試す1, 2週間ほど前にAvante.nvimを経由してCodeCompanion.nvimを導入しました。VimにAI agent機能を導入してもいまいち使い方が定まらなかったこともCursor導入に踏み切った要因の一つです。
実際に使用しているVimの開発環境
開発生産性への寄与
本記事では業務でのコーディングを想定しているため、開発生産性が高い方が良いという前提に立っています。
企業における開発者に期待されることは、いちはやく市場に価値を届け続けることです。これを思い切り噛み砕くと、開発者は速くコードを書き続ければ良いです。
「〜続ける」と記載したように一時的に速度が上がれば良いわけではなく、なるべく大きい速度をずっと維持することが求められます。そのためにはコードベースの内部品質を保つ必要があります。弊社ではそのためにコーディングルールとレビュープロセスを定めています。
話をさらに単純化すると、弊社における開発生産性の向上とはコーディングルールに則った上でレビューを通過できるだけの内部品質を備えたコードをなるべく速く書くことと言えます。
逆にコーディングルールとレビューをクリアしないコードをいくら書いても開発生産性には寄与しません。例えば、受入条件に記載されているシステムの振る舞いや、コードベースのルールとして定められている変数の命名規則など全てを満たしたコードを書かなければ、そのコードがメインストリームへコミットされることはありません。
Cursorの強み
CursorのVimに対しての強みは
- AI agentをファーストクラスの機能として導入することによる動線の良さ
- 生成されたコードのシームレスな適用
- Cursor tabによる編集の先回り
であると感じました。Vibe codingを行う上では明らかにVimよりも環境として整っています。これらが開発生産性にどのように影響したのかをみていきます。
Vibe codingの使い心地
AI agentやインラインサジェスチョン機能を利用して、AIの生成したコードをメインに実装するスタイルが主流である認識のもと、極力自然言語を使ってコーディングを進めました。その結果、一般的な内容にはなりますが、問題の一般性やコンテキストサイズに対してコード生成の速度と品質が変化すると感じました。
- ボイラープレートの実装は数秒で完了することが多い
- 一般的な問題 (ググれば出てきそうな問題) についての実装は数秒で完了することが多い
- 狭い領域の知識で済む問題への実装やリファクタリングは数秒で完了することが多い
- 数ファイル分の知識を含んだ問題は何度かやり取りを迫られることが多く実装完了まで時間がかかる
- 1ファイルでも数1000行のコードの大規模修正などは途中から変な回答をすることが多く実装完了まで時間がかかる
- 数百ファイルのコンテキストを必要とする問題は不正解を送ってくることがほとんどで基本的に実装完了しない
広いコンテキストや深いドメイン知識を要求される問題は任せることができなかったものの、AIが簡単に生成可能な部分については圧倒的な速度感を持っていました。AIが生成可能な部分を切り分けつつ、AI agentと自前実装をうまく使い分けることで、開発速度を大きく上げることができそうに思えます。
しかしながら、実感としてはいくら使い分けがうまくいってもこれまでの開発速度を上回るようには思えませんでした。そこで、単純なAIのレスポンス速度以外の部分についても深掘りを行なっていきます。
コードの記述以外におけるコスト
Vibe coding中の自分の行動を思い返すと、既存の開発スタイルとは異なる様々なコストを払っていたことに気づきました。
機能選択コスト
軽いものから行くと、AI機能の選択コストがあります。例えば、agent機能やインラインサジェスチョン機能のどちらを利用するのか考えなければなりません。先述の速度感の話は適切な機能を選んだ上でのものです。
似たものとしてAIモデルの選択コストがあります。モデル次第で返答の質が速度が変わるため、一定の認知負荷を払って選択する必要があります。
タスク分解コスト
コンテキストサイズの問題から、自分の脳内にあるタスクの粒度よりもさらに細かく砕いてAIに渡していたため、タスクの分解コストも生じていました。メンテナンス性の高いコードを書くためにはジュニアレベルのエンジニアとペアプロをするように対話しながら生成させる必要があるとの実験もあるため、現時点のモデルの能力ではこの作業は必要なものと捉えています。
翻訳コスト
もう一つAIモデルの使用にあたって必要なコストが自然言語への翻訳です。AIモデルへのインプットは自然言語です。真面目にVibe codingに取り組んだ結果発見したのですが、どうやら私は問題とその解法に関して脳内では自然言語ではない何かで認識してそれを実装していたようです。これは認知特性などにも左右されると思うので一概に言える話ではなく、あくまで私の場合についてです。そのため、AIモデルを使用するには脳内の情報を自然言語に翻訳する作業が必要になりました。
レビューコスト
Vibe codingではレビューを放棄しているものの、業務コードにおいて完全にそれを避けることはできません。Pull Requestを送った結果レビュワーの負担をいたずらに増やすわけにはいけないので、現状で、業務コードを書く際はレビューが必要だと考えています。
よって、開発者は実装の代わりにレビューを実施していると捉えることができます。レビューは実装と比べて楽なことも多いものの、一定のコストはかかります。
心理的コスト
最後に時間的なコストではありませんが、挙動が絶対的なものではないことから感じる心理的なつらさもありました。ボイラープレートは一瞬で実装され得るみたいな感覚は、挙動の典型例をまとめたものになっています。実際には簡単と思われる問題を投げたところ悶々と考え始めたり、サービスのAPIの不安定さからかシンプルに回答が遅い時があったりと、挙動の分散が大きく、それに応じて私の心も不安定になりました。
まとめ
実装におけるAIの速度感の他にもいくつか払う必要のある速度があることがわかりました。これらを踏まえてVibe codingの開発速度が手動での実装を上回るということは、下記の不等式が満たされている状況と表せます。
手動での実装コスト > AIのレスポンスタイム + 機能選択コスト + タスクの分解コスト + 自然言語への翻訳コスト + レビューコスト + 心理的コスト
Cursor tab
上記のコストが毎回のコーディングにかかっていたら、私はVibe codingのことを実用的ではないとすぐに放棄してしまっていたと思います。
Vibe codingを2週間続けられた要因はCursor tabの存在です。上述のコストの中で個人的に大きな割合を占めていたタスクの分割と自然言語への翻訳コストがCursor tabによって生成された場合は必要ありません。自分の思考速度を上回って、先回りで編集してくれる機能は開発生産性の観点で非常に優秀であると感じました。
ただし、Cursor tabや最近GitHub Copilotで発表されたNext edit suggestionsがVibe codingの開発スタイルに含まれるかは微妙にも思えます。これらはこれまでの開発スタイルも補助してくれる機能のため、Vibe codingの加点要素というよりはCursorのVimに対する加点要素という色合いが強いです。
Vibe coding vs 今までの開発スタイル
最初に述べたように、現在私はVimに帰っています。これは私の開発対象に関して、現時点ではVibe codingよりも自分で書く方が速いと判断したためです。
私が行なっている金融証券ドメインの開発において、AIが機能的にも品質的にも正答可能そうな問題はタスクをかなり小分けにしないと抽出できませんでした。また、Goのテストファイルなどはすぐに大きくなってしまうため、コンテキストサイズの逼迫がすぐに起こってしまうことも課題感として大きかったです。
逆に、品質のグレードをある程度落としても良くコンテキストも小さくおさまりがちなプロトタイピングや、タスクの一般的な問題への帰着箇所が比較的多いと思われるフロントエンド領域においては、Vibe codingの方が開発速度が上がる可能性は高いと感じました。
AIにコーディングしてもらっている図をAIに描いてもらいました
AIツールに対する予想
コストをなくす機能の強化
Cursor tabやNext edit suggestionsのように各コストをスキップできるような機能は、AI poweredなエディタにおいてどんどん推奨される使い方になると思います。
最近発表されたBackground agentはレスポンスタイムを削減する取り組みです。今後はレビューコストを省略するためにTDDへの動線強化や、テストの自動実行などが拡充されていくのではないかとも予想しています。
モデルの強化
大きな課題としてあるコンテキストサイズの問題はモデル自体の発展によりどんどん解消されています。
より難しい問題への対応についてもモデルはまだまだ賢くなっていくと予想しているため、段階的に解消されていくはずです。オープンソース運動の成果でジュニアレベルのコードだけでなく、シニアレベルのコードもインターネットで公開されているため、うまくファインチューニングすればシニアエンジニアクラスの知能を有するモデルが誕生すると思います。
より速くAIに私を超えてもらうためには
上記の予想からVibe codingなどのAIを活用した新しい開発スタイルは既存のスタイルの開発生産性を超えていくと予想しています。一方で、その臨界点はこれからの私の準備次第で早くも遅くもなると感じました。
早く臨界点を迎えられることは単純な開発生産性の向上につながるため望ましいことです。そこで、本章ではどうすればより早くAIに自分を超えてもらえるかについて考察します。
自分で使う
AIに限らずツールの有効性はそれぞれの開発環境に左右されるものだと思いますが、特にAIツールにおいては自分で使ってみないと本当に活用できるかの判断が難しいと思いました。
多くのツールが既存のワークフローの一部を自動化したり簡素化したりしてくれるものであるのに対して、AIツールは既存のワークフローとは異なるフローで開発することを迫られます。例えば新しいフローの一つであるVibe codingが、それぞれの開発対象に対してうまくハマるかどうかのナレッジは業界にまだまだたまっていません。ハマれば開発生産性が向上することは確かである以上、ハマらないことが自明でない限りは試さざるを得ないと考えています。これまで見た通り開発環境や個人による評価の分かれ目が大きいものである以上、これは新しい機能や新しいモデルが出るたびに自分で使ってみて評価をしないといけないことを意味します。
実は似ている部署の評価はいまいちでも、自分の環境においてはゲームチェンジャーだったことに気づかなかったということがないように、逐次手元で試してみることが必要だと感じました。
品質基準を明示する
開発生産性を品質基準を超えた成果物の生成速度とおいた上で、品質基準として弊社ではコーディングルールとレビューを採用していると述べました。
コーディングルールは文書であるのに対して、このレビューで確認していることは完全に明文化されているわけではなく、開発者それぞれの裁量に委ねられている部分が大きいです。人間であれば、レビュープロセスを通じて暗黙的な基準の概形を汲み取ってくれますが、AIモデルは明らかに基準が明文化されている方がパフォーマンスを出せると感じました。
暗黙的な基準に気づいたり、それを文書化することはAIを本格的に活用していく上で必要になってきます。これは既存の開発者や新規参加の開発者にとっても有用なもののため整えるべきものです。
ドキュメンテーションは一朝一夕で完了するものではないため、今のうちから将来と現在を見据えて可能な限り品質基準については文書化しておこうと思いました。
知識を凝集する
コンテキストサイズの問題やAIへの入力の手間を解消するためには、AIに渡す情報をなるべく端的にできると良いです。
これは一般的な良いコードの方向性とも一致するため、これまでのコーディングスキルをフル活用して良いコードを書くことは、将来的な開発生産性にも寄与することを指しています。特に、戦術的DDDのようなドメイン特有の問題と一般的な問題を分離する方向性は、より明確にAIを活用の敷居が低い範囲を抽出できるため有効であると考えています。
より広い範囲に目を向けると、コンポーネントの境界やシステム全体の知識の凝集度なども、うまく設計できているか否かでAIが活躍し始めるまでの時間が変わってくると思います。
AIを実際に触ってみる前は、ダメコードを量産してもAIが読み書きしてくれるなら別に問題ないのでは？などと考えていたのですが、それはAIを活用可能なタイミングをイタズラに遅らせることにつながると感じました。
本当のところをぶっちゃけると、Cursorを使い始める前は「Cursorの方が開発生産性は高いけど楽しくコーディングしたいからVimをメインに使います」という結論になると考えていたので、シンプルに開発生産性の観点でVimに戻ってくることになったのは意外でした。
また最後に挙げたもののうち、「自分で使う」については私が割と苦手としているところだったので良い教訓になりました。後の2つは逆に常日頃からこだわりを持っている部分だったので、考察を進めるうちに今後も無駄にならないことだったと気づけて嬉しかったです。
今後もAIによる開発環境の変化は頻繁に発生すると思いますが、一つ変わるたびにたくさん学べることが増えるので楽しくキャッチアップしていく所存です。(でもやっぱりVimから離れたくない。)
ブルーモでは次世代の金融システムを作る仲間を募集しています！
エンジニア、デザイナー、PdM、事業開発などさまざまポジションで募集をしているので興味がある方は下記の採用ページを覗いてみてください！
Views: 2
