🚀Kiro便利じゃん
Kiroが作ったspecは冗長な文章ながら、GeminiやChatGPTが書いた仕様書として機能していると思います。ユーザーストーリや要件の書き口は本当に設計を触ったことないとすればこれを身近な見本としてもいいんじゃないかと思えるくらいです。
ところで、「なぜ」このような機能が生まれたのかVSCodeの拡張機能ではなく独自のエディタになぜしたのか気になったためIntroducing Kiroを読んでみることにしました。
🔍Kiroが解決したかった問題
- バイブコーディングは動く物を提供してくれるが、その中で行われた決定・要件を満たしているか・仮定についてはわからない
- コードをPushする前の心の中のチェックリストを自動化したい
🪝KiroのSpecsとHooksという二つの大きな軸
自分はSpecsについては知っていましたがHooksについてはこの記事を読むまで知りませんでした。Hooksのアイデア自体はそれこそ保存を皮切りにterraform fmt打つスクリプトを組むとかCIをまわすとかありきたりなものでしたが、これを大きなコンセプトの中に組み込むということが新規性なのかなと思いました。
実際微妙にコードに落とし込みづらいタスク、例えばPRをghコマンドで作るとかをHooksでやってくれれば確かに便利だなという感触を受けました。
🌐ビジョンについて
「ソフトウェア製品の開発を困難にしている根本的な課題を解決することです。」とありました。確かにSpecsは設計を他の人と照らし合わせ、検証可能にするため必要不可欠です。また、Hooksは開発前にみんなが行なっている「心の中のチェックリスト」を外部化することによって開発者のストレスやミスを減らす・無くす方向でソフトウェア開発の困難を解決しているなと納得してしまいました。
🧬Kiroは「開発者」を模倣しようとしているのではないか
Kiroは実際のチーム開発での人の振る舞いを真似するようルール化されたAIように思えます。
- 実装の前にコードを読む点
- 仕様書を通して我々との期待値調整を行ってくる点
- 抽象 -> 具体の順にSpecを作っていく点
- タスク×個人×プロジェクトで覚えておくべきことを記録する「steering」機能
今までのコーディングエージェントも人のように振る舞いたがる雰囲気はありましたが、プロダクト開発をするときの理想的な振る舞いを徹底的に教え込んだのがKiroなのではないかなとIntroductiong Kiroを読んで思いました。
📈これからの開発にどう活かすか
今の所設計部分はChatGPTに書かせているものをベースに使っています。ただ、Kiroの設計思想を見る限りはそこも含めて一旦Spec化することを優先して作業していく方がいいかなというのを感じました。それによって開発のSSOTが実現されるために。