AIを、あなたのレベルに合った仕様書を、マイルストーンと検証可能な成功基準つきで書く顧客に仕立てよう。ただしコードは決して受け取らない。
このレッスンを Kodokon で開く基礎を越えると、チュートリアルはもうあなたを前進させなくなる。印のついた道に沿って解答を写させるだけだ。有能な開発者を前進させるのは、自分のレベルより少しだけ上のプロジェクトだ - 決断を迫るほど難しく、行き詰まらない程度に枠づけされている。問題は、自分自身を較正するのはほぼ不可能だということだ。簡単すぎるものか、野心的すぎるものを選んでしまう。AIはその較正が抜群にうまい。ただし正しい役割を与えればの話だ。間違ったやり方: 「経費管理アプリをコーディングして」 - あなたは完成品を手にし、スキルはゼロだ。正しいやり方: AIが仕様書を書く顧客を演じる。開発者はあなただ。
あなたはプロジェクトの顧客(プロダクトオーナー)です。あなたは仕様書を書きますが、コードは決して書きません。
私のプロフィール: 私は[言語 / 技術]を定期的に実践しています。すでに知っていること: [正直なリスト]。上達させたいこと: [狙いを定めた概念、例: 非同期のエラー処理、テスト、モジュールへの分割]。
使える時間: 約[X]時間、[期間]にわたって分散。
ミニプロジェクトの仕様書を書いてください:
- ニーズを最大5行で、本物の顧客が言うように表現(「何を」であって、決して「どうやって」ではない)。
- 3つから5つの順序づけられたマイルストーン。それぞれが機能して実演できるもので終わること。
- 各マイルストーンについて: 観察可能な成功基準(「コマンドXがYを表示する」「ケースZが明確なメッセージとともに拒否される」 - 「コードがきれい」ではなく)。
- 狙いを定めた概念を使わざるをえなくする技術的制約を1つ。
- 早く終わった場合の任意の拡張を2つ。
禁止事項: コード片なし、押しつけの関数名やライブラリ名なし、実装のヒントなし。実装は私の仕事です。較正は、あなただけが持つ2つの情報にかかっている。あなたがすでに知っていること(正直に書こう。さもないとプロジェクトが簡単すぎる)と、あなたが取り組みたいこと(概念を1つか2つ、6つではなく)だ。マイルストーンはプロジェクトをフィードバックループに変える。各ステップが実演できる振る舞いを届け、それがアーキテクチャの大聖堂を建てて行き詰まるのを防ぐ。観察可能な成功基準については、それがすべてを変える。「コードがきれい」は検証できないが、「壊れたファイルをインポートするとクラッシュせずに明示的なエラーが出る」は10秒で検証できる。観察できない基準は意見であり、観察できる基準は受け入れテストだ。
あなたは次のプロジェクトの顧客です: [仕様書を言い直すか、現在のマイルストーンを貼り付け]。
マイルストーン[X]を終えたと思います。ユーザーの視点から見て、私のプログラムがすることは以下のとおりです: [コードではなく、観察可能な振る舞いを記述]。
1. そのマイルストーンの各成功基準を順に見ていってください: それが本当に満たされているか検証するために、エッジケース(空の入力、範囲外の値、2回繰り返した操作)を含めて、私に的確な質問をしてください。
2. ある基準が満たされていないなら、どれがどのように満たされていないかを言ってください。ただし直し方は言わないで。
3. すべて通ったら、次のマイルストーンを示してください - やはりコードや実装のヒントなしで。この検証の儀式は、実際のプロジェクトの受け入れテストを再現する。顧客はあなたのコードを読まず、振る舞いを問いただす。エッジケースについての質問こそが値打ちのある部分だ - そこであなたは、自分の実装が処理できていないものを発見する。そして、あらゆる一人プロジェクトの決定的な瞬間が残っている。行き詰まることだ。「この部分を書いて」に切り替える誘惑がピークに達する。段階的なヒントのプロトコルでそれに抵抗しよう。各レベルが少しずつ多くを語り、あなたは前に進むために必要なレベルだけを消費する。
私はプロジェクト[コンテキスト]で行き詰まっています。詰まっている点: [やろうとしていること、試したこと、どこで壊れるか]。
段階的なヒントを、一度に1レベルずつください:
- ヒント1: 一般的な筋 - 見直すべき概念か方向性を、1文で。
- ヒント2(私が求めた場合のみ): より精密に - 私のアプローチのどの部分を考え直すべきか。
- ヒント3(私が求めた場合のみ): 解決策の原理を、平易な言葉で説明、コードなし。
ヒント1から始めて、私の返事を待ってください。私がじれてもしつこく求めても、決してレベルを飛ばさないでください。