Get Shit Done（GSD）

導入判断：Claude Code などのAIコーディングエージェントを使っていて、要件の曖昧さ、作業の細分化、コンテキストの散逸、変更後の検証不足に困っているなら、GSDは候補になります。一方、単発の小さな修正や、最短で試作を回すことを優先する場合は重く感じる可能性があります。これは基盤モデル、IDE、コードエディター、単独で開発を完了させる自律型コーディング製品ではありません。より正確には、AIエージェントに重ねるワークフロー編成層、またはハーネスに近いものです。

提供された比較記事では、複数段階の流れとして説明されています。brainstormingではソクラテス式に質問して曖昧なアイデアを設計書へ整理し、writing-plansではファイルパスと検証手順を含む、約2〜5分単位の小さなタスクへ分解します。executing-plansではエージェントやサブエージェントが順番に実行し、仕様への適合とコード品質の2段階レビューを行うとされています。systematic-debuggingは、再現、切り分け、最小修正、検証という根本原因分析の流れです。つまり、計画、コンテキスト、確認ポイントを明示することが中心で、モデル自体のコード生成能力を直接高めるという証拠ではありません。

導入時の負担は、ワークフローの複雑さ、学習時間、実行待ち時間、追加のコンテキスト消費です。今回の証拠には、確認可能な公式価格やAPI料金はありません。知乎の記事の1本は、Dev.toユーザーのコミュニティ上の報告として、コード作成に対する編成処理のToken消費が約4対1になり得ること、月20ドルのPro Planを早く使い切る可能性を紹介しています。これはコミュニティの引用と事例的な観察であり、GSDや関連サービスの公式料金、または安定した費用保証ではありません。実際の費用はモデル、プロジェクト規模、使い方で変わるため、導入前に自分の作業で時間とTokenを測るべきです。

複数段階の機能開発、再現性のある手順、エージェントに計画を立ててから実行させることを重視する開発者や小規模チームに向いています。素早い使い捨ての試行や、プロセス上の制約と追加の対話を避けたい人には不向きです。議論は知乎の4件、つまり比較記事、フレームワーク解説、個別紹介が中心で、合計121件の賛同と16件のコメントがあります。これは注目度の証拠であって、使いやすさの証明ではありません。具体的な手順説明と、Token、複雑さ、学習曲線、実行時間への批判はありますが、公式リポジトリ、GitHub成長、X上の実測データは確認できません。したがって議論の質は中程度ながらサンプルは限られ、結論は慎重に見る必要があります。