おい、要件を動くものにしろ - じゃあ、おうちで学べる

要件の表現をドキュメントかコードではコードなのだが、コードでの焼き込み方に真髄があると

私にとって動作する要件とは自動テストのコードのことなのだが自動テストを維持できる人は少ないのと自動テストを維持することを評価する組織が少なくてな。挙動とかは文章よりテストコード見る方が分かりやすいのに

要件を聞こうか・・・・・。

要件が腐るから更新とかってのは真面目なウォーターフォールならやってる。アジャイルにも真面目なのとなんちゃっての品質の差があるように、ウォーターフォールもピンキリ。ウォーターフォールの上澄みで観た既視感

『気づいたときには、ドキュメントと現場のあいだに、もう橋が架かっていない』 人間同士の「合意」って何なのか、それはなぜ軽んじる前提で進むのか、みたいなことがあまり再確認されないのが社会ってものなのかな

最近の仕様駆動開発の文脈では、仕様はバージョン管理可能で、人間が読める、AIエージェントを動かすための制御手段／ドキュメントという媒体そのものに、毎日読まれ続けるための仕組みが備わっていない

要件である「機能」を,どのような構造で実現するかの「設計」の定義が曖昧だった。記事で「仕様」「契約」と呼んでるものは、詳細実装仕様に思えた。「要件を曖昧にしない」のは◎。 「要件」に「設計」も含めてそう

なんか「屏風に書いた虎を動かせ」みたいなタイトルだ

エクセル関数の頃からSSTは関数と思っていた。問題は関数は一目で理解できても何百何千行のコードでは無理なこと。しかし、今やLLMがものの数十秒でそれらを理解して自然言語にも翻訳する。文書の意味が変わった。

冗長過ぎる

おい、と言うのが苦手すぎる

全部詰め込もうとすると長くなるよね

参考にはなるが、たしかに長い。ドメイン知識の構造化に触れているが、この記事も構造化できないものか？

たぶん仕様や要件じゃなくてコンテキストの話をしているというか、AIにコーディングさせると結局コンテキストに行き着く。。。

“「要件」と「仕様」と「契約」は、何が違うのか。3つは別物です。仕様駆動開発を語る人の多くは、この3つを混ぜて使っています。　AIに実装を任せるとき、Type Firstで、型から書き始める”