読んでいないコードを私たちはどれだけ信頼できるのか
はじめに こんにちは、Grafana Labsでデベロッパーアドボケイトをしているものです。 私は2018年前後から、SRE*1の啓蒙に携わってきました。SREの実践では本番環境のオブザーバビリティは欠かせず、私もその重要性を強く主張してい...
nguyen-oiAI生成コードの品質管理やテスト・オブザーバビリティの重要性を論じた良記事。TDDがプロンプトエンジニアリング最強の形ってのは納得感あるな
2026/10/30 10:33★
KoshianXテストをごまかすかあ。この1ヶ月読まずにアプリ書くことやってみてるけど、とりあえず他のLLMに粗探しさせるなどして意外にちゃんと動いてるのでびっくりしてる。だがこれでずっといけるのかどうか
2026/10/30 10:44★★★★
syu-m-5151読んでいないコードを出すなら、戻せる変更を一部に限り、観測してから広げる。本番で見つけた暗黙の業務判断を仕様とテストへ戻す流れがよい。監視を足して安心する話ではなく、展開を止める判断まで設計したい。
2026/10/30 11:24
nacika_inscatolareテストコードとclaude security と 設計起こして読むでいいとおもう
2026/10/30 11:31
roshiコードを”信頼”したところで不具合は出るからなー。不可逆な事象以外は前のめりに倒れて（AIに修正させて）さっさと改善ループ回すでいいんじゃないの？と思ったり。
2026/10/30 11:37★
t-wada"OE2eの整理に従えば、TDDが確かめるのは仕様に対する正しさで、オブザーバビリティが確かめるのは現実に対する振る舞いです。オブザーバビリティをTDDのフィードバックループを本番環境まで延ばしたものと捉えています"
2026/10/30 12:11
sakidatsumonoしかしその前もimportしたライブラリの中は読んでいない
2026/10/30 12:46★★★★★★★
terazzo具体例としてSQLのチューニングを考えると分かり易そう。／所要時間の合計だけじゃなくて計算論的制約も課すことが出来るように思う。反例の代わりに最悪ケース(もしくはそこそこ悪いケース)を探させる。
2026/10/30 13:11
momonga_dashなんかあった時の影響範囲が限られてて、すぐ気づけて、すぐ無かったことにできるほど、意思決定は簡単になる
2026/10/30 13:22★★
door-s-dev改めて考えてみると今までもライブラリのコードは読んでなかったな
2026/10/30 13:28
aobon700経験的にコードの質より、AIを信頼しすぎて、雑な指示で手間取る事の方が多いかな
2026/10/30 13:39
hiroomi開発時のテストだけでなく、本番環境での観測（オブザーバビリティ）によって、実際の動作や品質を継続的に検証する必要がある。工程が開発より外側で
2026/10/30 14:30
questbeat“ ”
2026/10/30 15:42
ngmy大昔のSIerみたいなことになってきたな。
2026/10/30 15:52
atsushieno自分も普段から「依存ライブラリのコードは読んでこなかったでしょ」って言って回っているほうだが、ライブラリの選択の時点である程度フィルタリングしていることも忘れてはならない。
2026/10/30 16:08
potnips非エンジニアは人間がコード書いてた時から「わからんけど信頼する」しかなかった。AIは嫌な顔せずに納得するまで説明してくれるから、エンジニアとプロジェクトを進めるより中身の理解は楽になった
2026/10/30 16:58
knok開発を外注して検収でコードまでみたことはないかな…仕事のタイプによってはやるのかもしれない
2026/10/30 17:30