# A Practical Guide to Becoming an AI-Native Engineer
**作者**: Bytebytego
**日期**: 2026-06-02T14:46:18.000Z
**来源**: [https://x.com/bytebytego/status/2061821715450351992](https://x.com/bytebytego/status/2061821715450351992)
---
If AI writing everything is the answer, then why are most engineering teams shipping more bugs, more incidents, and more technical debt than they shipped two years ago?
That's where this week's guest post starts, and it turns into one of the most practical guides we've seen for engineers trying to actually level up in the AI era.
A Practical Guide to Becoming an AI-Native Engineer, by Shah Rahman, Global Head of Autonomous ML Iteration & Optimization for Ads at Meta.
AI generates more than 75% of Google’s new code. OpenAI and Anthropic claim that almost every line of fresh code that they produce comes from AI. Amazon recently migrated 30,000 of its production applications from Java 8 to Java 17 in a matter of months, a project that would otherwise have taken an estimated 4,500 developer-years. And Mark Zuckerberg expects that AI agents will be operating as mid-level engineers by the end of 2026.
Reading those statements, we may feel as if we are looking at the last lines being written on the closing pages of an era. Perhaps even the closing pages of a profession.
But here’s the question: If AI writing everything is the answer, then why are most engineering teams shipping more bugs, more incidents, and more technical debt than they shipped two years ago?
In an April article in the New York Times, Mike Isaac and Erin Griffith gave a name to describe what's happening across the industry. They called it code overload.
The essence of code overload, according to Isaac and Griffith, is that “tech workers are producing so much code so quickly that it has become too much to handle.” Teams that have rebuilt their work around the use of AI agents are drowning in code churn and security holes.
But. Many engineers who have employed AI agents are pulling ahead of the field, achieving real productivity gains. They are using the same models and the same tools, but they are generating very different outcomes. What explains the gap?
It comes down to one decision. Real productivity gains come when engineers decide to make the leap from writing code to orchestrating it. This piece is a working guide for engineers who want to land on the productive side of that split. It will cover the practices, guardrails, and mindset shifts that separate AI-native engineering from vibe coding and from the everyday chaos that most teams are now generating at scale.
# From Engineer to Orchestrator
Let me first clarify one thing: engineers are not becoming obsolete. Coding has always been a small part of engineering (20-30% max). This underappreciated reality is more visible when AI agents and tools produce more code, but more code is not necessarily more productive (often it’s less). This is a critical distinction that the industry is blurring dangerously, and I state that as:
When Andrej Karpathy coined "vibe coding" in early 2025, it captured something useful — the ability for non-engineers to build functional software by describing what they want. That democratization is valuable. But it's categorically different from professional AI-native engineering.
AI-native engineering means commanding and mastering available and emerging AI agents and tools to engineer things that weren't possible in the pre-AI era. Knowing how to code remains a fundamental expectation. Without that knowledge, you can build systems using AI — and that's vibe coding. It has its place, but it's not engineering.
The AI-native engineer operates as an orchestrator — someone who can turbocharge 10x engineering into 100x output through proper orchestration of AI agents. And that bar continues to rise weekly.
## The Four Core Practices
1. Synchronized Context Engineering
Emerging as a distinct discipline, this is the single most important skill for AI-native engineers. Context engineering means the systematic curation and injection of project-specific information into AI working memory: architectural diagrams, coding standards, business rules, team conventions, and development workflows that are reusable and standardized across your team members.
This shifts basic "prompt engineering" to sophisticated "context engineering" reflecting a deeper understanding: the quality of AI output is bounded by the quality of context it receives. Teams practicing rigorous context engineering report 40–50% speed increases and dramatically reduced alignment overhead.
As context engineering matures, Anthropic's MCP — described as "USB-C for AI" — continues to be a universal standard for connecting agents to external tools and data sources. Context files like CLAUDE.md have become core infrastructure, not optional documentation. This persistent, evolving knowledge layer makes agents genuinely useful within your specific codebase, once you master developing and maintaining this critical context.
2. Specification-Driven Development
The quality of AI-generated code matches the quality of input specifications. Garbage in, garbage out — this principle applies with even more force when AI can generate garbage at unprecedented speed and volume.
Random prompting and vibe coding consistently underperform spec-driven workflows. AI agents get stuck in circular reasoning without clear specifications and instructions that are contained and well-defined. Consider this discipline: define what you want before asking AI to build it, break problems into discrete milestones with clear success criteria, and execute incrementally with validation at each checkpoint. Make sure the agent checks all open Qs with you and doesn’t run off on its own to find answers.
3. Critical Verification
AI-generated code quality approximates that of early-career developers. Research consistently shows that around 45% of AI-generated code contains security flaws. A Stanford study found that developers using AI assistants wrote significantly less secure code and were more confident it was secure — a dangerous combination.
Meanwhile, a striking METR/Anthropic randomized controlled trial found experienced open-source developers were actually 19% slower when using AI assistants on familiar codebases. The culprit? Over-reliance without adequate verification. A GitClear study found AI-assisted codebases showed increased "code churn" — code written and then quickly revised or deleted — suggesting raw output is a poor proxy for productivity.
In the AI-native era, the bottleneck has permanently shifted from writing code to proving that it works at scale, with reliability and security. When AI generates code quickly, review, testing, and verification of that code become the new rate-limiting factors, and verification now becomes non-negotiable.
4. Problem Decomposition
Avoid over-trusting AI with large, complex problems. Break tasks into AI-manageable chunks where humans handle edge cases, custom logic, and domain-specific aspects while AI agents handle the 70–80% of routine implementation. Complex problems lead to context pollution and slop generation that AI agents really struggle to recover from. Compacting and summarizing when context is polluted and shifting to a different session helps, but this discontinuity can be damaging for long-horizon tasks.. Many of us wasted hours, if not days, due to not decomposing and stubbornly confusing agents about expectations outside of a well-defined context, reasonable specifications, and a lack of verification guardrails.
## Time Allocation for AI-Native Work
I recommend the optimal split of: 40% context-setting, 20% generation and testing iteration, 40% reviewing and verification. This surprises many developers who spend most of their time in code generation. In practice, the generation step is fast; the verification and context work become the new time sink.
# The Individual Transformation Journey
## Phase 1: Foundation — should only take a couple of weeks
Begin with one primary AI assistant — pick your favorite one: Codex, Claude Code, or Cursor. Dive deep and build intuition for its capabilities and limitations through daily practice. Set up your workspace, workflow, and initial configurations. You’ll have to take the leap from the times of manual coding to AI-assisted and AI-generated coding practices. Your goal should be to develop judgment about when AI delivers value versus when it creates more work than it saves. Write down your personal notes, iterate, and build a strong foundation.
## Phase 2: Integration — should take a month max
Adopt structured prompting frameworks. Create project-specific context files encoding team standards and architectural patterns. Implement the "Plan first, then Execute and finally review" workflow: planning mode generates specifications, execution mode implements, and make sure you review after each atomic task. Establish approval gates and guardrails that prevent agent drift. Skipping the review will pile tech debt that you and your agent will both struggle downstream.
The critical practice here is small loops with verification checkpoints. Evidence shows tight human-in-the-loop cycles with limited scope dramatically outperform large autonomous runs, at least for coding tasks. This may feel counterintuitive and slower — but it produces dramatically better outcomes in practice. Indulging into somewhat unplanned and speculative autonomous agent runs will likely produce a large volume of slop whose only destiny may be throwaway and start all over again. Avoid that before it happens.
## Phase 3: Mastery — live on
Deploy AI agents for multi-step, multi-file tasks. Implement AI-assisted code review workflows. Use advanced techniques: multi-agent workflows, parallel sessions, and cross-agent verification loops. Every week, we hear about coding agents advancing on benchmarks and solving problems that were never solved before. Stay on top of those developments and embrace what Claude or Codex inventors are advocating, but adopt those to your needs (don’t blindly follow as their situations may be wildly different than yours).
Target metrics: 80%+ AI-generated coding rate with less than 20% rewrite rate. Achieve this, and you can pull your team toward the same proficiency level rather fast.
# Team Transformation: The Cultural Foundation
Research shows 70% of transformation success comes from operational and cultural change. These changes call for Organizational and technical leads to actively model transformation through daily AI usage. At the same time, ensure three critical aspects to establish the AI-native cultural foundation:
1. Psychological safety is paramount. MIT research found 83% of leaders believe psychological safety measurably improves AI initiative success. Celebrate "AI failure stories" as learning opportunities. Make this deliberate practice, not optional and ensure everyone feels included as part of the collective learning and growing exercise.
2. Evolved code review is essential. AI-generated code volume overwhelms traditional human review processes. Redesign review to distinguish AI-generated versus human code with separate review rubrics. Be especially vigilant about the dangerous combination of AI-generated and AI-reviewed PRs — these combinations should be explicitly guardrailed and governed, when necessary.
3. Shared context libraries become the core currency. Standardize context files, evaluation sets, and agent configurations across teams. Modern tooling enables easy packaging of context through plugins, skills, and commands — but watch for uncontrolled proliferation, where teams compete for standardization rather than collaborating. Don’t let too many team members’ desire to build agents and skills jeopardize your standardized agentic operating environment.
# The Agentic Development Life Cycle (ADLC)
Traditional SDLC — and even extreme agile — falls short for how AI agents develop software alongside humans. AI-native engineering evolution toward an Agentic Development Life Cycle redefines each phase.
## Planning
The most critical step. Use deep research and planning modes with multiple agents for parallel exploration. Specify against codebases, flag ambiguities, decompose into subtasks, and estimate difficulty. Create roadmaps with version milestones that help agents follow through incrementally. A planning agent can assemble findings from multiple exploration agents into a coherent implementation strategy. OpenClaw of Claude can run in multiple sub-agent in parallel.
## Building
AI agents handle end-to-end feature implementation like junior or mid-level engineers (at the time of this writing, which I expect to edge up to senior engineers within a year or two). The engineer acts as the tech lead, orchestrating multiple agents rather than coding directly. Sequential or parallel execution models depend on your roadmap and verification plan. The agentic coding tool landscape has matured rapidly — Claude Code, Cursor's Composer mode, GitHub Copilot's Agent Mode, and OpenAI's Codex agent all support this pattern with varying strengths. There’s new versions coming out every month -- watch closely for new capabilities.
## Testing
This is TDD reincarnated. Agents write test plans first, then implement code. All tests should fail at the beginning and then incrementally pass. Unit testing at the atomic level, integration testing across features, and end-to-end testing across the system. Don’t overindex on unit testing at the expense of integration or system testing lack.
Pro Tip: Consider separating planning, building, and testing agents. Each agent swarm specializes and develops a deep understanding of your codebase from a different perspective. Planning agents can challenge building agents who take shortcuts; testing agents who skip coverage; or the review agents who are biased towards incorrect implementations that appear to be correct. Similarly, review agents can hold every other upstream agent accountable for making mistakes or missing steps.
## Review
Deploy agent swarms specializing in key dimensions: functionality, quality, scalability, performance, reliability, security, and privacy. Agents take the first pass and produce reports; humans review each report carefully. When one agent discovers an issue — say, an injection vulnerability — apply the generalization principle: if one instance exists, others likely do too and this is your chance to proactively similar a vulnerability type in your code, not just one or two instances.
## Documentation
Move from post-facto documentation to continuous generation. AI agents generate summaries, key design decisions, architectural diagrams, and changelogs in real time. This flows naturally into API documentation, feature collaterals, and customer-facing contents. I’m quite excited about AI tools finally solving the outdated, stale, and inconsistent documentation problem that I’ve seen myself and my teams suffer for decades.
## Codify ADLC
Encode your Layer-1 (individual) and Layer-2 (team) practices into maintained, self-evolving context files, skills libraries, and MCP tools. This ensures ADLC adoption scales across the organization rather than remaining tribal knowledge or trapped in parts of the org. Promote the ADLC tooling package.
# What AI-Native Process Actually Looks Like
There's a seductive narrative in the industry right now: fewer people, less overhead, faster builds. But this narrative conflates construction costs with decision costs. AI has drastically reduced the cost of building, but that represents only 20–30% of total development costs, while leaving the cost of deciding what to build and what to cut largely untouched. With the proliferation of code and builders, this becomes a harder problem.
AI-native process optimization requires redirecting effort from coordinating execution to accelerating learning.
## The Learning Loop
AI compresses the first step dramatically. But compression value depends entirely on execution quality throughout the remaining cycle. Faster building without robust user observation and scope discipline produces faster divergence from genuine product goals. This results in customers not seeing the benefits of AI acceleration.
## Where AI Creates Genuine Leverage
Cheaper experimentation. Test more hypotheses per unit time. Over 70% of features never reach real users. AI makes it trivially cheap to test whether something matters before committing to full development. The discipline: kill non-viable concepts ruthlessly.
Faster prototyping for user research. Working prototypes replace documentation. Tools like Vercel's v0, Replit Agent, and Bolt.new enable functional prototypes from natural language in minutes. This produces superior signal quality from user testing. Encourage everyone to prototype aggressively, make it a habit before you build.
Automated boilerplate, not automated judgment. AI handles undifferentiated work: scaffolding, non-novel code, business logic tests, documentation, and data models. Teams focus on differentiated work: core business logic, empathetic user experiences, novel implementations, and the crucial decision of what to keep or kill.
The "design to 50%" principle. Ship minimal functionality enabling core user journeys. Observe where users hesitate, misunderstand, or abandon. This reveals actual product challenges rather than imagined ones. AI makes this approach nearly zero cost.
# Guardrails — Not Optional
The security landscape for AI-generated code has become genuinely alarming. The data shows AI-native development speed is creating new attack surfaces faster than manual security review or traditional tools can address. We observed roughly one new insecure AI integration appearing per week in our environment, many resulting in production incidents. Anthropic’s Daybreak and Mythos bring a clear wake-up call to security.
## Real Incidents, Real Consequences
Chat Integration RCE. Built in two days using AI, achieved Remote Code Execution by bypassing 2FA and exploiting open ACLs. It costs tens of hours to detect, mitigate, and fix.
Unauthorized Database Access. An AI coding agent accessed approximately 1,500 secure, unauthorized database tables without proper authorization, exposing sensitive data to prompt injection risks.
Google Docs Prompt Injection. An AI coding agent achieved Remote Code Execution through prompt injection embedded in a Google Docs document, bypassing input filtering protections entirely.
Supply Chain Poisoning. A new attack vector called "slopsquatting" emerged in 2025 — AI models hallucinate package names that don't exist, and attackers register those names with malicious code. Multiple documented incidents have resulted from this.
## Emerging Security Controls
Agent Identity and Access Control. Implement step-up 2FA. Apply the principle of least privilege. No shared credentials or open ACLs. Start with passive, read-only use cases and build confidence before granting read-write or broader access.
Data Classification Awareness. Agents must respect data classifications and sensitive boundaries. "Agentic Authorization" is an emerging enterprise challenge where agents bypass restrictions at machine speed that human oversight cannot match.
Prompt Injection Protection. External content — documents, web pages, user inputs — can contain hidden instructions that hijack agent behavior. Implement input filtering, content validation, and context sanitization. Never auto-execute untrusted commands. Resist the temptation of auto-accepting all agent suggestions.
Infrastructure Sandboxing. Agent activities must be observable and auditable. Block high-risk production surfaces — configurations, critical execution, critical storage — until controls are verified. Use sandboxing and OS-level enforcement.
## Technical Guardrails
Static analysis integration. Data shows roughly 30% of Python and 25% of JavaScript AI-generated snippets contain security weaknesses. Centralize advanced static analysis in CI/CD pipelines. Require mandatory human review for critical functions: authentication, payments, and PII handling.
Automated quality gates. Implement "Ralph Loops", OpenClaw, or another form of autonomous loops — iterative verification until success criteria are met. Type checking, linting, and test execution before diff submission. Multi-stage canary systems with stringent gates before production deployment.
Skills-based security. Where the agents are taught secure coding patterns, flagging common vulnerabilities during generation rather than after. Shift left, but with agents.
## Organizational Guardrails
Skill atrophy prevention. Gartner reports 50% of organizations will require "AI-free" skills assessments by 2026. Treat AI as a learning tool — request explanations alongside generated code. Occasionally, work without AI to preserve foundational abilities. The goal isn't Luddism; it's insurance against the day your AI tools are unavailable or producing subtly wrong, but potentially fatal results.
The productivity paradox. Individual productivity gains from AI tools often fail to materialize at the team and company levels. Focus on end-to-end cycle time and feature velocity, not coding speed alone. Adding AI to broken processes yields broken processes that generate more code, faster.
# The Engineer of 2026 and Beyond
The engineers thriving in the new environment treat AI as a collaborative partner for execution while maintaining the systems thinking, critical judgment, and communication skills that no AI can replicate. AI amplifies existing expertise rather than replacing it — senior engineers achieve dramatically better results because they bring deeper context and sharper judgment.
Your domain expertise is the key differentiator in AI-native productivity. No AI tool or agent can replace it. So, invest in sharpening your domain skills, whether that’s math, science, finance, health science, or a legal profession. Continuing to uplevel your engineering fundamentals pay recurring dividends in AI effectiveness.
This is a multi-year transformation, not a one-off tool adoption. Teams treating it as a tooling upgrade consistently fail to realize productivity gains. The organizations that succeed are the ones treating AI-native engineering as a new way of working — with new practices, new disciplines, and new definitions of what "amazing" looks like.
Are you building this way yet? If not, ping me, and I’m happy to have a chat.
This is Part 1 of a two-part series. Part 2, "AI-Native Leaders," covers the organizational transformation, leadership models, and measurement frameworks required to make AI-native engineering work at scale.
## 相关链接
- [Bytebytego](https://x.com/bytebytego)
- [@bytebytego](https://x.com/bytebytego)
- [19K](https://x.com/bytebytego/status/2061821715450351992/analytics)
- [Shah Rahman](https://www.linkedin.com/in/shahirahman/)
- [code overload](https://www.nytimes.com/2026/04/06/technology/ai-code-overload.html)
- [Bolt.new](https://bolt.new/)
- [have a chat](https://www.linkedin.com/in/shahirahman/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:46 PM · Jun 2, 2026](https://x.com/bytebytego/status/2061821715450351992)
- [19.3K Views](https://x.com/bytebytego/status/2061821715450351992/analytics)
- [View quotes](https://x.com/bytebytego/status/2061821715450351992/quotes)
---
*导出时间: 2026/6/3 09:27:02*
---
## 中文翻译
# 成为 AI 原生工程师的实用指南
**作者**: Bytebytego
**日期**: 2026-06-02T14:46:18.000Z
**来源**: [https://x.com/bytebytego/status/2061821715450351992](https://x.com/bytebytego/status/2061821715450351992)
---
如果“让 AI 写所有代码”就是答案，那为什么大多数工程团队如今交付的 bug、事故和技术债比两年前更多？
这就是本周客座文章的开篇之问，而它最终变成了我们见过的最实用的指南之一，献给那些希望在 AI 时代真正提升自己的工程师。
《成为 AI 原生工程师的实用指南》，作者 Shah Rahman，Meta 广告部门自主机器学习迭代与优化全球负责人。
谷歌超过 75% 的新代码由 AI 生成。OpenAI 和 Anthropic 声称，他们产出的几乎每一行新代码都来自 AI。亚马逊最近在短短几个月内将 30,000 个生产应用从 Java 8 迁移到了 Java 17——如果没有 AI，这个项目估计需要 4,500 开发人年。而马克·扎克伯格预计，到 2026 年底，AI 智能体将能够作为中级工程师开展工作。
读到这些言论，我们可能感觉自己正目睹一个时代在合上的书页上写下最后几行字。甚至可能是一个职业的最后一页。
但问题来了：如果“让 AI 写所有代码”就是答案，那为什么大多数工程团队如今交付的 bug、事故和技术债比两年前更多？
在《纽约时报》四月的一篇文章中，Mike Isaac 和 Erin Griffith 给这种现象起了个名字，用来描述整个行业正在发生的事情。他们称之为“代码过载”。
按照 Isaac 和 Griffith 的说法，代码过载的本质是“技术工作者以极快的速度产出大量代码，以至于已经多到无法处理”。那些围绕 AI 智能体重建工作方式的团队，正深陷于代码 churn（反复变动）和安全漏洞的泥潭。
但是。许多使用 AI 智能体的工程师正在脱颖而出，取得了真正的生产力提升。他们用的是同样的模型、同样的工具，产出的结果却截然不同。这种差距如何解释？
归结起来就是一个决定。当工程师决定从“编写代码”跃迁到“编排代码”时，真正的生产力提升才会到来。本文就是为那些想站在这次分化中“高效一侧”的工程师准备的工作指南。它将涵盖那些将 AI 原生工程与氛围编码（vibe coding）、以及大多数团队目前大规模产生的日常混乱区分开来的实践、护栏和思维转变。
# 从工程师到编排者
首先让我澄清一件事：工程师并不会被淘汰。编码一直以来只是工程工作的一小部分（最多 20-30%）。当 AI 智能体和工具产出更多代码时，这个被低估的现实变得更加明显——但更多代码并不一定意味着更高生产力（往往更低）。这是行业正在危险地模糊的一个关键区别，我把它表述为：
当 Andrej Karpathy 在 2025 年初创造“氛围编码”（vibe coding）一词时，它捕捉到了某种有用的东西——非工程师能够通过描述自己想要什么来构建可用的软件。这种民主化是有价值的。但它与专业的 AI 原生工程有着本质区别。
AI 原生工程意味着指挥和掌握现有及新兴的 AI 智能体与工具，去实现前 AI 时代不可能完成的工程。懂得如何编码仍然是一项基本要求。没有这些知识，你也可以用 AI 构建系统——但那就是氛围编码。它有它的位置，但那不是工程。
AI 原生工程师扮演的是编排者的角色——能够通过对 AI 智能体的妥善编排，将 10 倍工程能力放大为 100 倍产出的人。而这个门槛每周都在不断提高。
## 四大核心实践
1. 同步上下文工程
作为一门新兴的独立学科，这是 AI 原生工程师最重要的单项技能。上下文工程指的是将项目特定的信息系统地整理并注入 AI 的工作记忆：架构图、编码规范、业务规则、团队惯例，以及可在团队成员之间复用和标准化的开发工作流。
这将基础的“提示词工程”提升为复杂的“上下文工程”，体现了一个更深刻的认识：AI 输出的质量受限于其接收到的上下文的质量。践行严格上下文工程的团队报告称，速度提升了 40–50%，对齐开销也大幅降低。
随着上下文工程日趋成熟，Anthropic 的 MCP——被称为“AI 的 USB-C”——仍然是连接智能体与外部工具和数据源的通用标准。像 CLAUDE.md 这样的上下文文件已成为核心基础设施，而非可选的文档。一旦你掌握了开发和维护这一关键上下文，这个持久且不断演进的知识层就能让智能体在你的特定代码库中真正发挥作用。
2. 规格驱动开发
AI 生成代码的质量取决于输入规格的质量。垃圾进，垃圾出——当 AI 能以前所未有的速度和规模生成垃圾时，这条原则的威力更加凸显。
随机的提示词和凭感觉编码（vibe coding）一贯表现不如规范驱动的工作流。如果缺乏明确、封闭且定义良好的规范和指令，AI 智能体就会陷入循环推理。请遵循这样的纪律：在让 AI 构建之前先定义好你想要什么，将问题拆解为带有清晰成功标准的独立里程碑，并在每个检查点进行验证的增量式执行。确保智能体与你确认所有未决问题，而不是自作主张地去寻找答案。
3. 严格验证
AI 生成的代码质量大致相当于初级开发者。研究一致表明，约 45% 的 AI 生成代码包含安全缺陷。斯坦福大学的一项研究发现，使用 AI 助手的开发者编写的代码安全性明显更低，但却对其安全性更有信心——这是一个危险的组合。
与此同时，METR/Anthropic 的一项随机对照试验得出了一个惊人的发现：经验丰富的开源开发者在熟悉的代码库上使用 AI 助手时，实际上反而慢了 19%。罪魁祸首是什么？是缺乏充分验证的过度依赖。GitClear 的研究发现，AI 辅助的代码库出现了更多的“代码流失”（code churn）——即代码刚写完就很快被修改或删除——这表明原始产出是生产力的糟糕替代指标。
在 AI 原生时代，瓶颈已经永久地从编写代码转移到了证明代码能大规模可靠且安全地运行。当 AI 快速生成代码时，对该代码的审查、测试和验证就成为新的限速因素，验证现在变得不可或缺。
4. 问题拆解
避免在大型复杂问题上过度信任 AI。将任务拆解为 AI 可驾驭的块：由人类处理边界情况、自定义逻辑和领域特定的部分，而 AI 智能体处理那 70–80% 的常规实现。复杂问题会导致上下文污染和垃圾生成，AI 智能体很难从中恢复。在上下文被污染时进行压缩和总结并切换到新的会话会有所帮助，但这种不连续性对长周期任务可能是有害的。我们许多人都曾因为没有进行拆解，在缺乏明确定义的上下文、合理规范和验证护栏的情况下固执地让智能体对预期产生困惑，而浪费了数小时甚至数天的时间。
## AI 原生工作的时间分配
我推荐的最佳分配比例是：40% 用于设定上下文，20% 用于生成和测试迭代，40% 用于审查和验证。这让许多把大部分时间花在代码生成上的开发者感到意外。在实践中，生成步骤很快；验证和上下文工作才是新的时间消耗点。
# 个人转型之旅
## 阶段 1：打基础——只需几周时间
从选择一个主要的 AI 助手开始——挑你最喜欢的：Codex、Claude Code 或 Cursor。通过每日练习深入了解它，建立对其能力和局限性的直觉。搭建你的工作区、工作流和初始配置。你必须完成从手动编码到 AI 辅助和 AI 生成编码实践的跨越。你的目标应该是培养判断力：知道 AI 何时能创造价值，何时带来的工作量比节省的还多。写下你的个人笔记，不断迭代，打下坚实的基础。
## 阶段 2：整合——最多一个月
采用结构化的提示词框架。创建项目专属的上下文文件，将团队标准和架构模式编码进去。实施“先规划，再执行，最后审查”的工作流：规划模式生成规范，执行模式负责实现，并确保你在每个原子任务完成后进行审查。建立审批关卡和护栏，防止智能体偏离方向。跳过审查会堆积技术债，让你和你的智能体在下游都举步维艰。
这里的关键实践是带有验证检查点的小循环。证据表明，范围有限的紧凑人机协同循环远胜于大规模的自主运行，至少在编码任务上是如此。这可能感觉违反直觉且更慢——但在实践中会产生显著更好的结果。放任一些未经充分规划、带有猜测性的自主智能体运行，很可能会产生大量垃圾，其唯一的命运可能就是被丢弃然后从头再来。要在这种情况发生之前避免它。
## 阶段 3：精通——持续进行
将 AI 智能体部署用于多步骤、多文件的任务。实施 AI 辅助的代码审查工作流。使用高级技术：多智能体工作流、并行会话以及跨智能体验证循环。每周我们都能听到编码智能体在基准测试上取得进展、解决前所未有的问题。紧跟这些进展，拥抱 Claude 或 Codex 的创造者们所倡导的理念，但要将其适配到你的需求上（不要盲目跟随，因为他们的处境可能与你的截然不同）。
目标指标：80% 以上的 AI 生成代码率，且重写率低于 20%。做到这一点，你就能相当快地把你的团队提升到同样的熟练水平。
# 团队转型：文化基础
研究表明，70% 的转型成功来自运营和文化层面的变革。这些变革要求组织和技术负责人通过日常使用 AI 来积极示范转型。同时，要确保以下三个关键方面，以建立 AI 原生的文化基础：
1. 心理安全感至关重要。MIT 的研究发现，83% 的领导者认为心理安全感可显著提升 AI 项目的成功率。要将“AI 失败案例”作为学习机会加以庆祝。将这变为一种刻意的实践，而非可选项，并确保每个人都感到自己是集体学习与成长过程的一部分。
2. 演进后的代码审查必不可少。AI 生成代码的规模已超出传统的人工审查能力。需要重新设计审查流程，区分 AI 生成的代码与人工编写的代码，并采用不同的审查标准。要特别警惕“AI 生成代码 + AI 审查代码”这一危险组合——必要时，应对这类组合设置明确的护栏并加以治理。
3. 共享上下文库成为核心资产。在团队之间标准化上下文文件、评测集和智能体配置。现代工具可以通过插件、技能和命令轻松打包上下文——但要警惕无节制的泛滥，即各团队为争夺标准化主导权而竞争，而非协作。不要让过多团队成员构建智能体和技能的欲望危及你标准化的智能体运行环境。
# 智能体开发生命周期（ADLC）
传统的 SDLC——甚至极限敏捷——都难以适应 AI 智能体与人类协作开发软件的方式。AI 原生工程向智能体开发生命周期的演进重新定义了每个阶段。
## 规划
这是最关键的一步。使用深度研究和规划模式，配合多个智能体进行并行探索。针对代码库进行明确说明，标记歧义之处，分解为子任务，并估算难度。创建带有版本里程碑的路线图，帮助智能体逐步推进。一个规划智能体可以将多个探索智能体的发现整合为连贯的实施策略。Claude 的 OpenClaw 可以并行运行多个子智能体。
## 构建
AI 智能体能够端到端地完成功能实现，就像初级或中级工程师一样（就本文写作时而言，我预计在一两年内会逐步达到高级工程师的水平）。工程师扮演技术负责人的角色，协调多个智能体而非直接编码。串行或并行执行模式取决于你的路线图和验证计划。智能体编码工具生态已迅速成熟——Claude Code、Cursor 的 Composer 模式、GitHub Copilot 的 Agent 模式以及 OpenAI 的 Codex 智能体都以各自的优势支持这一模式。每月都有新版本发布——请密切关注新功能。
## 测试
这是 TDD（测试驱动开发）的转世重生。智能体先编写测试计划，再实现代码。所有测试在开始时都应失败，然后逐步通过。在原子层面进行单元测试，在功能层面进行集成测试，在系统层面进行端到端测试。不要过度偏重单元测试而牺牲集成测试或系统测试。
专业提示：考虑将规划、构建和测试智能体分开。每个智能体集群各司其职，并从不同视角深入理解你的代码库。规划智能体可以质疑走捷径的构建智能体；质疑跳过覆盖率的测试智能体；或质疑那些偏向于看似正确实则错误的实现的审查智能体。同样，审查智能体可以要求其他所有上游智能体为错误或遗漏的步骤负责。
## 审查
部署专注于关键维度的智能体集群：功能、质量、可扩展性、性能、可靠性、安全性和隐私。智能体先进行初步审查并生成报告；人类仔细审阅每份报告。当一个智能体发现问题时——比如注入漏洞——应运用泛化原则：如果一个实例存在，其他实例很可能也存在，这是你主动排查代码中同类漏洞类型的机会，而不仅仅是修复一两个实例。
## 文档
从事后编写文档转向持续生成文档。AI 智能体实时生成摘要、关键设计决策、架构图和变更日志。这些内容自然延伸到 API 文档、功能宣传材料和面向客户的内容。让我非常兴奋的是，AI 工具终于有望解决文档过时、陈旧和不一致的问题——我和我的团队已被这个问题困扰了几十年。
## 将 ADLC 固化为标准流程
将你的第一层（个人）和第二层（团队）实践编码为可维护、自演进的上下文文件、技能库和 MCP 工具。这确保 ADLC 的采用能在整个组织中规模化推广，而不是沦为部落知识或困在组织的某些角落。推广 ADLC 工具包。
# AI 原生流程的真实面貌
当下行业中有一种诱人的叙事：更少的人、更少的开销、更快的构建。但这种叙事将构建成本与决策成本混为一谈。AI 已大幅降低了构建的成本，但这仅占总开发成本的 20–30%，而决定构建什么以及舍弃什么的成本却基本未被触动。随着代码和构建者的激增，这成为一个更棘手的问题。
AI 原生流程优化需要将精力从协调执行转向加速学习。
## 学习闭环
AI 极大地压缩了第一步。但压缩的价值完全取决于整个剩余周期中的执行质量。没有可靠的用户观察和范围约束的快速构建，只会更快地偏离真正的产品目标。这会导致客户无法感受到 AI 加速带来的好处。
## AI 创造真正杠杆的领域
更便宜的实验。单位时间内测试更多假设。超过70%的功能从未触达真实用户。AI让“在投入完整开发之前测试某件事是否重要”变得极其廉价。纪律要求：无情地砍掉不可行的概念。
更快的用户研究原型。可运行的原型取代文档。Vercel 的 v0、Replit Agent 和 Bolt.new 等工具能在几分钟内从自然语言生成功能性原型。这能从用户测试中获得更高质量的信号。鼓励每个人积极制作原型，把它变成构建之前的一种习惯。
自动化样板代码，而非自动化判断。AI 处理无差异化的工作：脚手架、非创新性代码、业务逻辑测试、文档和数据模型。团队专注于差异化的工作：核心业务逻辑、有共情力的用户体验、创新实现，以及保留或砍掉什么这一关键决策。
“设计到50%”原则。发布能实现核心用户旅程的最小功能。观察用户在哪里犹豫、误解或放弃。这揭示的是真实的产品挑战，而非想象中的挑战。AI 使这种方式几乎零成本。
# 安全护栏——不是可选项
AI 生成代码的安全形势已经真正令人担忧。数据显示，AI 原生开发的速度所催生的新攻击面，比人工安全审查或传统工具所能应对的速度更快。我们在自己的环境中观察到大约每周出现一个新的不安全 AI 集成，其中许多导致了生产事故。Anthropic 的 Daybreak 和 Mythos 给安全问题敲响了明确的警钟。
## 真实事故，真实后果
聊天集成 RCE。用 AI 在两天内构建，通过绕过双重验证（2FA）并利用开放的 ACL 实现了远程代码执行。检测、缓解和修复花费了数十小时。
未授权数据库访问。一个 AI 编码代理在未经适当授权的情况下访问了约 1,500 张安全数据库表，使敏感数据面临提示注入风险。
Google 文档提示注入。一个 AI 编码代理通过嵌入在 Google 文档中的提示注入实现了远程代码执行，完全绕过了输入过滤保护。
供应链投毒。2025 年出现了一种名为 "slopsquatting"（垃圾包抢注）的新攻击向量——AI 模型会幻觉出不存在的软件包名称，而攻击者则用恶意代码注册这些名称。已有多起记录在案的事故由此产生。
## 新兴安全控制
代理身份与访问控制。实施分级双重验证（step-up 2FA）。应用最小权限原则。不共享凭据或开放 ACL。从被动的、只读的用例开始，建立信心后再授予读写或更广泛的访问权限。
数据分级意识。代理必须尊重数据分级和敏感边界。“代理式授权”是一个新兴的企业挑战——代理以机器速度绕过人类监督无法匹敌的限制。
提示注入防护。外部内容——文档、网页、用户输入——可能包含劫持代理行为的隐藏指令。实施输入过滤、内容验证和上下文净化。绝不自动执行不受信任的命令。抵制自动接受所有代理建议的诱惑。
基础设施沙箱。代理活动必须可观察、可审计。在控制措施得到验证之前，封锁高风险的生产面——配置、关键执行、关键存储。使用沙箱和操作系统级的强制执行。
## 技术护栏
静态分析集成。数据显示，约30%的 Python 和25%的 JavaScript AI 生成代码片段包含安全弱点。将高级静态分析集中到 CI/CD 流水线中。对关键功能强制要求人工审查：身份验证、支付和个人身份信息（PII）处理。
自动化质量门禁。实施 "Ralph Loops"、OpenClaw 或其他形式的自主循环——迭代验证直到达到成功标准。在提交 diff 之前进行类型检查、lint 和测试执行。采用带有严格门禁的多阶段金丝雀系统，再进行生产部署。
基于技能的安全。让代理学习安全编码模式，在生成过程中而非事后标记常见漏洞。向左移动，但用代理来实现。
## 组织护栏
技能萎缩预防。Gartner 报告称，到 2026 年，50% 的组织将要求“无 AI”技能评估。把 AI 当作学习工具——在生成代码的同时要求解释。偶尔在没有 AI 的情况下工作，以保持基础能力。目标不是做卢德分子；这是为了对冲某天你的 AI 工具不可用、或产生微妙错误但可能致命的结果的风险。
生产力悖论。AI 工具带来的个人生产力提升，往往无法在团队和公司层面兑现。关注端到端周期时间和功能交付速度，而不仅仅是编码速度。把 AI 加到坏掉的流程中，只会得到生成更多代码、速度更快的坏流程。
# 2026年及以后的工程师
在新环境中蓬勃发展的工程师把 AI 当作执行的协作伙伴，同时保持着 AI 无法复制的系统思维、批判性判断和沟通能力。AI 放大的是现有的专业能力，而非取代它——资深工程师之所以取得显著更好的成果，是因为他们带来了更深厚的上下文和更敏锐的判断。
你的领域专业知识是 AI 原生生产力的关键差异化因素。没有任何 AI 工具或代理能够取代它。因此，投资于磨练你的领域技能，无论是数学、科学、金融、健康科学还是法律职业。持续提升你的工程基础，将在 AI 有效性方面带来持续的回报。
这是一场多年的转型，而不是一次性的工具采用。把它当作工具升级来对待的团队，始终无法实现生产力的提升。成功的组织是把 AI 原生工程视为一种新的工作方式——包含新的实践、新的纪律，以及对“卓越”含义的全新定义。
你已经开始这样构建了吗？如果没有，联系我，我很乐意聊聊。
这是两部分系列文章的第一部分。第二部分“AI 原生领导者”将探讨让 AI 原生工程规模化落地所需的组织转型、领导力模型和衡量框架。
## 相关链接
- [Bytebytego](https://x.com/bytebytego)
- [@bytebytego](https://x.com/bytebytego)
- [19K](https://x.com/bytebytego/status/2061821715450351992/analytics)
- [Shah Rahman](https://www.linkedin.com/in/shahirahman/)
- [代码过载](https://www.nytimes.com/2026/04/06/technology/ai-code-overload.html)
- [Bolt.new](https://bolt.new/)
- [聊聊](https://www.linkedin.com/in/shahirahman/)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [2026年6月2日 晚上10:46](https://x.com/bytebytego/status/2061821715450351992)
- [1.93万次浏览](https://x.com/bytebytego/status/2061821715450351992/analytics)
- [查看引用](https://x.com/bytebytego/status/2061821715450351992/quotes)
---
*导出时间: 2026/6/3 09:27:02*
