AI生成コードの品質管理やテスト・オブザーバビリティの重要性を論じた良記事。TDDがプロンプトエンジニアリング最強の形ってのは納得感あるな
テストをごまかすかあ。この1ヶ月読まずにアプリ書くことやってみてるけど、とりあえず他のLLMに粗探しさせるなどして意外にちゃんと動いてるのでびっくりしてる。だがこれでずっといけるのかどうか
読んでいないコードを出すなら、戻せる変更を一部に限り、観測してから広げる。本番で見つけた暗黙の業務判断を仕様とテストへ戻す流れがよい。監視を足して安心する話ではなく、展開を止める判断まで設計したい。
テストコードとclaude security と 設計起こして読むでいいとおもう
コードを”信頼”したところで不具合は出るからなー。不可逆な事象以外は前のめりに倒れて（AIに修正させて）さっさと改善ループ回すでいいんじゃないの？と思ったり。
"OE2eの整理に従えば、TDDが確かめるのは仕様に対する正しさで、オブザーバビリティが確かめるのは現実に対する振る舞いです。オブザーバビリティをTDDのフィードバックループを本番環境まで延ばしたものと捉えています"
ライブラリのコード、読んでなかったよなあ、と思いつつ、よく使うライブラリやフレームワークのコードは読んでたわけで…
しかしその前もimportしたライブラリの中は読んでいない
具体例としてSQLのチューニングを考えると分かり易そう。／所要時間の合計だけじゃなくて計算論的制約も課すことが出来るように思う。反例の代わりに最悪ケース(もしくはそこそこ悪いケース)を探させる。
なんかあった時の影響範囲が限られてて、すぐ気づけて、すぐ無かったことにできるほど、意思決定は簡単になる
改めて考えてみると今までもライブラリのコードは読んでなかったな
経験的にコードの質より、AIを信頼しすぎて、雑な指示で手間取る事の方が多いかな
開発時のテストだけでなく、本番環境での観測（オブザーバビリティ）によって、実際の動作や品質を継続的に検証する必要がある。工程が開発より外側で
“ ”
大昔のSIerみたいなことになってきたな。
自分も普段から「依存ライブラリのコードは読んでこなかったでしょ」って言って回っているほうだが、ライブラリの選択の時点である程度フィルタリングしていることも忘れてはならない。
非エンジニアは人間がコード書いてた時から「わからんけど信頼する」しかなかった。AIは嫌な顔せずに納得するまで説明してくれるから、エンジニアとプロジェクトを進めるより中身の理解は楽になった
開発を外注して検収でコードまでみたことはないかな…仕事のタイプによってはやるのかもしれない
その議論は去年の今やっていれば価値もあっただろうが。Claude CodeやCodexのバグの出方が明らかにコードを見ていないものだったから、もう結論は出ている。
人間不信と同じだよ
いやまあライブラリは時の洗礼受けてるしね。。確からしさはスクラッチと比べればダンチではあるっしょ
遠くて近い つかめない どんなコードかわからない ゆっくり消える虹見てて トリコじかけになる♪
"各種テストを反例や限界の探索にも使い、技術仕様と非機能要件は本番環境でも確かめるのがよいと考えています。戻せる変更を限られた範囲に出し、SLOと観測結果をもとに展開を進めるかを判断"
今まで開発してきたときにミドルウェアのコードを全部読んできたか？って話（必要に応じて読むかもしれないが）、古くて新しい話
OS ベンダーが提供しているライブラリなどはベンダーを信頼。よく使われているライブラリは battle tested という判断。有名 OSS はリーナスの法則を期待。LLM のコードについてはどうなんだろうね。
あとで読む（コードを）
99％の事例では問題にならないと思うが,問題は「こけると人が死ぬ」1%のシステム。本番環境でしか掴めない要件不足の類があってはならないが,AI主導TDD等が主流になっても「AI抜きで開発してコスト10倍」を許容できるのか
信頼してない
TDDやハーネスは前提で、仕様通りのコードは書いてくれる。けど、いかに仕様に出なかった不具合やBugを見つけるかってことだと思ってる。
たしかに。そもそもimport先全部みてないのに（見てるわって方にはすみません）AIが書いたコード全部読んだかどうかが議論になるの面白い。
"ソフトウェア工学では、仕様どおりに作れているかを確かめることを検証（verification）と呼びます。作ったものが本当に求められていたものかを確かめる妥当性確認（validation）とは、区別されてきました*16。"
“AIが書くテストの精度が上がっても、判定の基準になる仕様や性質は人間の理解に依存します。”
「判定の基準になる仕様や性質は人間の理解に依存」＝「医療の世界でも同じ、診断・治療の根拠となる『臨床推論』は人間（医療従事者）の理解に依存する」
読んでいないコードを私たちはどれだけ信頼できるのか - YAMAGUCHI::weblog
AI生成コードの品質管理やテスト・オブザーバビリティの重要性を論じた良記事。TDDがプロンプトエンジニアリング最強の形ってのは納得感あるな
テストをごまかすかあ。この1ヶ月読まずにアプリ書くことやってみてるけど、とりあえず他のLLMに粗探しさせるなどして意外にちゃんと動いてるのでびっくりしてる。だがこれでずっといけるのかどうか
読んでいないコードを出すなら、戻せる変更を一部に限り、観測してから広げる。本番で見つけた暗黙の業務判断を仕様とテストへ戻す流れがよい。監視を足して安心する話ではなく、展開を止める判断まで設計したい。
テストコードとclaude security と 設計起こして読むでいいとおもう
コードを”信頼”したところで不具合は出るからなー。不可逆な事象以外は前のめりに倒れて（AIに修正させて）さっさと改善ループ回すでいいんじゃないの？と思ったり。
"OE2eの整理に従えば、TDDが確かめるのは仕様に対する正しさで、オブザーバビリティが確かめるのは現実に対する振る舞いです。オブザーバビリティをTDDのフィードバックループを本番環境まで延ばしたものと捉えています"
ライブラリのコード、読んでなかったよなあ、と思いつつ、よく使うライブラリやフレームワークのコードは読んでたわけで…
しかしその前もimportしたライブラリの中は読んでいない
具体例としてSQLのチューニングを考えると分かり易そう。／所要時間の合計だけじゃなくて計算論的制約も課すことが出来るように思う。反例の代わりに最悪ケース(もしくはそこそこ悪いケース)を探させる。
なんかあった時の影響範囲が限られてて、すぐ気づけて、すぐ無かったことにできるほど、意思決定は簡単になる
改めて考えてみると今までもライブラリのコードは読んでなかったな
経験的にコードの質より、AIを信頼しすぎて、雑な指示で手間取る事の方が多いかな
開発時のテストだけでなく、本番環境での観測（オブザーバビリティ）によって、実際の動作や品質を継続的に検証する必要がある。工程が開発より外側で
“ ”
大昔のSIerみたいなことになってきたな。
自分も普段から「依存ライブラリのコードは読んでこなかったでしょ」って言って回っているほうだが、ライブラリの選択の時点である程度フィルタリングしていることも忘れてはならない。
非エンジニアは人間がコード書いてた時から「わからんけど信頼する」しかなかった。AIは嫌な顔せずに納得するまで説明してくれるから、エンジニアとプロジェクトを進めるより中身の理解は楽になった
開発を外注して検収でコードまでみたことはないかな…仕事のタイプによってはやるのかもしれない
その議論は去年の今やっていれば価値もあっただろうが。Claude CodeやCodexのバグの出方が明らかにコードを見ていないものだったから、もう結論は出ている。
人間不信と同じだよ
いやまあライブラリは時の洗礼受けてるしね。。確からしさはスクラッチと比べればダンチではあるっしょ
遠くて近い つかめない どんなコードかわからない ゆっくり消える虹見てて トリコじかけになる♪
"各種テストを反例や限界の探索にも使い、技術仕様と非機能要件は本番環境でも確かめるのがよいと考えています。戻せる変更を限られた範囲に出し、SLOと観測結果をもとに展開を進めるかを判断"
今まで開発してきたときにミドルウェアのコードを全部読んできたか？って話（必要に応じて読むかもしれないが）、古くて新しい話
OS ベンダーが提供しているライブラリなどはベンダーを信頼。よく使われているライブラリは battle tested という判断。有名 OSS はリーナスの法則を期待。LLM のコードについてはどうなんだろうね。
あとで読む（コードを）
99％の事例では問題にならないと思うが,問題は「こけると人が死ぬ」1%のシステム。本番環境でしか掴めない要件不足の類があってはならないが,AI主導TDD等が主流になっても「AI抜きで開発してコスト10倍」を許容できるのか
信頼してない
TDDやハーネスは前提で、仕様通りのコードは書いてくれる。けど、いかに仕様に出なかった不具合やBugを見つけるかってことだと思ってる。
たしかに。そもそもimport先全部みてないのに（見てるわって方にはすみません）AIが書いたコード全部読んだかどうかが議論になるの面白い。
"ソフトウェア工学では、仕様どおりに作れているかを確かめることを検証（verification）と呼びます。作ったものが本当に求められていたものかを確かめる妥当性確認（validation）とは、区別されてきました*16。"
“AIが書くテストの精度が上がっても、判定の基準になる仕様や性質は人間の理解に依存します。”
「判定の基準になる仕様や性質は人間の理解に依存」＝「医療の世界でも同じ、診断・治療の根拠となる『臨床推論』は人間（医療従事者）の理解に依存する」