Vibe Codingとは:できることと人が確認すべきこと
Vibe Codingの本来の意味と、会話しながらAIに実装を任せる開発との違いを整理し、試作品と本番利用で人が確認すべき範囲を説明します。
Vibe Codingの本来の意味と、会話しながらAIに実装を任せる開発との違いを整理し、試作品と本番利用で人が確認すべき範囲を説明します。
AIに別の修正を依頼している流れで、本番向けビルドコマンドが実行された経緯と、その後に導入した承認制ルールの記録です。
AIは実在しないURLを参考文献候補として提示することがあります。このサイトで作ったURLチェックスクリプトの仕組みと、結果の分類方法を整理します。
AI支援でブログを書くときに、著者の体験談と外部事実を分け、どこに引用が必要かを判断するための実践ルールを整理します。
AIに別の作業を依頼していたところ、ナビゲーションのレイアウトが変更されていた経験から、UIを保護するルールをCLAUDE.mdに追加した経緯と効果を説明します。
AIを使って記事のドラフトを作成すると著者らしさが消えやすい問題に対し、my-blog-writing SKILLで文体・禁止表現・E-E-A-Tの確認基準を定義しました。ドラフト段階の品質を整え、著者が編集・レビューしやすい状態にする仕組みを整理します。
AIへの実装依頼の前に仕様書を書くことで、意図と異なる実装や繰り返し修正が減ります。Spec Firstという考え方と、仕様書の書き方を説明します。
繰り返し発生するAI作業の問題を、再現性・具体性・検証性の3条件でハーネスへ移すか判断する方法を整理します。
1つの記事に複数のトピックを入れると、読者がどこに何があるかわからなくなります。このサイトで「1ページ1トピック制」を導入した経緯と、どこを1トピックの単位とするかの判断基準を説明します。
AIが作成したドラフトを自動チェックし、最終的に人が確認するレビュー体制を導入した経験から、自動チェックで検出できることと、人が確認する必要があることを整理します。
コーディングエージェントで作成したコードを、外部接続、データ変更、計算・変換、表示・デザインに分け、確認優先度をレビュー表として整理します。
AIへ依頼する前に確認したいリスク判定として、可逆性・影響範囲・検証のしやすさの3軸と、人間が握る判断領域を整理します。
AIが作成したドラフトは、そのままではビジネス文書に使いにくいことがあります。誇張表現・口語副詞・比喩的な危険表現・個人ブログ的な表現という4つのパターンごとに、具体的な書き換え例を整理します。
Claude Codeへプロジェクト固有の前提を渡すCLAUDE.mdの書き方と、指示が動作を導く範囲を設定前後の例で説明します。