なぜ、コーディングのコストが桁違いに小さくなったのに従前の仕様書のままの運用なのか、書類を揃えないと安心できない官僚制なのか
ちゃんと読んでないけどFR-001とかのIDってユニークにできるの？
こういうのが切実にほしい。
LLMの気まぐれに頼らず、IDとハッシュで仕様と実装のズレを決定的に検知するのアプローチとして凄く良い
そうだね バージョン＋ハッシュでも良さそう
ひとつのイシューに関する実装が複数コード、モジュールにわたる場合でも対応できるのだろうか。それともイシューをコードに対応するレベルまで分割する方向だろうか
例の validatePassword が void or 例外投げる という部分が興味深い
長期間続けているうちにごちゃごちゃになったりしないだろうか
決定的に検出したいならTDDで良いのでは？
この辺、バランスが難しいよね...どんどんエージェントのskillが進化するから自前実装を躊躇してしまう...
SDDを理解できてないから的外れかもしれないけど、仕様とコードのズレって構成管理の仕組みで担保するものじゃないのか
「複数のドキュメントの整合性が維持できない」は割と現実的に感じてる痛みではあるが……関数単位の仕様についてはjsdocとかで困らないのだよな。ズレが出るのはより上の文書
仕様駆動開発のつらみは仕様とコードのズレではなくて、AIに指示するためにドキュメントが詳細設計レベルになってしまうことなんだよな。最終的にこのドキュメント必要？ってなる。
関数レベルの変更を検出するツール。仕様というか、入出力や振る舞いの詳細設計と関連付けるようだ。仕様と言うには詳細すぎるし、ハッシュは手段なので、本筋には関係が無い。／うまく機能する気がしないが。
TDDでAIがテストを書いたら誰が要求を満たした事を証明するのかって話でしょ?とはいえ、SDDで怖いのは仕様同士の矛盾や優先順位の認識ズレなのでなので、そこをカバーできないと痛みは無くならないと思う。
ズレを見つけるなんてお利口さんだにゃ！ボクの毛玉の絡まりも直してほしいにゃ。
AIそのまま感すごかったので真面目に読んでないが、コードはほぼ自動生成してる以上、今後もブラックボックス化が進むと思うのでテスト側と仕様書を紐づけたほうがまだ筋が良いように思う。
Ctx消費しないし更新が決定論的。応用すれば何にでも使えそう。専用のルールをAgentに強いるのがめんどいぐらいで、メンテが雑なことが予見されてるプロジェクトでは良さそう。考え方だけもらおうかな
仕様書駆動開発ってワンショットの仕様書でやるから仕様とコードなんかズレようがないと思うんだけど、わいの知ってる仕様書駆動開発とは別物のようだ
検証用ハーネス整備の話だと思うんだけど、作業が漏れるのはプラン時の検出が難しくなってるからだと思うので、ドキュメント構造を整備するとか、対応表を導入する等リーダビリティ整備もした方が良さそう
肝は検証をLLMでなく決定的CLIに任せ、Stop Hookのexitコードでループに挟んだ点。エージェントが自分の出力を自分で採点して通す構図を断てるのが、4層統合以上に効く
ついこういったツールで人間がコードを書く感覚でボトルネックや問題点が頭に浮かんでオールドタイプを実感する。開発スタイルで問題点が大分違うよなぁ。
よさそうー
仕様駆動開発で起こる「仕様とコードのズレ」をハッシュで決定的に検出するツールを作った
なぜ、コーディングのコストが桁違いに小さくなったのに従前の仕様書のままの運用なのか、書類を揃えないと安心できない官僚制なのか
ちゃんと読んでないけどFR-001とかのIDってユニークにできるの？
こういうのが切実にほしい。
LLMの気まぐれに頼らず、IDとハッシュで仕様と実装のズレを決定的に検知するのアプローチとして凄く良い
そうだね バージョン＋ハッシュでも良さそう
ひとつのイシューに関する実装が複数コード、モジュールにわたる場合でも対応できるのだろうか。それともイシューをコードに対応するレベルまで分割する方向だろうか
例の validatePassword が void or 例外投げる という部分が興味深い
長期間続けているうちにごちゃごちゃになったりしないだろうか
決定的に検出したいならTDDで良いのでは？
この辺、バランスが難しいよね...どんどんエージェントのskillが進化するから自前実装を躊躇してしまう...
SDDを理解できてないから的外れかもしれないけど、仕様とコードのズレって構成管理の仕組みで担保するものじゃないのか
「複数のドキュメントの整合性が維持できない」は割と現実的に感じてる痛みではあるが……関数単位の仕様についてはjsdocとかで困らないのだよな。ズレが出るのはより上の文書
仕様駆動開発のつらみは仕様とコードのズレではなくて、AIに指示するためにドキュメントが詳細設計レベルになってしまうことなんだよな。最終的にこのドキュメント必要？ってなる。
関数レベルの変更を検出するツール。仕様というか、入出力や振る舞いの詳細設計と関連付けるようだ。仕様と言うには詳細すぎるし、ハッシュは手段なので、本筋には関係が無い。／うまく機能する気がしないが。
TDDでAIがテストを書いたら誰が要求を満たした事を証明するのかって話でしょ?とはいえ、SDDで怖いのは仕様同士の矛盾や優先順位の認識ズレなのでなので、そこをカバーできないと痛みは無くならないと思う。
ズレを見つけるなんてお利口さんだにゃ！ボクの毛玉の絡まりも直してほしいにゃ。
AIそのまま感すごかったので真面目に読んでないが、コードはほぼ自動生成してる以上、今後もブラックボックス化が進むと思うのでテスト側と仕様書を紐づけたほうがまだ筋が良いように思う。
Ctx消費しないし更新が決定論的。応用すれば何にでも使えそう。専用のルールをAgentに強いるのがめんどいぐらいで、メンテが雑なことが予見されてるプロジェクトでは良さそう。考え方だけもらおうかな
仕様書駆動開発ってワンショットの仕様書でやるから仕様とコードなんかズレようがないと思うんだけど、わいの知ってる仕様書駆動開発とは別物のようだ
検証用ハーネス整備の話だと思うんだけど、作業が漏れるのはプラン時の検出が難しくなってるからだと思うので、ドキュメント構造を整備するとか、対応表を導入する等リーダビリティ整備もした方が良さそう
肝は検証をLLMでなく決定的CLIに任せ、Stop Hookのexitコードでループに挟んだ点。エージェントが自分の出力を自分で採点して通す構図を断てるのが、4層統合以上に効く
ついこういったツールで人間がコードを書く感覚でボトルネックや問題点が頭に浮かんでオールドタイプを実感する。開発スタイルで問題点が大分違うよなぁ。
よさそうー