Fuck-u-code: AIパイプラインが見落としていた Deterministic 品質ゲート
型チェック、lint、設計ルールはある。でも deterministic スタックは複雑性、重複、命名の惨状を見抜けない。$0で解決する方法を紹介する。
今のAIコードパイプラインの実態を正直に見てみよう。 Cursor や Claude Code でコードを生成する。TypeScript の strict モードが型の不一致を捕捉するから、 を実行する。ESLint…
アイデアとインサイト
AI ファースト開発、コーディングガードレール、使い捨て前提のアーキテクチャを探求します。
Rustのプロパティベーステストが単体テストでは見逃すバグを見つける
例ベースのテストは思いついた入力だけをカバーする。プロパティベースのテストはランダムデータを生成し、不変条件を検証し、失敗を最小の反例まで縮小する。
関数を書いた。 と でテストして、パスした。リリースした。 ユーザーが1要素のスライスを渡すと、関数はそれを黙って落とす。Issueが立つ。テストファイルを見つめながら、こんな当たり前のことにどうして気づかなかったのかと思う。…
バージョン1は決して問題ではない：AIコーディングと長期保守
AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。
すべてのAIコーディングデモは同じ流れをたどる。誰かがモデルにプロンプトする。動くアプリが現れる。聴衆は感心する。 当然そうなるべきだ。速度は本物だ。能力は本物だ。バージョン1はAIがループに入ることで確実に速く出荷される。 問題は、バージョン1は決して難しい部分ではなかったということだ。…
AI生成コードと置換可能性の原則
AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。
AI生成コードの品質に関する議論の多くは、生成時点での正確性に焦点を当てている。出力はコンパイルできるか？テストに通るか？仕様に合致するか？ これらは最低限の条件にすぎない。本当のコストについては何も教えてくれない。…
AI Codebaseのための決定的ガードレール
人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。
AI生成コードに対する標準的なアドバイスは「注意深くレビューせよ」だ。 このアドバイスは正しいが、スケールにおいては無意味だ。 AI出力をレビューする開発者は、注意力があり、ドメインに精通し、時間的プレッシャーがないときに問題を発見する。それ以外のすべての条件 — つまり大半の条件 — では、見落としが発生する。…
ユニットテストはパスする。本番コードは壊れたまま。
コードカバレッジのメトリックは偽の安心感を生む。ここでは、ユニットテストがなぜ実際に寝不足を引き起こすバグを見逃し、代わりに何をテストすべきかを解説する。
コードカバレッジ90%なのに、午前2時にページャーが鳴った。 ユニットテストはパスした。CIはグリーンだった。それでもバグは本番に潜り込んだ。カバレッジは嘘をつかなかったが、真実も語らなかった。実行された行を測定しただけで、実際に検証された振る舞いを測定したわけではないからだ。…
Rustのランタイムcontractsはリリースビルドで無料にできるが、コンパイラは勝手にやってくれない
Rustはdebug assertionsを自動で除去するが、本物のdesign-by-contractにはdebug_assert!以上のものが必要だ。リリースバイナリーから完全に消えるゼロコストのランタイムcontractsを作る方法を紹介する。
Rustは開発中にランタイムcontractsを強制し、リリースビルドから完全に消し去ることができる。ただし、この言語はcontractsを第一級の概念として扱っていない。ビルディングブロックは手に入るが、自分で配線を引く必要がある。…
ゼロ、一、それとも十二：本番環境の関数に実際に必要なアサーションの数
開発者はアサーションを紙吹雪のように撒き散らすか、あるいは完全に避けるかのどちらかだ。有用な不変条件と本番クラッシュのトリガーを分ける判断フレームワークを紹介する。
ほとんどの本番 codebase は、二つの派閥のいずれかに属する。派閥Aは…
バリデーション層がビジネスロジックより肥大化している
手作りのバリデーションは codebase を膨張させ、それでもエッジケースを見逃す。宣言的なスキーマで runtime contracts を enforce し、実装に干渉しない方法を解説する。
API がリクエストを受け取るたびにバリデーションを行う。外部システムから引数を受け取る関数も同様にチェックする。これを手作業で行うと、1つのエンドポイントにビジネスロジックを超える量のバリデーションコードが蓄積する。 これは runtime contracts に伴う隠れたコストだ。type system…
TypeScriptのstrictNullChecksはコンパイル時のガードであり、実行時の盾ではない
strict modeはあなたが書いたnullを捉えるが、APIやDOMクエリ、JSON.parseから実行時に到達するnullは捉えない。型システムが終わり、あなたの防御が始まる境界はここだ。
でを有効にした。赤い波線をすべて修正した。やはもう解決した問題だと確信して、プロダクションにリリースした。 するとバックエンドのレスポンスの構造が変わり、DOMクエリが何も返さず、がTypeScriptが安全だと教えてくれたまさにそのコードでを投げた。何が起きたのか？ TypeScriptのstrict null…