本スクラップの概要

自分でコードを極力書かずにwindsurfにコードを書いてもらうという実装方法でマークダウンエディタを開発している。
いろいろ試してよかったことやうまく行かなかったことのメモを残したスクラップ

開発したアプリ

• マークダウンエディタ
  • 後にも書いているがソースコードにメールアドレスが混入していることに気が付かず開発を進めてしまったためソースコードは非公開
  • 良い感じに機能ができたら動作する様子が分かる動画やLPとか作ってみて成果物が分かるようにはする予定

ツール

LLM

• windsurf：メイン
• v0：UIだけ
• gemini：Google AI Studioだと無料で使い放題なので壁打ち相手

BaaS

• supabase：認証、DB、ストレージ

開発言語

• Next.js App Router

開発マシン

• windows11
• WSL Ubuntu 22.04

2025/03/08 時点でよさそうなやり方

手順

1. ドキュメントを作成する
2. ドキュメントに足りないところがないかAIに確認してもらう
3. ドキュメントをもとにコードを作成してもらう
4. テストコードを作成してもらう

思っていること

• テストコードは絶対に必要
  • 既存コードを不必要に修正することが多いので気が付けるようにする
    • その時はテストコードも直してくるが、修正ファイルが倍になるので気が付きやすい
  • 編集中の既存に直接関係ないデザインを「こっちのほうが良いでしょ？」と修正することがある
• テストを先に書いてもらったほうが良い？
  • 自分のプロンプトだったり元のコードが悪いのか既存のコードにテストコードを書くのは苦手な印象はある
  • 今回のマークダウンアプリではやらないが、次のアプリ開発では試す価値あり
    • 手順を変えないほうが仮説の検証としてよいと思うので手順は変えない

LLMモデル

• claudeが一番良いというかclaude以外はしっかりと指示を出さないといけない気がする
• claudeは必要なファイルを勝手に見てくれるが、他のLLMは細かく指示出さないとみてくれない印象

コツ

• タスクは細かくする
  • CRUDを実装したい場合は一気に作るのではなくC→R→U→Dの順番で進めるといった感じ
• 自分の想像以上の修正をすること多いので必ず成果物は確認する
• 意図通りと違う実装をした際には修正内容を指示するより、会話モードにして会話を通じて合意してから修正させるときれいに行く
  • クレジットはその分消費するけど...

設計

• Presentational/Containerパターンが良さそう
  • 最初はwindsurfで実装
  • v0のほうがデザインはそれっぽいの出る印象なのでpropsを指定してv0に作成してもらう

ヒヤッとしたこと

• 自分のメールアドレスがmigrationファイルに含まれていたのでAIが作成したコードはよく確認してからcommitする
  • どこで自分のメールアドレスが分かったのかは不明だけどおそらくDBの中身をコマンドで確認して入れたと思う
  • 念のためprivateで開発していたので影響は無し
  • ポートフォリオとして外部に公開しようと思っていたので残念ではある

supabaseを実装させるときのコツ

Authetication

• 結構雑に指示出してもいい感じに作ってくれる

storage

• RLSほしい場合は、RLS無しで実装 → RLSを後からつけるといったやり方がよさそう
  • 最初からRLSありで実装しようとしたところエラー多発
  • エラーを貼って修正してほしいとプロンプト出してもうまく解消できなかった

windsurfのクレジット節約

• claudeが一番少ない指示でいい感じに実装をしてくれるので可能な限りclaudeを使う
• 財布に余裕があるなら課金してclaude使い続けるのが理想だが、User PromptとFlow Actionで同じクレジットを消費するようになるのでどんどん減っていくのでかなり財布に余裕がない限りは避けたほうが良い印象
• Claude以外で節約目的であればCasscade Baseが個人的には一番良い気がする

うまく行かないこと

コマンド実行

• WSLだからなのかコマンド実行してもらう際にyarnのパスが通っておらずエラーが返ってくる
  • npmにしても変わらず

箇条書きリストと番号付きリストの表示切替

• 以下のようにクラスをつけるだけなのにli要素のクラスを切り替えようとしてうまく行かなかった
  • ulにlist-disc
  • olにlist-decimal
• プロンプト頑張るより手動で実装したほうが早いかつクレジットも消費しないので手動で修正

lintの型エラー修正

• anyを使っているのが問題なのにエラーをそのまま渡して修正を指示するとanyを使ったままのコードを返すことがある
• 型つけるだけなので量が多くなければ手動で直したほうが早い

Plateの導入

• https://platejs.org/
• 何かうまく行かなかったのでドキュメント見ながら自分で実装した

「すげー！」と感動したポイント

マークダウン

• typoraやCosenseといった感じの編集中の行だけプレーンテキストになって、他の行はマークダウンプレビューの表示にしたかったのだが、これは良い感じのライブラリがなく実装が必要な箇所
  • それを以下のプロンプト１回で実装終わったこと

マークダウンのプレビュー機能を作成してください
２カラムではなく現在編集中の行だけプレーンテキストになってほかの行はマークダウンで表示されるような形にしたいです

このシステムの要件等はdocs配下にあるドキュメントに書かれているのでそちらを確認してください

カーソルがないので編集中の行が分かりにくいが以下が完成したコンポーネントのスクリーンショット

調べたらTiptap導入する方が今後の開発やりやすそうと思った

注意点

マイグレーション

• 新しくマイグレーションを作るより既存のファイルを修正しがちなので運用中のアプリで使う際には注意必要

ドキュメント作成

コード→ドキュメントの順番で作成していくと、ドキュメント作成時にコードを書きたがるので開発が進むとドキュメントと差異が発生しやすい

いろいろ破綻してきたので最初から作った方がよさそうと思ってきた

• 同じstateが２カ所にある状態がある
• そもそもコミットに自分のメールアドレスが入っている

LLMのおかげでドキュメントさえしっかりしていれば再実装に時間かからないことは分かっているのでありな気がする

反省点

• 技術選定を事前にしっかりしていなかった
• PRのレビューを怠った

収穫

• LLMだけで実装は十分に可能
• 自分の手で実装したほうが早いこともある
• ドキュメントをgitリポジトリに入れるのは効果的