仮説階層モデル - kawasima

仕様を「正解」じゃなく「仮説」と定義し直すの、不確実な開発には刺さるな。階層化して検証コストを意識するのは、AI時代の基本になりそう

"LLMとエージェントによって（…）仕様は「正解を先に固める文書」から、「仮説を構造化し、どのエビデンスで採択・棄却するかを明示する文書」へ変わる"

アブダクション

仕様を『正解の指示書』から『仮説×採択基準』へ再定義する設計論。実装層は安くなり上位の価値・行動仮説は依然現実観測律速、採択基準を仕様の主役に据える視点が肝

こういうむずかしいこともAIがやってくれて、人間はぼけーっとしてればいい世界を作る、という政党に投票したい。AIの時代には資本主義はもう時代遅れだよ。

もともと仕様は仮説のベースライン（仕様が正解という考え方は受託文化の悪癖）で、コーディング&テストが仮説検証の場であったが、LLMは仕様を正解としてしまうので仮説検証の場を新たに設ける必要があるということ

「何を作るか」より「何が満たされたら採択するか」が主役。これはGojko Adzicの[Specification by Example https://martinfowler.com/bliki/SpecificationByExample.html]が、抽象的な記述ではなく具体的な受け入れ基準を仕様の中心に据えた

これは硬直的な人間を絶対に説得できないやつ。役職なしでは政治的に無理なのでこれをやりたいならそれができる組織に行くしかない。

仮説とは不確実性を含んだ主張。 エビデンスとはその不確実性を減らすために集める観測。 学習とは、エビデンスを元として仮説の不確実性が減ること。学習の結果、仮説は採択されるか、棄却されるか、書き換えられる

普通に普段やっていることのように思えるけど、何となくやってたことをもっとちゃんと定義するということだろうか。

"LLM時代の仕様とは、何を作るかを詳細に命令する文書ではない。価値仮説・行動仮説・ドメイン仮説・相互作用仮説・実装仮説を分け、それぞれの採択基準と観測方法を明らかにする、学習のための構造である"

既存の用語を意図的に誤用して読者の常識を打ち破り、目から鱗を誘うという、倫理的に良くないテクニックが用いられている。先日のマーティン・ファウラーと同じ悪質さを感じる。こんなのを有難がるのは滑稽。

俺もこう言うのは考えてるよ。一旦かなり哲学的なところに入っていく必要が出てきてるよね。仕様とは何かみたいな。／上手いモデル化はできないと思ってる、できるならこの20年でやったはずだ。むしろシンプルにした

VISION.md, ROADMAP.md, plans/*, decisions/*, notes/* など書かせるときに、仮説であって検証結果次第で見直すよ、みたいなルールにして、仕様や設計は最新のスナップショットとして残してたけど、次やるときの参考にしたい