# Why Your “AI-First” Strategy Is Probably Wrong
**作者**: Peter Pang
**日期**: 2026-04-13T04:23:32.000Z
**来源**: [https://x.com/intuitiveml/status/2043545596699750791](https://x.com/intuitiveml/status/2043545596699750791)
---
99% of our production code is written by AI. Last Tuesday, we shipped a new feature at 10 AM, A/B tested it by noon, and killed it by 3 PM because the data said no. We shipped a better version at 5 PM. Three months ago, a cycle like that would have taken six weeks.
We didn't get here by adding Copilot to our IDE. We dismantled our engineering process and rebuilt it around AI. We changed how we plan, build, test, deploy, and organize the team. We changed the role of everyone in the company.
CREAO is an agent platform. Twenty-five employees, 10 engineers. We started building agents in November 2025, and two months ago I restructured the entire product architecture and engineering workflow from the ground up.
OpenAI published a concept in February 2026 that captured what we'd been doing. They called it harness engineering: the primary job of an engineering team is no longer writing code. It is enabling agents to do useful work. When something fails, the fix is never "try harder." The fix is: what capability is missing, and how do we make it legible and enforceable for the agent?
We arrived at that conclusion on our own. We didn't have a name for it.
## AI-First Is Not the Same as Using AI
Most companies bolt AI onto their existing process. An engineer opens Cursor. A PM drafts specs with ChatGPT. QA experiments with AI test generation. The workflow stays the same. Efficiency goes up 10 to 20 percent. Nothing structurally changes.
That is AI-assisted.
AI-first means you redesign your process, your architecture, and your organization around the assumption that AI is the primary builder. You stop asking "how can AI help our engineers?" and start asking "how do we restructure everything so AI does the building, and engineers provide direction and judgment?"
The difference is multiplicative.
I see teams claim AI-first while running the same sprint cycles, the same Jira boards, the same weekly standups, the same QA sign-offs. They added AI to the loop. They didn't redesign the loop.
A common version of this is what people call vibe coding. Open Cursor, prompt until something works, commit, repeat. That produces prototypes. A production system needs to be stable, reliable, and secure. You need a system that can guarantee those properties when AI writes the code. You build the system. The prompts are disposable.
## Why We Had to Change
Last year, I watched how our team worked and saw three bottlenecks that would kill us.
The Product Management Bottleneck
Our PMs spent weeks researching, designing, specifying features. Product management has worked this way for decades. But agents can implement a feature in two hours. When build time collapses from months to hours, a weeks-long planning cycle becomes the constraint.
It doesn't make sense to think about something for months and then build it in two hours.
PMs needed to evolve into product-minded architects who work at the speed of iteration, or step out of the build cycle. Design needed to happen through rapid prototype-ship-test-iterate loops, not specification documents reviewed in committee.
The QA Bottleneck
Same dynamic. After an agent shipped a feature, our QA team spent days testing corner cases. Build time: two hours. Test time: three days.
We replaced manual QA with AI-built testing platforms that test AI-written code. Validation has to move at the same speed as implementation. Otherwise you've built a new bottleneck ten feet downstream from the old one.
The Headcount Bottleneck
Our competitors had 100x or more people doing comparable work. We have 25. We couldn't hire our way to parity. We had to redesign our way there.
Three systems needed AI running through them: how we design product, how we implement product, and how we test product. If any single one stays manual, it constrains the whole pipeline.
## The Bold Decision: Unifying the Architecture
I had to fix the codebase first.
Our old architecture was scattered across multiple independent systems. A single change might require touching three or four repositories. From a human engineer's perspective, it is manageable. From an AI agent's perspective, opaque. The agent can't see the full picture. It can't reason about cross-service implications. It can't run integration tests locally.
I had to unify all the code into a single monorepo. One reason: so AI could see everything.
This is a harness engineering principle in practice. The more of your system you pull into a form the agent can inspect, validate, and modify, the more leverage you get. A fragmented codebase is invisible to agents. A unified one is legible.
I spent one week designing the new system: planning stage, implementation stage, testing stage, integration testing stage. Then another week re-architecting the entire codebase using agents.
CREAO is an agent platform. We used our own agents to rebuild the platform that runs agents. If the product can build itself, it works.
## The Stack
Here is our stack and what each piece does.
Infrastructure: AWS
We run on AWS with auto-scaling container services and circuit-breaker rollback. If metrics degrade after a deployment, the system reverts on its own.
CloudWatch is the central nervous system. Structured logging across all services, over 25 alarms, custom metrics queried daily by automated workflows. Every piece of infrastructure exposes structured, queryable signals. If AI can't read the logs, it can't diagnose the problem.
CI/CD: GitHub Actions
Every code change passes through a six-phase pipeline:
Verify CI → Build and Deploy Dev → Test Dev → Deploy Prod → Test Prod → Release
The CI gate on every pull request enforces typechecking, linting, unit and integration tests, Docker builds, end-to-end tests via Playwright, and environment parity checks. No phase is optional. No manual overrides. The pipeline is deterministic, so agents can predict outcomes and reason about failures.
AI Code Review: Claude
Every pull request triggers three parallel AI review passes using Claude Opus 4.6:
Pass 1: Code quality. Logic errors, performance issues, maintainability.
Pass 2: Security. Vulnerability scanning, authentication boundary checks, injection risks.
Pass 3: Dependency scan. Supply chain risks, version conflicts, license issues.
These are review gates, not suggestions. They run alongside human review, catching what humans miss at volume. When you deploy eight times a day, no human reviewer can sustain attention across every PR.
Engineers also tag @claude in any GitHub issue or PR for implementation plans, debugging sessions, or code analysis. The agent sees the whole monorepo. Context carries across conversations.
The Self-Healing Feedback Loop
This is the centerpiece.
Every morning at 9:00 AM UTC, an automated health workflow runs. Claude Sonnet 4.6 queries CloudWatch, analyzes error patterns across all services, and generates an executive health summary delivered to the team via Microsoft Teams. Nobody had to ask for it.
One hour later, the triage engine runs. It clusters production errors from CloudWatch and Sentry, scores each cluster across nine severity dimensions, and auto-generates investigation tickets in Linear. Each ticket includes sample logs, affected users, affected endpoints, and suggested investigation paths.
The system deduplicates. If an open issue covers the same error pattern, it updates that issue. If a previously closed issue recurs, it detects the regression and reopens.
When an engineer pushes a fix, the same pipeline handles it. Three Claude review passes evaluate the PR. CI validates. The six-phase deploy pipeline promotes through dev and prod with testing at each stage. After deployment, the triage engine re-checks CloudWatch. If the original errors are resolved, the Linear ticket auto-closes.
Each tool handles one phase. No tool tries to do everything. The daily cycle creates a self-healing loop where errors are detected, triaged, fixed, and verified with minimal manual intervention.
I told a reporter from Business Insider: "AI will make the PR and the human just needs to review whether there's any risk."
Feature Flags and the Supporting Stack
Statsig handles feature flags. Every feature ships behind a gate. The rollout pattern: enable for the team, then gradual percentage rollout, then full release or kill. The kill switch toggles a feature off instantly, no deploy needed. If a feature degrades metrics, we pull it within hours. Bad features die the same day they ship. A/B testing runs through the same system.
Graphite manages PR branching: merge queues rebase onto main, re-run CI, merge only if green. Stacked PRs allow incremental review at high throughput.
Sentry reports structured exceptions across all services, merged with CloudWatch by the triage engine for cross-tool context. Linear is the human-facing layer: auto-created tickets with severity scores, sample logs, and suggested investigation. Deduplication prevents noise. Follow-up verification auto-closes resolved issues.
## How a Feature Moves from Idea to Production
New Feature Path
The architect defines the task as a structured prompt with codebase context, goals, and constraints.
An agent decomposes the task, plans implementation, writes code, and generates its own tests.
A PR opens. Three Claude review passes evaluate it. A human reviewer checks for strategic risk, not line-by-line correctness.
CI validates: typecheck, lint, unit tests, integration tests, end-to-end tests.
Graphite's merge queue rebases, re-runs CI, merges if green.
Six-phase deploy pipeline promotes through dev and prod with testing at each stage.
Feature gate turns on for the team. Gradual percentage rollout. Metrics monitored.
Kill switch available if anything degrades. Circuit-breaker auto-rollback for severe issues.
Bug Fix Path
CloudWatch and Sentry detect errors.
Claude triage engine scores severity, creates a Linear issue with full investigation context.
An engineer investigates. AI has already done the diagnosis. The engineer validates and pushes a fix.
Same review, CI, deploy, and monitoring pipeline.
Triage engine re-verifies. If resolved, ticket auto-closes.
Both paths use the same pipeline. One system. One standard.
## The Results
Over 14 days, we averaged three to eight production deployments per day. Under our old model, that entire two-week period would have produced not even a single release to production.
Bad features get pulled the same day they ship. New features go live the same day they're conceived. A/B tests validate impact in real time.
People assume we're trading quality for speed. User engagement went up. Payment conversion went up. We produce better results than before, because the feedback loops are tighter. You learn more when you ship daily than when you ship monthly.
## The New Engineering Org
Two types of engineers will exist.
The Architect
One or two people. They design the standard operating procedures that teach AI how to work. They build the testing infrastructure, the integration systems, the triage systems. They decide architecture and system boundaries. They define what "good" looks like for the agents.
This role requires deep critical thinking. You criticize AI. You don't follow it. When the agent proposes a plan, the architect finds the holes. What failure modes did it miss? What security boundaries did it cross? What technical debt is it accumulating?
I have a PhD in physics. The most useful thing my PhD taught me was how to question assumptions, stress-test arguments, and look for what's missing. The ability to criticise AI will be more valuable than the ability to produce code.
This is also the hardest role to fill.
The Operator
Everyone else. The work matters. The structure is different.
AI assigns tasks to humans. The triage system finds a bug, creates a ticket, surfaces the diagnosis, and assigns it to the right person. The person investigates, validates, and approves the fix. AI makes the PR. The human reviews whether there's risk.
The tasks are bug investigation, UI refinement, CSS improvements, PR review, verification. They require skill and attention. They don't require the architectural reasoning the old model demanded.
Who Adapts Fastest
I noticed a pattern I didn't expect. Junior engineers adapted faster than senior engineers.
Junior engineers with less traditional practice felt empowered. They had access to tools that amplified their impact. They didn't carry a decade of habits to unlearn.
Senior engineers with strong traditional practice had the hardest time. Two months of their work could be completed in one hour by AI. That is a hard thing to accept after years of building a rare skill set.
I'm not making a judgment. I'm describing what I observed. In this transition, adaptability matters more than accumulated skill.
## The Human Side
Management Collapsed
Two months ago, I spent 60% of my time managing people. Aligning priorities. Running meetings. Giving feedback. Coaching engineers.
Today: below 10%.
The traditional CTO model says to empower your team to do architecture work, train them, delegate. But if the system only needs one or two architects, I need to do it myself first. I went from managing to building. I code from 9 AM to 3 AM most days. I design the SOPs and architecture of the system. I maintain the harness.
More stressful. But I'm enjoying building, not aligning.
Less Arguing, Better Relationships
My relationships with co-founders and engineers are better than before.
Before the transition, most of my interaction with the team was alignment meetings. Discussing trade-offs. Debating priorities. Disagreeing about technical decisions. Those conversations are necessary in a traditional model. They're also draining.
Now I still talk to my team. We talk about other things. Non-work topics. Casual conversations. Offsite trips. We get along better because we stopped arguing about work that can be easily done by our system.
Uncertainty Is Real
I won't pretend everyone is happy.
When I stopped talking to people every day, some team members felt uncertain. What does the CTO not talking to me mean? What is my value in this new world? Reasonable concerns.
Some people spend more time debating whether AI can do their work than doing the work. The transition period creates anxiety. I don't have a clean answer for it.
I do have a principle: we don't fire an engineer because they introduced a production bug. We improve the review process. We strengthen testing. We add guardrails. The same applies to AI. If AI makes a mistake, we build better validation, clearer constraints, stronger observability.
## Beyond Engineering
I see other companies adopt AI-first engineering and leave everything else manual.
If engineering ships features in hours but marketing takes a week to announce them, marketing is the bottleneck. If the product team still runs a monthly planning cycle, planning is the bottleneck.
At CREAO, we pushed AI-native operations into every function:
- Product release notes: AI-generated from changelogs and feature descriptions.
- Feature intro videos: AI-generated motion graphics.
- Daily posts on socials: AI-orchestrated and auto-published.
- Health reports and analytics summaries: AI-generated from CloudWatch and production databases.
Engineering, product, marketing, and growth run in one AI-native workflow. If one function operates at agent speed and another at human speed, the human-speed function constrains everything.
## What This Means
For Engineers
Your value is moving from code output to decision quality. The ability to write code fast is worth less every month. The ability to evaluate, criticize, and direct AI is worth more.
Product sense or taste matters. Can you look at a generated UI and know it's wrong before the user tells you? Can you look at an architecture proposal and see the failure mode the agent missed?
I tell our 19-year-old interns: train critical thinking. Learn to evaluate arguments, find gaps, question assumptions. Learn what good design looks like. Those skills compound.
For CTOs and Founders
If your PM process takes longer than your build time, start there.
Build the testing harness before you scale agents. Fast AI without fast validation is fast-moving technical debt.
Start with one architect. One person who builds the system and proves it works. Onboard others into operator roles after the system runs.
Push AI-native into every function.
Expect resistance. Some people will push back.
For the Industry
OpenAI, Anthropic, and multiple independent teams converged on the same principles: structured context, specialized agents, persistent memory, and execution loops. Harness engineering is becoming a standard.
Model capability is the clock driving this. I attribute the entire shift at CREAO to the last two months. Opus 4.5 couldn't do what Opus 4.6 does. Next-gen models will accelerate it further.
I believe one-person companies will become common. If one architect with agents can do the work of 100 people, many companies won't need a second employee.
## We're Early
Most founders and engineers I talk to still operate the traditional way. Some think about making the shift. Very few have done it.
A reporter friend told me she'd talked to about five people on this topic. She said we were further along than anyone: "I don't think anyone's just totally rebuilt their entire workflow the way you have."
The tools exist for any team to do this. Nothing in our stack is proprietary.
The competitive advantage is the decision to redesign everything around these tools, and the willingness to absorb the cost. The cost is real: uncertainty among employees, the CTO working 18-hour days, senior engineers questioning their value, a two-week period where the old system is gone and the new one isn't proven.
We absorbed that cost. Two months later, the numbers speak.
We build an agent platform. We built it with agents.
## 相关链接
- [Peter Pang](https://x.com/intuitiveml)
- [@intuitiveml](https://x.com/intuitiveml)
- [1.2M](https://x.com/intuitiveml/status/2043545596699750791/analytics)
- [@claude](https://x.com/@claude)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:23 PM · Apr 13, 2026](https://x.com/intuitiveml/status/2043545596699750791)
- [1.2M Views](https://x.com/intuitiveml/status/2043545596699750791/analytics)
- [View quotes
---
## 中文翻译
# 为什么你的“AI优先”战略可能是错的
**作者**: Peter Pang
**日期**: 2026-04-13T04:23:32.000Z
**来源**: [https://x.com/intuitiveml/status/2043545596699750791](https://x.com/intuitiveml/status/2043545596699750791)
---
我们要么 99% 的生产代码都是由 AI 编写的。上周二，我们在上午 10 点发布了一个新功能，中午进行了 A/B 测试，下午 3 点因为数据表现不佳就下线了。我们在下午 5 点发布了一个更好的版本。三个月前，这样一个周期需要六周时间。
我们并不是通过在 IDE 中添加 Copilot 做到这一点的。我们拆解了工程流程并围绕 AI 进行了重建。我们改变了规划、构建、测试、部署和组织团队的方式。我们改变了公司中每个角色的定位。
CREAO 是一个智能体平台。我们拥有 25 名员工，其中 10 名是工程师。我们从 2025 年 11 月开始构建智能体，两个月前，我从零开始重构了整个产品架构和工程工作流。
OpenAI 在 2026 年 2 月发布了一个概念，概括了我们一直在做的事情。他们称之为“驾驭工程”：工程团队的主要工作不再是编写代码，而是让智能体能够完成有用的工作。当出现问题时，解决方案绝不是“再努力一点”。解决方案是：缺少了什么能力，我们如何让它对智能体来说清晰可见且可执行？
我们独自得出了这个结论。当时我们甚至没有给它命名。
## AI优先不等于使用AI
大多数公司只是把 AI 附着在现有的流程上。工程师打开 Cursor。产品经理（PM）用 ChatGPT 起草规格文档。QA（测试人员）尝试用 AI 生成测试。工作流程保持不变。效率提升了 10% 到 20%。结构没有任何变化。
这叫 AI 辅助。
AI 优先意味着你要根据“AI 是主要构建者”这一假设，重新设计你的流程、架构和组织。你不再问“AI 如何帮助我们的工程师？”，而是开始问“我们要如何重构一切，让 AI 来负责构建，而工程师提供方向和判断？”
这种差异是指数级的。
我看到一些团队声称自己是 AI 优先，但仍然运行着相同的冲刺周期，使用着相同的 Jira 看板，开着相同的每周站会，执行着相同的 QA 签收流程。他们把加到了循环中。但他们没有重新设计循环。
一个常见的版本就是人们所说的“氛围编程”。打开 Cursor，不断地尝试提示词直到能用，提交，重复。这能产出原型。但生产系统需要稳定、可靠和安全。你需要一个能保证这些特性的系统，尤其是在 AI 编写代码的情况下。你需要构建系统。提示词是一次性的。
## 为什么我们不得不改变
去年，我观察了我们团队的工作方式，发现了三个会让我们完蛋的瓶颈。
产品管理瓶颈
我们的 PM 花了数周时间来研究、设计和规范功能。几十年来，产品管理一直都是这样工作的。但是智能体可以在两小时内实现一个功能。当构建时间从数月缩减到数小时时，长达数周的规划周期就成了制约因素。
花几个月时间去思考，然后只花两小时去构建，这毫无意义。
PM 需要进化为具有产品思维的架构师，以迭代的速度工作，或者退出构建循环。设计需要通过快速的“原型-发布-测试-迭代”循环来实现，而不是通过委员会评审的规格文档。
QA 瓶颈
也是同样的动态。在智能体发布功能后，我们的 QA 团队花了几天时间测试边缘情况。构建时间：两小时。测试时间：三天。
我们用 AI 构建的测试平台取代了人工 QA，这些平台测试由 AI 编写的代码。验证必须与实施保持同步。否则你只是把瓶颈在原来的位置下游十英尺处重建了一遍。
人员瓶颈
我们的竞争对手拥有 100 倍甚至更多的人力来完成类似的工作。我们只有 25 人。我们无法靠招人来达到同等水平。我们必须通过重新设计来实现。
三个系统需要 AI 贯穿其中：我们如何设计产品，如何实施产品，以及如何测试产品。如果其中任何一个仍然是手动的，它就会限制整个管道。
## 大胆的决定：统一架构
我得先修复代码库。
我们旧的架构分散在多个独立的系统中。一次单一的更改可能需要修改三四个仓库。从人类工程师的角度来看，这是可控的。但从 AI 智能体的角度来看，这是不透明的。智能体看不到全貌。它无法推理跨服务的影响。它无法在本地运行集成测试。
我不得不将所有代码统一到一个单一的单一仓库中。原因之一：这样 AI 就能看到一切。
这是驾驭工程原则的实际应用。你将系统的更多部分变成智能体可以检查、验证和修改的形式，你获得的杠杆效应就越大。对于智能体来说，碎片化的代码库是不可见的。统一的代码库则是清晰可读的。
我花了一周时间设计新系统：规划阶段、实施阶段、测试阶段、集成测试阶段。然后又花了一周时间使用智能体重新架构了整个代码库。
CREAO 是一个智能体平台。我们使用我们自己的智能体重建了这个运行智能体的平台。如果产品能构建它自己，那它就运作正常了。
## 技术栈
这是我们的技术栈以及每个部分的用途。
基础设施：AWS
我们在 AWS 上运行，使用自动扩缩容器服务和断路器回滚机制。如果部署后指标下降，系统会自动回滚。
CloudWatch 是中枢神经系统。所有服务的结构化日志，超过 25 个警报，由自动化工作流每天查询的自定义指标。基础设施的每一部分都暴露出结构化、可查询的信号。如果 AI 无法读取日志，它就无法诊断问题。
CI/CD：GitHub Actions
每次代码变更都要经过六个阶段的管道：
验证 CI → 构建并部署到开发环境 → 测试开发环境 → 部署到生产环境 → 测试生产环境 → 发布
每个拉取请求（PR）上的 CI 门控强制执行类型检查、代码规范检查、单元测试和集成测试、Docker 构建、通过 Playwright 进行的端到端测试以及环境对等性检查。没有哪个阶段是可选的。没有人工干预。管道是确定性的，因此智能体可以预测结果并推理失败原因。
AI 代码审查：Claude
每次拉取请求都会触发三次使用 Claude Opus 4.6 的并行 AI 审查：
第一轮：代码质量。逻辑错误、性能问题、可维护性。
第二轮：安全性。漏洞扫描、身份验证边界检查、注入风险。
第三轮：依赖扫描。供应链风险、版本冲突、许可证问题。
这些是审查门控，而非建议。它们与人工审查并行运行，能以人类无法企及的量级捕获人类遗漏的问题。当你一天发布八次时，没有人类审查员能在每个 PR 上保持持续的注意力。
工程师还会在任何 GitHub issue 或 PR 中标记 @claude，以获取实施计划、调试会话或代码分析。智能体能看到整个单一仓库。上下文在对话之间持续保留。
自愈反馈循环
这是核心所在。
每天 UTC 时间上午 9:00，一个自动化健康工作流会运行。Claude Sonnet 4.6 查询 CloudWatch，分析所有服务的错误模式，并生成一份执行健康摘要，通过 Microsoft Teams 发送给团队。没有人需要去索要它。
一小时后，分诊引擎运行。它将来自 CloudWatch 和 Sentry 的生产错误进行聚类，跨越九个严重性维度对每个集群进行评分，并在 Linear 中自动生成调查工单。每张工单包括样本日志、受影响的用户、受影响的端点以及建议的调查路径。
系统会去重。如果一个未解决的 issue 涵盖了相同的错误模式，它会更新该 issue。如果之前已关闭的 issue 再次出现，它会检测到回归并重新打开。
当工程师推送修复时，同一个管道会处理它。三轮 Claude 审查评估 PR。CI 验证。六阶段部署管道在开发和生产环境中逐步提升，每个阶段都进行测试。部署后，分诊引擎会重新检查 CloudWatch。如果最初的错误已解决，Linear 工单会自动关闭。
每个工具处理一个阶段。没有工具试图做所有事情。每日循环创建了一个自愈循环，错误被检测、分诊、修复和验证，只需最少的人工干预。
我告诉《商业内幕》的一位记者：“AI 会生成 PR，人类只需要审查是否有任何风险。”
功能门控与支持栈
Statsig 处理功能门控。每个功能都在门控后发布。发布模式：先对团队启用，然后按百分比逐步推出，最后全面发布或下线。终止开关可以立即关闭某个功能，无需部署。如果某个功能导致指标下降，我们会在数小时内将其撤下。糟糕的功能在发布的当天就会消亡。A/B 测试通过同一系统运行。
Graphite 管理 PR 分支：合并队列将代码变基到主干，重新运行 CI，只有通过（绿色）才合并。堆叠式 PR 允许在高吞吐量下进行增量审查。
Sentry 报告所有服务的结构化异常，由分诊引擎与 CloudWatch 合并以获取跨工具上下文。Linear 是面向人类的层：自动创建的工单，带有严重性评分、样本日志和建议的调查路径。去重功能防止噪音。后续验证会自动关闭已解决的问题。
## 功能如何从创意走向生产
新功能路径
架构师将任务定义为一个结构化的提示词，包含代码库上下文、目标和约束。
智能体分解任务，规划实施，编写代码，并生成自己的测试。
创建一个 PR。三轮 Claude 审查对其进行评估。人类审查员检查战略风险，而不是逐行的正确性。
CI 验证：类型检查、规范检查、单元测试、集成测试、端到端测试。
Graphite 的合并队列进行变基，重新运行 CI，如果通过则合并。
六阶段部署管道在开发和生产环境中逐步提升，每个阶段都进行测试。
功能开关为团队开启。逐步百分比推出。指标受到监控。
如果出现任何下降，终止开关待命。对于严重问题，断路器会自动回滚。
Bug 修复路径
CloudWatch 和 Sentry 检测到错误。
Claude 分诊引擎评估严重性，创建包含完整调查上下文的 Linear issue。
工程师进行调查。AI 已经完成了诊断。工程师验证并推送修复。
使用相同的审查、CI、部署和监控管道。
分诊引擎重新验证。如果已解决，工单自动关闭。
两条路径使用同一个管道。一个系统。一个标准。
## 结果
在 14 天内，我们平均每天进行 3 到 8 次生产部署。在我们的旧模式下，整整两周的时间可能连一次生产发布都完成不了。
糟糕的功能在发布当天就会被撤下。新功能在构想的当天就能上线。A/B 测试实时验证影响。
人们认为我们是用质量换取了速度。但用户参与度上升了。支付转化率上升了。我们产出了比以前更好的结果，因为反馈循环更紧密。每天发布比每月发布能让你学到更多东西。
## 新的工程组织
只存在两种类型的工程师。
架构师
一到两个人。他们设计标准操作程序（SOP），教 AI 如何工作。他们构建测试基础设施、集成系统、分诊系统。他们决定架构和系统边界。他们定义智能体眼中的“好”是什么样子的。
这个角色需要深度批判性思维。你要批评 AI。而不是跟随它。当智能体提出一个计划时，架构师要找出漏洞。它漏掉了什么失败模式？它越过了什么安全边界？它在积累什么技术债务？
我拥有物理学博士学位。我的博士学位教给我最有用的东西，就是如何质疑假设、压力测试论点以及寻找缺失的部分。批评 AI 的能力将比编写代码的能力更有价值。
这也是最难填补的角色。
操作员
其他所有人。工作依然重要。结构发生了变化。
AI 给人类分配任务。分诊系统发现一个 Bug，创建工单，浮现诊断结果，并将其分配给正确的人。该人员进行调查、验证并批准修复。AI 生成 PR。人类审查是否存在风险。
任务包括 Bug 调查、UI 优化、CSS 改进、PR 审查、验证。它们需要技能和专注力。它们不需要旧模式所要求的架构推理能力。
谁适应得最快
我注意到了一个意想不到的模式。初级工程师比高级工程师适应得更快。
没有传统实践束缚的初级工程师感到充满了力量。他们能够接触到放大其影响力的工具。他们没有需要摒弃的十年积习。
拥有深厚传统实践的高级工程师则最为艰难。他们两个月的工作量，AI 可以在一小时内完成。在花数年建立了一套稀缺技能之后，这是一件很难接受的事情。
我不是在做出评判。我是在描述我的观察。在这种转型中，适应能力比积累的技能更重要。
## 人性化管理
管理工作的坍塌
两个月前，我 60% 的时间都花在管理人员上。对齐优先级。开会。提供反馈。辅导工程师。
现在：低于 10%。
传统的 CTO 模式说要赋能你的团队去做架构工作，培训他们，委派任务。但如果系统只需要一两个架构师，我需要先自己做。我从管理转向了构建。我大多数日子从早上 9 点编码到凌晨 3 点。我设计系统的 SOP 和架构。我维护这个“驾驭”。
压力更大了。但我正在享受构建，而不是对齐。
减少争执，更好的关系
我与联合创始人和工程师的关系比以前更好了。
在转型之前，我与团队的大部分互动是对齐会议。讨论权衡。辩论优先级。对技术决策持有分歧。这些对话在传统模式中是必要的。它们也很消耗精力。
现在我仍然和我的团队交谈。我们谈论其他事情。非工作话题。随意的交谈。团建旅行。我们相处得更好了，因为我们不再争论那些可以由我们的系统轻松完成的工作。
不确定性是真实存在的
我不会假装每个人都很开心。
当我不再每天和每个人说话时，一些团队成员感到不确定。CTO 不跟我说话意味着什么？在这个新世界中我的价值是什么？这些担忧是合理的。
有些人花更多时间争论 AI 是否能做他们的工作，而不是真正去工作。转型期会产生焦虑。我对此没有一个完美的答案。
但我有一个原则：我们不会因为工程师引入了生产 Bug 就解雇他。我们改进审查流程。加强测试。添加护栏。这对 AI 同样适用。如果 AI 犯了错，我们就构建更好的验证、更清晰的约束、更强的可观测性。
## 超越工程
我看到一些其他公司采用 AI 优先的工程，但其他一切仍然保持手动。
如果工程在几小时内就能发布功能，但市场营销需要一周时间来宣布，那么市场营销就是瓶颈。如果产品团队仍然按月度规划周期运行，那么规划就是瓶颈。
在 CREAO，我们将 AI 原生运营推入了每一个职能部门：
- 产品发布说明：由根据变更日志和功能描述生成。
- 功能介绍视频：AI 生成的动态图形。
- 社交媒体上的每日帖子：AI 编排并自动发布。
- 健康报告和分析摘要：从 CloudWatch 和生产数据库生成。
工程、产品、营销和增长都在一个 AI 原生工作流中运行。如果一个职能部门以智能体速度运行，而另一个以人类速度运行，那么人类速度的职能部门就会制约一切。
## 这意味着什么
对于工程师
你的价值正在从代码产出转向决策质量。快速编写代码的能力每个月都在贬值。评估、批评和指导 AI 的能力则在增值。
产品感或品味很重要。看着一个生成的 UI，在用户告诉你之前你就知道它是错的吗？看着一个架构提案，你能看到智能体遗漏的失败模式吗？
我告诉我们 19 岁的实习生：训练批判性思维。学会评估论点、寻找漏洞、质疑假设。了解什么是好的设计。这些技能是会复利的。
对于 CTO 和创始人
如果你的 PM 流程比你的构建时间还长，从那里开始。
在扩展智能体之前先构建测试“驾驭”。快速的 AI 如果没有快速的验证，就是快速移动的技术债务。
从一名架构师开始。一个人构建系统并证明它有效。在系统运行后，让其他人入职操作员角色。
将 AI 原生推入每一个职能部门。
预期会有阻力。有些人会反对。
对于行业
OpenAI、Anthropic 和多个独立团队都汇聚于相同的原则：结构化上下文、专门的智能体、持久记忆和执行循环。驾驭工程正在成为一种标准。
模型能力是驱动这一切的时钟。我将 CREAO 的整个转变归功于过去两个月。Opus 4.5 做不到 Opus 4.6 能做的事。下一代模型将进一步加速这一进程。
我相信一人公司将会变得普遍。如果一位带着智能体的架构师能完成 100 人的工作，许多公司就不需要第二名员工了。
## 我们还处于早期
大多数与我交谈的创始人和工程师仍然以传统方式运作。有些人在考虑转型。很少有人真正做到了这一点。
一位做记者的朋友告诉我，她就这个话题采访了大约五个人。她说我们要比其他任何人都走得远：“我不认为有其他人像你们这样完全重建了他们的整个工作流程。”
任何团队都可以利用现有的工具做到这一点。我们的技术栈中没有任何东西是专有的。
竞争优势在于决定围绕这些工具重新设计一切，以及愿意承担相应的成本。成本是真实的：员工的不确定性、CTO 每天 18 小时的工作日、高级工程师质疑自己的价值、旧系统已去而新系统未经验证的两周时期。
我们承担了这些成本。两个月后，数据说明了一切。
我们构建了一个智能体平台。我们是用智能体构建的。
## 相关链接
- [Peter Pang](https://x.com/intuitiveml)
- [@intuitiveml](https://x.com/intuitiveml)
- [1.2M](https://x.com/intuitiveml/status/2043545596699750791/analytics)
- [@claude](https://x.com/@claude)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:23 PM · Apr 13, 2026](https://x.com/intuitiveml/status/2043545596699750791)
- [1.2M Views](https://x.com/intuitiveml/status/2043545596699750791/analytics)
- [View quotes