production

4 posts

エラートラッカーはどこで死んだか知っている。再現には役立たない

スタックトレースはクラッシュの発生場所を示すが、原因ではない。ここでは、本番のクラッシュを実際にデバッグ可能なローカルテストケースに変える、キャプチャ&リプレイのパターンを解説する。

本番がどこでクラッシュしたかは正確にわかっている。スタックトレースは の147行目を指している。例外は に対する だ。コードを引っ張り出してテストを実行すれば、すべて合格する。サンプルペイロードでエンドポイントを手動で叩いても、問題なく動く。 バグは本物だ。顧客が遭遇している。自分のマシンでは再現できない。…

テストはパスした。だがデータはまだ間違っている

statistical debuggingは本番データを信号として扱い、バグをその異常として捉える。unit testを1つも追加せずに、データの破損、オフバイワンエラー、静かな失敗を見つける方法を解説する。

テストスイートはグリーンだ。ログは静かだ。ダッシュボードに赤い線はない。それでも、ユーザーの3%がマイナスの合計金額の請求書を受け取っているかもしれないし、推薦モデルが削除された製品を静かに先頭にランキングしているかもしれないし、集計パイプラインが特定のタイムゾーンからの返金を二重にカウントしているかもしれない。…

恐怖か驀進か:AIコーディングが分ける二つの現実

AIコーディングが機能するのは、どんな混乱からも立ち直れるエリートチームだけ。それ以外に残るのは恐怖とCI失敗と放棄された実験。格差の本質はモデルではない。

同じAIモデルを使う二つのチームを観察すれば、まったく異なる二つの結果を目にするだろう。…

本番環境でのAIコーディング:ほとんどのチームが挫折する理由

ほとんどのチームはAIコーディングを試し、QAに不合格になるコードをリリースし、そして諦める。問題はモデルではない——AIの出力を信頼できるものにするガードレールの欠如だ。

AIコーディングを試すほとんどのチームは、同じ軌跡をたどる。 最初は興奮している。モデルが数分で機能を生成し、それをリリースする。QAがバグを見つけ、修正をリリースする。QAがさらに別のバグを見つける。今度は無関係であるはずの別のmoduleだ。修正は14ファイルに及び、QAはさらに3つの問題を発見する。…