全文摘要：替代「写代码」这个动作已经在发生，替代「程序员」这个职业在可验证数据里还没发生。2023 年的对照实验测到 55.8% 提速，2025 年的对照实验测到 19% 变慢，两个数字都真实。差别不在 AI 行不行，而在任务形状、人的资历和验证成本。本文用一个可运行的任务评分器，把「会不会被替代」拆成四个可打分的维度。
目录
- 先说结论
- 两组互相打脸的数据
- 为什么「感觉快了」和「实测变慢」能同时成立
- 一个任务级模型：可替代性四维
- 一个能跑的替代性评分器
- 症状 → 原因 → 解法对照表
- 就业市场已经给出的答案
- 哪些能力反而升值
1. 先说结论（The Verdict）
结论分两层，而且这两层经常被混为一谈 👀。
第一层，动作层：替代已经发生。 写样板代码、补单元测试骨架、把一段 Python 翻译成 Go、给报错信息找根因——这些动作的边际成本已经被压到接近零。如果你的日常工作是「把明确的需求转成语法正确的代码」，那你被替代的不是职业，是工序。
第二层，职业层：替代没有发生。 2025 年美国劳工统计局（Bureau of Labor Statistics，BLS）的十年预测里，软件开发者的岗位数量预计从 2024 年到 2034 年增长 15.8%，绝对增量约 267,700 个，是所有职业平均增速（约 4%）的近四倍。
同一个市场，一边在砍初级岗，一边在加总岗位。这不是矛盾数据，这是结构在换血。
打个比方 🎭：电梯普及之后，电梯操作员这个工种消失了，但「盖楼」这个行业没有消失，反而盖得更多了。AI 现在扮演的不是「替代建筑工人」的角色，它更像电梯——把某一层工位整层拆掉，同时让楼能盖得更高。
2. 两组互相打脸的数据（The Contradiction）
先把最反直觉的两个数字摆在一起，因为几乎所有关于这个话题的争论，都在这两个数字之间来回撞墙 🧱。
2.1 2023 年：快 55.8%
Peng 等人在 2023 年做了一个随机对照试验（Randomized Controlled Trial，RCT），招募 95 名职业开发者，任务是「用 JavaScript 实现一个 HTTP 服务器，越快越好」。实验组可以用 GitHub Copilot，对照组只能用搜索引擎和 Stack Overflow。
结果是实验组平均快 55.8%（95% 置信区间内统计显著）：平均完成时间 1 小时 11 分，对照组 2 小时 41 分；任务完成率 78% 对 70%。
更值得注意的是分层结果：收益最大的是经验较少的开发者，资深开发者的提速幅度明显更小。这个细节后面会变得非常关键。
参考资料：
2.2 2025 年：慢 19%
两年后，METR（Model Evaluation and Threat Research）做了另一个 RCT，设计几乎是冲着上面那个实验来的：16 名资深开源开发者，在自己熟悉的仓库上处理 246 个真实 issue，随机分配「允许用 AI」和「禁止用 AI」。工具有 Cursor Pro 加 Claude 3.5/3.7 Sonnet。
三方预测全部偏乐观，实测全部相反：
同一批人在做完任务之后，主观感受是「AI 让我快了 20%」，客观计时是「慢了 19%」。主观与客观的偏差达到约 39 个百分点，而且这个偏差不是随机噪声，是系统性的方向错误。
参考资料：
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity -- arXiv ⭐值得阅读
2.3 两个数字并不冲突
把两个实验的关键条件并排看，会发现它们测的其实是两件不同的事 ⚖️：
结论不是「谁造假了」，而是：AI 的收益强烈依赖于任务是否自包含、代码库是否陌生、人是否新手。三个条件同时有利时，你拿到 55.8%；三个条件同时不利时，你拿到 −19%。
3. 为什么「感觉快了」和「实测变慢」能同时成立（The Perception Gap）
这个问题比「AI 行不行」重要得多，因为如果连当事人都测不准自己快没快，那所有靠自评得出的效率结论都不可信。
3.1 不信任在涨，使用量也在涨
Stack Overflow 2025 年开发者调查（84% 的受访者使用或计划使用 AI 工具，较 2024 年的 76% 上升）给出了一个非常拧巴的画像：
- 46% 明确不信任 AI 输出的准确性（2024 年为 31%）
- 33% 表示信任
- 仅 3% 表示「高度信任」
- 使用率创新高，信任度创新低
参考资料：
这不是「大家嘴上骂手上用」这么简单。它说明开发者已经把 AI 当成一个默认不可信、必须复核的外部依赖——而这个复核动作的成本，通常不计入「我用 AI 省了多少时间」的自评里。
3.2 验证成本是隐藏账单
Ziegler 等人对 GitHub Copilot 的内部数据分析显示，代码建议的接受率大约在 27% 量级，即接近四分之三的建议被开发者当场丢弃。
参考资料：
被丢弃的那 73% 就是纯成本：生成、阅读、判断、删除。这部分时间在任何「AI 帮我写了多少行」的统计里都不会出现。
类比 🎭：这就像请一个语速极快但偶尔胡说的助手帮你记会议纪要。会议结束你拿到 10 页纸，看起来效率爆炸，实际上你要逐句核对哪句是他真听到的、哪句是他脑补的。核对时间不计入「纪要生成速度」，但它确实被花掉了。
3.3 一个可复算的推论
用 METR 的数字做一个粗算：假设一个任务原本需要 100 分钟人工完成。AI 让你在生成环节省下 24 分钟（开发者的预估值），但引入了复核与纠偏成本；最终实测耗时 119 分钟。那么隐含的复核成本约为 43 分钟，占原任务时长的 43%。
这个数字在不同任务上差别巨大，但它的存在方式很稳定：任务越难验证，复核成本越接近甚至超过生成成本。这就是为什么写测试用例比自己写业务代码更安全——测试天然自带验证器（跑一下就知道红绿）。
4. 一个任务级模型：可替代性四维（Four Dimensions）
既然「AI 会不会替代程序员」这个问法太粗，那就换一个能算的问法：这个具体任务，有多容易被替代？
我把它拆成四个可以主观打分的维度，每维 0 到 5 分 👇
4.1 规格确定性（Spec Certainty）
需求有多明确。5 分代表「输入输出格式、边界条件、异常处理都写清楚了」，0 分代表「先做出来看看，老板说要那种感觉」。
确定性越高，越容易被替代。 这是四个维度里权重最大的一项，因为 AI 最擅长的就是把明确规格翻译成实现。
4.2 验证成本（Verification Cost）
判断结果对不对要花多少力气。5 分代表「只能上线一周后看业务指标」，0 分代表「跑一遍单测就知道」。
验证成本越高，越难被替代。 注意方向：难验证不是 AI 的护城河，是人的护城河——因为必须有人承担「我认为它是对的」这个判断。
4.3 上下文耦合（Context Coupling）
任务依赖多少没写进代码里的隐性知识。5 分代表「改这里会踩到三年前某个客户的特殊约定」，0 分代表「一个独立的工具函数」。
耦合越强，越难被替代。 这类知识的载体是人脑和聊天记录，不在上下文窗口里。
4.4 责任归属（Accountability）
出了问题谁签字。5 分代表「涉及资金、合规、人身安全，必须有人负责」，0 分代表「错了重跑一遍就行」。
责任越重，越难被替代。 这是最被低估的一维：AI 可以给出方案，但不能承担后果。监管、合同、事故复盘，需要的都是一个可被追责的主体。
4.5 四个维度的组合直觉
把四维放在一起，能解释前面所有矛盾数据：
Peng 实验里的「从零写一个 HTTP 服务器」落在第一行，METR 实验里的「在自己仓库里处理真实 issue」落在第三、四行。同一批技术，风险等级差了两个数量级。
5. 一个能跑的替代性评分器（Runnable Scorer）
光靠嘴说四个维度很难对齐，把它写成代码就具体了。下面这段可以直接复制运行，只依赖标准库 🐍。
"""任务可替代性评分器：给定开发任务的四个维度打分，输出 AI 替代风险分（0-100）。
维度说明（每项 0-5 分）：
spec_certainty 规格确定性：需求写得越清楚越高
verification_cost 验证成本：判断结果对不对越费劲越高
context_coupling 上下文耦合：依赖的隐性知识越多越高
accountability 责任归属：出错后要人担责的程度越高越高
"""
from dataclasses import dataclass
# 四个维度的权重，合计 1.0；规格确定性权重最高，因为它最直接决定 AI 能否接手
WEIGHTS = {
"spec": 0.35, # 规格确定性
"verify": 0.25, # 易验证性（验证成本取反）
"coupling": 0.20, # 低耦合
"duty": 0.20, # 低责任
}
@dataclass
class Task:
"""一个待评估的开发任务。
属性:
name: 任务名称，仅用于输出展示
spec_certainty: 规格确定性 0-5
verification_cost: 验证成本 0-5
context_coupling: 上下文耦合 0-5
accountability: 责任归属 0-5
"""
name: str
spec_certainty: int
verification_cost: int
context_coupling: int
accountability: int
def score(task: Task) -> tuple[float, dict[str, float]]:
"""计算任务的 AI 替代风险分。
参数:
task: 待评估的任务
返回:
(风险分 0-100, 各维度归一化贡献字典)
数据流示例：spec_certainty=5 → 5/5 = 1.0 → 1.0 * 0.35 = 0.35
"""
parts = {
"spec": task.spec_certainty / 5, # 确定性越高，风险越高
"verify": 1 - task.verification_cost / 5, # 验证成本越低，风险越高
"coupling": 1 - task.context_coupling / 5, # 耦合越低，风险越高
"duty": 1 - task.accountability / 5, # 责任越轻，风险越高
} # 每项都归一化到 0-1
total = sum(parts[key] * weight for key, weight in WEIGHTS.items()) # 加权求和 0-1
return round(total * 100, 1), {key: round(value, 3) for key, value in parts.items()}
def verdict(risk: float) -> str:
"""把风险分翻译成人话判断。
参数:
risk: score() 返回的风险分
返回:
风险等级字符串
"""
if risk >= 75: # 高确定性 + 低验证成本 + 低耦合 + 低责任
return "高：AI 可以先出稿，人只做抽查"
if risk >= 45: # 至少有两维对 AI 有利
return "中：AI 做草稿，人做主要修改"
return "低：人主导，AI 只提供备选思路" # 多维不利，AI 只能当助手
TASKS = [
Task("写一个 CSV 导出函数", spec_certainty=5, verification_cost=1,
context_coupling=1, accountability=1),
Task("排查线上偶发死锁", spec_certainty=2, verification_cost=5,
context_coupling=4, accountability=3),
Task("设计跨部门权限模型", spec_certainty=2, verification_cost=3,
context_coupling=5, accountability=5),
]
for item in TASKS: # 逐个任务评估
risk_score, detail = score(item) # 得到风险分与维度明细
print(f"{item.name}：{risk_score} 分 → {verdict(risk_score)}")
print(f" 维度明细 {detail}\n") # 打印归一化后的四维贡献
实际输出：
写一个 CSV 导出函数：87.0 分 → 高：AI 可以先出稿，人只做抽查
维度明细 {'spec': 1.0, 'verify': 0.8, 'coupling': 0.8, 'duty': 0.8}
排查线上偶发死锁：26.0 分 → 低：人主导，AI 只提供备选思路
维度明细 {'spec': 0.4, 'verify': 0.0, 'coupling': 0.2, 'duty': 0.4}
设计跨部门权限模型：24.0 分 → 低：人主导，AI 只提供备选思路
维度明细 {'spec': 0.4, 'verify': 0.4, 'coupling': 0.0, 'duty': 0.0}
这个评分器的价值不在于分数准不准（权重是我拍的），而在于它逼你把「会不会被替代」拆成四个能被追问的问题。你答不出「这个任务的验证成本是多少」，就说明你还没想清楚自己在这件事里到底值钱在哪。
6. 症状 → 原因 → 解法对照表（Symptom Table）
下面这张表把日常可观察到的现象，直接映射到它的机制与应对动作。建议按「我最近最像哪一行」来读，而不是从头读到底 📋。
DORA 那组数字值得单独说清楚，因为它是目前少见的、按组织级指标测出来的负向结果：每 25% 的 AI 采纳度提升，对应交付吞吐量约 1.5% 的下降和交付稳定性约 7.2% 的下降（稳定性由变更失败率与返工率构成）。
参考资料：
这里必须给一个反直觉取舍的理由：为什么吞吐量只掉了 1.5%，稳定性却掉了 7.2%，两者差了近五倍？因为 AI 主要压缩的是「写」这一段，而吞吐量的瓶颈通常在后半段——评审、联调、发布、灰度。稳定性则直接暴露在「写」的产出质量上，所以它对 AI 的边际变化最敏感。这个不对称本身就是判据：哪一段是你的瓶颈，AI 就在哪一段失效。
7. 就业市场已经给出的答案（The Labor Signal）
讨论到这里，可以离开实验室数据看真实市场了。市场给出的答案比任何一篇论文都直接，而且分层极其明显 💼。
7.1 入口层在收缩
Brynjolfsson、Chandar、Chen 三位用美国最大的薪酬软件供应商的行政数据（覆盖数千万雇员）做了分析，结论是六条事实，其中最刺眼的一条是：生成式 AI 广泛采用之后，AI 暴露度最高职业中 22 至 25 岁的早期职业者，就业相对下降 13%（已控制企业层面的冲击）；而同一批职业中经验更丰富的从业者，就业保持稳定甚至继续增长。
参考资料：
注意 13% 的口径：「相对下降」是相对于低暴露职业的对照组，不是绝对失业率。不同二手报道在绝对降幅上给出过更大的数字，但论文本身的可复算口径是 13% 的相对降幅。
7.2 总量层在扩张
同一时间，BLS 的十年预测给出的是增长：软件开发者岗位 2024 至 2034 年预计增长 15.8%，绝对增量约 267,700 个，行业基数在 2024 年约为 169 万人。作为对照，全美所有职业的平均预测增速约为 4%。
把两条放在一起，得到的不是「程序员要消失了」，而是金字塔的底座被抽走、中上层被加厚。这个结构的后果比「消失」更难处理：入口消失意味着没有人再通过打杂成长为资深。
类比 🎭：这像一家餐厅把学徒岗全部取消，只留主厨。短期看成本降了、出菜没受影响；三年后发现没人能接主厨的班，因为主厨是学徒熬出来的。
7.3 需求侧在改口径
招聘市场的变化比就业统计更快。2026 年对约 4.5 万条软件工程师在招岗位的分析显示，明确提到新一代生成式 AI 技能的比例约 20.5%，若把传统机器学习算进来则升至约 28.3%。
2026 年 3 月《财富》杂志把一类新角色称为「supervisor class（监督者阶层）」：他们的主要价值不再是写代码，而是编排写代码的 agent、审查产出、做高层架构决策。Karpathy 在 2026 年的 Sequoia Ascent 上把这个转向讲得更直白——他把自己 2025 年 2 月提出的 vibe coding（氛围编程）划给「所有人的下限工具」，而把专业软件需要的部分改称 agentic engineering（智能体工程）：你可以更快，但你依然要为软件负责，不允许因为「氛围」引入漏洞。
参考资料：
- Sequoia Ascent 2026 summary -- karpathy ⭐值得阅读
- AI Agents Are Now in 1 in 10 Software Engineer Job Postings -- InterviewStack
8. 哪些能力反而升值（What Appreciates）
如果四维模型成立，那「升值的能力」不需要靠猜，直接取四个维度的补集就行 🎯。
8.1 规格能力：把模糊需求变成可验证表述
规格确定性是权重最高的一维，而它的供给方是人。能把「老板说要那种感觉」翻译成「输入 3 类、边界 5 条、异常 2 种、验收标准 4 项」的人，在任何 AI 工具面前都是稀缺的。
这也是为什么 prompt 技巧本身在贬值、而需求拆解在升值：前者是让 AI 听懂你，后者是让你自己先想清楚。
8.2 验证能力：设计「跑一下就知道对不对」的关卡
前面的推论已经算过账：任务越难验证，复核成本越接近生成成本。所以能把难验证的任务改造成易验证的人，直接吃掉了那笔隐藏账单。
具体动作很朴素：写契约测试、造最小复现、把灰度指标提前定义好、把「我觉得对」换成「这个断言通过」。这类工作从前被看作杂活，现在是杠杆最高的位置。
8.3 上下文能力：把隐性知识显性化
上下文耦合是 AI 最难攻的一维，但它的壁垒性质很尴尬：它保护的是「知道这件事的人」，而不是「这个人所在的公司」。一旦隐性知识被写成文档、ADR（Architecture Decision Record，架构决策记录）或测试用例，它就从人的护城河变成了组织的资产。
所以更准确的说法是：懂隐性知识的人短期升值，长期任务是把这份知识交出去，然后换到下一层隐性知识上去。
8.4 责任能力：成为能签字的那个人
责任归属是唯一一维 AI 在结构上无法接管的东西。不是因为模型不够强，而是因为它不能成为被追责的主体——监管、合同、事故复盘都需要一个能承担后果的人。
这意味着「能签字」本身就是一种稀缺资源，而签字资格来自可追溯的判断记录：你过去做的技术决策、你留下的复盘、你在关键节点说过的话。
8.5 一个诚实的反面
最后要说清楚不适用的场景，否则前面全是在自我安慰 ⚠️：如果你的工作长期停留在「规格明确、验证便宜、耦合很低、责任很轻」象限内，那么四维模型给出的结论就是高替代风险，而且这个结论不会因为你把它读成励志文而改变。
真正的选择只有两个：往四维中的任意一维上移，或者接受这个工序正在被压缩的事实并提前换道。前者需要时间，后者需要勇气，两个都不轻松。
决定某个环节要不要接 agent，先用第 4 节四维打分：规格确定、验证便宜、耦合低、责任轻的直接上；需要有人签字的，AI 只能出草稿。
本专栏《AI开发范式》聚焦 AI 进入工程流程后的真实约束——接口可靠性、成本控制、任务可替代性与协作方式变化，每篇配一段可直接运行的代码或一份判据表，每月更新两到三篇。想按顺序读完，可在专栏页订阅。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Full summary: The replacement of "writing code" has already taken place, and the replacement of "programmer" has not taken place in verifiable data. In 2023, the control experiment measured 55.8% speed, and in 2025 the control experiment measured 19% slower, and both figures were true. The difference is not AI, it's not okay, it's mission shape, people's qualifications and verification costs. This paper uses a runable task scorer to break "will not be replaced" into four scoring dimensions.
Contents
- Let's start with the conclusion.
- Two sets of face-to-face data.
- Why does "fright" and "real slow" work together?
- A mission-level model: alternative 4D
- An alternative scorer to run.
- Symptoms, cause, solution comparison.
- The answers given by the job market.
- What's going on?
1. First conclusion (The Verdict)
The conclusions are two layers, and they are often confused.
Level one, action level: replacement already occurs. Write template codes, patches to test skeletons, translate a piece of Python into Go, find a reason for the error information -- the marginal cost of these actions has been pushed to near zero. If your day-to-day work is "to translate a clear demand into a code that is grammatically correct," then you are replaced not by a profession, but by a process.
Second, occupational: substitution did not occur. In a 10-year projection by the United States Bureau of Labor Statistics (BLS) in 2025, the number of software developers is expected to grow by 15.8 per cent from 2024 to 2034, with an absolute increase of approximately 267,700, nearly four times the average rate of growth for all occupations (about 4 per cent).
In the same market, while cutting off junior posts, they are adding general posts. It's not contradictory data. It's structure in blood exchange.
Example: After the elevator spread, the elevator operator disappeared, but the building industry did not disappear, but it built more. AI is not now playing the role of "substitute construction worker" but is more like an elevator -- tearing down the entire floor of a certain floor and allowing the building to be built higher.
2. Two sets of face-to-face data (The Construction)
Let's put together the two most anti-intuitive numbers, because almost all the debate on this subject is between these two numbers and back.
2.1 2023: fast 55.8%
In 2023, Peng et al. conducted a random control test (Randomized Controlled Trial, RCT) to recruit 95 career developers with the task of " working with JavaScript to achieve an HTTP server as soon as possible". The team could use GitHub Copilot, and the control group could only use the search engine and Stack Overflow.
The result was an average speed of 55.8 per cent (95 per cent of confidence intervals) for the experimental group: an average of 1 hour and 11 minutes for completion and 2 hours and 41 minutes for control groups; and a mission completion rate of 78 per cent versus 70 per cent.
More noteworthy are the tiered results: the greatest returns are from less experienced developers, who are significantly less rapid. This detail will become very critical.
References:
2.2 2025: Slow 19%
Two years later, METR did another RCT, designed almost immediately for the above experiment: 16 senior open source developers, handling 246 real issues in their familiar warehouses, randomly distributing "Apmissible" and "prohibited" AI. Tools include Cursor Pro plus Claude 3.5/3.7 Sonet.
The three-party projections are all optimistic and, indeed, counterproductive:
After the same group of people did the job, the subjective feeling was "AI made me 20% fast" and the objective count was "19% slow." The subjective and objective deviation reaches about 39 percentage points, and it is not random noise and is a systemic error in direction.
References:
- Measuring the Impact of Earthly-2025 AI on Experience Open-source Development -- arXiv
2.3 There is no conflict between the two figures
When you look at the key conditions of the two experiments together, you see that they actually measure two different things.
The conclusion is not "who faked" but: AI's proceeds are strongly dependent on whether the mission is self-inflicted, whether the code library is foreign, and whether people are beginner. You get 55.8% when three conditions are favourable; you get -19% when three conditions are unfavourable.
Why does "fright" and "real slow" work together?
The question is much more important than "AI can't do it" because if even the client can't measure himself fast, all self-assessment efficiency conclusions are not credible.
3.1 Increased mistrust and use
Stack OverFlow 2025 (84% of respondents used or planned to use the AI tool, up from 76% in 2024) gives a very twisted picture:
- 46% Explicitly distrusting the accuracy of AI output (31% in 2024)
- 33%, show confidence.
- Only 3% means "high faith."
- High usage and low confidence
References:
It's not as simple as "people scold their hands". It shows that the developers have taken AI as an external dependencies that are not credible by default and must be reviewed -- and the cost of this review exercise is usually not included in the self-assessment of how much time I saved with AI.
3.2 Certification costs are hidden bills
Internal data analysis of GitHub Copilot by Ziegler et al. showed that the acceptance rate for code recommendations was approximately 27 per cent, i.e. nearly three quarters of the recommendations were discarded by developers on the spot.
References:
The 73% that was abandoned was pure cost: generation, reading, judgement, deletion. This part of the time doesn't appear in any of the statistics about how many lines AI wrote for me.
Analogous: It's like asking an assistant who talks very fast but occasionally bullshits to take your minutes. At the end of the meeting, you get the 10 pages and it looks like they're going to explode, and you actually have to check every sentence he really heard and which one he built. The check time does not count as "the speed at which the minutes are generated" but it was spent.
3.3 A recalculated inference
Make a rough calculation using METR figures: assume that a task would have taken 100 minutes to do it manually. AI saves you 24 minutes at generation, but introduces review and correction costs; ultimately it takes 119 minutes. The implicit cost of the review would then be approximately 43 minutes, or 43 per cent of the duration of the original mandate.
This figure varies significantly from mission to mission, but it exists in a stable way: the more difficult the task is to verify, the closer the cost of the review will be, and even more, the cost of generating it. That's why it's safer to write a test example than to write a business code — to test a natural self-tasker.
4. A mission-level model: Alternative 4D (Four Dimensions)
Since the question of "AI will replace the programmer" is too crude, then the question is: how easy is this particular task to replace?
I split it into four dimensions that can be rated subjectively, 0 to 5 minutes per dimension.
4.1 Specific certainty
How clear is the need. Five points means "the input and output format, border conditions, unusual handling" and zero points means "first look, the boss says it's the feeling."
The higher certainty, the easier it is to be replaced. This is the largest of four dimensions, because AI's best at translating clear specifications into reality.
4.2 Verification Cost
How hard it takes to judge the outcome. Five points for "business indicators only a week later" and zero points for "show it through a single run."
The higher the cost of certification, the harder it is to be replaced. Note the direction: it's hard to verify that it's not an AI moat, it's a human moat -- because someone has to bear the judgement that "I think it's right."
4.3 context coupling
The task depends on a lot of hidden knowledge not written in the code. Five points for "replacement of a special contract with a client three years ago" and zero points for "an independent tool function".
The stronger the coupling, the harder it is to be replaced. The vectors of this knowledge are human brains and chat records, not in context window.
4.4 Attribution of responsibility (accountability)
There's a problem with the signature. Five points are "funds, compliance, personal security, someone has to be responsible" and zero points are "a wrong run again".
The greater the responsibility, the harder it is to be replaced. It's the most underrated dimension: AI can give a plan, but can't bear the consequences. Regulation, contract, and accident recurrence require a subject to be pursued.
4.5 Combined intuition of four dimensions
Putting four dimensions together explains all the contradictions in the front:
In the first line of the Peng experiment, "Book from zero a HTTP server", and in the third and fourth lines of the METR experiment, "Managing real issues in your own warehouse". In the same technology, the risk level is two orders of magnitude.
5. A runable alternative scorer
It's hard to match the four dimensions with the mouth alone. It's a specific code. The following section can be copied directly and only relies on the standard library.
An alternative scorer for a ""mission: score the four dimensions of the development task and output AI alternative risk score (0-100).
Dimension description (0-5 minutes each):
spec certainty specification certainty: the more needs are written
Validation cost: the harder to judge, the higher the result.
Context coupling context: The more hidden knowledge you depend on, the higher it is.
Attribution of responsibility: the higher the degree of responsibility the person is held responsible for the error
"""
from dataclasses import dataclass
# 4 dimensions weight, total 1.0; specification has the highest certainty weight as it most directly determines whether AI can take over
WEIGHTS = {
"spec": 0.35, # specification certainty
"verifiy": 0.25, # Visibility (certification cost reverse)
"coupling" : 0.20, # Low # - Yeah.
"duty": 0.20, # Low responsibility
}
@dataclass
class Task:
A development mission to be evaluated.
Properties:
Name: Task name, only for the output presentation
spec certainty: specification certainty 0-5
Validation cost 0-5
Contact coupling: context coupling 0-5
aaccountability: attribution 0-5
"""
name: str
spec_certainty: int
verification_cost: int
context_coupling: int
accountability: int
def score(task: Task) -> tuple[float, dict[str, float]]:
""calculates the AI alternative risk score for the mission.
Parameters:
task: To be evaluated
Return:
(Risk score 0-100, Dictionary of contribution at each dimension)
Example of data stream: spec certainty=5 →5/5 = 1.0 *1.0 *0.35 = 0.35
"""
parts = {
"spec": task.spec certancy /5, # higher certainty, higher risk
"verify": 1 - task. Verification cost/ 5, # The lower the cost of validation, the higher the risk
"coupling": 1 - task.context coupling /5, # The lower the coupling, the higher the risk
"duty": 1 - task.accountability/ 5, # the lighter the responsibility, the higher the risk
♪ Everything's down to 0-1
* weight for key, weight in WEIGHTS.items() # weighted sum 0-1
return round(total * 100, 1), {key: round(value, 3) for key, value in parts.items()}
def verdict(risk: float) -> str:
""to translate risk into human judgment.
Parameters:
risk of return min
Return:
Risk Level String
"""
If risk > = 75: # High certainty + low validation cost + low coupling + low liability
"High: AI can write first, people only check."
# At least two dimensions for AI
Return "C: AI to draft, people to make major changes"
# Doppelganger, AI, only an assistant
TASKS = [
Task ("Book a CSV Export Function", spec certancy=5, verification cost=1,
context_coupling=1, accountability=1),
Task.
context_coupling=4, accountability=3),
Task.
context_coupling=5, accountability=5),
]
# Mission-by-mission assessment
Risk score, detail = score(item) # Get risk and dimension details
print(f"{item.name}: {risk score} →verdict(risk score}}”)
Print 4-D contribution after integration
Actual output:
Write a CSV export function: 87.0 minutes high: AI can start with a script, and people only do random checks
{'spec': 1.0, 'verify': 0.8, 'coupling': 0.8, 'ty': 0.8}
Queueline death lock: 26.0 cents
{'spec': 0.4, 'verify': 0.0, 'coupling': 0.2, 'ty': 0.4}
Design cross-sectoral permission model: 24.0 minutes Low: People-led, AI provides only alternative ideas
'spec': 0.4, 'verify': 0.4, 'coupling': 0.0, 'ty': 0.
The value of this scorer isn't just that it's a miscalculation, it's that it forces you to break "can't be replaced" into four questions that can be asked. You can't answer "what is the cost of this mission," which means you haven't figured out what you're worth in this.
Symptom Table
The following table directly maps the mechanisms and responses to the daily observed phenomena. It's suggested to read "what I've been most like lately" instead of reading from the beginning.
The DORA figure deserves to be singled out because it is a negative result, currently rare, measured by organizational indicators: an increase in AI adoption per 25 per cent, a decrease in delivery throughput of about 1.5 per cent and a decrease in delivery stability of about 7.2 per cent (stability consisting of change failure and return rates).
References:
Here's a reason to give a counter-intuitive alternative: why is it only 1.5%, and stability 7.2%, almost five times the difference? Because AI mainly compresses the "write" section, while the bottlenecks in the volume of throughput are usually in the latter half - evaluation, intercomment, publish, greyscale. Stability is directly exposed to the quality of "writing" output, so it is most sensitive to marginal changes in AI. And this asymmetricality is the rule in itself: which is your bottleneck, which is which AI is not.
7. The Labor Signal
So here we are, we can leave the lab data for the real market. The market's answer is more direct than any paper, and it's very visible at the level.
7.1 The entrance level is shrinking
Brynjolfsson, Chandar, Chen, and three of America's largest paid software providers (covering tens of millions of employees) analysed and concluded that six facts were the most striking of which were the relative decline of 13 per cent in employment among early occupations between 22 and 25 years of age, following the widespread adoption of Generating AI, while employment remained stable and even continued to grow among more experienced practitioners in the same professions.
References:
Note that the 13% calibre "relative decline" is a control group relative to low-exposure occupations, not an absolute unemployment rate. Different second-hand reports give a larger figure in absolute drops, but the recalcitrant calculator of the paper itself is a 13% relative drop.
7.2 Volume Levels are expanding
At the same time, the BLS 10-year projections show growth: software developers are expected to grow by 15.8 per cent in 2024 to 2034, with an absolute increase of approximately 267,700, and an industry base of about 1.69 million in 2024. In contrast, the average projected increase for all occupations in the United States is about 4 per cent.
Put the two together, it's not "programmers are going to disappear", it's the bottom of the pyramid that is removed and the upper middle is thickened. The consequences of this structure are more difficult to deal with than "disappearing": the disappearance of the entrance means that no one will grow into a senior by doing so.
Similarity: It's like a restaurant that cancels all apprenticeships and leaves the chef alone. The short-term cost has been reduced and the food has not been affected; three years later, no one has been able to take over the chef, as the chef has survived the apprenticeship.
7.3 Demand side is changing calibre
The recruitment market changes faster than employment statistics. An analysis of the recruitment of approximately 45,000 software engineers in 2026 showed that the percentage of explicit references to a new generation of generated AI skills was about 20.5 per cent, rising to about 28.3 per cent if traditional machine learning was included.
In March 2026, The Fortune magazine called a new type of role "subvisor class": their main value is no longer code writing, but agent, reviewing outputs and making high-level institutional decisions. Karpathy, on Sequoia Ascent in 2026, put this turn more clearly -- He assigned his proposed vibe coding in February 2025 to "the floor tool for everyone" and changed the part of his professional software requirements to "agentic engineering" (AI agent Project): You can be faster, but you are still responsible for the software, and you are not allowed to introduce loopholes because of the atmosphere.
References:
- Sequia Ascent 2026 Summary-karpathy worth reading.
- AI Agents Are Now in 1 in 10 Software Engineer Job Postings -- InterviewStack
8. What increases capacity
If a four-dimensional model is established, the ability to appreciate doesn't have to be guessed, just to take a four-dimensional supplement.
8.1 Specification capabilities: Translating vague requirements into verifiable representations
Speculation certainty is the highest dimension of weight, and its supplier is human. A person who can translate "the boss says that he wants that feeling" into "input 3 categories, 5 boundaries, 2 anomalies, acceptance criteria 4 sections" is scarce for any AI tool.
This is why the prompt technique itself is devalued and demand is debunking: The first is for AI to understand you, the second is for you to think for yourself.
8.2 Validation capability: Designed to "get to know" Cut.
The previous inference has already been accounted for: the more difficult the task is to verify, the closer the cost of review is to generate costs. So it was possible to change the hard-to-test assignment to an easy-to-test person and to eat the hidden bill.
The actions are simple: writing contract tests, making minimum recurrences, pre-defined greyscale indicators, replacing "I feel right" with "this claim is passed". This type of work was once seen as a chores, and is now the most leveraged position.
8.3 context Capacity: Visibility of hidden knowledge
The context coup is one of the most difficult dimensions of AI, but its barrier is embarrassing: it protects "the person who knows about this" rather than "the company where this person belongs". Once hidden knowledge is written into a document, ADR (Architection Regulation Record, Structure Decision Record) or a test example, it turns from a human moat to an organizational asset.
So, more precisely, people with hidden knowledge appreciate in the short term, and the long-term task is to turn that knowledge out and switch it to the next level of hidden knowledge.
8.4 Liability: becoming the person who can sign
Accountability is the only dimension of AI that structurally cannot take over. Not because the model is not strong enough, but because it cannot be the subject of accountability — regulation, contract, accident recurrence — a person who can bear the consequences.
This means that "can sign" is in itself a scarce resource, and that signature qualifications are derived from retrospective judgement records: the technical decisions you made in the past, the duplicates you left behind, what you said at the key nodes.
8.5 An honest negative.
Finally, let's make it clear what's not applicable, or it's all about consolation. If your work stays within a "specified, inexpensive, low-coup, low-responsibility" radius, then the four-dimensional model's conclusion is a high substitution risk, and it will not change because you read it into an inspirational text.
There are only two real options: moving up to any one of the four dimensions, or accepting the fact that the process is being condensed and moving ahead. The former takes time, the latter takes courage, and neither is easy.
To decide whether or not to take up a particular link, we will start with a four-dimensional score from section 4: specification-setting, validation, low-cost, low-cost, low-responsibility directs; if someone has to sign, AI can only draft.
This column, " AI Development Model ", focuses on the true constraints of AI following entry into the engineering process - interface reliability, cost control, alternative and collaborative changes for tasks, each with a direct running code or a statement, updated two to three times a month. To read in order, you can subscribe to the column page.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.