软件工程的未来是生成式的


5 个月前

像大多数科技行业的人,以及很多非科技行业的人一样,在过去的一年里,我越来越多地使用生成式人工智能(genAI),并开始相信它预示着软件工程以及我们设计、构建和修改解决方案与产品的方式将发生重大变化。

生成式人工智能不是一种潮流

我已经是一名专业工程师大约18年,其中大约10年是在全职创新团队中工作。我见证了许多潮流和趋势的兴起与消退,也见证了一些改变我们构建方式的技术的到来。区块链/Web3曾经是一个很大的干扰,但现在已经逐渐消退;云计算(主要是AWS和无服务器架构)彻底改变了工程领域;增强现实(AR)和虚拟现实(VR)则一直在炒作与失望之间起伏不定。

生成式人工智能,也就是大型语言模型(Large Language Models)或ChatGPT,并不是一种潮流——它是一项颠覆性的技术,已经并将继续以多种方式改变软件工程。

最简单的例子是,我几乎不再使用StackOverflow了——这个网站是用来解决编码问题的问答平台。我现在只用GPT——它几乎总是能给我一个不错的答案,我可以请求进一步的细化,而且它提供的细节和解释让我在做事情时更加安心。

不过——我觉得这就像是有人第一次给你一辆车,而你却用它来拉车。

生成式人工智能的能力远不止于帮助我们编码,我相信它最终将能够为我们完成大部分构建工作。

我最近在LinkedIn上看到一项MIT的研究——不同团队使用生成式人工智能或谷歌来解决一个问题。使用ChatGPT的团队完成得最快,但使用谷歌进行搜索和研究的团队对解决方案的理解更深刻。LinkedIn上的发帖者认为,努力工作以理解问题是很重要的,但我只是想——我们为什么需要理解它?

在ChatGPT出现之前,我就希望减少我的编码量。我热爱编码——这是我主要的个人爱好——但我讨厌写那些我认为可以自动化的代码。云工程已经开始引导我们走上这条道路——今天我可以使用CDK和AWS在S3和Cloudfront上快速搭建一个完全安全的生产React网站,老实说,我不需要理解它是如何工作的。我大致可以向你解释,但如果需要详细解释网络层等的深层细节,我会感到困难。但我为什么要理解这一切呢?我记得12年前为项目订购物理服务器,讨论我们需要什么负载均衡器,以及何时能在数据中心安装它们。现在看来真是疯狂!

同样,今天我们仍然在为构建普通解决方案而反复编写复杂的代码,我认为这也是疯狂的。

在2023年5月,我写了这篇文章,讲述了我如何使用Lambda@Edge和DynamoDB为我的网站启用动态社交媒体元标签。这真的是我作为工程师最自豪的时刻之一——我遇到了一个非常棘手的问题,最初完全不知道如何解决,然后我进行了大量的谷歌搜索和StackOverflow查询,搞明白了,最后成功了!然而——我本不应该这样做,我应该专注于我网站的内容,而不是如何在一个页面的React网站中让元标签工作。

软件工程的未来

大多数企业软件项目团队的结构如下:

  • 产品负责人负责引导解决方案,确定其功能等。
  • 设计师负责理解问题,设计界面和用户体验等。
  • 工程师负责构建UI、API、数据库、安全性、测试等。
  • 如果需要,可能还有一些数据科学家。

我相信,工程师目前所做的很多工作都可以通过生成式人工智能和其他方法实现自动化,设计师的部分工作也可以如此。我们仍然需要与真实的人接触,理解他们的需求,构思新产品和解决方案——但当真正需要构建某样东西时,启动一个IDE并开始编码似乎是一种浪费的努力,因为我们可能可以使用生成式人工智能来为我们完成这项工作。

想象一下,如果我们可以简单地说:“我想要一个托管在AWS上的React应用,符合我公司的安全标准,连接到一个使用API的数据库。这个应用有4个屏幕——一个用户可以登录的主页,从数据库中检索和查看数据……并确保所有内容符合公司的品牌指南。”然后它就会自动为我们构建出来。接着我们查看它,提出一些要求,比如“好吧,在主页上我现在想要一个图片轮播,然后我想要从数据库中显示的PDF文件以滚动的方式展示……”然后它就自动完成了。如果几周后我们的用户想要一个新功能,他们只需提出请求——它就会自动重新构建、测试并部署。

我相信这种自动化解决方案的构建是可能的——使用传统技术和生成式人工智能;而且只需时间问题,就会有人构建出这样的工具。

构建的民主化

这种生成式的构建整个解决方案的方式可能会彻底改变人们将产品推向市场的方式。我曾在都柏林的一所大学教授应用开发课程,面向商业和市场营销的学生——其目的是帮助那些有伟大商业想法但没有技术技能的人。学生们有很多惊人的想法——从分享时尚的新方式到寻找最佳咖啡的地方——但很少有学生具备足够的知识将这些想法变为现实,而不需要寻找技术合伙人或支付费用。

想象一下,他们可以直接“请求”一个大型语言模型来实现——将他们的想法转化为具体的可行解决方案,让他们专注于重要的事情——市场营销、理解客户、创造收入等。再也不必受制于技术,因为他们的实际客户并不关心技术,只关心产品本身。

这是否意味着工程师失业?

不——恰恰相反!我所谈论的是我们今天所做的事情——比如连接API,弄清楚如何为屏幕组件设置CSS,想出如何在用户第一次访问屏幕时添加教程覆盖——很多这些都可以被自动化。让我们专注于构建解决方案中更有趣的部分——我们是否在构建正确的东西,我们能多快迭代和调整,我们的用户喜欢和不喜欢产品的哪些方面?

一个能够构建完整解决方案的生成式人工智能工具并不是威胁——而是一个美好的机会,可以加速你的开发过程,成为一个智能助手,帮助你更快地完成更多工作。

工程师不仅仅是编码者——我多年来一直相信,早在最近的生成式人工智能爆发之前,工程师远不止是那些将代码提交到GitHub的人。一个优秀的工程师在与用户进行创意工作坊时和登录AWS检查Cloudwatch日志时同样游刃有余;工程师的工作是以最具创造性和高效的方式解决问题和创造解决方案。而且,什么比让另一个更复杂的解决方案(生成式人工智能)来承担编码的重任更高效呢?

我上面提到的团队结构:

  • 产品负责人负责引导解决方案,确定其功能等。
  • 设计师负责理解问题,设计界面和用户体验等。
  • 工程师负责构建UI、API、数据库、安全性、测试等。
  • 如果需要,可能还有一些数据科学家。

可以变得更像:

工程师是产品、设计和编码的专家。

  • 如果需要,可能还有一些数据科学家!

别忘了——谁在构建这些惊人的生成式人工智能工具?

别忘了,我们需要工程师来构建这些惊人的生成式人工智能工具!

当然,一旦我们拥有能够实现我所描述的功能的工具,我们可以利用它们自动构建出更好的工具,能够做更多的事情……

感谢你的阅读——我很想知道你的想法或评论,可以在下面留言,或者在 LinkedInTwitter 上联系我!安迪

FluxAI 中文

© 2025. All Rights Reserved