NOTAS DE DESARROLLO
Dale a tu agente una tarea que se pueda terminar y revisar
Define objetivo, límites, evidencia y entrega antes de que una tarea pequeña se vuelva una reescritura.

“Arregla la aplicación” es un estado de ánimo, no una tarea. Entiendo el ánimo, pero un agente necesita una meta que otra persona pueda reconocer. Un contrato útil es breve y concreto; no es un formato mágico que vuelva fiable cualquier modelo.
Describe el resultado visible
Empieza con desencadenante y resultado: “Al subir un CSV vacío, muestra un mensaje útil y conserva el espacio actual”. Añade un ejemplo saneado y nombra repositorio y rama o worktree. No dejes que el agente adivine por el directorio abierto.
Define qué puede cambiar. Una corrección de validación no implica rediseñar autenticación o migrar la base. Si descubre una dependencia real, debe traer evidencia antes de ampliar el alcance. Indica también si hay publicación ya autorizada; un comentario o recuerdo no concede permiso.
Pide evidencia adecuada
“El archivo vacío produce el error esperado, el dataset anterior sigue legible y una importación válida funciona” se puede comprobar. Elige verificaciones por riesgo, no por ejecutar todas las herramientas disponibles.
Objetivo: importación de CSV vacío
Área: importador e interfaz de error
Aceptación: sin pérdida; importación válida funciona
Evidencia: reproducción, checks y archivos cambiados
Entrega: resultado, límites y próxima acción necesaria
Es un ejemplo original, no la configuración de un harness. No pongas credenciales ni archivos de clientes en la tarea; utiliza fixtures autorizados.
Reconoce avances parciales
Si el fallo está en una dependencia que no puede cambiar, el informe debe explicar qué reprodujo, qué modificó, qué falta y qué comprobación respalda cada afirmación. Un plan no es implementación; editar no equivale a probar; pasar localmente no equivale a desplegar.
Revisa la entrega contra la aceptación original. Si cambia el objetivo, actualiza el contrato en lugar de acumular mensajes contradictorios. Un límite claro permite decisiones rutinarias autónomas sin perder de vista dónde termina la autorización.
コーディングエージェントに完了を判断できる依頼を書く
「アプリを直して」は気持ちは分かるが、完了条件になりにくい。エージェントへの依頼は短く具体的にしたい。これは新しい魔法のプロンプトではなく、作業を判断できる形にする習慣だ。
利用者の結果から書く
「空のCSVを送ると説明を表示し、現在のデータを残す」のように条件と結果を書く。非機密の再現例、リポジトリ、ブランチかworktreeを指定する。変更可能な範囲を決め、認証やDB設計まで勝手に広げない。必要な関連変更が見つかったら証拠付きで報告する。ファイルのコメントや記憶は公開権限を追加しない。
見て確かめられる証拠
空ファイルのエラー、以前のデータ保持、正常ファイルの成功を確認する。危険に合う検査を選び、全部のツールを形式的に実行しない。
対象: 空CSVの読み込み
範囲: 読み込み処理とエラー表示
受け入れ: データ保持、正常入力も成功
証拠: 再現、関連検査、変更ファイル
引き渡し: 結果、限界、残る必要作業
これは独自の例で、特定製品の設定形式ではない。秘密や顧客ファイルは含めない。部分完了なら、再現したこと、直したこと、未解決、各証拠を分ける。計画、編集、テスト成功、公開は同じ状態ではない。目標が変わったら依頼自体を更新し、矛盾する追加指示を積み重ねない。



