🆒

Cool Cline は設計書にどれだけ忠実にコーディングしてくれるか検証してみた

2025/01/16に公開

はじめに

前回の記事の続きです。

https://zenn.dev/ken_5/articles/62b2500dcc93af

この記事では設計書をmarkdownで作成ました。
作成した設計書をcool clineに渡してどれだけ忠実にコーディングしてくれるか検証しました。

今回は皆さんに成果物を見せられるよう、設計書(markdownで作成)はChatGPTに作ってもらったものを使用しました!

設計書を書いてもらうためChatGPT o1に投げたプロンプト
Todoリストを管理するwebアプリケーションの設計書を作成してください。
設計書には以下を記載してください。
・画面一覧
・各画面の画面項目
・各画面での処理
言語はVue.jsで、SPAでサーバー側は無しで、AWS S3でホスティングできるような形にしてください。
todoリストの内容はlocal storageに保存してください。

これをベースにちょっと3回くらい追加修正してもらいした。

最終的にChatGPTが書いてくれた設計書 (ちゃんとチェックしなかったことが後で裏目に...)

長いです。気になる人は開いて見てみてください

1. アプリ概要

  • アプリ名: Vue.js TodoリストSPA (拡張版・詳細設計)
  • 目的: Todoリストの追加/編集/削除/完了、優先度・タグ管理、検索・フィルタ・統計など、多機能なタスク管理を実現する。
  • 主な特徴
    1. SPA (Single Page Application): すべての画面を Vue.js で構築し、ページ遷移を高速化
    2. LocalStorage 保存: ログイン不要で個人用のタスクをデバイス上に保存
    3. 多機能化: 優先度設定、タグ付け、期日管理、統計など
    4. AWS S3 ホスティング: Static Website Hosting 機能で簡単デプロイ
  • 技術スタック
    • フロントエンド: Vue.js (v3 以上)
    • ビルドツール: Vite or Vue CLI
    • データ永続化: LocalStorage (キー名は例として "myTodoList", "myTags")
    • ルーティング: Vue Router
    • サーバーサイド: なし

2. デザインの指針

  1. シンプル&ミニマル

    • 主要機能を直感的に操作しやすい UI
    • 余白、フォントサイズ、配色をシンプルに保つ
  2. 視認性とコントラスト

    • ボタンや文字が見やすい配色(コントラスト比)を確保
    • 優先度や完了状態を色やアイコンで明確に表現
  3. レスポンシブ対応

    • PC / タブレット / スマホでレイアウトが崩れない
    • ナビゲーションや入力フォームを流動的に配置
  4. アクセシビリティ

    • 適切なラベル付け、ボタンサイズ、フォーカス表示
    • 色覚障害に配慮した配色 (重要箇所は色だけでなくアイコンや文字で伝える)
  5. ブランドカラー (例)

    • プライマリカラー: #2196F3 (ライトブルー)
    • アクセントカラー: #FFC107 (アンバー)
    • 背景色: #FAFAFA (ほぼ白)
    • 文字色: #212121 (濃いグレー)
  6. アイコン・ボタン

    • Material Icons や Font Awesome などを活用
    • タスクの完了状態や優先度をアイコンやカラーで区別

3. 画面一覧

  1. Todoリスト画面 (ListView)
    • メインの画面。タスクの一覧、検索・フィルタ、タスク追加操作を行う。
  2. タスク登録・編集画面 (EditView)
    • タスクを新規登録または編集する画面。タイトル・詳細・優先度・タグ等を入力。
  3. タグ管理画面 (TagsView) [オプション]
    • タスクに付与するタグを一括管理。作成・編集・削除。
  4. 統計・レポート画面 (StatsView) [オプション]
    • タスクの完了率、優先度やタグ別の集計などをグラフや数値で表示。

4. 各画面の詳細設計

4.1 Todoリスト画面 (ListView)

4.1.1 画面項目

項目名 種別 必須/任意 文字数制限 バリデーション・挙動
ヘッダー - (表示のみ) - - アプリ名(例: "My Todo")、メニュー(タグ管理・統計画面へのリンクなど)を表示。
タスク検索ボックス input[type=text] 任意 0 ~ 50 - 文字列の長さが 50 文字を超えないように制限。
- 入力中にリアルタイムで検索 or ボタン押下で検索。
フィルタ機能 セレクト/チェックボックス等 任意 - - 「未完了のみ」「優先度別」「期日順」など
- 選択された条件にもとづき一覧を動的にフィルタ
ソート機能 セレクト 任意 - - 「作成日順」「期日順」「優先度順」など
- 選択された条件にもとづき並べ替え
新規タスク入力欄 input[type=text] 任意 1 ~ 50 - タスクタイトルを簡易に追加する欄。
- 半角/全角混在可。
- 1文字以上入力がある場合のみ追加可能。
「+」追加ボタン ボタン - - - 上記の新規タスク入力欄の内容をもとにタスクを作成。
- 空の場合はエラー扱い (画面上でメッセージ表示)
タスク一覧 (カード/リスト) リスト表示 - - - 登録済みタスクを下記項目とともに表示:
1. 完了チェックボックス
2. タスクタイトル
3. 優先度(色やアイコン)
4. タグ(色付きラベル)
5. 期日 (任意)
6. 編集ボタン
7. 削除ボタン
フッター - (表示のみ) - - 著作権表記やアプリ情報。任意。

4.1.2 バリデーションチェックとエラーメッセージ

  1. 新規タスク入力欄

    • 必須: 1文字以上入力が必要
    • 文字数制限: 50文字以内
    • エラーメッセージ例:
      • 未入力: 「タスク名を入力してください」
      • 50文字超過: 「タスク名は 50文字以内で入力してください」
  2. 検索ボックス

    • 50文字を超えた場合、追加入力を抑制 or エラーメッセージ表示
    • エラーメッセージ例: 「検索キーワードは 50文字以内で入力してください」
  3. エラーメッセージの表示場所

    • 新規タスク入力欄の直下、または画面上部にバナーとして表示するなど。

4.1.3 処理フロー

  1. 初期表示

    • LocalStorage からタスク一覧を取得
    • 必要に応じて、フィルタ・ソート条件を初期化して表示
  2. タスクの絞り込み・ソート

    • 検索ボックス入力、フィルタ・ソート UI の操作にあわせて配列を再生成し表示
  3. 新規タスクの追加

    • 入力欄にテキストを入力 → 追加ボタン押下
    • バリデーションに合格したら、新規タスクオブジェクト { id, title, detail, ... } を作成
    • LocalStorage 更新 → リストを再描画
    • バリデーションエラーの場合は追加せず、エラーメッセージ表示
  4. 完了/未完了の切り替え

    • チェックボックス操作時に donetrue/false に切り替え、LocalStorage を更新
    • リスト再描画
  5. 編集ボタン押下

    • router.push('/edit/' + task.id) などで編集画面へ遷移
  6. 削除ボタン押下

    • 確認ダイアログ(例: 「このタスクを削除しますか?」)で OK → タスク削除 → LocalStorage 更新 → リスト再描画

4.2 タスク登録・編集画面 (EditView)

4.2.1 画面項目

項目名 種別 必須/任意 文字数制限 バリデーション・挙動
ヘッダー - (表示のみ) - - 「タスク登録・編集」などのタイトルを表示
タスクタイトル欄 input[type=text] 必須 1 ~ 50 - 入力が無い場合は保存不可
- 50文字超過でエラー
タスク詳細欄 textarea 任意 0 ~ 300 - 300文字程度の上限を設ける (任意)
- 超過した場合エラーメッセージ
優先度 セレクトまたはラジオ 任意 - - "High" / "Medium" / "Low" から選択
- 初期値は "Medium"など
タグの選択 マルチセレクト/チェックボックス等 任意 - - 既存のタグ一覧を読み込み表示
- 複数選択可能
期日 (dueDate) input[type=date] 任意 - - 過去日を選択した場合の扱いは要件次第 (制限する or 警告だけ表示など)
完了/未完了チェックボックス チェックボックス - (編集のみ) - - 編集時のみ表示。新規の場合は常に未完了スタート
保存ボタン ボタン - - - バリデーションチェック→問題なければ LocalStorage に反映し、ListView へ戻る
キャンセルボタン ボタン - - - 変更を破棄して ListView へ戻る

4.2.2 バリデーションチェックとエラーメッセージ

  1. タスクタイトル

    • 必須: 1文字以上
    • 上限: 50文字
    • エラーメッセージ例:
      • 未入力: 「タスクタイトルを入力してください」
      • 50文字超過: 「タスクタイトルは 50文字以内で入力してください」
  2. タスク詳細

    • 任意。ただし、上限 300文字程度
    • 300文字超過時: 「タスク詳細は 300文字以内で入力してください」
  3. 期日(dueDate)

    • 過去日入力を禁止する場合: 「期日は本日以降の日付を選択してください」
    • 特になしの場合はそのまま通すが、保存後にラベルなどで強調表示させる方法もあり
  4. タグ選択

    • 任意。タグの新規追加が必要な場合はタグ管理画面へ案内するなど
  5. 保存ボタン押下時

    • 上記バリデーションをすべて通過したら LocalStorage に反映
    • エラーがあれば画面上にメッセージを表示し、保存を中断
  6. エラーメッセージの表示場所

    • 該当フィールド付近か、画面上部にまとめて表示

4.2.3 処理フロー

  1. 初期表示

    • URL の :id パラメータを読み取り
      • あり → 該当タスクを LocalStorage から取得し、フォームに反映 (編集モード)
      • なし → 新規モード (空フォーム)
  2. 保存ボタン押下

    • 入力値をバリデーションチェック
    • OK → タスクオブジェクトを作成/更新 (id, title, detail, priority, tags, dueDate, done, createdAt, updatedAt)
    • LocalStorage に保存 → ListView へ戻る
    • NG → エラーメッセージ表示。保存処理中断
  3. キャンセルボタン押下

    • 変更を破棄して ListView へ戻る

4.3 タグ管理画面 (TagsView) [オプション]

4.3.1 画面項目

項目名 種別 必須/任意 文字数制限 バリデーション・挙動
ヘッダー - (表示のみ) - - 「タグ管理」というタイトル
新規タグ入力欄 input[type=text] 任意 1 ~ 20 - 1文字以上 20文字以内
- 既に存在するタグ名の重複を禁止するかどうかは要検討
新規タグ追加ボタン ボタン - - - 入力値をバリデーション→重複や文字数制限 NG → エラー
タグ一覧 リスト/テーブル表示 - - - 登録済みタグの一覧を表示
- 各タグに編集 / 削除ボタン
タグ編集モーダル input[type=text] 任意 1 ~ 20 - 編集時に同じバリデーションを実施
フッター - (表示のみ) - - 任意

4.3.2 バリデーションチェックとエラーメッセージ

  1. 新規タグ入力欄

    • 必須(1文字以上) / 上限20文字
    • 重複チェック: 既存タグ一覧と同名がある場合はエラー → 「同じタグ名が既に存在します」
    • エラーメッセージ例:
      • 「タグ名を入力してください」
      • 「タグ名は 20文字以内で入力してください」
      • 「同じタグ名が既に存在します」
  2. 編集時

    • 同様に文字数・重複チェック

4.3.3 処理フロー

  1. 初期表示

    • LocalStorage からタグ一覧を読み込み、表示
  2. 新規タグ追加

    • 入力値バリデーション → OK ならタグオブジェクトを作成 { name, color?, description? }
    • LocalStorage に保存 → 再描画
  3. タグ編集

    • 編集ボタン押下 → 編集モーダルまたはページを開く → バリデーション通過後、LocalStorage 更新 → 再描画
  4. タグ削除

    • 削除ボタン押下 → 確認ダイアログ → OK なら削除
    • タスク画面側でこのタグを参照している場合、どう処理するか(タグを外す or 削除不可エラー)を検討

4.4 統計・レポート画面 (StatsView) [オプション]

4.4.1 画面項目

項目名 種別 バリデーション・挙動
ヘッダー - (表示のみ) 「統計・レポート」などのタイトル
完了タスク数 数値表示 全タスク数に対する完了数 (例: 10 / 15 )
優先度別タスク数 グラフまたはリスト High / Medium / Low ごとの件数・比率など
タグ別タスク数 グラフまたはリスト タグごとのタスク数 (円グラフ・棒グラフなど)
期日別カレンダー表示 カレンダー(任意) 期日が設定されたタスクを表示
フッター - (表示のみ) 任意

4.4.2 処理フロー

  1. 初期表示

    • LocalStorage から全タスクを取得
    • 完了数、優先度別、タグ別などを集計
    • グラフを描画 (Chart.js などライブラリ使用可)
  2. フィルタ (オプション)

    • 期間指定 (今月のみ、今年のみ) などを行い、グラフを再描画
  3. エラーケース

    • タスクが存在しない場合: 「登録されているタスクがありません」などのメッセージ表示

5. データ構造

5.1 タスク情報 (LocalStorage キー: "myTodoList")

{
  "tasks": [
    {
      "id": "xxxx-xxxx-xxx",   
      "title": "タスクタイトル",
      "detail": "詳細情報",      
      "done": false,
      "priority": "High",       // "High" | "Medium" | "Low"
      "tags": ["仕事", "急ぎ"], // タグ名の配列
      "dueDate": "2025-01-20",  // 期日
      "createdAt": "2025-01-13T12:34:56.000Z",
      "updatedAt": "2025-01-13T13:00:00.000Z"
    },
    ...
  ]
}
  • title: 最大 50文字、必須
  • detail: 最大 300文字、任意
  • tags: タグ管理で登録されたタグ名を参照
  • done: boolean (初期値 false)
  • priority: string ("High"/"Medium"/"Low")
  • dueDate: string (ISO8601 または "YYYY-MM-DD" フォーマット)

5.2 タグ情報 (LocalStorage キー: "myTags")

{
  "tags": [
    {
      "name": "仕事",
      "color": "#F44336",   
      "description": "仕事関連タスク"
    },
    {
      "name": "趣味",
      "color": "#9C27B0",
      "description": ""
    },
    ...
  ]
}
  • name: 一意のタグ名(最大 20文字)
  • color: 任意 (ラベルの背景色などに使用)
  • description: 文字列 (最大 50 〜 100文字程度でも可)

6. バリデーション共通仕様

  1. 入力制限

    • 必須項目が未入力の場合はエラー
    • 文字数超過時はエラー
    • 重複禁止等、要件で決められたものは保存前にチェック
  2. エラーメッセージ表示方法

    • 各入力項目の直下で赤文字表示、または画面上部にまとめて表示するなど
    • メッセージ例: 「○○は必須入力です」「○○は50文字以内で入力してください」
  3. 処理中断

    • バリデーションエラーが一つでもあれば保存処理は行わない

7. フォルダ構成例

my-todo-app/
├─ public/                
├─ src/
│  ├─ assets/            
│  ├─ components/        
│  │  ├─ TodoList.vue      // タスク一覧表示用のコンポーネント
│  │  ├─ TodoItem.vue      // 個々のタスクアイテム
│  │  ├─ EditTask.vue      // タスク編集フォーム(小コンポーネントとして分割する例)
│  │  ├─ TagList.vue       
│  │  ├─ TagItem.vue       
│  │  └─ StatsChart.vue    // グラフ描画コンポーネントなど
│  ├─ views/              
│  │  ├─ ListView.vue      // Todoリスト画面
│  │  ├─ EditView.vue      // タスク登録・編集画面
│  │  ├─ TagsView.vue      // タグ管理画面
│  │  └─ StatsView.vue     // 統計・レポート画面
│  ├─ router/
│  │  └─ index.js          // Vue Router 設定
│  ├─ store/ (Optional)    // Pinia / Vuex など使用の場合
│  ├─ App.vue
│  └─ main.js            
├─ .gitignore
├─ index.html
├─ package.json
└─ vite.config.js (または vue.config.js)

上記設計書を渡してコーディングしてもらいました。

生成されたが...

待つこと数分、完了しました。

動かしてみると、、、おや、動かない!
ちゃんとデータをLocal storageに保存してくれなかったので、指示しながら修正しました。
修正は一瞬では終わらず思ったより時間かかりました。

cool clineというより、deepseekの性能によるところかと思われます。

生成物を詳しくチェック!

(参考:生成にかかったコスト)
Tokens: ↑1.8M ↓2.3K
API Cost: $0.2613(執筆時 約41円)

成果物はこちらのリンクから見れます

画像1

画像2

画像3

画像4

...

なんかダs...
まずはChatGPTに「デザイン要件にどれだけ沿っているか」を採点してもらいましょう。

スクショとデザイン要件を与えてChatGPTに採点してもらいました

結果:
総合評価: 50/60 by ChatGPT 4o

  • 全体的にシンプルで直感的なデザインが良く、改善点はレスポンシブ対応とアクセシビリティのさらなる強化です。
  • 特に、色以外の視覚表現やスマホ対応での動作確認が次のステップとして重要です。
ChatGPTの具体的な評価はこちら

以下の基準に基づいて、アップロードされたデザインを採点します。


1. シンプル&ミニマル

評価: 9/10

  • デザインはシンプルで、余計な装飾がなく、主要機能にアクセスしやすい。
  • 余白やフォントサイズも適切で視覚的に負担が少ない。
  • 若干、「タグ管理」ページで余白のバランスが改善可能に見える。

2. 視認性とコントラスト

評価: 8/10

  • ボタンや文字の色分けが明確で、優先度の区別も直感的。
  • 「完了率」など一部の文字サイズを少し大きくするとさらに視認性が向上する可能性がある。
  • 色覚障害者に配慮し、色だけでなくアイコンや文字表現を追加できると良い。

3. レスポンシブ対応

評価: 7/10

  • スクリーンのレイアウトは明確であるが、スマートフォンやタブレットでどのように崩れず表示されるかの確認が必要。
  • 入力フォームやリストが狭い画面に適応するか、具体的な動作が不明なため減点。

4. アクセシビリティ

評価: 8/10

  • ボタンのサイズが適切で、ラベルも分かりやすい。
  • 色覚障害に関する配慮は、色以外の表現(例: テキストやアイコンの使用)で補足できると完璧。
  • フォーカス表示の確認は未実施のため、現時点では減点。

5. ブランドカラー

評価: 9/10

  • プライマリカラーとアクセントカラーが適切に使用され、全体の統一感がある。
  • 背景色と文字色も視認性が良い。

6. アイコン・ボタン

評価: 9/10

  • タスク完了状態や優先度が明確なカラーコードで区別されている。
  • アイコンが適切に使用されているが、デザインに一貫性を持たせるため、全ての項目にアイコンの追加も検討できる。

総合評価: 50/60

  • 全体的にシンプルで直感的なデザインが良く、改善点はレスポンシブ対応とアクセシビリティのさらなる強化です。
  • 特に、色以外の視覚表現やスマホ対応での動作確認が次のステップとして重要です。

との評価。結構点数高い。
しかし、なんかちょっと、ダサいですね。
要件をクリアした上でいかに美しく見せるかは簡単にできるものではないということですね。
今回はアクセシビリティを考えて色のコントラストを意識したせいか、色調の統一感がないのがダサく見えている要因だと思います。
あとは所々マージンが変ですね。

デザイン性は一旦おいておいて、次に行きます。

どちらかというと、こちらが大切。

設計書にどれだけ忠実に作っているかをチェックしました

Todoリスト画面 (ListView)

画面項目利用状況

画面項目 存在するか
ヘッダー OK
タスク検索ボックス OK
フィルタ機能 NG
ソート機能 NG
新規タスク入力欄 NG
新規タスク「+」追加ボタン OK
タスク一覧 ( カード/リスト) OK
フッター NG

処理利用状況

処理項目 存在するか
バリデーションチェックとエラーメッセージ OK
処理フロー NG, 画面項目不足により、不足

「文字列の長さが 50 文字を超えないように制限」という要件があるのにエラーメッセージがあるのは、そもそも設計書が矛盾している。失敗した、ちゃんと設計書をレビューしておけば良かった。

Chat GPT o1だとこんなものか。o1 proなら矛盾しないのかな?

合計

OK : 5件
NG : 5件
結構NGが多い


タスク登録・編集画面 (EditView)

画面項目利用状況

画面項目 存在するか バリデーション エラーメッセージ
タスクタイトル欄 OK OK ( *1 ) NG指定と違う
タスク詳細欄 OK OK ( *1 )
優先度 OK
タグの選択 OK
期日 (dueDate) OK OK ( *1 ) NG指定と違う
完了/未完了チェックボックス NG
保存ボタン OK
キャンセルボタン OK

( *1 )指定文字数以上入力させないようになっているので、エラーを出していないケースあり

処理利用状況

処理項目 存在するか
処理フロー OK

合計

OK : 11件
NG : 3件

先ほどの画面よりは良いが、エラーバリデーションは実施できているのにエラーメッセージが違うことでNG数が増えた。


タグ管理画面 (TagsView)

画面項目利用状況

画面項目 存在するか バリデーション エラーメッセージ
ヘッダー OK
新規タグ入力欄 OK OK OK
新規タグ追加ボタン OK
タグ一覧 OK
タグ編集モーダル OK OK OK
フッター NG

処理利用状況

処理項目 存在するか
処理フロー OK

合計

OK : 10件
NG : 1件
フッターは全部の画面に存在しないので、この画面単体の要素だけで見ると、なんと全部OK!


統計・レポート画面 (StatsView)

画面項目利用状況

画面項目 存在するか バリデーション エラーメッセージ
ヘッダー OK
完了タスク数 OK
優先度別タスク数 OK
タグ別タスク数 OK
期日別カレンダー表示 NG
フッター NG

フッターはタスク一覧の時からなかったが、
期日別カレンダー表示もなかった。

処理利用状況

処理項目 存在するか
初期表示 OK
フィルタ ( オプション) オプションとしたためか、機能はなし
エラーケース NG。実装されていない

タスクが存在しない場合: 「登録されているタスクがありません」などのメッセージ表示
というエラーケースは実装されていなかった。

合計

OK : 5件
NG : 3件
存在しない項目が1つと、エラーケース未実装が1つ。

設計書に従った度の点数付け:全画面の合計

OK : 29件(約70%)
NG : 12件(約30%)

うーん、これはどうなんでしょう。
3割も無視されたと見るべきか、7割も従ってくれたと見るべきか。
7割も従ってくれたと見る方が良いかもしれませんね。
全部手動で書いたらもっと時間がかかるはずです。

課題感

local storageにデータ入れてくれていなかった問題など、そういうところは手動で修正した後のレビュー結果です。
そこが動かないと実質何も動かないので、流石に修正しました。
割と修正に時間がかかりました。

deepseek特有の問題

deepseekはAPIを使おうが、渡したデータが学習に使われる可能性がありそうな規約の書き方だったので、社内規則によっては使えないかもしれないですね。

コーディング品質

何のLLMを使うかで生成物は変わってきます。

また、今回は安さ優先でdeepseekを使いましたが、結構修正させられました。
LLMのコーディング性能によって生成物のクオリティが変わりそうです。
デザイン性も変わりそうです。

そこで、同じ設計書を渡したら、Claude 3.5 sonnetならどうなるかも試してみました。

Claude 3.5 sonnetを使って設計書からコーディングしてみた

Claudeの成果物はこちらのリンクから見れます

deepseekの成果物はこちらのリンクから見れます

(参考:Claudeで生成にかかったコスト)
Tokens: ↑ 17 ↓ 16.2k
Cache: +112.1k → 520.3k
API Cost: $0.82(執筆時 約128円)

Claudeどうだった?

deepseekより良い!
何より、修正にかかった時間が少ないです。
1発目からlocal storageをちゃんと使ってくれました。
あと、デザイン性も私はclaudeの方が好きです。

設計書への忠実度は高かったです。(むしろ設計書の不備が浮き彫りに。。。)
具体的な点数、deepseekとの比較は次回の記事で記載しようと思います。

デメリットはあった

デメリットは、何よりもコストが高いことです
deepseek: 41円 vs claude: 128円
3倍違うのは、結構変わるのではないでしょうか。
deepseek基準で1万円使うようなら、claudeだと3万円です。
個人でこれだとお財布に厳しいですが、その分の生産性向上を考えると使っても悪くない気はします。

総評

  • 設計書をベースに自動コーディングを試した結果、deepseekで約7割の実装完了率はまずまずといえるでしょう。
    • 自分で1からコーディングするよりは早いと思われます。
  • 私の場合、Claudeの方がdeepseekより良かったですが、値段を考えたらdeepseekも選択肢に入ります。
  • フィルタ機能やフッターなど一部の要素が無視された点は課題です。色々追加検証が必要そうです。
    • 無視されないように最初のプロンプトを頑張る
    • 生成物が要件に合っているか自動でチェックしてもらう
    • 生成物が要件に合っていなければ、都度指摘する など...
  • deepseekは安い分、何回修正してもお財布に優しいです。
  • Claudeはdeepseekと比べて一発目の品質が高く、割と要件も守ってくれました。
  • しかし、claudeはdeepseekと比べて3倍のコストがかかったので、お財布と要相談です。

最後に

今回の検証で、Cool Clineでのコーディングは割と設計書に沿ってくれることがわかりました。
実務でも使っていけそうな気がします。
LLMでClaudeかdeepseekか、どちらを選ぶかは悩みものですね。(もちろんChatGPT, geminiでも良いです。)

今回触れなかったClaudeが設計書にどれだけ沿ってくれたかについては、
次回の記事でClaude vs deepseek どっちが設計書に忠実にコーディングしてくれるかと比較した記事を執筆しようと思います。


XでもAI情報を発信しています。
長くならないことは大体Xで発信します。

よかったらフォローお願いいたします⭐️
Xはこちら

Discussion