AIアプリケーションの将来は型安全性に依存する

AIによって生成されたコードはコンパイルされるかもしれないが、厳格な型安全性がなければ、その成功は非常に短期間で終わってしまう。型安全性は、壊れやすいコードが隠れたバグやランタイムエラーに腐るのを防ぐためのガードレールである。

私たちは、コンテキスト、指示、linting、フィードバックループを通じて、AIに厳格な型付けを強制する必要がある。数時間かかるかもしれないが、持続するコードを生成する。

インセンティブ問題

AIはあなたを喜ばせたい。与えられた報酬関数を最適化し、ほとんどの場合、それは「コンパイルされるか？」である。そのため、AIは緑のチェックマークを得るために必要なすべての角を切るだろう。そのショートカットはコンパイル時には問題ないように見えるが、ランタイムでは崩壊する。

これが、AIがanyを愛する理由である。あるいは、stringなどの広い型を選択するが、UUIDなどの厳格な型が期待される場合である。コードはコンパイルされるが、正しさはすでに妥協されている。さらに、AIは数ファイル前に何を書いたかを覚えていないので、型安全性がなければ、プロジェクトは複雑さが増すにつれてすぐに自重で崩壊する。

2つの種類のエラー

AIによって生成されたコードが実行されるとき、通常、2つの種類の型安全性の問題が見られる：

1. コンパイル時エラー

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

2. ランタイムエラー

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

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

データベース乗算器

データベースに接続した瞬間、エラーは増加し、原因はより困難に追跡される。SQLは理由があるために型付けされる。
すべてをstring | anyに平坦化するAIは、保証を失う：

• 悪い書き込み： ブール値フィールドに「true」を挿入することはコンパイルされるが、データベースを破壊する。
• 悪い読み取り： クエリはNULLを返すが、AIはstringと想定し、ランタイムクラッシュにつながる。
• 壊れた関係： 関係キーはUUIDとして期待されるが、AIはstringとして扱い、誤ったガベージ値を送信する。ジョインはクラッシュしないが、データは返されない。このエラーは、結果が不足または一貫性がないと表面化するまで隠される。

これが、真剣なチームが型付け言語を使用し、スキーマからAPIまで型安全性を強制する理由である。如果そうでない場合、データベースはあなたを保護しなくなり、隠された問題は増える。

成熟したチームが厳格な型付けを強制する理由

厳格な型付けは、開発者を遅くすることではなく、スケールを可能にすることである。
型：

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

型安全性がなければ、AIのコードの粗さは悪化する。型安全性があれば、同じAIは信頼できるコードを生成する。

AIを型安全性に強制する方法

あなたはAIをジュニアエンジニアのように扱う必要がある。速く、才能があるが、方向性がなければ粗末である。

適切なコンテキストを提供する

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

厳格な指示を与える

非常に明確に、AIにanyを使用しないこと、unknownを許可しないこと、すべてのメソッド、オブジェクト、変数に型を付けることを伝える。AIはこれらの指示に従うのに苦労するだろう（特に最初のパスで）。

lintingで強制する

ジュニア開発者のコードをレビューするように、AIのコードをチェックする必要がある。カスタムのlintルールを設計し、「良いコード」とは何かを定義する。lintの失敗をモデルにフィードバックするまで繰り返す。数回かかるかもしれないが、型安全性を含めるための報酬関数をシフトする。

チェックを繰り返す

コンパイル時エラー、ランタイムログ、クリックスルーテスト。各イテレーションは、AIに型を絞り、プロダクションレベルのコードに近づくように強制する。

より良い構築方法

私は、生の生成速度を犠牲にしても、高品質を優先することは長期的には支払いが戻ってくることを学んだ。それは、any型に対するゼロトレランスを戦うこと、複数のフィードバックループと厳格なlintルールを強制することを意味する。AIはそれを通過するまで、コードを「完了」と呼ぶことはできない。継続的な努力が必要だが、それが唯一の方法で、品質が低下するのを防ぐことができる。

先ほど、私は重要な点を述べた：AIがランタイムエラーを型を緩和することで修正し始めると、悪性のサイクルに入る。各修正は別のガードレールを取り除き、結果はコンパイルされるが壊れやすく、メンテナンスできないコードベースになる。逆もまた真である：AIが毎回型安全性を尊重するように強制すれば、徳のサイクルを作り出す。各イテレーションはガードレールを絞り、コードベースはクリーンになり、品質は信頼性と構築性のものになる。

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