AIアプリビルディングの未来はタイプセーフティに依存する

AIによって生成されたコードはコンパイルされるかもしれないが、厳格なタイプセーフティがないとその成功は非常に短期間である。タイプセーフティは、システムが拡大するにつれて、もろいコードが隠れたバグやランタイムエラーに腐るのを防ぐガードレールである。

私たちは、AIを厳格なタイピングに従わせるために、コンテキスト、指示、linting、フィードバックループを使用し始める必要がある。数時間かかるかもしれないが、持続するコードを生成する。

インセンティブの問題

AIはあなたを喜ばせたい。与えられた報酬関数を最適化し、ほとんどの場合、それは単に「コンパイルされるか?」である。つまり、グリーンチェックマークを取得するために必要なすべてのコーナーカットを行う。

これが、AIがanyを好む理由である。あるいは、UUIDが期待される場所で、stringのような広いタイプを選択する。コードはコンパイルされるが、正しさはすでに妥協されている。さらに、AIは数ファイル前に何を書いたかを覚えていないので、タイプセーフティなしで、プロジェクトはすぐに複雑さの下に崩壊する。

2種類のエラー

AIによって生成されたコードが実行されると、通常、2種類のタイプセーフティ問題が見られる：

1. コンパイル時エラー

• 何が起こるか: コンパイラーが宣言されたタイプと渡されたものとの不一致を検出する。
• 人間がどう修正するか: コーラーが間違っているか（42をstringに変換）、または関数シグネチャが間違っているか（numberタイプを受け付けるように変更）を決定する。
• AIがどう修正するか: 引数タイプをanyに変更する。問題は「解決」されたが、将来のエラーを検出するガードレールが削除された。

2. ランタイムエラー

• 何が起こるか: コンパイラーはすべてが正常であると思っている（タイプが緩和されていることが多い）が、実際の値はランタイムで期待と一致しない。
• 人間がどう修正するか: 変数をその源（APIまたはデータベースクエリなど）まで遡り、境界でタイプを修正して、データが適切なstringとして入力されるようにする。
• AIがどう修正するか: コンテキストなしで、AIは推測する。すべてをString(…)で囲む、またはタイプを再び緩和する。クラッシュはこのスポットで消えるが、ロジックは壊れる。Numberは数学のために意図されたが、stringになる。

ランタイムエラー → AI「修正」→ 緩いタイピングのサイクルはすぐに複合する。 結果はコンパイルされ、ランタイムエラーが少なくなるコードベースになるが、信頼できない。医療スケジューリングシステムを想像してみよう。医師のシフトはアプリによって管理される。タイプの不一致が入り込む：intの時間はstringとして扱われる。AIはタイプをanyに緩和することで「修正」する。コードはコンパイルされ、エラーは消えるが、シフト計算はサイレントに壊れ、医師は二重に予約され、病院の全翼がカバーされない。

データベース乗算子

データベースに接続する瞬間、エラーは増加し、その原因はより難しくなります。SQLは理由があるためにタイピングされている。毎回スキーマ（INT、TEXT、UUID、BOOLEAN）はデータについての仮定を符号化する。

AIがすべてをstring | anyに平坦化すると、保証は失われる：

• 悪い書き込み: 真をブール値フィールドに挿入することはコンパイルされるが、DBを破壊する。
• 悪い読み取り: クエリはNULLを返すが、AIは文字列を想定し、ランタイムクラッシュにつながる。
• 壊れた関係: 関係キーがUUIDとして期待されるが、AIはそれをstringとして扱い、誤ってガベージ値を送信し、ジョインはクラッシュしないが、データは返されない。エラーは後に結果として現れるまで隠される。

これが、真剣なチームがタイプ付き言語を使用し、スキーマからAPIまでタイプセーフティを強制する理由である。如果そうでない場合、データベースはあなたを保護しなくなるし、隠された問題は複合する。

なぜ成熟したチームは厳格なタイピングを強制するのか

厳格なタイピングは、開発者を遅くすることについてではない。スケール可能にすることについてである。

タイプは：

• 意図をコードに符号化する。
• リファクタリングを安全かつ予測可能にする。
• バグの全クラスをプロダクションに到達する前に捕捉する。
• 将来の開発者（およびAI）に、関数またはオブジェクトを使用する方法を示す。

タイプセーフティなしで、AIのコードの汚さは複合する。タイプセーフティありで、同じAIは信頼できるコードを生成する。

AIをタイプセーフティに従わせる方法

あなたは、AIをジュニアエンジニアのように扱う必要がある。速く、才能があるが、方向なしで無謀である。

正しいコンテキストを提供する

インターフェイスとタイプを使用できるようにする。使用例を示す。コードの構造については意見を持つ。

厳格な指示を与える

明確にAIにanyを使用しないこと、unknownを許可しないこと、すべてのメソッド、オブジェクト、変数にタイプを付けることを伝える。特に最初のパスで、これらの指示に従うのが難しいことを期待する。

lintingで強制する

ジュニア開発者のコードをレビューするように、AIのコードもチェックする必要がある。カスタムlintルールを設計し、「良いコード」とは何かを定義する。lintingの失敗をモデルにフィードバックし、パスするまで繰り返す。複数のラウンドかかるかもしれないが、報酬関数はタイプセーフティを含むようにシフトする。

チェックを繰り返す

コンパイル時エラー、ランタイムログ、クリックスルーテスト。各イテレーションで、AIはタイプを締め付け、プロダクショングレードのコードに近づく。

より良いビルディング方法

私は、生の生成速度を犠牲にしても、高品質を優先することが長期的には支払いが戻ってくることを学んだ。つまり、anyタイプのゼロトレランスを戦うこと、複数のフィードバックループと厳格なlintingルールを強制すること、コードを「完了」と呼ぶ前にAIがそれらをパスすることを意味する。

先ほど述べた重要な点：AIがランタイムエラーをタイプを緩和することで修正し始めると、悪循環に入る。各修正は別のガードレールを剥奪し、結果はコンパイルされるがもろく、メンテナンスできないコードベースになる。逆もまた然り：もしAIを毎回タイプセーフティを尊重させるなら、美徳の循環を作り出す。各イテレーションでガードレールを締め付け、コードベースはクリーンになり、品質は信頼できるものになる。

これが、私が持続可能なコード品質を提供するシステムであると信じるものである。各イテレーションは基準を緩和するのではなく、強化するように設計されている。これが、最も優れたエンジニアリングチームが強くタイプ付けされた言語を選択する理由である。タイプセーフティはメンテナンスのための基準ガードレールであり、AIがそれを無視することを許可すると、アプリは決してプロダクショングレードには到達しない。