#テスト

この記事を読んでまず思ったのは、ツールが「正しそうに見える間違い」を平然と出す怖さが、かなり生々しく書かれているな、ということだった。しかも厄介なのは、単にバグを踏んだ話ではなく、調べた先の見え方そのものが誤解を誘う形になっていた点だと思う。 いちばん引っかかったのは、package rename が「存在しない package」と区別できないという話だ。version を見ているだけでは、まだ出ていないのか、名前が変わったのか分からない。言われてみれば当たり前なのに、実際にはその当たり前を見落としやすい。機械的な checker ほど、見つかった事実だけで断定してしまう危うさがあるんだなと思った。 もうひとつ印象に残ったのは、broken link の話だ。spec を参照しているつもりのリンクが、実は overview に飛ぶだけで、見た目には壊れていない。これはかなり嫌な失敗で、単に「リンクが切れている」よりタチが悪い。検証できる顔をしながら、実際には検証先が違う。こういうのは人間でも気づきにくいし、だからこそ test で縛るしかないのだろう。 ただ、ここで面白いのは「dete

この元記事は、APIドキュメントの書き方ひとつで、AI agent が普通に失敗する話を扱っている 問題は「出力は number、入力は string」という型のズレ。人間は気づいて回避しても、agent はそのままつなぐので落ちる テストも人間向けの書き方になっていて、`String()` で勝手に直していたからバグを見逃していた 直し方としては、出力側を変えるのではなく、入力側を広げるのが安全だった ただし `z.union()` や `z.coerce.string()` には別の危険があるので、筆者は `preprocess` で限定的に吸収する方法を選んでいる いまのAIは「空気を読む」のではなく、文字どおりに実行する。だからAPI docs も、テストも、そこに合わせて鍛え直す必要がある この記事で扱っているのは、かなり地味だけれど、実はものすごく厄介なバグです。 著者たちは helpdesk の仕組みを MCP 経由で AI agent に触らせていて、agent はチケット一覧を取り、スレッドを読み、下書きを作る、といった操作ができるようになっていました。 で、ある日、

著者は、AI coding を使っていると「人間なら即クビ」レベルの妙な挙動に何度も遭遇したが、それでも利用をやめるどころか、さらに使い込むようになった。 この記事の中心テーマは、AI にコードを書かせるときは code review 以上に test process が大事 だ、という主張。 その根拠として、著者は昔働いていた CPU 設計会社 Centaur のテスト文化を紹介する。そこでは、手書きテストより fuzzing や random testing を重視し、unit test はほぼ使わず、専任の test engineer がいた。 著者は、AI 時代の開発でも「人間が全部レビューする」より、「大量の自動テストで叩く」ほうが現実的で、しかも強いと考えている。 ただし、これは単なる理想論ではなく、実際にバグを見つけて直してきた現場の感覚から来ている。 本文を読んでまず面白いのは、著者の出発点がかなり変わっていることです。AI coding を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バ