真的不再需要程序员了?

2024-06-14 01:52
文章标签 程序员 真的 不再 需要

本文主要是介绍真的不再需要程序员了?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

图片

AI时代:程序员的终结还是新起点?

©作者|Ninja Geek

来源|神州问学

“基本上以后不会存在程序员这种职业了,所有人只要会说话,甚至连写字可能都不用,你就具备今天程序员所具备的能力,所以这个意义还是很大的。未来的编程语言只会剩下两种:一种叫英文,一种叫中文,这也是目前世界上人工智能技术最领先的两个语言。“

                                                                                                                     — 李彦宏

在 2024 年 3 月的一档对话节目中,百度公司创始人、董事长兼 CEO 李彦宏先生谈到了对未来软件工程领域的判断。

“由于 AI 创造的奇迹,技术鸿沟被缩小,所有人都不再需要学习程序设计,现在程序语言属于每个人。”

                                                                                                                      —黄仁勋

在 2024 年迪拜举行的世界政府高峰会上 NVIDIA 首席执行官黄仁勋先生的发言。

我们从人才市场的角度来看,自从以 ChatGPT 为代表的大语言模型问世以来,写作和翻译的自由职业者受到来自人工智能的压力最大。同时,软件开发相关职位反而增加了 6%。

从一位软件开发者的角度去思考,我们需要明白,大语言模型的回答质量需要考虑以下几个方面:

1. 模型的参数规模:理论上来说,参数规模越大的模型,在联想、上下文理解方面更有优势。

2.支持的上下文窗口大小:支持更长上下文的模型,对于提问者的意图理解更有优势。

3.更好的算法:在相同或更少的计算资源下,提升模型的训练速度、减少过拟合、提高模型的泛化能力,这样,模型在不同任务中的表现更优。

4.优质的语料数据:精准的原始数据有助于模型的回答表现。多样化的原始语料意味着模型能学到更广泛的知识,避免偏见的产生。

5.提示词的质量:精心涉及过的提示词总是能比随意输入的提示词在更少的轮次获得你想要的答案。

我们试想一个场景,当我们需要在一个 IO 密集型场景下去解决网络请求吞吐量控制的问题,这里就会涉及到入线程、信号量、线程切换等技术专有名字,如果做为解决问题的人不具备这些背景知识,他是很难提出好的提示词,那么大模型也就无法给出最优解。

从接触过的许多非技术领域的管理者对于人工智能带来的生产力提升的错误理解谈起

“我们的客户一直希望能够更快的获得更多功能,并且认为人工智能就是解决交付瓶颈的银弹。”

我一开始对于这种想法不以为然,但随着接触的客户越来越多,发现这是目前存在的一种普遍理解。那么人工智能真的是下一颗“银弹”吗?

许多人认为人工智能是软件开发领域的重磅炸弹。显然,我不这么认为。就目前而言,人工智能仍然是辅助性的,而不是一种替代关系。

稍后我会展开来谈。

蜜月期

在一些领域,的确,人工智能已经超越人类工程师,如代码快速生成、代码审查(当然这不包括业务逻辑的审查,仅仅只是某种代码逻辑的审查)、测试和文档生成。

在过去几十年间,创造代码的工作一直牢牢掌控在人类工程师手里,但也不得不承认,人类工程师的代码输出速度和质量却并不稳定。特别是在不同工程师间的差异最多可能达到 7 倍。

随着人工智能的发展,我们对软件开发领域的掌控力正在减弱。

如 GitHub Copilot、通义灵码提供的编程辅助工具能够在瞬间生成代码。只要你的提示词质量够好,这些工具/模型就可以给你质量不错的回答。我曾仅花费一周的时间,利用 GitHub Copilot 使用 Spacy 自然语言处理框架完成了一个生产可用的文本分类模型的实现。要知道在此之前我毫无 Spacy 框架的相关经验。如果没有大语言模型,通常的做法是去阅读官方文档,在 Spacy GitHub 官方项目主页查找各种 issue 的解决方法,去 Google 中去大海捞针式的去查找一些很小众领域的问题,这还无法保证一定能找到答案。这些所花的时间可能是数倍之多。因此,不可否认,大语言模型给工程师带来的便利是值得肯定的。

但我反对的是无脑的支持人工智能,甚至认为她是无所不能的,至少现在不是,也不希望她是😛。

下面我会从几个层面来进行说明。

对于组织来讲,为什么生成式人工智能对软件开发企业有如此大的吸引力?

对于组织来讲,追求更高的质量、更低的成本和更快的速度是永恒的主题。

但总体而言,我们回顾过去几十年软件行业的发展,并不能完全满足这些期待。软件研发的过程往往进展缓慢、令人沮丧。对许多人而言,软件开发带来的负担大于其好处。

因此,各类企业对于生成式人工智能的前景垂涎三尺,希望能够出现一种技术提供无限的生产力。企业希望出现没有情绪,不会生病,无时无刻在产出代码的数字员工。似乎从大语言模型和未来的通用人工智能身上找到了答案。

但这真的能实现吗?我们需要明白一点,效率不等同于效果。快速做事并不意味着快速做出正确的事。人工智能可能会让我们更加关注产出而不是好的结果。而在这一过程中减少人的参与是一个可怕的想法。

这也是我们在使用人工智能解决问题时必须避免陷入的思维陷阱。

软件开发仍然是一种创造性工作,不只是编码本身

A bad system will beat a good person every time.

                                                                                                  — Edwards W. Deming

这是美国著名物理学家、统计学家爱德华兹 戴明说过的一句名言。

这意味着环境、行为和工作方式决定绩效。价值流动的问题不在于人,而在于人所处的系统。

人工智能无法修复损坏的系统。

我将这句话引申到人工智能领域则是:“糟糕的系统每次都会打败好人和人工智能。”

让我们来看看我是如何得出对人工智能的立场的。

更多、更快的产出一定带来更好的结果吗?

许多公司和组织开发的软件产品中充斥着面向绩效的,不必要的,半成品的功能。

多年来的信息系统建设导致信息孤岛的出现,要把这些信息孤岛重新连接起来,仍然需要具有行业经验的设计者来解决这些问题,这时,人工智能可以起到很好的辅助作用。如果一味追求产出而不是结果的系统并不会从更多的功能和特性中受益。

其问题的核心从来都不是开发人员可以输入多少代码以及速度有多快,也不是产品经理构思出多么酷炫的功能和输出了多少 PRD 文档。其实更多的是关于:

●我们对用户的了解程度。

● 我们可以更快的否定掉那些伪需求。

●我们如何更密切的与客户协作以解决他们的真实问题。

能够轻松地产出客户想要的任何功能的能力对于组织来讲是极具吸引力的。

但是,一旦整个系统出现问题,这一切都只是空中楼阁。信息孤岛的存在则会让更多好的想法停留在待办清单上。如果我们很少与客户交流,那么更多的产出只是在浪费时间和金钱。

与过往的各种开发技巧和工具相比,人工智能的确做得更好,变得更有效率了,但还没有出现颠覆式变革。我们试想,当前使用人工智能解决你的编码问题,使用传统的方式,如 Google 搜索,查找 GitHub issue,翻阅 StackOverflow 同样可以解决你的问题。

人工智能可以代替真实的客户沟通过程吗?

大概在几周以前我阅读了一篇文章,文章中提到如何利用人工智能来代替真实的客户沟通过程。

大概的意思是只需要将客户系统的关系型数据库结构和数据丢给大语言模型中即可。它将了解客户的需求和愿望。接着,我们就可以向大语言模型提出各种各样的问题,最后得到满意的回答。这种方法让我首先想到了神话传说中的炼丹炉,似乎把任何东西丢到炼丹炉就能制造出长命百岁的灵丹妙药。这听起来似乎过于理想化,我们来看看为什么:

1. 随着互联网与移动电商的兴起,我们与客户之间已经不受物理空间的限制,通过远程会议、即时通讯软件、电子邮件这些工具我们可以随时与客户保持连接。但没有发生变化的部分仍然是持续沟通。随着商业环境和业务的复杂化,没有什么比持续的沟通能更快了解客户和解决客户问题的“灵丹妙药”。也就是说人工智能无法感知物理环境的变化和情感变化,对,至少目前不行。

2. 大语言模型的幻觉问题一直是业界公认的难题。由于本质上语言模型是建立在概率学基础上的技术,因此,我们无法得到一个面面俱到,百分之百没有问题的模型,我们能做的只是让她变得更好而已。在真实的业务场景中,一定会有那么一些业务单元是绝不允许出现错误的,在这种情况下需要谨慎使用 AI,适当的工程化手段是必要的。

哪些部分是人工智能在客户沟通过程中能帮到我们:

1.如果你深刻理解客户的问题,那么你可以借助人工智能来学习和增强领域知识。可以想象一下,当你对客户所处的业务环境足够了解后,通过切片和数据清洗来使人工智能更好的“理解”用户的业务。这将是有用的。我认为人工智能是一个快速、强有力的客户业务的研究助手,而不能代替真实的客户沟通过程和对特定业务领域的学习和了解。

2.快速的原型输出。以往任何时候都没有像现在这种可以利用人工智能技术快速将想法转变成实际可运行的原型产品,当你认为你已经理解了客户的需求和需要解决的问题时,你确定真的完全懂了吗?没有什么比能够运行的系统更能够证明你已经弄明白要解决的问题。

了解您的客户和客户所处的业务环境没有捷径可走。

我们应该坚信人与人的沟通作用远大于人与机器的沟通,这也是我想谈的最后一点。

人工智能是否值得信赖

多年来,企业和组织一直在寻找建立信任的最佳方法。

那么人工智能值得信赖吗?

在一开始,人工智能似乎非常好。她完全透明、可以不间断的 24 小时工作、掌握丰富的知识、没有脾气。但盲目信任人工智能可不是什么好事,还记得终结者里的天网吗?

我们必须加强法律法规,对人工智能加以约束,因为人工智能带来了许多额外的问题:

●安全、数据保护和版权问题日益突出。

●数据治理与合规问题需要引起重视。

●加强模型的质量控制措施以便捕捉可能的人工智能幻觉。

从好的方面来说,目前许多大语言模型都提供了自省机制,某种程度上能自我修正可能的错误,但这并不能消除人类反馈机制,人类反馈机制仍然是改善大模型的必要有效手段,这种手段可能会一直存在。

人始终应该处于绝对控制的角色。

人工智能适合缓解瓶颈

如果你读过 Eliyahu M. Goldratt 的《目标》,你就会知道约束理论背后的概念。没读过也没关系,让我来总结一下:

“目标”的核心理念就是如何识别瓶颈和消除瓶颈。瓶颈总是潜伏在系统中,造成流程混乱。对瓶颈之外的系统部分的任何改进都无济于事。以下是他建议的要点:

1. 识别并优化瓶颈。

2. 增加出现瓶颈部分的容量使其不再阻碍流程流动。

3.找到下一个约束点并重复这个过程。

人工智能则可以通过多种方式帮助你实现这一点:

● 分析并识别瓶颈。

●建议优化造成约束或阻碍的方法。

●通过自动化来加速寻找并优化瓶颈的过程。

团队可以将 AI 作为约束理论的好伙伴。我们试想一下,编码速度其实很少会成为整个软件产品生命周期的瓶颈。

因此,我们可以更好的利用人工智能来作为瓶颈的破坏者而不是通过代码生成器来改进系统和流程。

结论和思考

在我写完这篇文章后,停下来思考良久,我意识到:

1. 更快的输出并不一定会带来更好的结果。

2. 人工智能无法代替与客户的直接沟通。

3. 人需要具备完全掌控的能力,而不是相反。

4. 持续学习,保持竞争力。

因此:

“我们应该让团队来决定如何使用人工智能来改进系统。团队最清楚问题出在哪里。就像任老讲的,让听得见炮声的人做决策。没有谁能比一线作战的人更好的指导人工智能应该做什么和怎么做。”

归根结底我们需要回归到人性的一面,团队仍然至关重要。当人工智能来临时,只是团队中的角色发生了变化,团队为人工智能腾出了她擅长的那部分空间。只有团队能更好的部署人工智能以改进整个系统和流程。

人工智能会一直存在,人也是如此。让我们彼此找到合适的生态位吧。

这篇关于真的不再需要程序员了?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1059047

相关文章

【新闻】AI程序员要来了吗?阿里云官宣

内容提要 6 月 21 日,在阿里云上海 AI 峰会上,阿里云宣布推出首个AI 程序员。 据介绍,这个AI程序员具备架构师、开发工程师、测试工程师等多种岗位的技能,能一站式自主完成任务分解、代码编写、测试、问题修复、代码提交整个过程,最快分钟级即可完成应用开发,大幅提升研发效率。 近段时间以来,有关AI的实践应用突破不断,全球开发者加速研发步伐。有业内人士坦言,随着大模型性能逐渐提升,AI应

BD错误集锦8——在集成Spring MVC + MyBtis编写mapper文件时需要注意格式 You have an error in your SQL syntax

报错的文件 <?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE mapperPUBLIC "-//mybatis.org//DTD Mapper 3.0//EN""http://mybatis.org/dtd/mybatis-3-mapper.dtd"><mapper namespace="com.yuan.dao.YuanUserDao"><!

Groovy:程序员的 DSL

什么是DSL? 领域特定语言,针对一个特定的领域,具有受限表达性的一种计算机程序语言。可以看做是一种抽象处理的方式。 具有四个元素,第一个是计算机程序设计语言,使用DSL来指挥计算机做事情,语言性(一种特定的语言),受限的表达性,并不像同通用的设计语言那样具有广泛的能力,针对一个明确的领域。 分类有哪些? 外部DSL:不同于应用系统主要使用语言的语言,通常采用自定义语法,宿主应用的代码采用

在WinCE的C#编程中,需要静态调用C++的动态库,需要添加using System.Runtime.InteropServices

using System.Runtime.InteropServices;         [DllImport("Win32DLL.dll", EntryPoint = "WriteREG_SZToRegTCHAR")]         private static extern bool WriteREG_SZToRegTCHAR(int iFlag, string regKeyP

某大厂程序员吐槽:离职交接时,新人被工作量吓退,领导却污蔑我故意劝退新人,我怒晒工作短信反击证明,新人看了后也决定走人了!

一位知名大公司的程序员分享了他离职时的遭遇:在交接工作时,新进的同事因工作量过大而感到压力,但出乎意料的是,他们的领导却指责我故意吓唬新人。为了证明自己的清白,我晒出了工作短信作为反击,结果连新人也决定离开。 在任何组织里,团队文化的优劣都是决定工作效率和质量的关键。一个和谐相处的团队不仅能提升工作效率,还能使工作氛围变得轻松愉快。 然而,一旦团队内部出现权力斗争或领导偏爱小团体、

1024程序员节 技术对抗赛 算法与安全答题 标准答案

请注意每次出题答案顺序都不一样,请仔细辨别   快查看计算题、专业题答案: 4根 11,24 对称加密算法 42 6787 题中选项皆有可能 远程控制软件 6次 25002550 593 2017年6月1日 x正比于根号n增加 15瓶药 具体题目: 关于钓鱼邮件的说法,下列错误的是:(B) A:即便邮箱有提供安全保护功能,所有送达邮箱的邮件也未必安全 B:

Selenium WebDriver 3.0 需要注意的事项

首先,要使用WebDriver 3.0 的话 请使用JAVA 8(必要)   其次,由于W3C标准化以及各大浏览器厂商的积极跟进,自WebDriver 3.0 之后,Selenium不再提供默认的浏览器支持. 也就是说 如果你要使用Firefox, 就需要用到Mozilla自己的驱动实现: geckodriver ,这里是github下载地址 https://github.com/mozil

H5测试需要关注的测试方面

原文转自:https://blog.csdn.net/u011695652/article/details/77932393 Html5是近五年来风头最劲的前端界面语言,不管是在PC端和手机端都得到了大幅度的使用,相信不久的将来将会替代Html4成为所有主流WEB界面的前端编写语言。而从H4升级到H5,还是有很多不同特性。且在插件的应用上也大大简化。下面我们就来探讨一下H5测试时应考虑的测试

提升方法AdaBoost你真的懂吗

路边的茶楼 人影错落 街上传来 两三声吆喝 人前摇扇 醒木拍桌 各位看官 你细听分说                                                                                                                                 《说书人》 1. 简介 提升(boosting)

「Debug R」如何不需要重新启动R/Rstudio就可以升级已经加载的R包

当我们已经加载了一个R包,例如ggplot2时,然后此时你发现ggplot2目前出最新版了,你心血来潮想要升级它,于是你输入了install.packages("ggplot2"), 结果弹出了下面这个界面 一个神奇的界面 它强烈建议你重启一下Rstudio,并且说到Rstudio会非常智能的重启并继续你的任务。但是根据我多年踩坑的经验,它通常没有那么智能。即便它有它说的那么智