AI 擅长生成样板代码、测试、文档和重构建议,但定义正确问题、评估技术权衡、验证输出、保护安全可靠性的责任仍由工程师承担。
AI 编码工具可以快速生成函数、解释陌生的代码、编写测试、重构文件、提出修复建议。
这种能力给开发者带来了一个棘手的问题:
如果 AI 都能写代码了,软件工程师还能做什么?
答案并非"无事可做"。写语法只是工程工作的一个环节。真正困难的工作在第一行代码生成之前就已经开始,并在代码编译之后长期持续。
本文将解释工程师仍然掌控着什么、角色如何演变,以及在 AI 融入日常软件开发后,开发者应该加强哪些技能。
AI 在以下方面越来越有用:
软件工程师仍然负责:
AI 可以生成实现,却无法为结果负责。
代码生成不等于软件工程
一个 prompt 可以产出一个能跑的函数。但这不意味着这个函数就适合放在生产系统中。
工程师仍然需要回答以下问题:
这些问题需要业务上下文、技术判断和责任感。AI 可以辅助分析,但拍板仍是工程团队的活儿。
AI 通常只会响应交给它的任务。结果的质量很大程度上取决于任务本身是否正确。
比如这样一个需求:
为 API 添加缓存来提速。
immediate 实现可能很简单,但工程师应该先调查:
在理解问题之前就生成代码,可能让系统更复杂,却解决不了根本原因。
工程师的首要职责不是写代码,而是确保团队在解决正确的问题。
AI 工具在生成局部解决方案时往往很有效。但生产软件需要更宏观的视角。
一个功能可能影响到:
一段代码在一个文件里看起来正确,却可能在系统的其他地方制造问题。
架构工作要求工程师理解组件如何交互、故障可能发生在哪里、以及项目中哪些权衡是可以接受的。
例如,添加一个新的 AI 功能可能需要决策:
代码只是设计的一部分。
AI 生成的代码应该被视为一个提案,而不是自动可信的答案。
输出可能包含:
一个有用的 AI 辅助工作流如下:
AI 生成代码的速度越快,严格的审查就越重要。没有验证的速度只会更快地制造缺陷。
生成的解决方案可能编译通过,但仍然不安全。
工程师必须检查以下领域:
AI 并不知道所有的安全需求、业务规则或合规约束,除非这些上下文被提供。即使提供了上下文,结果仍然需要人工审核。
可靠性问题类似。在演示中工作的功能可能在以下情况失败:
生产工程关注的是为这些情况做准备,而不仅仅是让成功路径走通。
大多数工程决策没有一个完美的答案。
团队可能需要在以下之间做选择:
AI 可以列出利弊,但后果仍由人来承担。
正确的决策取决于团队的经验、截止日期、用户、预算、现有系统和对运维复杂性的容忍度。
强的工程师不只是问"我们能建成吗?",还会问:
软件开发不会在 PR 合并后就结束。
工程师继续:
AI 可以帮助完成其中许多任务,但长期可维护性取决于一致的架构、文档、测试和团队知识。
一个充斥着快速生成解决方案的代码库,当这些解决方案不遵循共同模式时,会变得越来越难维护。
目标不是生成尽可能多的代码。目标是构建团队能够安全运维和修改的软件。
初开发者面临一个真实的挑战。许多曾经提供早期经验的日常任务,现在可以用 AI 快速完成。
这并没有让编程基础变得不重要。恰恰相反,它们变得更加重要,因为开发者必须足够理解,才能识别生成的代码何时出错。
初级工程师应该练习:
一个能生成代码的初级开发者很常见。一个能验证、解释、测试和改进代码的初级开发者更有价值。
开发者不需要在打字速度上和 AI 竞争。他们需要在下述工作中变得更强:这些工作环绕在代码生成之外。
系统设计:了解服务、数据库、队列、API、缓存和客户端如何协作。
安全:理解常见漏洞,将安全融入设计和审查,而不是事后补救。
测试和调试:学会证明软件能正常工作,以及当它不工作 时如何隔离原因。
产品和业务:理解用户、业务目标和解决错误问题的代价。
沟通:工程师必须向技术和非技术队友解释风险、需求、权衡和决策。
AI 辅助开发:学会提供有用的上下文、审查生成的输出、保护敏感信息,以及判断何时不该用 AI。
在接受 AI 生成的代码之前,问自己:
如果最后一个问题的答案是"否",那这段代码还没准备好合并。
AI 可以让开发者更快。它可以减少重复工作,帮助团队更快地探索解决方案。
但它也可能生成令人信服的错误,增加需要审查的代码量,并鼓励团队在充分理解问题之前就行动。
这不是在论证每个工程角色或任务都将保持不变。日常工作在持续演变,对开发者的期望也在提高。最强的工程师将是那些把 AI 速度与技术基础、产品理解和审慎判断结合起来的人。
在 Techifive,我们把 AI 视为工程工作流的一部分,而不是工程所有权的替代品。
自从你开始使用 AI 编码工具以来,哪项工程技能对你来说变得更加重要了?
某些评论可能只对登录访客可见。登录后查看所有评论。