3 posts
手作りのバリデーションは codebase を膨張させ、それでもエッジケースを見逃す。宣言的なスキーマで runtime contracts を enforce し、実装に干渉しない方法を解説する。
API がリクエストを受け取るたびにバリデーションを行う。外部システムから引数を受け取る関数も同様にチェックする。これを手作業で行うと、1つのエンドポイントにビジネスロジックを超える量のバリデーションコードが蓄積する。 これは runtime contracts に伴う隠れたコストだ。type system…
AI-generated code を production で持たせたいなら、code review だけでは足りません。type constraints から mutation testing、runtime containment までの layered safety stack が必要です。
AI-generated code の危険なところは、常に間違っていることではありません。 危険なのは、merge できてしまう程度には正しく見えることです。 そこが本当のリスクです。明らかに壊れている code は止まります。もっともらしく見え、いくつかの happy-path tests を通り、しかも重要な…
Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。
ソフトウェアエンジニアリングには、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。 function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage…