AIに良い仕事をさせるにはコンテキストの設計が命って話だな。仕様DBを作る根気が凄いわ
自分もClaudeにテスト生成を任せて3ヶ月、結局異常系の網が薄いまま事故った。原因は要件の境界条件を自然言語で投げてた怠慢、表で渡すと精度が変わる
ソース、設計資料、DBへのアクセス権も与えて網羅的なテスト作ってもらったら、イッパツでめきめき利用枠を消費しちゃった＾＾； 貧乏AIerのつらいところ。
生成AI、カッチリ網羅するの苦手な気がしている。80%くらいの正解率で良いものに向いていて、テストケースはどうなんだろ。
生成AIには、目や耳、身体が無い。つまりは現実世界を観測できず、現実世界に基づいた情報は推測して作るしかない。現実世界を観測しなくても推測を促す情報を与えてあげる。テストに限らずこの観点で考えてる
aiに期待するのはこういうところなんだけどね。テストの作成や保守なんて人間の仕事ではない
そもそものテスト設計が出来てないのでは？この記事だとどのレイヤーのテストなのかも意識していないように見える
LLMの答えは文脈次第なので、コンテキスト（仕様やコードベース）を渡さないと答えも見当はずれになるっていう当たり前の話が書いてある？ 「〇〇の情報をくれないと答えられない」をチェックする skill を作れば良さそ
ドキュメントをまともに作らづに、雑に開発している会社は品質が上がらない、安定しないという当たり前のお話。
別のエージェントにレビューさせて合格点のゲート設けないと、アプリが腐るよ
AIでできる事はどんどん増えてるけど、結局は使う人(指示)次第で品質や結果が変わるよね。
状態数が多いと途端にポンコツになるんだよ、でほとんどの難しいAIに助けてほしい仕事ほど状態数が多い
全パス網羅のホワイトボックステスト構築には向いていると思う。問題はそれを日常的に実行していると開発が進まなくなるくらい時間がかかるようになること。一部省略すると、そこがバグったりケースが陳腐化する。
仕様DBを作るのはいいね。（現状は）結局人間が確認しなきゃいけないので、AIと人間の双方が使いやすい仕様の管理方法が必要。まぁいずれはAIのほうが人間より漏れや間違いが少なくなるかもしれないけど…
あれほど頼れるAIが、しょっぱいテストケースを作ってくる理由を考えた - Qiita
AIに良い仕事をさせるにはコンテキストの設計が命って話だな。仕様DBを作る根気が凄いわ
自分もClaudeにテスト生成を任せて3ヶ月、結局異常系の網が薄いまま事故った。原因は要件の境界条件を自然言語で投げてた怠慢、表で渡すと精度が変わる
ソース、設計資料、DBへのアクセス権も与えて網羅的なテスト作ってもらったら、イッパツでめきめき利用枠を消費しちゃった＾＾； 貧乏AIerのつらいところ。
生成AI、カッチリ網羅するの苦手な気がしている。80%くらいの正解率で良いものに向いていて、テストケースはどうなんだろ。
生成AIには、目や耳、身体が無い。つまりは現実世界を観測できず、現実世界に基づいた情報は推測して作るしかない。現実世界を観測しなくても推測を促す情報を与えてあげる。テストに限らずこの観点で考えてる
aiに期待するのはこういうところなんだけどね。テストの作成や保守なんて人間の仕事ではない
そもそものテスト設計が出来てないのでは？この記事だとどのレイヤーのテストなのかも意識していないように見える
LLMの答えは文脈次第なので、コンテキスト（仕様やコードベース）を渡さないと答えも見当はずれになるっていう当たり前の話が書いてある？ 「〇〇の情報をくれないと答えられない」をチェックする skill を作れば良さそ
ドキュメントをまともに作らづに、雑に開発している会社は品質が上がらない、安定しないという当たり前のお話。
別のエージェントにレビューさせて合格点のゲート設けないと、アプリが腐るよ
AIでできる事はどんどん増えてるけど、結局は使う人(指示)次第で品質や結果が変わるよね。
状態数が多いと途端にポンコツになるんだよ、でほとんどの難しいAIに助けてほしい仕事ほど状態数が多い
全パス網羅のホワイトボックステスト構築には向いていると思う。問題はそれを日常的に実行していると開発が進まなくなるくらい時間がかかるようになること。一部省略すると、そこがバグったりケースが陳腐化する。
仕様DBを作るのはいいね。（現状は）結局人間が確認しなきゃいけないので、AIと人間の双方が使いやすい仕様の管理方法が必要。まぁいずれはAIのほうが人間より漏れや間違いが少なくなるかもしれないけど…