Modern Engineering Values
What it is
A field-tested set of engineering values from Christoph Nakazawa (cpojer) after delivering multiple projects written mostly or entirely by AI. The values address how agent-assisted development changes team structure, code ownership, taste, constraints, context management, and stack decisions.
Why it matters
As AI-generated code becomes the default, the bottleneck shifts from "can we write this?" to "can we own, understand, and evolve this?" These values provide a concrete framework for maintaining engineering discipline when most lines are written by agents.
Key points
1. Strong Ownership
Agent amplification makes ownership effects more extreme. People who deeply understand the product execute faster; people without context generate more noise. The most effective teams are small (2-3 people) with clear ownership boundaries and isolated repositories. Code review should focus on alignment, not arguing about code.
2. Taste, Taste, Taste
"I have a low tolerance for bullshit, and with agents, everyone can generate a lot of bullshit all day long. Please just stop." Taste becomes the primary filter when execution cost approaches zero.
3. Strict Guardrails and Fast Feedback Loops
Agents are like new engineers dropped into a codebase without context. The more constraints (lint rules, automated tests, type checks), the faster the iteration. Strict guardrails and fast feedback loops are the difference between an agent finishing in 1 minute versus 60 minutes.
4. Context in the Repo
Previously context was scattered across Notion, Google Docs, people, implicit knowledge, production behavior, commits, and code. Every agent session is like a new employee. The best place to inject taste, values, principles, and personal thinking is inside the repository itself. Simpler, less code is easier to understand and fix.
5. Own Your Stack
Historically 95% of code might be third-party dependencies. Each dependency introduces code, architecture, constraints, and decisions you do not necessarily understand or control. Agents change the cost calculus, reducing the complexity of building your own. cpojer spent years building his own open-source JavaScript stack (database, i18n, UI library, tooling, starter templates) to enable fast, constrained project creation with full control over product and user experience.
6. Option Value
Any system change should unlock more options for future improvement. AI fundamentally changes the time required for large-scale changes, but vibe-coding yourself into a corner can make escape difficult or impossible.
Management implication
Engineering management becomes more technical, not less. As execution gets cheaper, individual contributors gain more leverage. Managers can no longer own only outcomes or direction; they must retain domain expertise, be able to make confident project changes, and provide technical leadership.
Evidence across sources
| Source | Key Claim | Relevance |
|---|---|---|
| cpojer — Modern Engineering Values | Six values after delivering multiple AI-written projects; 770 commits/30 days, 15k lines/day average | Primary operational framework |
Open questions
- How transferable are these values to teams that cannot afford to build their own stack?
- Does "strong ownership" in small teams scale to organizations with 50+ engineers?
- What is the maintenance burden of custom stacks when the original builder leaves?
- How do these values interact with open-source contribution norms?
Prompts for witness
- Which of the six values is most violated in your current projects?
- If you were to write your own engineering values for agent-assisted work, what would differ from cpojer's list?
- What is the right balance between "own your stack" and "don't rebuild what exists" in your domain?
Related
- harness-engineering/ai-engineering-culture-stack
- harness-engineering/agentic-engineering-practices
- product-trends/ai-founder-guide-to-taste
- claude-code/what-makes-good-agents-md
Prompts for witness
- Prompt 1: cpojer 提出的六个价值观中，"Strong Ownership"和"Taste"与 Jean 目前的多 agent 项目并行状态是否冲突？她同时在推进 Aperture、Book Nebula、Color Work 等 5+ 项目，每个项目都有不同的技术栈。如果严格执行"小团队、强 ownership"，她需要砍掉哪些？这个取舍过程本身值得记录。
- Prompt 2: 反方：如果 agents 的产出质量确实在快速提升，"taste as filter"会不会变成一种精英主义的傲慢？当代码生成成本趋近于零，"阻止 bullshit"的审美标准是否反而会成为创新的阻碍？Jean 自己在 OSS PR 和 agent 输出中，有没有过"先发布再打磨"的成功反例？