软件工程的未来是生成的

和大多数工程师一样，包括许多非技术领域的人，我在过去的一年中越来越多地使用genAI，并开始相信它预示着软件工程和设计、构建、改变解决方案和产品的重大变革。

GenAI不是一种时尚。

我已经是一名专业工程师约18年了，其中大约有10年是在全职创新团队工作。我见过时尚和趋势来来去去，也见过改变我们建造事物方式的技术的出现。区块链/ Web3 一度是一个大的分心，但已经渐渐消失，云计算（主要是AWS，无服务器）彻底改变了工程行业，AR 和VR 一直是充满炒作和幻灭的过山车。

生成式人工智能即大型语言模型，又称ChatGPT，并非一时的风尚 - 它是一项改变游戏规则的技术，已经并将继续在许多不同方面改变软件工程。

最简单的例子是我几乎不再使用StackOverflow了-这是一个编程问题的问答网站。我现在只使用GPT-它几乎总是给我一个不错的答案，我可以要求改进，它提供的详细信息和解释让我在做什么方面感到更加舒服。

然而 - 我认为这就像有人第一次给你一辆汽车，然后你用它来拉马车。

生成型人工智能不仅可以帮助我们编码，我相信它最终将能够为我们大部分建设。

最近我在LinkedIn上看到一篇帖子提到了一项麻省理工学院的研究 - 不同团队使用genAI或谷歌来解决问题。使用ChatGPT的团队做得最快，但使用谷歌进行搜索和研究的团队更好地理解了解决方案。LinkedIn上的发布者观点是重要的是要付出努力，这样你才能理解它，但我却在想 - 为什么我们需要理解它呢？

远在ChatGPT到来之前，我就想要减少编程的量。我热爱编程 - 这是我的主要个人爱好 - 但我讨厌编写我认为可以自动化的代码。云工程已经让我们开始了这个旅程 - 今天我可以使用CDK和AWS在S3＆Cloudfront上快速搭建一个完全安全的生产React网站，而且老实说我不需要了解这一切是如何工作的。我大部分情况下可以把它解释给你听，但如果需要我解释网络层等的深入细节，我会困难重重。但我为什么要全都懂呢？我记得12年前为项目订购物理服务器时，讨论我们需要哪些负载均衡器，以及何时能在数据中心安装它们。现在这看起来像是疯狂的事情！

同样，今天我们仍在反复撰写复杂的代码来构建常规解决方案，我认为这也是疯狂的。

在2023年5月，我写了这篇关于如何使用Lambda@Edge和DynamoDB在我的网站上启用动态社交媒体元标签的帖子。这实在是我作为工程师最骄傲的时刻之一——我遇到了一个真正棘手的问题，一开始我根本不知道如何解决，然后我进行了大量的谷歌搜索和堆栈溢出，找到了解决方法，最后成功实现了！然而——我不应该不得不这样做，我应该专注于我的网站内容，而不是如何在单页反应站点中使元标签生效。

软件工程的未来

大多数企业软件项目团队通常包括以下成员：

产品负责人引导解决方案，了解它的功能等。
设计师们需要了解问题，设计接口和体验等。
工程师们负责构建用户界面（UI）、应用程序接口（API）、数据库（DB）、安全性和测试等。
也许需要一些数据科学家。

我相信工程师目前所做的很多工作可以通过genAI和其他方法自动化，一些设计师的工作也可以。我们仍然需要与真实人群相遇，了解他们的需求，构思新产品和解决方案——但当需要开始构建东西时，启动一个IDE并开始编写代码似乎是在浪费精力，因为我们可能可以使用genAI来为我们构建东西。

想象一下，如果我们只需要说“我想要一个托管在AWS上的React应用，符合我的公司的安全标准，连接到数据库使用一个API。应用程序应该有4个屏幕 - 一个主屏幕，用户可以登录，在数据库中检索和查看数据... 并确保所有内容符合公司的品牌准则”，而这一切都只为我们构建。然后我们看看它，说“好的，在主屏幕上我现在想要一个图片轮播，然后我想要数据库中的pdf文件以滚动方式显示...”，然后它就会自动完成。然后再过几周，我们的用户想要一个新功能，他们只需要求 - 它会被自动重新构建，测试和部署。

我相信利用传统技术和人工智能，自动化解决方案构建是可能的；只是时间问题，很快就会有人建立这样的工具。

楼宇的民主化

这种创造性的解决方案构建方式可能会彻底改变人们将产品推向市场的方式。我曾经在都柏林的一所学院教授一门关于应用开发的课程，针对的是商业和市场营销学生——它的目的是帮助那些有着伟大商业创意但缺乏技术技能的人。有太多惊人的创意——从分享时尚新方法到寻找最好咖啡的地方——而很少有学生拥有足够的知识将它们变为现实，除非找到技术联合创始人或花钱实现。

想象一下，他们只需要“请求”一个LLM来做这件事 - 将他们的想法转化为具体的有效解决方案，并让他们专注于重要事项 - 营销、了解客户、创造收入等等。当他们的实际客户只关心产品本身，而不关心技术时，他们就不再受技术的控制。

这是否意味着工程师会失业？

不是 — 相反！我在谈论的是今天我们做的事情 — 比如连接API，设计屏幕组件的CSS样式，想办法如何在用户首次点击屏幕时添加教程覆盖层 — 这些都可以自动化处理掉。让我们专注于构建解决方案的更有趣的部分 — 我们是否在构建正确的东西，我们可以多快地迭代和转变方向，用户喜欢什么不喜欢产品的哪些方面？

一种能够构建完整解决方案的人工智能工具并不是威胁 - 它是一个美好的机会，可以加速您的开发流程，是一个智能助手，帮助您更快地前进，做更多的事情。

工程师不仅仅是编码者 - 多年来，早在最近的genAI爆发之前，我一直相信工程师远远不止是把代码提交到GitHub的人。一名优秀的工程师就像在与用户一起进行构思的研讨会中感到舒适一样，也能够登录AWS查看Cloudwatch日志；工程是关于以最有创造力和有效率的方式解决问题并创造解决方案。有什么比让另一个更复杂的解决方案（genAI）来完成编码中的繁重工作更有效呢？

我上面所搭建的团队结构: