The 70% problem: Hard truths about AI-assisted coding70% 的问题：人工智能辅助编码的硬道理

A field guide and why we need to rethink our expectations实地指南以及为什么我们需要重新思考我们的期望

After spending the last few years embedded in AI-assisted development, I've noticed a fascinating pattern. While engineers report being dramatically more productive with AI, the actual software we use daily doesn’t seem like it’s getting noticeably better. What's going on here?
过去几年，我一直从事人工智能辅助开发工作，我发现了一个有趣的现象。虽然工程师们表示使用人工智能后工作效率显著提高，但我们日常使用的实际软件似乎并没有明显改善。这是怎么回事呢？

I think I know why, and the answer reveals some fundamental truths about software development that we need to reckon with. Let me share what I've learned.
我想我知道原因何在，而答案揭示了一些我们需要认真思考的软件开发基本真理。让我与大家分享一下我的心得。

How developers are actually using AI
开发人员如何实际使用人工智能

I've observed two distinct patterns in how teams are leveraging AI for development. Let's call them the "bootstrappers" and the "iterators." Both are helping engineers (and even non-technical users) reduce the gap from idea to execution (or MVP).
在团队如何利用人工智能进行开发方面，我观察到两种截然不同的模式。让我们称它们为 "引导者 "和 "迭代者"。这两种模式都在帮助工程师（甚至非技术用户）缩短从想法到执行（或 MVP）之间的差距。

The Bootstrappers: Zero to MVP
Bootstrappers：从零到 MVP

Tools like Bolt, v0, and screenshot-to-code AI are revolutionizing how we bootstrap new projects. These teams typically:
Bolt、v0 和截图转代码人工智能等工具正在彻底改变我们引导新项目的方式。这些团队通常

• Start with a design or rough concept
  从设计或粗略概念开始

• Use AI to generate a complete initial codebase
  使用人工智能生成完整的初始代码库

• Get a working prototype in hours or days instead of weeks
  在数小时或数天内而不是数周内获得工作原型

• Focus on rapid validation and iteration
  注重快速验证和迭代

The results can be impressive. I recently watched a solo developer use Bolt to turn a Figma design into a working web app in next to no time. It wasn't production-ready, but it was good enough to get very initial user feedback.
结果可能令人印象深刻。最近，我看到一位个人开发者使用 Bolt 在很短的时间内将 Figma 设计转化为一个可运行的网络应用程序。虽然它还不能投入生产，但已经足够获得最初的用户反馈了。

The Iterators: daily development
迭代器：日常开发

The second camp uses tools like Cursor, Cline, Copilot, and WindSurf for their daily development workflow. This is less flashy but potentially more transformative. These developers are:
第二阵营在日常开发工作流程中使用 Cursor、Cline、Copilot 和 WindSurf 等工具。这些工具不那么华丽，但可能更具变革性。这些开发人员是

• Using AI for code completion and suggestions
  使用人工智能完成代码并提出建议

• Leveraging AI for complex refactoring tasks
  利用人工智能完成复杂的重构任务

• Generating tests and documentation
  生成测试和文档

• Using AI as a "pair programmer" for problem-solving
  将人工智能作为解决问题的 "配对程序员"

But here's the catch: while both approaches can dramatically accelerate development, they come with hidden costs that aren't immediately obvious.
但问题是：虽然这两种方法都能大大加快开发速度，但它们都有隐性成本，而这些成本并不是显而易见的。

The hidden cost of "AI Speed"
人工智能速度 "的隐性成本

When you watch a senior engineer work with AI tools like Cursor or Copilot, it looks like magic. They can scaffold entire features in minutes, complete with tests and documentation.
当你看到高级工程师使用 Cursor 或 Copilot 等人工智能工具工作时，感觉就像变魔术一样。他们可以在几分钟内搭建出整个功能，并提供完整的测试和文档。
But watch carefully, and you'll notice something crucial: They're not just accepting what the AI suggests. They're constantly:
但仔细观察，你会发现其中的关键之处：他们不只是接受人工智能的建议。他们不断地

• Refactoring the generated code into smaller, focused modules
  将生成的代码重构为更小、更集中的模块

• Adding edge case handling the AI missed
  增加处理人工智能遗漏的边缘情况

• Strengthening type definitions and interfaces
  加强类型定义和接口

• Questioning architectural decisions
  质疑建筑决策

• Adding comprehensive error handling
  添加全面的错误处理

In other words, they're applying years of hard-won engineering wisdom to shape and constrain the AI's output. The AI is accelerating their implementation, but their expertise is what keeps the code maintainable.
换句话说，他们正在运用多年积累的工程智慧来塑造和限制人工智能的输出。人工智能加快了他们的实施速度，但他们的专业知识却保证了代码的可维护性。

Junior engineers often miss these crucial steps. They accept the AI's output more readily, leading to what I call "house of cards code" – it looks complete but collapses under real-world pressure.
初级工程师往往会错过这些关键步骤。他们更容易接受人工智能的输出，导致我所说的 "纸牌屋代码"--看起来很完整，但在现实世界的压力下就会崩溃。

The knowledge paradox  知识悖论

Here's the most counterintuitive thing I've discovered: AI tools help experienced developers more than beginners. This seems backward – shouldn't AI democratize coding?
这是我发现的最违反直觉的事情：人工智能工具对经验丰富的开发人员的帮助要大于初学者。这似乎有些落后--人工智能不是应该让编码民主化吗？

The reality is that AI is like having a very eager junior developer on your team. They can write code quickly, but they need constant supervision and correction. The more you know, the better you can guide them.
现实情况是，人工智能就像你的团队里有一个非常热心的初级开发人员。他们可以快速编写代码，但需要不断监督和纠正。你了解得越多，就越能更好地指导他们。

This creates what I call the "knowledge paradox":
这就是我所说的 "知识悖论"：

• Seniors use AI to accelerate what they already know how to do
  老年人利用人工智能加速他们已经知道如何做的事情

• Juniors try to use AI to learn what to do
  青少年尝试使用人工智能学习该怎么做

• The results differ dramatically
  结果大相径庭

I've watched senior engineers use AI to:
我曾亲眼目睹高级工程师们使用人工智能：

• Rapidly prototype ideas they already understand
  快速制作他们已经了解的创意原型

• Generate basic implementations they can then refine
  生成基本实施方案，然后加以完善

• Explore alternative approaches to known problems
  探索解决已知问题的替代方法

• Automate routine coding tasks
  自动化日常编码任务

Meanwhile, juniors often:
同时，青少年经常

• Accept incorrect or outdated solutions
  接受不正确或过时的解决方案

• Miss critical security and performance considerations
  错过关键的安全和性能考虑因素

• Struggle to debug AI-generated code
  努力调试人工智能生成的代码

• Build fragile systems they don't fully understand
  建立他们并不完全了解的脆弱系统

The 70% problem: AI's learning curve paradox
70% 的问题：人工智能的学习曲线悖论

A tweet that recently caught my eye perfectly captures what I've been observing in the field: Non-engineers using AI for coding find themselves hitting a frustrating wall.
最近引起我注意的一条推文完美地捕捉到了我在这一领域的观察结果：使用人工智能进行编码的非工程师发现自己遇到了一堵令人沮丧的墙。
They can get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns.
他们可以出乎意料地迅速达到 70% 的目标，但最后的 30% 则会导致收益递减。

This "70% problem" reveals something crucial about the current state of AI-assisted development. The initial progress feels magical - you can describe what you want, and AI tools like v0 or Bolt will generate a working prototype that looks impressive. But then reality sets in.
这个 "70% 的问题 "揭示了人工智能辅助开发现状的关键所在。最初的进展给人一种神奇的感觉--你可以描述自己想要什么，v0 或 Bolt 等人工智能工具就会生成一个看起来令人印象深刻的工作原型。但随后现实就来了。

The two steps back pattern
后退两步模式

What typically happens next follows a predictable pattern:
接下来发生的事情通常遵循一种可预测的模式：

• You try to fix a small bug
  您尝试修复一个小错误

• The AI suggests a change that seems reasonable
  人工智能提出了一个看似合理的修改建议

• This fix breaks something else
  此修复还破坏了其他东西

• You ask AI to fix the new issue
  您要求人工智能解决新问题

• This creates two more problems
  这又产生了两个问题

• Rinse and repeat  冲洗和重复

This cycle is particularly painful for non-engineers because they lack the mental models to understand what's actually going wrong. When an experienced developer encounters a bug, they can reason about potential causes and solutions based on years of pattern recognition.
对于非工程人员来说，这种循环尤其痛苦，因为他们缺乏心智模型来理解究竟是什么出了问题。当经验丰富的开发人员遇到错误时，他们可以根据多年的模式识别推理出潜在的原因和解决方案。
Without this background, you're essentially playing whack-a-mole with code you don't fully understand.
如果没有这些背景知识，你基本上就是在和你不完全理解的代码玩打地鼠游戏。

The learning paradox continued
学习悖论仍在继续

There's a deeper issue here: The very thing that makes AI coding tools accessible to non-engineers - their ability to handle complexity on your behalf - can actually impede learning. When code just "appears" without you understanding the underlying principles:
这里还有一个更深层次的问题：让非工程师也能使用人工智能编码工具的根本原因--它们能代表你处理复杂性--实际上会阻碍学习。当代码只是 "出现"，而你却不了解其基本原理时：

• You don't develop debugging skills
  你没有掌握调试技能

• You miss learning fundamental patterns
  您错过了基本模式的学习

• You can't reason about architectural decisions
  你无法对建筑决策进行推理

• You struggle to maintain and evolve the code
  您需要努力维护和改进代码

This creates a dependency where you need to keep going back to AI to fix issues, rather than developing the expertise to handle them yourself.
这就产生了一种依赖性，你需要不断回到人工智能来解决问题，而不是自己开发专业知识来处理这些问题。

The knowledge gap  知识差距

The most successful non-engineers I've seen using AI coding tools take a hybrid approach:
我所见过的使用人工智能编码工具最成功的非工程师采用的是混合方法：

1. Use AI for rapid prototyping
   利用人工智能进行快速原型设计

2. Take time to understand how the generated code works
   花时间了解生成的代码如何工作

3. Learn basic programming concepts alongside AI usage
   在使用人工智能的同时学习基本编程概念

4. Build up a foundation of knowledge gradually
   逐步建立知识基础

5. Use AI as a learning tool, not just a code generator
   将人工智能作为学习工具，而不仅仅是代码生成器

But this requires patience and dedication - exactly the opposite of what many people hope to achieve by using AI tools in the first place.
但这需要耐心和奉献精神，而这恰恰与许多人最初使用人工智能工具的初衷背道而驰。

Implications for the future
对未来的影响

This "70% problem" suggests that current AI coding tools are best viewed as:
这个 "70% 的问题 "表明，目前的人工智能编码工具最好被视为：

• Prototyping accelerators for experienced developers
  为经验丰富的开发人员提供原型开发加速器

• Learning aids for those committed to understanding development
  为那些致力于了解发展的人提供学习工具

• MVP generators for validating ideas quickly
  用于快速验证创意的 MVP 生成器

But they're not yet the coding democratization solution many hoped for. The final 30% - the part that makes software production-ready, maintainable, and robust - still requires real engineering knowledge.
但它们还不是许多人所希望的编码民主化解决方案。最后的 30%，也就是使软件具备生产就绪、可维护性和健壮性的部分，仍然需要真正的工程知识。

The good news? This gap will likely narrow as tools improve. But for now, the most pragmatic approach is to use AI to accelerate learning, not replace it entirely.
好消息是什么？随着工具的改进，这种差距可能会缩小。但就目前而言，最务实的方法是利用人工智能加速学习，而不是完全取代学习。

What actually works: practical patterns
实际效果：实用模式

After observing dozens of teams, here's what I've seen work consistently:
在观察了数十个团队后，我发现以下方法始终行之有效：

1. The "AI first draft" pattern
1.人工智能初稿 "模式

• Let AI generate a basic implementation
  让人工智能生成一个基本实现

• Manually review and refactor for modularity
  手动审查和重构以实现模块化

• Add comprehensive error handling
  添加全面的错误处理

• Write thorough tests  编写全面的测试

• Document key decisions  记录关键决策

2. The "Constant conversation" pattern
2.持续对话 "模式

• Start new AI chats for each distinct task
  为每个不同的任务启动新的人工智能聊天

• Keep context focused and minimal
  保持上下文重点突出、简明扼要

• Review and commit changes frequently
  经常审查和提交更改

• Maintain tight feedback loops
  保持紧密的反馈回路

3. The "Trust but verify" pattern
3.信任但要核实 "模式

• Use AI for initial code generation
  使用人工智能生成初始代码

• Manual review of all critical paths
  手动审查所有关键路径

• Automated testing of edge cases
  边缘案例自动测试

• Regular security audits  定期安全审计

Looking forward: The real promise of AI?
展望未来：人工智能的真正前景？

Despite these challenges, I'm optimistic about AI's role in software development. The key is understanding what it's really good for:
尽管存在这些挑战，但我对人工智能在软件开发中的作用持乐观态度。关键是要了解它的真正用途：

1. Accelerating the known  加速已知
   AI excels at helping us implement patterns we already understand. It's like having an infinitely patient pair programmer who can type really fast.
   人工智能擅长帮助我们实现我们已经了解的模式。这就好比有一个耐心无限、打字速度极快的配对程序员。

2. Exploring the possible  探索可能
   AI is great for quickly prototyping ideas and exploring different approaches. It's like having a sandbox where we can rapidly test concepts.
   人工智能非常适合快速构建创意原型和探索不同的方法。这就像一个沙盒，我们可以在其中快速测试各种概念。

3. Automating the routine  日常工作自动化
   AI dramatically reduces the time spent on boilerplate and routine coding tasks, letting us focus on the interesting problems.
   人工智能大大减少了用于模板和常规编码任务的时间，让我们可以专注于有趣的问题。

What does this mean for you?
这对你意味着什么？

If you're just starting with AI-assisted development, here's my advice:
如果你刚刚开始人工智能辅助开发，我有以下建议：

1. Start small  从小事做起

   • Use AI for isolated, well-defined tasks
     将人工智能用于孤立、明确的任务

   • Review every line of generated code
     审查生成的每一行代码

   • Build up to larger features gradually
     逐步建立更大的功能

2. Stay modular  保持模块化

   • Break everything into small, focused files
     将所有内容分解成重点突出的小文件

   • Maintain clear interfaces between components
     组件之间保持清晰的接口

   • Document your module boundaries
     记录模块边界

3. Trust your experience  相信自己的经验

   • Use AI to accelerate, not replace, your judgment
     利用人工智能加速而非取代您的判断力

   • Question generated code that feels wrong
     生成的代码感觉不对的问题

   • Maintain your engineering standards
     保持工程标准

The rise of agentic software engineering
代理软件工程的兴起

The landscape of AI-assisted development is shifting dramatically as we head into 2025. While the current tools have already changed how we prototype and iterate, I believe we're on the cusp of an even more significant transformation: the rise of agentic software engineering.
进入 2025 年，人工智能辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们的原型设计和迭代方式，但我相信我们正处于一个更重大变革的风口浪尖：代理软件工程的崛起。

What do I mean by "agentic"? Instead of just responding to prompts, these systems can plan, execute, and iterate on solutions with increasing autonomy.
什么叫 "代理"？这些系统不只是对提示做出反应，还能规划、执行和迭代解决方案，自主性越来越强。

If you’re interested in learning more about agents, including my take on Cursor/Cline/v0/Bolt, you may be interested in my recent JSNation talk above.
如果您有兴趣了解有关代理的更多信息，包括我对 Cursor/Cline/v0/Bolt 的看法，您可能会对我最近在 JSNation 上发表的演讲感兴趣。

We're already seeing early signs of this evolution:
我们已经看到了这种演变的早期迹象：

From responders to collaborators
从响应者到合作者

Current tools mostly wait for our commands. But look at newer features like Anthropic's computer use in Claude, or Cline's ability to automatically launch browsers and run tests.
目前的工具大多等待我们的指令。但看看一些新功能，比如 Anthropic 在 Claude 中使用计算机，或者 Cline 自动启动浏览器和运行测试的能力。
These aren't just glorified autocomplete - they're actually understanding tasks and taking initiative to solve problems.
这不仅仅是美化了的自动完成功能，他们实际上是在理解任务，并主动解决问题。

Think about debugging: Instead of just suggesting fixes, these agents can:
想想调试：这些代理不仅能提出修复建议，还能

• Proactively identify potential issues
  主动发现潜在问题

• Launch and run test suites
  启动和运行测试套件

• Inspect UI elements and capture screenshots
  检查用户界面元素并截图

• Propose and implement fixes
  提出并实施修复

• Validate the solutions work (this could be a big deal)
  验证解决方案的有效性（这可能是一件大事）

The Multimodal future  多式联运的未来

The next generation of tools may do more than just work with code - they could seamlessly integrate:
下一代工具可能不仅仅是处理代码，它们还可以无缝集成：

• Visual understanding (UI screenshots, mockups, diagrams)
  可视化理解（用户界面截图、模型、图表）

• Verbal language conversations
  口头语言对话

• Environment interaction (browsers, terminals, APIs)
  环境交互（浏览器、终端、应用程序接口）

This multimodal capability means they can understand and work with software the way humans do - holistically, not just at the code level.
这种多模态能力意味着他们可以像人类一样理解和使用软件--从整体上，而不仅仅是代码层面。

Autonomous but guided  自主但有指导

The key insight I've gained from working with these tools is that the future isn't about AI replacing developers - it's about AI becoming an increasingly capable collaborator that can take initiative while still respecting human guidance and expertise.
我在使用这些工具的过程中获得的重要启示是，未来人工智能并不是要取代开发人员，而是要让人工智能成为一个能力越来越强的合作者，在尊重人类指导和专业知识的同时，也能发挥主动性。

The most effective teams in 2025 may be those that learn to:
2025 年，最有效的团队可能是那些学会 "学会 "的团队：

• Set clear boundaries and guidelines for their AI agents
  为人工智能代理设定明确的界限和准则

• Establish strong architectural patterns that agents can work within
  建立强大的架构模式，让代理可以在其中工作

• Create effective feedback loops between human and AI capabilities
  在人类和人工智能能力之间建立有效的反馈回路

• Maintain human oversight while leveraging AI autonomy
  在利用人工智能自主性的同时保持人工监督

The English-first development environment
英语优先的开发环境

As Andrej Karpathy noted:
正如 Andrej Karpathy 指出的那样：

"English is becoming the hottest new programming language."
"英语正在成为最热门的新编程语言"。

This is a fundamental shift in how we'll interact with development tools. The ability to think clearly and communicate precisely in natural language is becoming as important as traditional coding skills.
这是我们与开发工具交互方式的根本转变。用自然语言进行清晰思考和准确交流的能力正变得与传统编码技能同等重要。

This shift towards agentic development will require us to evolve our skills:
这种向代理式发展的转变要求我们不断提高自己的技能：

• Stronger system design and architectural thinking
  更强的系统设计和架构思维

• Better requirement specification and communication
  改进需求说明和沟通

• More focus on quality assurance and validation
  更加注重质量保证和验证

• Enhanced collaboration between human and AI capabilities
  加强人类与人工智能能力之间的协作

The return of software as craft?
软件作为工艺的回归？

While AI has made it easier than ever to build software quickly, we're at risk of losing something crucial - the art of creating truly polished, consumer-quality experiences.
虽然人工智能让快速构建软件变得前所未有的容易，但我们却有可能失去一些至关重要的东西，那就是创造真正精良的消费者品质体验的艺术。

The Demo-quality trap  演示质量陷阱

It's becoming a pattern: Teams use AI to rapidly build impressive demos. The happy path works beautifully. Investors and social networks are wowed. But when real users start clicking around? That's when things fall apart.
这已成为一种模式：团队利用人工智能快速构建令人印象深刻的演示。这条幸福之路运行良好。投资者和社交网络都为之惊叹。但当真正的用户开始点击时呢？这就是事情败露的时候。

I've seen this firsthand:
我亲眼目睹了这一切：

• Error messages that make no sense to normal users
  对普通用户毫无意义的错误信息

• Edge cases that crash the application
  使应用程序崩溃的边缘情况

• Confusing UI states that never got cleaned up
  从未清理过的混乱用户界面状态

• Accessibility completely overlooked
  完全忽略了无障碍环境

• Performance issues on slower devices
  较慢设备上的性能问题

These aren't just P2 bugs - they're the difference between software people tolerate and software people love.
这些不仅仅是 P2 错误，它们是人们能够容忍的软件与人们喜爱的软件之间的差别。

The lost art of polish
失传的抛光艺术

Creating truly self-serve software - the kind where users never need to contact support - requires a different mindset:
创建真正的自助服务软件--用户永远不需要联系技术支持的软件--需要一种不同的思维方式：

• Obsessing over error messages
  痴迷于错误信息

• Testing on slow connections
  在慢速连接上进行测试

• Handling every edge case gracefully
  从容应对各种边缘情况

• Making features discoverable
  使功能可被发现

• Testing with real, often non-technical users
  与真实用户（通常为非技术用户）进行测试

This kind of attention to detail (perhaps) can't be AI-generated. It comes from empathy, experience, and caring deeply about craft.
这种对细节的关注（也许）是人工智能无法生成的。它来自于同理心、经验和对工艺的深切关注。

The renaissance of personal software
个人软件的复兴

I believe we're going to see a renaissance of personal software development. As the market gets flooded with AI-generated MVPs, the products that will stand out are those built by developers who:
我相信，我们将看到个人软件开发的复兴。当市场上充斥着人工智能生成的 MVP 时，能够脱颖而出的产品将是那些由具备以下特质的开发人员开发的产品：

• Take pride in their craft
  为自己的手艺感到自豪

• Care about the little details
  关注小细节

• Focus on the full user experience
  注重全面的用户体验

• Build for the edge cases
  针对边缘情况进行构建

• Create truly self-serve experiences
  打造真正的自助服务体验

The irony? AI tools might actually enable this renaissance. By handling the routine coding tasks, they free up developers to focus on what matters most - creating software that truly serves and delights users.
讽刺的是什么？人工智能工具或许真的能促成这一复兴。通过处理日常的编码任务，它们能让开发人员腾出手来，专注于最重要的事情--创建真正服务于用户并让用户感到愉悦的软件。

The bottom line  底线

AI isn't making our software dramatically better because software quality was (perhaps) never primarily limited by coding speed.
人工智能并没有让我们的软件变得更好，因为软件质量（或许）从来都不是受编码速度的主要限制。
The hard parts of software development – understanding requirements, designing maintainable systems, handling edge cases, ensuring security and performance – still require human judgment.
软件开发的难点--理解需求、设计可维护的系统、处理边缘情况、确保安全和性能--仍然需要人的判断。

What AI does do is let us iterate and experiment faster, potentially leading to better solutions through more rapid exploration. But only if we maintain our engineering discipline and use AI as a tool, not a replacement for good software practices.
人工智能的作用是让我们更快地进行迭代和实验，通过更快速的探索，有可能找到更好的解决方案。但前提是我们必须保持工程纪律，并将人工智能作为一种工具，而不是替代良好的软件实践。
Remember: The goal isn't to write more code faster. It's to build better software. Used wisely, AI can help us do that. But it's still up to us to know what "better" means and how to achieve it.
请记住目标不是更快地编写更多代码。而是要构建更好的软件。明智地使用人工智能可以帮助我们做到这一点。但我们仍需了解 "更好 "的含义以及如何实现它。

What's your experience been with AI-assisted development? I'd love to hear your stories and insights in the comments.
您在人工智能辅助开发方面有什么经验？我很乐意在评论中听听您的故事和见解。