知識が育つブログ

AI が書いた TypeScript を毎回同じ基準で受け入れるか拒否するかを判定するために、型が所有する範囲を確定し、はしごで過剰設計をふるい落とし、コンパイラの証拠を残す方法をまとめた記事

同じ依頼でも毎回違うコードを出す AI を、テスト・リント・スクリプトといった決定論的な装置を何層も重ねて検査し、モジュール化で検査単位を細かく分けるワークフローを段階ごとに解説します

AI が書いたコードが静かに誤る理由と、正解をテストで再現し、ハーネスを整え、独立したレビュアーを付ける三つの柱を初心者にも分かるように解説します

カラム配列からソートキーの union を導出し、ドメインごとに異なる行の型を合成コンポーネントの各パーツまで届けながら学んだこと — そしてその過程で何度も顔を出した変性の話

コード生成ツールに作業を任せる際、判定基準を先に文書化し、コード・画面・レビュー意見を証拠へ格下げし、確信が足りなければ止める設計を整理した

分離された拡張機能の実行空間でメッセージベース RPC によって保存を依頼し、変更信号と query 無効化で別画面が単一の原本を読み直す流れを整理した

assertNever、satisfies Record、パターンマッチライブラリという三つの層のうち何をいつ使うか、そして catch-all のデフォルト分岐が漏れを隠してしまう理由

Record が約束する totality、何も検査しない type predicate、実行タイミングが違う wrapper の ReturnType、sanitizer と勘違いされる excess property check のように、実装が守らないことを型が約束してしまうパターン

導出できる値は保存せず、ライブラリがすでに所有している union はコピーせず、それでも残る client 状態だけを union にする順序と、状態に action を入れてはいけない理由