自上个世纪60年代软件危急（Software Crisis)起，软件从业职员和软件用户日益意识到由于软件和软件开拓掩护的繁芜性必将导致软件中充斥各种问题（bug），且难以创造和解决。这也常常导致软件研发的投资达不到预期的收益而失落败。
在经典著作《人月神话》中，Frederick P. Brooks回顾了软件从业者为了彻底办理这一顽疾而进行的各种考试测验，不幸的是，这些努力都未竟全功。在此书出版后的三十多年后，Brooks仍在反复检视业界各种新的考试测验，但仍不得不哀叹“并没有一招毙敌的银子弹啊！
”
韶光来到21世纪20年代，OpenAI为代表的天生式人工智能崭露锋芒，软件工程师们惊喜或惊异地创造，这些GPT不仅可以和你谈天胡扯，也可以根据自然措辞天生代码或测试用例。
那AI有没有可能成为办理软件工程各种问题的终极办理方案呢？
人工智能现在能帮助我们做什么软件事情？
日益强大的AI现在已经能在很多编码、测试事情中帮助软件工程师，例如：
集成于IDE的代码天生（copilot)：在软件代码编写时，工程师常常被分配的事情是重复性的，即在公司里已经有别的同事写过类似的代码片段了。
Copilot就像个不知疲倦的伙伴，会利用机器学习技能，根据你写的代码的高下文，自动帮助你补足乃至是天生代码。而且，更知心的是，这些天生的代码是没有语法缺点的。这大大提升了工程师编写代码的效率。
代码质量检测：在代码编写完成时，软件工程师须要自检代码的质量。之前，我们用到的类似Sonar、Coverity之类的工具是基于规则的判断，误判和漏判的概率都不低。结合机器学习的理解能力，代码静态扫描工具可以更有效地创造代码中的毛病、漏洞和“坏味”。如果利用得当，这会大大缓解测试的压力。
自动化测试：AI已经可以根据软件需求和软件代码的理解，自动天生测试用例并实行，常见工具有Selenium和TestNG，这使得测试工程师可以更频繁、更全面地测试软件，从而提升交付软件的质量。
团队协作：利用自然措辞理解技能，AI可以读懂代码，并天生相应的文档、演示材料。这无论是对工程师间的协作沟通，还是对新加入员工的培训，以及离职职员的交卸都有巨大的益处。
这个列表还在持续延长，一韶光，有人惊呼，AI可以按需天生软件（他们把软件大略等同于可运行的代码，这是一个知识性谬误）了，软件的所有麻烦来日诰日就将消散了。
以是，万事大吉了吗？
以商用软件交付为例，一个范例的、忽略了商务活动的软件项目过程大致如下：
须要解释的是，这里虽然用线性的办法表述了这个过程，但在实际项目里，这些环节或步骤常常是迭代往来来往且有所交叠的。
软件编码和测试只是事情的一小部分。每一位有履历的项目经理或产品经理都知道，写代码和让代码在实验室的环境里跑起来，只是全体项目事情的一小部分。
有统计称，这部分在大部分项目的事情量中占比不超过40%。以是，如果AI只能在写代码、测试代码这些事上发挥浸染，那么显然不能称之为“银子弹”。
软件需求网络与剖析的主要性未降落。各大AI公司都有不同的演示，口齿伶俐的产品经理在一块白板前边说边画，AI便快速地天生了代码，然后支配在生产环境上，于是用户就可以利用了。
但大多数人忽略了一点，即能把软件系统要干什么描述清楚，这实在不在大多数软件用户的能力范围内，更不用说准确描述软件的系统边界以及在分外情形下的行为模式了。
在软件工程中有一句名言：Garbage in, garbage out! 这句话在AI时期仍不过时。
做过商用软件需求调研的软件人一定有过这样的痛楚经历，收到的需求是模糊的、不完全的、乃至是自相抵牾的。这倒也不一定是客户代表在故意刁难，而是很可能在实际业务场景下，各个部门用户的诉求便是这样的。这也常常导致，没有业务流程重组，乃至是组织变革，直接上软件系统很有可能导致软件达不到设计的目的。
软件的实质繁芜性日益提升。险些所有的商用软件既不是从零写起的伶仃系统，既须要在之前版本长进级，也须要与其它已存在的软件系统协同事情。
以是，软件工程师须要花很多韶光去理解、理解现有的软件系统，然后才能谨小慎微地实现自己的那个需求，类似于“在已有的迷宫里去增加一个小迷宫”。AI在这样繁芜的环境里构建软件的能力仍需验证。
AI生产代码的同等性疑问。AI时期之前，软件研发实质上还是“大规模的手工业”，团队与团队之间，乃至是团队内部在办理类似问题时可能采取非常不同的技能思路与方案。
在书法作品里，同一个”之“字，书法家喜好写身分歧的形式以展示其艺术性。但这种个性化在软件工程里却是一个灾害。
虽然，古早的软件管理者希望通过技能标准和技能规范等办法来约束，不得不承认，软件同等性仍旧一贯是巨大的寻衅。其征兆便是一个缺点可能在不同的代码片段里用不同的办法展现出来，外在表现形式也千奇百怪。特殊是，经由一段韶光后，软件的可掩护性一定持续降落。AI天生代码仍有某种不可预测性，以是软件同等性问题并未得到缓解。
对软件未来利用的预测仍不可知。一个好的架构师在做架构设计时都会面向当前的利用场景，且适度地考虑未来的可扩展性，但这实质上是一个基于各种考虑成分的综合妥协。纵然是一流的架构师，仍不能规避短视或过度灵巧的误判，一年后，乃至半年后拍大腿的场景习认为常。目前看，AI在这方面也不太可能供应可靠的帮助。
同样，这个列表目前也挺长的。以是，目前AI还远不能称之为“包治百病的灵丹灵药“。
那么，我们能期待AI在哪些领域进一步提升呢？
AI应可以帮助网络与剖析需求。拥有自然措辞理解能力的AI不仅应可以不厌其烦地从不同层级的用户处网络需求，还应可以从大量的文档记录中理解竞品的情形、当前在用软件的问题、乃至是当前业务流的各种场景、例外情形、以及协同机制。从而，构建与持续掩护软件需求的全景图。让软件工程师和客户代表既能不雅观之全貌，也能快速理解细节，”构建从3万英尺到12英寸不同高度的视角。“ 进而彻底肃清软件需求层面由于误解导致的质量问题，规避冲突的需求，减少无效需求。
AI应提升在繁芜业务环境里修正软件并保持同等性的能力。大略地实现一个排序，或者用户处理这样的需求是随意马虎的。
但要保持与业务环境里其它系统或本系统其它部分的同等性就不那么随意马虎，例如，在排序问题中，对相同条款该当如何处理？要不要去重？在响运用户时，如何处理非常输入？这既哀求AI能全局性地理解本系统的代码和周边干系系统的边界、行为，还要有能力掌握使其代码输出的同等性，彻底规避其”不苟言笑地胡说八道“的情形。
AI应提升软件验收的能力。大略地根据需求文档和代码去设计测试用例和天生测试代码与数据是手工时期的无奈妥协。
我们期待AI还可以从客户业务流程记录、过往系统利用日志与掩护日志、干系联系统的交互等更全面的信息出发，总结提炼出更全面的软件验收测试方案，并设计出相应的测试用例、数据与测试代码。
如果能进一步做市场与客户剖析，对软件未来的利用场景进行合理的预测，进而进行相应的测试那将更有帮助。
AI应能帮助用户更好的利用软件。只管软件项目团队常日会在软件试运行和正式上线前给目标用户做培训，也会准备干系的用户利用手册。但比较常见的是，系统上线后，做事支持职员还是要疲于奔命，回答用户的各种各样、稀奇古怪的问题。
站在用户的角度，新的软件系统便是令人费解，让人充满挫折感。纵然一个本来该当很大略的财务报销系统，普通用户便是不知道该如何填写，导致每每被财务职员无情地打回。
具备自然措辞理解能力的AI天经地义地被期望成为软件用户的私人助理，帮助用户精确利用软件、办理用户问题、提升用户满意度。
结语
”AI来了，软件工程师要全员下岗了。“ 这个事短期看还不会发生，由于软件工程面临问题的繁芜性、可变性、难以预测性等特点还是没有改变的，还是须要受过专业演习的工程师持续努力。
但仅从写代码这个事情讲，其难度门槛已经在持续降落了，事实上这在AI时期之前，也是在降落的。
以是，正面地看，AI在重塑软件工程，软件工程师将不得不持续拥抱AI。被AI武装的软件工程师将更高效、更有全局不雅观、更有客户视角，从而能更敏捷地构建与掩护软件，知足客户持续且多变的需求。