#WIP 従来の仕様は、実装前に正解を固定し、実装をその正解へ一致させるための記述だった。 しかし、ソフトウェア開発で本当に不確実なのは、実装が仕様通りに作れるかだけではない。そもそもその機能に価値があるのか、ユーザーが想定通りに行動するのか、業務的に何を正しいとみなすべきか、どの相互作用なら使えるのかも不確実である。 LLMとエージェントによって、選択肢生成・プロトタイピング・実装修正のコストは大きく下がった。これにより、仕様は「正解を先に固める文書」から、「仮説を構造化し、どのエビデンスで採択・棄却するかを明示する文書」へ変わる。 したがって、LLM時代の仕様とは、何を作るかを詳細に命令する文書ではない。価値仮説・行動仮説・ドメイン仮説・相互作用仮説・実装仮説を分け、それぞれの採択基準と観測方法を明らかにする、学習のための構造である。 ただしひとくちに「仮説」といっても、そこには層があ

こんにちは。こんばんは。 Findy Team+ 開発のフロントエンドリードをしている @shoota です。 今回はフロントエンドからは少し離れ、AIによるプルリクエストのレビューシステムを作成した話を書きます。 Findy Team+フロントエンドの現状と課題 AIコーディング時代の新たな課題 AIによる自動レビュー（Approve）を作ろう 解決したい課題 レビューは大きく3種類ある 誰が使えるのか 何を判定するのか 判定のキモはTidy First?の分類 実装とポイント GitHub Actions Claude Code Actions ワークフローの変化とプロンプトの改善 実行コスト おわりに Findy Team+フロントエンドの現状と課題 過去のブログでも触れていますが、Findy Team+のフロントエンドは、非常に大きなモノレポで構成されています。 tech.find