【新智元导读】
2024年的AI编程到底什么实力?近日,谷歌的工程主管Addy Osmani,为我们揭示了AI辅助编码在一线开发中的真实情况。
2024年,AI编程已然渗透了各行各业,影响着软件的整个生命周期。
那么问题来了,AI coding用过都说好,但我们平时用的软件咋感觉没啥进步呢?
近日,Addy Osmani,谷歌的工程主管,同时也是一位亚马逊畅销书作家,为我们揭示了AI辅助编码在一线开发中的真实情况。
一般来说,团队利用AI进行开发有两种不同的模式:「引导程序(bootstrappers)」 和 「迭代器(iterators)」。两者都在帮助工程师(甚至是非技术用户)缩小从想法到执行的差距。
Bootstrappers
这一类包括Bolt, v0, 和screenshot-to-code等AI工具,其特点为:
从设计或粗略概念开始;
使用AI生成完整的初始代码库;
能够在几小时或几天内获得工作原型;
专注于快速验证和迭代
这样的工作流令人印象深刻。比如一位独立开发人员可以使用Bolt,在短时间内将Figma设计转变为有效的Web应用程序。尽管达不到生产级别的要求,但用来获得初步的用户反馈绰绰有余。
Iterators
这一类主要负责日常开发工作流程,包括Cursor、Cline、Copilot和WindSurf等工具,效果没有上面那么浮夸,但更加实在,比如:
完成代码、提供建议;
执行复杂的重构任务;
生成测试和文档;
作为解决问题的「结对程序员」
虽然这两种方法都可以大大加快开发速度,但「天下没有免费的午餐」。
「AI速度」的隐性成本
高级工程师使用Cursor或Copilot等AI工具,可以在几分钟内搭建整个功能的基架,并完成测试和文档,就像变魔术一样。
但仔细观察就会发现,在参考AI建议的同时,资深工程师们还会:
将生成的代码重构为更小的模块;
添加边缘情况处理;
优化类型定义和接口;
添加全面的错误处理;
甚至是质疑AI给出的架构
换句话说,他们正在用多年积累的工程智慧,塑造和限制AI的输出。AI负责加速代码实现,但人类的专业知识确保代码的可维护性。
而初级工程师就经常错过这些关键步骤。他们更容易接受AI的输出,从而导致所谓的「纸牌屋代码(house of cards code)」——看起来很完整,但在现实世界的压力下会崩溃。
知识悖论
所以实际上,相比于初学者,AI反而更能帮助有经验的开发人员,——这多少有点反直觉。
高级工程师利用AI快速构建想法的原型(理解)、生成基本实现(可改进)、探索已知问题的替代方法等等;
而初学者却经常接受不正确或过时的解决方案、忽略关键的安全性和性能问题、不知道如何调试AI生成的代码,最终构建了一个自己不完全理解的脆弱系统。
使用AI进行编码的非工程师,经常遇到一个窘境:
他们可以出人意料地迅速完成70%的工作,但最后的30%就相当痛苦了。
「70% problem」揭示了AI辅助开发的现状,刚开始如有神助,后来被现实按在地上摩擦。
实际情况通常是:
尝试修复一个小错误——>
AI提出了一个似乎合理的更改——>
这个更改破坏了其他一些东西——>
要求AI修复新问题——>
又产生了两个新bug——>
无限循环
这个循环对于非工程师来说尤其痛苦,因为他们缺乏专业知识来理解真正出了什么问题。
有经验的开发人员遇到bug时,可以根据多年的模式识别来推理潜在原因和解决方案。如果没有这个背景,那基本上就是在用自己不完全理解的代码「打地鼠」。
学习悖论
还有一个更深层次的问题:让非工程师使用AI编码工具,实际上可能会阻碍学习。
代码生成了、运行了,但「开发者」不了解基本原理,此时,他错过了学习基本模式、没有培养调试技能、无法对架构决策进行推理,而这份代码又需要维护和扩展。
于是,「开发者」不断返回AI来解决问题,而没有培养自己处理问题的专业能力。
非工程师使用AI编码工具的最好方式可能是「混合模式」:
1. 使用AI进行快速原型设计
2. 花点时间了解生成的代码是如何工作的
3. 学习基本的编程概念以及AI使用
4. 逐步建立知识基础
5. 将AI用作学习工具,而不仅仅是代码生成器
但这需要耐心和奉献精神,与许多人使用AI工具的目标恰恰相反。
「70% problem」表明,当前的AI还不是许多人希望的那个AI。最后30%的工作(使软件可用于生产、可维护等),仍然需要真正的工程知识。
最佳实践
Addy Osmani观察了几十个团队,总结了一些最佳实践方式:
让 AI 生成基本实现;手动审查和模块化重构;添加全面的错误处理;编写全面的测试;记录关键决策。
「持续对话」模式
为每个不同的任务开始新的AI聊天;保持上下文集中和最小;经常查看和提交更改;保持紧密的反馈循环。
「信任但验证」模式
使用AI生成初始代码;手动审查所有关键路径;边缘案例的自动测试;定期安全审计。