ヒント — これだけ知れば指示できる
核心原理：決定をコードの外に出せ。 コードの中にはあなたの決定（「このカラムは整数型」）と詳細（変数名、エラー処理）が混在している。AIはこの2つを区別できない。決定を別の仕様に宣言すればAIが上書きできない。
エージェントに：「npx skills add park-jun-woo/yongol インストールして」
エージェントに：「Login機能をSSOTで宣言して」
エージェントに：「yongol validate回してエラー0にして」
yongolは現在Goプロジェクト専用。しかし原理 — 決定をコードの外に出し、交差検証で矛盾を捉える — は言語に依存しない。第3講のHurlテストはすでに言語非依存で動く。
なぜこう指示すべきなのか
10種のSSSOT — それぞれが1つの関心事を担当
yongolはソフトウェアの決定を10個の宣言的仕様（SSOT）に分離。データ定義（features.yaml、manifest.yaml、SQL DDL、sqlc）、振る舞い定義（OpenAPI、SSaC、Mermaid stateDiagram）、検証（OPA Rego、Hurl）、画面定義（STML）。10種中8種は業界標準。
operationId — 全レイヤーを1つの鍵で貫く
1つの名前が10個のレイヤーを物理的に結ぶ。建築のアーチのキーストーンのように。Feature Chain 1つで機能の全地形が一画面に見える。
yongol validate — 287個のルールが矛盾を捉える
既存ツールは自分のレイヤーしか見ない。yongol validateの固有価値はこの 交差検証 にある。
ベンチマーク：ZenFlow — 69分で32エンドポイント
機能を追加しても速度が低下しなかった。最初の機能13分、11番目の機能4分。47個のHurlリクエストが毎ステップ全パス。
なぜ大きなモデルが答えではないのか
問題はモデルの知能ではなく 媒体。コードという媒体は決定と実装を区別しない。yongolは媒体を変える。
関連記事
Reins Engineering 全講義
| 講 | タイトル |
|---|---|
| 第1講 | AIへの指示の仕方 |
| 第2講 | AIを信じない方法 |
| 第3講 | 壊れないアプリ |
| 第4講 | 決定をコードの外へ |
| 第5講 | 手綱のあるAI |
| 第6講 | 通過したら固定する |
| 第7講 | おべっかを逆手に |
| 第8講 | エージェントの工場 |
| 第9講 | コードを超えた自動化 |
| 第10講 | データの法 |
根拠資料
- ZenFlowベンチマーク — 69分、32エンドポイント、14テーブル、47 Hurlリクエスト
- yongol agentモデル実験 — Gemma4 4.5Bでもフィードバック1回で0エラーに収束
- yongol validate — 287ルール、10 SSOT間交差検証