这个职业有新的已核实记录时通知我 → · 标出哪些任务是你的(VOLO Pro,发布期间免费)→
初级程序员
把描述出来的问题变成能跑、能维护的代码 —— 并且越来越多地,要判断生成的代码到底对不对。
拿一个生成的 PR(你的或同事的),写一份真的找出了问题的评审意见,附上推理。每周做一次,把它们存下来。
这不是失业概率。它把「岗位任务中有多少暴露于自动化」与「采用实际走到了哪一步」合成为一个值 —— 只用于在同一套口径下横向比较职业,除此之外不作他用。
专门针对入门级与职业早期的软件岗位 —— 它面临的情况与资深工程岗明显不同。本站现在有六个软件页,用两种方式切同一批工作:按资历(这一页与「中高级软件工程师」)和按你负责哪一层(前端、后端、数据工程)。一个刚入行的前端会同时落在其中两页上,这是刻意的 —— 它们问的是不同的问题。
到底什么在变#
分析单位是任务,不是职位名称。职业不会被整体替代 —— 变的是它的任务构成。
每一格是一项任务。大小是它在这份工作里的分量,颜色是它正在往哪个方向走。点一格,看这个判断还不能说明什么。
生成它和为它负责是两回事。仍然要有人判断它是否正确,而这个人过去正是通过「先自己写」才学会判断的。
这是生成式代码天花板暴露得最清楚的地方,也是「初级」和「能放手让他独立干」之间的分界线。
审得好,前提是自己写过被审的那种东西。如果练出这份判断力的写代码工作正是被自动化的那部分,那么几年之内这项任务会出现人手断层。
这就是你做的吗?认一下,这一页会缩到只剩与你有关的那一份。
职位名只是一组恰好被打包买走的任务,而没有两个人手里的那一组是一样的。什么都不会被发送出去 —— 它只留在这个浏览器里。
近期变化#
在论文附录的暴露度最高五分位里,系统软件开发者按就业人数排第 7,而软件开发是作者专门做案例分析的两个职业之一。ADP 的美国私营部门工资单记录,覆盖数百万名劳动者,2022 年 11 月至 2026 年 6 月。11% 的下降指 22–25 岁、处于 AI 暴露度最高两个五分位的劳动者;同龄人中暴露度最低三个五分位的就业增长约 10%。资深劳动者没有可比的缺口,作者明确表示未发现全经济范围的岗位替代。结论是描述性的、非因果的,且在职业层面测量,不在任务层面。
招聘、人数、工时或职责出现可验证变化。权重最高 —— 但因果归因仍需论证,不能默认。
一份依法进行的普查:20 道固定题,每个上报的机构逐题答 Y 或 N,写下产品名与授权数量级。「用 AI 生成代码」是 45 个里 31 个答 Y,点到的产品三年前都还不存在。一个 Y 是雇主报告自己有这个工具,不是在量它写了多少代码、其中多少被留下;授权的数量级也不是「有这么多人在用它写代码」。那道题不分入行十年还是十个月;这条记录挂在这里,是因为写常规代码 —— CRUD 接口、表单、标准集成、已知模式的测试 —— 本来就是这项任务,不是因为清单说到了初级开发者。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
约束英国内政部软件团队的工程标准。它说团队应在 AI 有帮助时使用它;AI 辅助的产出在进入生产前必须经人审阅批准,并且必须可追溯;团队对所有 AI 辅助的代码和产出负全部责任,因为 AI 工具无法取代人对系统决定、设计和变更的判断、理解、所有权与责任。硬性的「必须」针对的是人工审阅;关于设计的那句是对责任归属的表述。它约束的是一个政府部门的工程师。
失败、撤回、监管或成本正在抑制采用。可以下调评估,或扩大不确定区间。
一项高校研究:在一家 IT 咨询公司的一个项目上,用大模型起草需求规格,由公司的资深分析师评估。有一部分用户故事所有模型都没处理好,因为分析师掌握的知识可能是隐性的,没有写进需求调研文档;分析师估计起草时间可节省 10% 到 15%;作者的结论是模型能帮助早期文档工作,但不能取代人的介入。这只是一个项目、一位专家,研究的角色是需求分析师而不是开发者。
真实场景里的小规模试验。说明落地条件正在被检验,不代表条件已经成立 —— 所以单独一次试点永远不够,两次互不相干的才够。
一家大型科技公司的自报数据,未说明「生成」如何计量(补全还是整段函数)。未提及招聘;审核环节仍由工程师承担。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
谷歌工程师描述自己的内部工具。谷歌把全体开发者的 50% 随机分组,让他们在集成开发环境里获得机器学习给出的构建失败修复建议,并与其余开发者对比 11 周;此后,每月遇到构建失败的用户中约 34% 会采用这类修复,机器学习构建修复也向全体谷歌开发者开放。开发者会预览每个修复,自己决定接受还是拒绝。这些是构建与编译错误 —— 文章说是容易理解的一类问题 —— 不是原因远离症状的运行时故障;谷歌出售开发者 AI 工具。
企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。
这对你意味着什么#
这个职业在「入门级 vs 资深」上的分裂,是首批职业里最尖锐的。让初级岗位在经济上值得设立的那些任务,正是被自动化的部分;而定义资深工作的那些任务,不是。风险不是「编程不再是职业」—— 而是梯子的最低一级正在被拆掉,顶端却完好。具体地说:你需要证明的是判断力而不是产量,而且要在别人通常还不会这么要求你的时候就做到。
你的位置相对稳固,但它依赖于「有一批人用慢办法学会了判断」这个供给。如果入门这一级持续断裂,几年后到来的约束就不是自动化 —— 而是没有人积累起足够经验去审查工具的产出。这件事值得现在就当成招聘和带人的问题来想,而不是以后。
你的选择#
四个方向,每个都写明真实约束和一个本周可验证的动作。继续做下去也是正当选择 —— 只要它是被选择的,而不是被默认的。
比梯子预期的更快建立判断力
稀缺的是「能判断生成代码对不对」的人。这件事你第一天就可以开始证明,不必等两年。
前提是待在一个有真实后果的代码库里。玩具项目教不会这个。
拿一个生成的 PR(你的或同事的),写一份真的找出了问题的评审意见,附上推理。每周做一次,把它们存下来。
转向「错了代价很高」的方向
支付、安全、数据一致性、基础设施 —— 这些「自信地答错会真的赔钱」的领域,会把人牢牢留在环节里。
需要深度,而深度需要时间。选一个方向,待到足够久,久到别人有问题会来问你。
在你当前的系统里挑一个这样的领域,从头读到尾,直到你能向别人讲清它的失效模式。
工程与问题之间的岗位
解决方案工程、开发者体验、技术产品 —— 这些岗位的价值在于同时理解系统和「别人需要它做什么」。
要求把沟通当成一级能力来练,不是每个人都愿意。
给你做过的东西写文档,交给一个不熟悉它的人,看着他卡在哪里 —— 不要帮忙。
把工程思维带到非软件领域
很多行业里几乎没有「既懂本行、又能动手做」的人。这个组合很稀缺,而且不和生成式工具正面竞争。
行业知识几乎要从零开始,第一年通常感觉像在倒退。
找一个非软件行业、有重复性问题的人,做出能帮上忙的最小的东西。这一个项目就是证明。
常见问题#
该学,但理由和五年前不同。过去学编程是为了能产出代码,现在的价值在于能判断代码 —— 而你没法判断一份你自己写不出来的代码。这套训练依然有效;变化的是入门级就业市场不再可靠地「一边发工资一边让你练出判断力」。要明确地为这个缺口做计划,而不是假设第一份工作会教你。
这些岗位存在的经济理由 —— 在规格清晰的工作上提供廉价产能 —— 正在减弱,而且这是真实的结构性变化,不是周期。但完全停止招初级的团队会给自己制造问题:几年后没有人是用「难的办法」学会判断产出的。合理预期是:这个角色会围绕审查与判断被重新定义,而且每个团队里的数量比过去少。
对初级开发者来说,信号不是模型能力,是你公司的应届招聘数。看看今年招了多少初级,和两年前比。有几家砍掉初级岗的组织已经公开承认,他们把「培养资深」的那条路一起砍了 —— 那句承认才是值得追踪的事件。
写常规代码 —— 标为「正在自动化」的那一项,也是过去填满初级开发者头两年的那件事。系统设计与需求梳理不在其中,但那是你走完那两年之后才到的地方 —— 而现在没有东西替代那条路。
该学,但理由变了:你现在学写代码,是为了能审代码,不是为了产出代码。要把「读起来顺、其实是错的」产出审好,前提是自己写过同样的东西 —— 也就是说,学习仍然得用慢办法完成,尽管产出的市场变小了。
还在读书、想往这个方向走?
这些专业能通到这里。它们的页面会拆解:哪些能力真的用得上、毕业生普遍缺什么。
这些判断底下是什么#
这一页上 5 条任务判断里,4 条有已核实事件支撑、1 条是平台推断,每一条都在它出现的地方标注着。它们底下是 1 个技术维度、一条自语言模型进入公众视野以来的回溯轨迹,以及 6 条已核实事件。
同一个职能里的其他岗位#
一家公司先把工作分成职能,再分成岗位。下面这些和这一份工作同在「技术与数据」里 —— 那是一件关于组织结构的事实,不是「它们相似」或者「它们在朝同一个方向变」的判断。
中高级软件工程师 · 前端工程师 · 后端工程师 · 数据工程师 · 算法 / 机器学习工程师 · AI 研究员 · 测试工程师 · 数据分析师 · 数据科学家 · 统计师 · 经济学家 · 业务分析师 · 业务系统与流程负责人 · IT 支持 / 技术支持 · 网络安全分析师 / 安全运营 · 运维 / 平台工程师 / SRE · 网络工程师 · 技术文档工程师 / 技术写作 · 基金申请书撰写人
