AI ファースト開発、コーディングガードレール、使い捨て前提のアーキテクチャを探求します。
AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。
すべてのAIコーディングデモは同じ流れをたどる。誰かがモデルにプロンプトする。動くアプリが現れる。聴衆は感心する。 当然そうなるべきだ。速度は本物だ。能力は本物だ。バージョン1はAIがループに入ることで確実に速く出荷される。 問題は、バージョン1は決して難しい部分ではなかったということだ。…
AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。
AI生成コードの品質に関する議論の多くは、生成時点での正確性に焦点を当てている。出力はコンパイルできるか？テストに通るか？仕様に合致するか？ これらは最低限の条件にすぎない。本当のコストについては何も教えてくれない。…
人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。
AI生成コードに対する標準的なアドバイスは「注意深くレビューせよ」だ。 このアドバイスは正しいが、スケールにおいては無意味だ。 AI出力をレビューする開発者は、注意力があり、ドメインに精通し、時間的プレッシャーがないときに問題を発見する。それ以外のすべての条件 — つまり大半の条件 — では、見落としが発生する。…
コードカバレッジのメトリックは偽の安心感を生む。ここでは、ユニットテストがなぜ実際に寝不足を引き起こすバグを見逃し、代わりに何をテストすべきかを解説する。
コードカバレッジ90%なのに、午前2時にページャーが鳴った。 ユニットテストはパスした。CIはグリーンだった。それでもバグは本番に潜り込んだ。カバレッジは嘘をつかなかったが、真実も語らなかった。実行された行を測定しただけで、実際に検証された振る舞いを測定したわけではないからだ。…
Rustはdebug assertionsを自動で除去するが、本物のdesign-by-contractにはdebug_assert!以上のものが必要だ。リリースバイナリーから完全に消えるゼロコストのランタイムcontractsを作る方法を紹介する。
Rustは開発中にランタイムcontractsを強制し、リリースビルドから完全に消し去ることができる。ただし、この言語はcontractsを第一級の概念として扱っていない。ビルディングブロックは手に入るが、自分で配線を引く必要がある。…
開発者はアサーションを紙吹雪のように撒き散らすか、あるいは完全に避けるかのどちらかだ。有用な不変条件と本番クラッシュのトリガーを分ける判断フレームワークを紹介する。
ほとんどの本番 codebase は、二つの派閥のいずれかに属する。派閥Aは…
手作りのバリデーションは codebase を膨張させ、それでもエッジケースを見逃す。宣言的なスキーマで runtime contracts を enforce し、実装に干渉しない方法を解説する。
API がリクエストを受け取るたびにバリデーションを行う。外部システムから引数を受け取る関数も同様にチェックする。これを手作業で行うと、1つのエンドポイントにビジネスロジックを超える量のバリデーションコードが蓄積する。 これは runtime contracts に伴う隠れたコストだ。type system…
strict modeはあなたが書いたnullを捉えるが、APIやDOMクエリ、JSON.parseから実行時に到達するnullは捉えない。型システムが終わり、あなたの防御が始まる境界はここだ。
でを有効にした。赤い波線をすべて修正した。やはもう解決した問題だと確信して、プロダクションにリリースした。 するとバックエンドのレスポンスの構造が変わり、DOMクエリが何も返さず、がTypeScriptが安全だと教えてくれたまさにそのコードでを投げた。何が起きたのか？ TypeScriptのstrict null…
AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。
AI と一緒に数週間でもリリースを回していれば、この感覚にはもう覚えがあるはずです。 PR を開く。コードは十分きれいだ。命名も悪くない。テストもある。見た目には明らかな破綻はない。なのに、どこかがおかしい。 境界が少し曖昧なのかもしれない。contract…
AI-generated code を production で持たせたいなら、code review だけでは足りません。type constraints から mutation testing、runtime containment までの layered safety stack が必要です。
AI-generated code の危険なところは、常に間違っていることではありません。 危険なのは、merge できてしまう程度には正しく見えることです。 そこが本当のリスクです。明らかに壊れている code は止まります。もっともらしく見え、いくつかの happy-path tests を通り、しかも重要な…