分かりみが深い。確か「文章を書くように」と設計されたCOBOLが意外とAI時代は相性良かったりして（笑）
SDDを、SSoT -> Code の順で作ると思っているからおかしくなる。Spec は、commit できる Plan-mode だ。技術面の SSoT は ADR とか、各フェイズの最後に整合させる。今後はSDD + E2E が無いと修正,レビューで律速になる
ここで「ぴゅう太」の日本語ベーシックですよ🤔
全体のドキュメントは欲しいけど、機能単位は要らないよね
計画⇒実装⇒検証 の順番にすすめる。仕様は計画に含める 何を作るか決めないと何もできない
SSDのドキュメントは意思決定した内容のみの最小限に留める努力が必要なんでは？AI目線でコードだけだと絶対変えられない仕様というのがわからんし。詳細にドキュメント詰め過ぎたらただの二重定義
結局ドキュメントが腐るのはAI時代も同じか。盆栽いじってる方がマシってのは草
コードだけ置いて説明の無い技術ブログとか溢れてるけどあれはやめてほしい。ドキュメント不要論の勘違い。
コードを読めばわかる人のみの職場ならいいのでは？他人どころか将来の自分がコードを読んで「よくわからん…」となる可能性もあるから、自然言語で読みやすいドキュメントが必要なわけで。
アーキテクチャの全体図の話でIaCの話をする人の意見が参考になるとは思えない。
わかる。仕様をAIに書かせると必要最低限なドキュメントにならんし、綺麗なだけで可読性もほどほど。最初に作業計画とテストで作って、ドキュメントは最後、が今のところ満足いく。
どの範囲でいらないという話かよくわからんが、人間がテストしないで完成にする前提なの？
仕様駆動開発、いつのまにか狭義の意味での仕様駆動開発のことを指す言葉になっており、使うのがめんどくさい言葉になっている感があり
関係者全員がコードを読めるならね
仕様駆動開発はやめた方がええ
分かりみが深い。確か「文章を書くように」と設計されたCOBOLが意外とAI時代は相性良かったりして（笑）
SDDを、SSoT -> Code の順で作ると思っているからおかしくなる。Spec は、commit できる Plan-mode だ。技術面の SSoT は ADR とか、各フェイズの最後に整合させる。今後はSDD + E2E が無いと修正,レビューで律速になる
ここで「ぴゅう太」の日本語ベーシックですよ🤔
全体のドキュメントは欲しいけど、機能単位は要らないよね
計画⇒実装⇒検証 の順番にすすめる。仕様は計画に含める 何を作るか決めないと何もできない
SSDのドキュメントは意思決定した内容のみの最小限に留める努力が必要なんでは？AI目線でコードだけだと絶対変えられない仕様というのがわからんし。詳細にドキュメント詰め過ぎたらただの二重定義
結局ドキュメントが腐るのはAI時代も同じか。盆栽いじってる方がマシってのは草
コードだけ置いて説明の無い技術ブログとか溢れてるけどあれはやめてほしい。ドキュメント不要論の勘違い。
コードを読めばわかる人のみの職場ならいいのでは？他人どころか将来の自分がコードを読んで「よくわからん…」となる可能性もあるから、自然言語で読みやすいドキュメントが必要なわけで。
アーキテクチャの全体図の話でIaCの話をする人の意見が参考になるとは思えない。
わかる。仕様をAIに書かせると必要最低限なドキュメントにならんし、綺麗なだけで可読性もほどほど。最初に作業計画とテストで作って、ドキュメントは最後、が今のところ満足いく。
どの範囲でいらないという話かよくわからんが、人間がテストしないで完成にする前提なの？
仕様駆動開発、いつのまにか狭義の意味での仕様駆動開発のことを指す言葉になっており、使うのがめんどくさい言葉になっている感があり
関係者全員がコードを読めるならね