AI Engineering Culture Stack
What it is
The AI engineering culture stack is a pace-layer model for agent-assisted software work: standards are the slow foundation, then architecture, specs, plans, and code as the fastest layer. The reusable insight is that code becomes cheap and volatile when agents can generate it quickly, so the durable leverage moves downward into the layers that preserve judgment, system theory, and alignment.
Why it matters
This reframes AI engineering away from the "software factory" metaphor. The hard problem is not eliminating variance like an assembly line; it is keeping humans and agents aligned on what should be built, why, and under which constraints. Without slow layers, AI-generated code becomes "nobody's theory": runnable output without the shared mental model needed to evolve the system.
For Jean's workflow, this argues for strengthening AGENTS.md, CLAUDE.md, architecture notes, skill rules, absorb logs, and MOCs before expecting agents to reliably execute more autonomous work.
Evidence across sources
| Source | Evidence | Implication |
|---|---|---|
| Every — The Culture of AI Engineering | Noah Brier maps AI engineering to standards, architecture, specs, plans, and code, using Stewart Brand's pace layers and Peter Naur's "programming as theory building". | Agent output quality depends on durable cultural and architectural layers, not only model capability. |
| AI 简报 2026-06-07 Evening | Kieran Klaassen reports writing no code this year yet shipping more, because agents moved his bottleneck from implementation to planning, product taste, and feedback. | The leverage point in agentic engineering shifts downward from code to judgment and alignment layers. |
| AI 简报 2026-06-07 Evening | Matt Van Horn's plan-first workflow: 80% planning, code last; plan.md as persistent checkpoint; voice input and contextual compounding across documents and decisions. | Fast code generation requires even stronger slow-layer discipline to preserve intent and recover context. |
Open questions
- This is still a single-source candidate; it needs second-source validation from real team practices or Jean's own OpenClaw/wiki workflow.
- Where should this stack be enforced in practice: repository rules, skills, tests, MOCs, or periodic reviews?
- How much of
specshould remain prose versus becoming executable tests, schemas, or scripts? - When a project grows, which local pattern deserves promotion into a reusable skill or global standard?