アシシュ・セルヴァラジ氏は、新時代のソフトウェア開発におけるガードレールのスケーリングに取り組むApproximaの共同創業者である。
プログラマーとして過ごした11年間で、私はシンプルなウェブサイトの作成から分散システムの開発へと進化してきたが、コードを書く方法は変わらなかった。テキストエディタを開き、頭の中でタスクを整理し、それを使用するプログラミング言語の構文に変換していた。
2025年初頭、AI支援機能が利用可能になったが、私は一度も使わなかった。大規模言語モデル（LLM）に中途半端なバージョンを書かせ、その後編集や改良、問題修正に時間を費やすよりも、自分でコードを書く方がはるかに速かったからだ。その年を通じて、これらのシステムを試し続けるうちに、その出力をより信頼できるようになっていることに気づいた。最初は単純なタスクから始まったが、やがて私はモデルと対話しながらすべてのコードを書くようになった。私の仕事は、コードを書くことから、高レベルのアプローチを設計し、モデルに実装の草案を作成させ、そのコードに問題がないかレビューすることへと変わった。
AIを活用したコーディングができること、できないこと
過去4カ月間、毎日これらのツールを使用してきたが、もう後戻りはできないことは明らかだ。これらのツールを使った実験やプロトタイピングは、新しいプロジェクトを始めるために必要な定型コードのほとんどがLLMによって完全に処理されるため、楽に感じられる。
よくある落とし穴は、プロトタイプが実際のコードベースになると、物事が崩れ始めることだ。これらの完全にAIで生成されたプロジェクトが大きくなるにつれて、開発者もLLMも完全にコントロールできない状態に達し始める。開発者は、プロトタイプだった頃と同じレベルの信頼をLLMの出力に寄せ続けるが、複雑化したコードベースには統合の問題やセキュリティホールが無数に存在する可能性があるため、品質が低下していることが多い。
ユーザーは非常に敏感で、自分たちが使用するソフトウェアがどのように変化しているかに気づいている。「Vibe-coded（雰囲気でコーディングされた）」は低品質なソフトウェアに対する侮蔑的な表現となり、人々は一貫性のないインターフェースや特定の色やスタイルの過度な使用など、AIで生成されたコードの特徴的な兆候をすぐに指摘する。ソフトウェアにおいて信頼は極めて重要だ。ユーザーは、仕事をこなし、データを安全に保ち、日常的に使用できるだけの信頼性をソフトウェアに求めている。急いでリリースされた機能は、苦労して築いた信頼を壊し、ユーザーが企業全体をどう認識するかを変えてしまう可能性がある。AIがもたらす加速を活用しながらユーザーの信頼を維持するには、企業はガードレールを進化させる必要がある。
AI時代において従来のガードレールがどう変わるべきか
従来、企業はソフトウェアリリースに対して2つの主要なガードレールを持っていた。コードレビューと品質保証である。
コードレビュー
コードレビューでは、開発者は自分が書いたコードを、他のチームメンバーがレビューしやすいスコープの小さな単位に分割する。しかしAIの登場により、単一のエンジニアが取り組めるタスクの種類が増えているため、スコープの単位を構成するコードの量が大きくなっている。各単位が大きくなっているだけでなく、レビューすべき単位の数も増えている。レビュアーには、すべての変更を徹底的にレビューする余裕がなく、バグが紛れ込む余地が生まれている。
レビューをスケールさせるには、AIの活用が不可欠だ。AIモデルはコードレビューにかなり優れており、明らかな問題のほとんどを捉えることができる。レビューに提出されるすべてのコード変更に対してAIを実行することで、人間によるレビューの負担が軽減される。人間がコードを読む頃には、すでに機械によるレビューを経ているため、人間が対処すべき問題は少なくなっているはずだ。明らかな問題を指摘する時間を減らし、変更の波及効果を考える時間を増やすことができる。
品質保証
ソフトウェアの品質保証は常に自動テストと人間のチームの組み合わせだったが、急速な反復の新時代では、人間のチームはリリースされる機能の数に圧倒される可能性がある。
エンドツーエンドテストは、ソフトウェアが実行されたときに、主要なユーザージャーニーが期待通りに機能することを検証する自動テストだ。これらは、実際のブラウザでソフトウェアを実行し、人間と同じように要素をクリックするフレームワークを利用する。
しかし、実際のユーザー行動を再現しようとしているため、これらのテストは適切にメンテナンスされないことが多い。ユーザーインターフェースが変更されると壊れ、基礎となるユーザージャーニーが依然として機能している場合でも失敗する可能性がある。これらの問題により、エンジニアはソフトウェアをリリースする際にこれらのテストの結果を無視し、失敗は無関係だと想定する傾向がある。
このガードレールを強化することは極めて重要であり、チームがこれらのテストをリリースのブロッカーとして扱う必要がある。LLMはUIの変更に同期してこれらのテストを簡単に更新できるが、そうするよう求められる必要があり、エンジニアはこれらのテストがコードのリリースをブロックする場合にのみ手間をかける。さらに、ユーザージャーニーをテストする完全に決定論的なフレームワークから、LLMを活用してページで実際に何が起こっているかを診断するフレームワークに移行することで、これらのテストの脆弱性を減らすことができる。
最後に
ソフトウェア開発が変化し、もう後戻りはできないことは明らかだ。私はもう、かつてのように何千行ものコードを書くことはないだろう。チームは成功するために最新のツールを採用しなければならず、信頼性の高いソフトウェアを提供しながらそれを行わなければならない。良いニュースは、モデルが従来の世界でチームが持っていたのと同じガードレールを強化し、スケールさせるのに役立つということだ。
