Build, then align

What it is

Zach Lloyd（Warp CEO）2026-05-07 在 X 上发布的核心观点：在 Agent 时代，"先对齐再开发"的传统流程已经过时。如果你还在花大量时间开会、写 doc、Slack 对齐之后才动手 build，you're doing it wrong。

Why it matters

当编码变成产品开发中最便宜的步骤，整个组织工作流发生倒置。团队若在 build 前持续投入对齐会议，等于把最昂贵的资源——时间——花在最没有杠杆效应的活动上。

旧世界的对齐为什么必要

写代码是最贵、最慢的环节，所以在动手前要确保所有 stakeholder（开发、设计、PM、senior 工程师、Leadership）对"要做什么"达成一致。两个目的：

1. 第一次就尽可能做对
2. 避免"以为在做 X 结果做出来是 Y"——这种 stakeholder surprise 会带来巨大延迟

为了对齐，需要会议、Slack 长串、Loom 录屏——昂贵，但比"做错了重来"便宜。

新世界为什么这套流程崩了

编码瓶颈正在消失。当 build 变得极快极便宜，前置对齐的成本反而成了瓶颈。

"Once something is built, you are no longer guessing. You are experimenting. What's more, you are all experimenting on the same thing, not on some hypothetical implementation of a thing which every stakeholder is imagining working in a slightly different way."

关键洞察：脑子里想象的产品和实际跑起来的产品永远不一样。每个 stakeholder 脑中那个"实现"都略有不同——前置对齐其实是在对齐一堆幻觉。

流程对比

旧流程（Warp 的 How We Work guide）

1. 明确问题和用户目标
2. 团队探索解决方案空间（product jam）
3. 设计多个方案 mockup（设计瓶颈）
4. 团队对齐选哪个方案（团队对齐瓶颈）
5. 写代码（编码瓶颈，正在消失）
6. review 是否符合 spec（验证瓶颈）
7. 内部 dogfood 迭代
8. Bug bash
9. Ship

新流程

把第 4 步（团队对齐）移到第 5、6 步之后。

仍然要做问题定义、product jam、设计第一版猜测方案——但目标是尽快启动一个基于实物的反馈循环，而不是争论哪个方案最好。

旧:  问题 → 方案争论 → 对齐 → 写代码 → 验证 → 迭代
新:  问题 → 初版设计 → 写代码 → 体验 → 对齐 → 迭代
                              ↑
                       低成本 build = 真实样本

关键心法

• 不要纠结第一版是否完美 — it doesn't matter
• 想做几个版本就做几个版本，让用户试
• 别浪费 cycle 猜，build it 然后体验真实方案
• "Alignment should come after we have solutions in-hand"

Warp 的反例与正例

反例（2023）：做 Warp Drive（协作平台）时，花了无数小时在 mockup、Slack、PRD 上对齐才动手。Zach 自评："I would not do this again."

正例（2026 最近）：发布 coding agent 套件时，只在"问题"上对齐（让 Warp 成为用任何 coding agent 的最佳地方），但不 bikeshed 方案。设计团队出初版设计 → 团队 build → 一起迭代 → 上线时自然对齐。

一个重要边界

Zach 强调：他说的 alignment 是人和人对齐（humans aligning with each other on how a product should work），不是人和 agent 对齐（humans aligning with agents on how to build）。后者他完全支持，参见他自己的 Spec & Verify 文章。

换句话说：

• 人对人 alignment → 后置（先 build）
• 人对 agent alignment → 前置（写好 spec）

Evidence across sources

Open questions

• Does "build then align" apply to regulated industries where post-build changes carry compliance costs?
• How does team size affect the viability of this workflow? Warp is a startup; does it scale to 500-person product teams?
• When coding is no longer the bottleneck, what becomes the new bottleneck — design judgment, user research, or distribution?

Related

• vibe-coding-market-dynamics — 编码瓶颈消失带来的产品流程重组
• ai-mediated-competence / ai-driven-layoffs-2026 — build-验证循环变快后，对"判断对错"的能力反而要求更高
• agent-native-architecture-three-principles — Agent 时代的设计哲学