生成式人工智能不会为你建立工程团队-CSDN博客

本文链接：https://blog.csdn.net/qq_41537900/article/details/139823809

生成式人工智能不会为你建立工程团队

在这里插入图片描述

软件产业正在成长

在某种程度上，这是行业成熟的必然结果。任何领域的早期都有点像狂野的西部，赌注很低，没有监管，标准刚刚形成。如果你看看其他行业的早期历史——医药、电影、广播——相似之处是惊人的。

任何新兴技术都有一个神奇的时刻，在这个时刻，角色之间的界限是多孔的，任何有动力、有好奇心、愿意努力工作的人都可以抓住机会。

它永远不会持久。它不能;这是不应该的。在进入这个行业之前，你必须具备的必备知识和经验急剧增加。赌注增加，任务的规模增加，错误的代价飙升。我们开发认证、培训、标准、法律仪式。我们争论软件工程师是不是真正的工程师。

软件是一个学徒行业

进入这个行业所需的先决知识越来越多，节奏越来越快，风险也越来越高，所以你不能再像曾经那样，在工作中学习所有的东西。

然而，你也不可能在大学里学到你需要知道的一切。一个计算机科学学位通常比一个普通的软件工程师为你的计算机研究生涯做了更好的准备。进入这个行业更实际的途径可能是一个好的编码训练营，它强调解决问题和学习现代工具包。在这两种情况下，与其说你学会了“如何做这项工作”，不如说你“学会了足够的基础知识来理解和使用学习这项工作所需的工具”。

软件是一个学徒行业。你不可能通过读书来学习成为一名软件工程师。你只能通过做，做，再做，再做来学习。不管你的教育内容是什么，大部分的知识都是在工作期间学到的。它永远不会结束!学与教是终身的实践;他们必须这么做，因为行业变化太快了。

要培养一名称职的软件工程师，需要扎实的七年多的时间。(或者像大多数职位晋升者所说的那样，“高级软件工程师”。)这意味着多年来每天都要与经验丰富的工程师一起编写、审查和部署代码。这就是它所需要的时间。

“高级工程师”是什么意思?

以下是我经常遇到的一些对我的时间表非常愤怒的反驳，例如:

“七年? !我花了两年时间!”

“我在不到五年的时间里就被提升为高级软件工程师了!”

对你有好处。没错，七年并没有什么神奇之处。但要成长为一名经验丰富的工程师需要时间和经验，才能成为一个团队的支柱。更重要的是，它需要练习。

我认为，我们已经开始使用“高级软件工程师”来指代那些能够发布代码并在生产力方面发挥积极作用的工程师，我认为这是一个巨大的错误。这意味着较低级别的工程师在生产率方面一定是净负的，这是不正确的。而且它忽略了软件工程工作的真正本质，编写代码只是其中的一小部分。

对我来说，成为一名高级工程师主要不是你写代码的能力。随着时间的推移，它与您理解、维护、解释和管理生产中的大量软件的能力以及将业务需求转化为技术实现的能力有更大的关系。很多工作都是围绕着制作和管理这些大型、复杂的社会技术系统展开的，而代码只是这些系统的一种表现形式。

成为高级工程师意味着什么?这意味着你首先学会了如何学习，以及如何教书;如何在头脑中掌握这些模型并对其进行推理，以及如何随着时间的推移维护、扩展和操作这些系统。这意味着你有良好的判断力和值得信任的直觉。

这就引出了人工智能的问题。

我们不能再蚕食自己的未来了

当你的第一个工程师是非常非常难的。直到我看到我的小妹妹(刚毕业，成绩很好，有一些实际经验，工作非常努力)奋斗了近两年才在她的领域找到一份真正的工作，我才意识到这有多难。那是几年前的事了;有趣的是，从那以后，事情似乎变得更加困难了。

在过去的一年里，我读到了很多关于不同行业的入门级工作被人工智能取代的文章。其中一些绝对是有价值的。任何需要将文档从一种格式转换为另一种格式，阅读和总结一堆文本，或者用另一组图标替换一组图标的苦差事似乎都很容易受到攻击。对我来说，这并不是革命性的，它只是将现有的自动化热潮扩展到涵盖文本材料和数学材料。

然而，最近，科技领域的一些高管和所谓的“思想领袖”似乎真的相信，生成式人工智能即将取代初级工程师所做的所有工作。我读过很多关于初级工程工作如何被自动化淘汰，或者对初级工程师的需求正在萎缩的文章。这已经把我逼疯了。

所有这些都表明了对工程师实际工作的深刻误解。由于不雇用和培训初级工程师，我们正在毁掉自己的未来。我们不能再这样做了。

编写代码是比较容易的部分

人们表现得好像编写代码是软件最难的部分。事实并非如此。从来没有，将来也不会。编写代码是软件工程中最简单的部分，而且它正变得越来越容易。困难的部分是如何处理代码——操作它、理解它、扩展它，以及在它的整个生命周期中管理它。

初级工程师从学习如何编写和调试代码行、函数和代码片段开始。当你练习并朝着成为一名高级工程师的方向前进时，你将学会从软件中组成系统，并引导系统通过变化和转换的浪潮。

社会技术系统由软件、工具和人员组成;理解它们需要熟悉软件、用户、产品、基础设施和持续变化之间的相互作用。这些系统极其复杂，易受混乱、不确定性和突发行为的影响。如果有人声称了解他们正在开发和操作的系统，那么这个系统要么非常小，要么(更有可能)他们知道的不够多，不知道他们不知道的东西。换句话说，代码很容易，但系统很难。

目前的人工智能生成工具浪潮已经帮助我们快速生成大量代码。简单的部分正以惊人的速度变得更加容易。但是它并没有在管理、理解或操作代码方面提供任何帮助。如果说有什么不同的话，那就是它只会让艰难的工作变得更加艰难。

但是这些代码首先必须被理解、调整并清晰地集成到系统中。

生成代码很容易，生成好的代码却很难

如果你读了很多令人屏息的思考文章，你可能会在脑海中想象软件工程师们兴高采烈地为ChatGPT制作提示，或者使用Copilot生成大量代码，然后将出现的任何内容提交到GitHub上，然后离开。这与我们的现实并不相似。

正确看待像Copilot这样的工具的方式更像是一个非常花哨的自动完成或复制粘贴功能，或者可能像Stack Overflow搜索结果加上谷歌的“我觉得很幸运”的邪恶的爱的孩子。你每次都要掷骰子。

当文件中已经有一个并行文件，并且您只想在稍加修改的情况下复制粘贴时，这些工具将发挥最佳作用。或者当您在编写测试时，您有一大块相当重复的YAML，它在插入正确的列和字段名时重复该模式，就像自动模板一样。

但是，您不能信任生成的代码。我怎么强调都不为过。ai生成的代码总是看起来很合理，但即使它“有效”，它也很少与你的需求一致。它将愉快地生成不需要解析或编译的代码。它会组成变量，方法名，函数调用;它会产生不存在的幻觉。生成的代码将不遵循您的编码实践或惯例。它不会重构或为你提供智能抽象。一段代码越重要、越困难或越有意义，你就越不可能使用AI生成可用的工件。

您不必从头开始输入代码，这样可以节省时间，但是在提交代码之前，您需要逐行检查输出，并进行修改，更不用说将其交付到生产环境了。在许多情况下，这将花费与编写代码相同甚至更多的时间，尤其是在自动完成功能变得如此聪明和复杂的今天。将人工智能生成的代码与其他代码库保持一致可能需要大量的工作。坦率地说，这种努力并不总是值得的。

生成可以编译、执行并通过测试集的代码并不是特别难;困难的部分是创建一个代码库，让许多人、团队和连续几代的团队可以在未来几年里导航、改变和推理。

工程师如何真正使用生成式人工智能

这就是TLDR:你可以生成很多代码，非常快，但你不能相信结果。然而，在一些用例中，生成式AI一直很出色。

例如，要求chatGPT使用不熟悉的API生成示例代码通常比阅读API文档更容易——毕竟，语料库是在API用于实际工作负载的存储库上进行训练的。

生成式AI也非常擅长生成令人讨厌或乏味的代码，但它们的范围很窄且易于解释。场景越可预测，这些工具就越适合为您编写代码。如果您需要的是有效地复制粘贴模板—任何时候都可以使用sed/awk或vi宏生成所需的代码—生成式AI非常擅长此道。

它也非常擅长为您编写小函数，以便在不熟悉的语言或场景中执行操作。如果你有一段Python代码，你想在Java中做同样的事情，但你不懂Java，生成人工智能会帮你。

再一次，记住，结果完全是捏造的几率是50%。你总是不得不假设结果是不正确的，直到你可以亲自验证它。但这些工具绝对可以在无数方面加速你的工作。

生成式人工智能有点像初级工程师

肯特•夸克(Kent Quirk)将生成式人工智能描述为“一个打字非常快的易激动的初级工程师”。我喜欢这句话——它给我留下了不可磨灭的印象。

生成式人工智能就像一个初级工程师，你不能把他们的代码投入生产。你要为此负责——从法律上、道德上和实践上。你仍然需要花时间去理解它，测试它，编写它，在风格上和主题上对它进行改造，以适应你的代码库，并确保你的团队成员也能理解和维护它。

实际上，这个类比是恰当的，但前提是你的代码是一次性的和自包含的，即不打算集成到一个更大的工作体中，或者保存下来，被其他人阅读或修改。

嘿，在这个行业的某些角落里，大多数代码都是只写的、一次性的代码。有些机构每年推出几十款一次性应用，每款应用都是为某个特定的发布或营销活动而编写的，然后任其自生自灭。但这不是大多数软件。一次性代码很少见;需要长期工作的代码是常态。甚至当我们认为一段代码可以一次性使用时，我们也常常是错误的。

但生成人工智能不是你团队的成员

在这种特殊意义上——生成你知道是不可信的代码——genai有点像一个初级工程师。但在其他方面，这个类比是站不住脚的。因为添加一个编写代码的人到您的团队中与自动生成代码完全不同。这些代码可能来自任何地方——stack Overflow, Copilot，等等。你不知道，这也不重要。没有反馈循环，没有人在另一端反复尝试学习和改进，也不会对你的团队氛围或文化产生影响。

最明显的是:给初级工程师提供代码评审反馈不同于编辑生成的代码。当你的努力投入到别人的学徒生涯中时，你的努力会更有价值。这是一个把你在自己的职业生涯中学到的经验传授给别人的机会。即使只是构建你的反馈来解释和传达你的信息，也会迫使你以更严格的方式思考问题，并有办法帮助你更深入地理解材料。

在你的团队中加入一名初级工程师将会立即改变团队的动态。它创造了一种环境，在这种环境中，提问是常态化的，鼓励的，教与学是一种常态。我们一会儿会更多地讨论团队动力。

你在帮助一个初级工程师升级上投入的时间会很快得到回报。时间过得真快。在招聘的时候，我们倾向于高估高级工程师，就像低估初级工程师一样。这两种刻板印象都没有帮助。

我们低估了雇用年长员工的成本，而高估了雇用年轻员工的成本

人们似乎认为，一旦你雇佣了一名高级工程师，你就可以把他们放到一个团队中，他们会立即变得富有成效，而雇佣一名初级工程师则会永远拖累团队的表现。两者都不对。老实说，大多数团队要做的大部分工作都不是那么困难，只要它被分解成它的组成部分。低级工程师有足够的空间执行和发展。

你的会计的粗略简化的观点是这样的。“当我们可以花20万美元聘请高级工程师来加快速度时，为什么要花10万美元聘请初级工程师来放慢速度呢?”这毫无意义!

但是你知道，我也知道，每个关注的工程师都应该知道，这不是工程的运作方式。这是一个学徒行业，生产率是由每个团队的产出和承载能力决定的，而不是每个人。

一个人可以通过很多方式为团队的整体速度做出贡献，就像一个人可以通过很多方式消耗团队的能量，或者给周围的人增加摩擦和拖累一样。这些并不总是与人的水平相关(至少不是人们倾向于假设的方向)，编写代码只是一种方式。

此外，你聘请的每个工程师都需要一段时间和投资才能做出贡献。招聘和培训新工程师是一项代价高昂的工作，无论他们的水平如何。任何高级工程师都需要花时间来建立他们对系统的心智模型，熟悉工具和技术，并加快速度。多久?这取决于代码库的整洁和组织程度，你过去使用工具和技术的经验，你在培训新工程师方面的能力等等，但可能需要6-9个月。它们可能要一年左右才能达到巡航高度。

是的，对于一个初级工程师来说，这个斜坡会更长，是的，这将需要团队更多的投资。但它不是无限的。你的初级工程师应该在大致相同的时间范围内(6个月到1年)实现净收益，而且他们的发展速度远远快于其他高级贡献者。(不要忘记，他们的贡献可能远远超过他们自己编写的代码。)

你不必成为一名高级工程师来增加价值

就编写和发布特性而言，我所知道的一些最有生产力的工程师都是中级工程师。他们还没有陷入所有会议、策划、指导、建议和架构的泥潭，他们的日历上还没有被打断的痕迹，他们可以做一些事情。你会看到他们早上第一件事就是戴上耳机，整天写代码，晚上出门时取得了令人难以置信的进步。

中级工程师处于这种可爱的临时状态，他们在编程方面已经足够优秀，可以非常高效，但他们仍在学习如何构建和维护系统。他们所做的就是写代码，一堆又一堆代码。

他们精力充沛，全身心投入。他们玩得很开心!他们不会厌倦第1000次编写网页表单或登录页面。一切都是新鲜的、有趣的、令人兴奋的，这通常意味着他们会做得更好，尤其是在更有经验的人的指导下。团队中有中级工程师是很了不起的。你得到他们的唯一途径是雇佣初级工程师。

在团队中拥有初级和中级工程师是防止过度工程和过早复杂性的一种非常好的预防方法。他们对问题的了解还不足以想象出所有需要解决的无限边缘情况。它们有助于让事情变得简单，这是最难做到的事情之一。

雇佣初级工程师的长期争论

如果你问的话，几乎每个人都会全心全意地同意雇用初级工程师是一件好事……应该由其他人来做。这是因为雇用初级工程师的长期理由是令人信服的，而且相当容易理解。

整个行业需要更多的高级工程师
总得有人来训练他们
初级工程师更便宜
它们可能会增加一些急需的多样性
他们通常对投资培训他们的公司非常忠诚，并且会在公司待上几年而不是跳槽
我们是不是已经说过需要有人来做这件事了?

但公司或资本主义通常不擅长长期思考。这样一来，就会让人觉得你雇佣初级工程师是一种无私的公共服务行为，而你自己却付出了巨大的代价。公司更有可能想要将这些成本外部化，这就是我们现在所处的位置。

雇佣初级工程师的短期理由

然而，在短期内雇佣初级工程师——自私的、固执的、有利可图的原因——对团队和公司有利的原因，至少有同样多的争论。你只需要稍微转移一下你的视角，从个人到团队，让他们成为焦点。

让我们从这里开始:招聘工程师并不是一个“为工作挑选最佳人选”的过程。招聘工程师就是组建团队。软件所有权的最小单位不是个人，而是团队。只有团队才能拥有、构建和维护软件的语料库。它本质上是一种协作性的活动。

如果招聘工程师是为了挑选“最好的人”，那么用你的钱雇佣资历最高、经验最丰富的人是有意义的，因为我们用“资历”和“经验”来代表“生产力”。(值得怀疑，但我们不要吹毛求疵。)但是每个人的生产力并不是我们应该优化的。团队的生产力才是最重要的。

最好的团队总是拥有不同的优势、观点和专业水平。单一文化可以在短期内取得惊人的成功——它甚至可能超过一个多元化的团队。但它们不能很好地扩展，也不能优雅地适应不熟悉的挑战。你等待多样化的时间越长，难度就越大。

我们需要雇佣初级工程师，而且不是一次，而是持续不断。我们需要继续从下往上给漏斗喂食。初级工程师只做几年初级工程师，中级工程师变成高级工程师。超级高级工程师实际上并不是指导初级工程师的最佳人选;最有效的导师通常是比你高一级的人，他清楚地记得你的处境。

一个健康、高效的团队有不同的层次

一个健康的团队是一个生态系统。你不会在一个产品工程团队中配备6名数据库专家和1名移动开发人员。你也不应该让6名员工+工程师和1名初级开发人员。一个好的团队是由各种技能和水平组成的。

你是否曾经在一个只由员工或首席工程师组成的团队中工作过?这一点也不好玩。这不是一个高效的团队。只有这么多高层架构和规划工作要做，只有这么多重大决策需要做出。这些工程师把大部分时间花在无聊和重复的工作上，所以他们倾向于过度设计解决方案和/或偷工减料——有时是同时进行的。他们会为了“有趣”的东西而竞争，并找到理由与对方进行技术斗争。他们长期在使系统简单和易于处理的工作上缺乏文档和投资。

只有中级工程师(或初学者、高级工程师等)的团队会有不同的病态，但会有类似的争论和盲点问题。工作本身在复杂性和难度上有很大的差异——从简单的、严格限定范围的功能到艰难的、高风险的体系结构决策。从事这项工作的人占据类似的范围是有道理的。

最好的团队是那些没有人感到无聊的团队，因为每个人都在做一些挑战自己、突破自己界限的事情。实现这一目标的唯一方法便是让团队成员拥有不同的技能水平。

我们面临的瓶颈是招聘，而不是培训

我们现在面临的瓶颈不是我们培养新的初级工程师并赋予他们技能的能力。也不是关于大三学生学习如何更加努力;关于这个话题，我看到了很多可靠的、善意的建议，但这并不能解决问题。瓶颈是给他们第一份工作。瓶颈是由那些将其视为外部化成本的公司构成的，而不是对他们公司未来的投资。

在他们的第一份工作之后，工程师通常可以找到工作。但在我看来，得到第一份工作简直是谋杀。这几乎是不可能的——如果你没有从顶尖大学毕业，也没有进入大型科技公司的输送系统，那么这就是掷骰子，一个运气问题，或者谁有最好的关系的问题。在“生成人工智能可以取代初级工程师”的幻想从沼泽中崛起之前，一切都很艰难。现在……现炒。

如果你当初没有进入科技行业，你现在会在哪里?

我知道我会在哪里，但不是在这里。

互联网喜欢取笑婴儿潮一代，这一代人以顺利上大学、买房和退休而闻名，然后在他们之后拉上梯子，同时嘲笑年轻人是雪花。“好吧，婴儿潮一代”可能会继续存在，但我们能试着让“好吧，总工程师”不再成为一件事吗?

没有人认为我们需要更少的高级工程师

许多人似乎认为我们不需要初级工程师，但没有人认为我们需要更少的高级工程师，或者在可预见的未来需要更少的高级工程师。

我认为可以肯定的是，任何确定的和可自动化的东西最终都会被自动化。软件工程也不例外——我们是起点!当然，我们一直在寻找自动化和提高效率的方法，这是我们应该做的。

但大型软件系统是不可预测和不确定的，具有突发行为。仅仅是用户的存在就给系统注入了混乱。组件可以自动化，但复杂性只能管理。

即使系统可以完全自动化并由人工智能管理，我们无法理解人工智能如何做出决策这一事实也是一个巨大的、可能无法克服的问题。在一个人类无法调试或理解的系统上运行业务，似乎是一种存在的风险，任何安全、法律或财务团队都不会同意。也许这种未来的某个版本会实现，但现在很难看到。我不会拿我的事业或我的公司来赌它的发生。

同时，我们还需要更多的高级工程师。种植它们的唯一方法就是固定漏斗。

每个公司都应该雇佣初级工程师吗?

不。你需要能够为他们的成功做好准备。让你不适合雇佣初级工程师的一些因素:

你只有不到两年的时间
你的团队一直处于救火状态，或者你的系统没有懈怠
你没有经验丰富的管理者，或者你有糟糕的管理者，或者根本没有管理者
你没有产品路线图
你的团队中没有人有兴趣成为他们的导师或指导者

唯一比不雇佣任何初级工程师更糟糕的事情是，把他们招进一个他们什么都学不到的糟糕经历中。(我不会像辛迪在这篇文章中那样设定这么高的标准;虽然我理解她的想法，但找到第二份工作比找到第一份工作要容易得多，我想大多数初级工程师都会坦率地选择一份糟糕的第一份工作。)

作为一个完全分布式的公司并不是一个完全的交易破坏者，但它确实使事情变得更加困难。如果可能的话，我建议初级工程师去找办公室工作。当你能吸收随意的谈话和技术上的闲聊时，你学得更快，而在家工作就失去了这种能力。如果你是远程办公的雇主，要知道你需要更加努力地工作来弥补这一点。我建议向那些成功做到这一点的人(他们确实存在!)寻求建议。

我还建议公司不要一开始就雇佣一个初级工程师。如果你打算雇一个，那就雇两个或三个。给他们一群同伴，这样就不那么令人生畏和孤立了。