ai-native-engineeringlisted

# AI-native Engineering 人間主体の開発で身についた「大変そうだから小さく始める」という直感を、そのままAI主体の開発へ持ち込まない。AIは明確な仕様を持つ実装・検証・移行作業を長時間かつ並列に進められる。人間なら大規模に見える基盤整備でも、AIが数日継続して進められ、人の関与が判断とレビューに限られるなら、十分に安いことがある。 同時に、AIが作れることと、作る価値があることは別である。需要未確認の機能や将来像だけに基づく汎用機構は、コード量だけでなく、理解・変更・運用する対象を増やす。 目的は初期実装量の最小化ではない。**プロダクトのライフサイクル全体で、手戻り、移行、保守、並列開発の阻害、機会損失を最小化しながら、本来あるべき品質を最短で実現すること**である。 これは最も多く作ることでも、最も少なく作ることでもない。必要な契約と品質を満たす**最も単純な構成**を選び、機構は実需に合わせて足す。 ## 最上位原則 1. **今の実装コストではなく、総コストで判断する。** 実装、将来の移行、データ変換、互換維持、運用、障害、開発停止を含める。 2. **後から高く付く決定を先に正す。** 全体へ波及する基盤や不可逆な契約は、現在小規模でも妥協案へ流さない。 3. **同じ結果を出せるなら、最も単純な構成を選ぶ。** 機構、抽象、概念、運用対象を増やす案は、増やす具体的な理由を示せない限り採らない。単純さは品質の削減ではなく、同じ品質を少ない仕組みで達成することである。 4. **後から安く足せるものは需要を待つ。** 独立した機能、表示、便利機能は、実需が出た時にAIで追加できるなら先回りしない。 5. **コア体験の品質を後回しにしない。** ユーザーが価値を得る主要導線は、機能数を絞っても、操作性、明瞭さ、応答性、accessibility、失敗時の回復を含む完成度を初期から高くする。 6. **品質をYAGNIの対象にしないが、機構の量と混同しない。** テスト、データ整合性、復旧可能性、現在の脅威モデルに必要なsecurityは価値を成立させる条件である。脅威や規模のない防御機構は品質ではなく投機的な運用負荷として評価する。 7. **人間の時間とAIの時間を分ける。** AIの実装時間を人間工数と同じ重さで扱わず、人間の判断待ちと外部待ちをカレンダー上の支配要因として扱う。 8. **理想形は機構の最大化ではない。** 業界標準に沿い、根本問題を解き、将来の主要経路を塞がず、不要な概念を持たない形を理想とする。 ## なぜ「後から高く付くか」が重要か 一度広く使われた基盤契約は、変更時にコード以外も動かす。 - データ移行、二重書込み、backfill、互換期間が発生する。 - API利用者、複数repository、デプロイ、監視、運用手順へ波及する。 - 認証・権限境界の変更は、全経路の再監査を要求する。 - 大型refactor中は共有箇所が不安定になり、他の並列実装を止める。 - 移行期間中の二重構造が、障害と認知負荷を増やす。 AIが移行コードを速く書けても、状態を安全に動かす順序、互換性、観測期間、人間の確認、外部連携までは消えない。したがって、**変更半径が大きく、状態を持ち、他作業を長く塞ぐ決定ほど、初期に良い設計へ投資する価値が高い**。 ## 5つの判断軸 提案ごとに、少なくとも次を言語化する。 ### 1. 後戻りコスト - 変更対象は局所か、全体横断か。