加载失败
讨论来自一篇题为“Writing code is cheap now”的观点文章与相关评论，核心争论是：LLM 与 agentic engineering（用 AI 代理自动生成、测试与修改代码的做法）将从想法到运行代码的边际成本显著降低，但软件的设计、审查、维护与业务知识成本并未同步下降。评论引用了技术博客与实务案例来讨论影响层面，包括 OpenClaw（被引用为快速商业化的示例）、Cloudflare（CDN/网络服务商）在引入自动化后出现的故障以及个人在 Anki 上用 Claude Code（Anthropic 的模型/工具）即时改功能的经验。参与者基于对算力、tokens、FOSS 维护负担与组织问责的观察，讨论是否需要从语言、架构到交付与支持流程进行系统性重构。整体结论倾向于：生成变便宜改变了“输入”，但长期价值仍取决于设计、维护与组织能力。
评论普遍认为生成代码的原料已变廉价，但关键在于如何指挥这些“廉价输入”产生真实价值。社区把这种做法称为 agentic engineering（用 AI 代理自动生成、测试与修改代码的实践），强调新的核心技能是设计指令、设定约束并审查代理输出以达成可用产品。有人指出可用模式化流程（例如把代理置于测试优先的 red/green TDD 流程）来提升质量，但要落地需要新的个人与组织习惯。总体结论是：写代码变便宜了，但能把产出变成可靠产品的“指挥与验证”能力更稀缺且更值钱。
多条评论强调敲代码本身并非软件工程最有价值的部分，真正的难点在于系统设计、性能、安全和处理边缘情形，这些都依赖经验和判断力。维护成本仍随代码行数与系统复杂度增长，FOSS 维护者面临的审查负担上升，而彻底审查 AI 生成代码的工作量往往不亚于手写代码。已有实例被引用来说明风险，例如在引入 AI 自动改写后出现的关键服务故障，提示自动化改写关键基础设施可能带来运营隐患。由此产生的结论是：写出来便宜的代码可能会生成新的长期负债，整体工程成本未必下降。
有人主张不仅仅是改变个体工作习惯，而是要从问责机制、代码结构、语言设计到交付与支持流程全盘重构，以承受突增的代码产量与代理化开发方式。评论指出当前下游环节（审查、测试、部署、运营支持）尚未准备好接纳大量自动生成的代码，如果仍按旧流程高速交付会产生瓶颈与风险。也有观点认为市场竞争会筛选出采用效果好的公司，但多数评论倾向于必须系统性改革才能真正受益，否则只是把问题往后推。整体讨论强调“如何组织”和“谁负责”成为关键议题，而不是单纯的生成速度。
多数评论承认在某些场景下编码代理和 LLM 能提高产出，但对“十倍提升”的说法普遍持怀疑态度，认为真实提升多数处于个位数到几十个百分点。评论里提到有快速成功的案例（例如短期内完成并对外展示的项目），但这些往往是原型或样本较小的情形，长期可维护性与质量仍有疑问。低产出同事在 AI 帮助下确实能提升工作量，但同时带来更多审查和修正工作，长期可持续性与替代高素质工程师仍不明确。
许多评论把廉价生成的代码比作廉价消费品：能快速大规模生产但质量、寿命与可维护性不足，容易产生大量技术债。商业领导者常以季度导向追求“快与便宜”，LLM 工具的可用性可能被滥用来快速发布功能，从而放大未来的修复成本与风险。若把代码视为负债，那么便宜制造更多代码实际上会拖慢未来迭代并增加运维负担。总体担忧是大量“可用但尴尬”的产品会充斥市场，长远代价高于短期收益。
评论普遍指出写代码变容易并不等于理解业务逻辑、边缘情况与系统交互也变容易，很多时间仍花在与利益相关者沟通、查证规则和试错上，这些知识并未被自动化取代。因此职业路径会发生变化：初级岗位可能被压缩，而经验工程师更多转向审查、诊断、系统设计和监督 AI 代理的角色。飞行自动化的类比被多次提及：自动系统能处理正常场景，但一旦出现异常仍需要人类介入处理。总体上工作重心从“敲代码”转向“审查与决策”。
部分评论设想将小型或本地 LLM 嵌入应用，使其按用户使用动态调整或为每个用户提供专属代理，从而实现高度个性化体验。批评者指出若每个用户拥有不同代码或行为变体，将带来巨大的支持成本与安全一致性问题，难以为规模化产品提供可维护的客服与合规保证。有实际例子提到在个人工具（如记忆卡应用）上用 Claude Code 即时增加功能，带来即时价值但 UX 易碎且需频繁修复，体现出个性化与可支持性的矛盾。讨论亦触及代理之间通信协议、数据存储与是否会改变传统浏览器/GUI 的使用模式等系统性问题。
反对者提醒不要忽视模型训练与推理的实际成本：tokens（用于 LLM 的计费单位）与算力并不免费，创业公司短期内会抢占云端资源，真实成本与外部性仍有不确定性。有人提出我们已将大量投资与供应链重定向用于自动化代码生成，长期负担可能由社会承担而非仅反映在个人订阅费上。尽管历史上算力趋势长期走低，但短中期的成本、容量与商业模型仍会影响普及速度与可持续性。评论因此呼吁把注意力从纯粹生成速度转向总体经济与运营成本。
有人提出廉价代码生成使得快速做出可丢弃原型变得可行，从而能在短时间内尝试多种实现来验证思路。但真正昂贵的仍然是决策流程：发现边缘案例、理解监管/业务限制以及将个人试错转化为组织知识的过程并未因自动生成代码而便宜。结论是生成更多原型可以加速探索，但并未显著降低长期维护、合规或产品成熟所需的投入，最终仍需人为判断何时达到“刚好够用”。
部分评论把代码生成与 AI 图像相类比：产量激增并不必然带来同等规模的有意义或受众认可的产出。大量低价值或相似的生成物会稀释注意力并增加筛选与评审成本，真正有价值的软件或艺术品仍然稀缺。因此仅靠更低的生成门槛并不能自动增加社会上有意义的产出量，需要配套的过滤、评价与设计流程来把产出转化为长期价值。
Agentic engineering（代理工程 / agents）: 用 AI 代理（agents）自动生成、测试、修改并递归改进代码的一整套实践，核心在于如何设计指令、约束边界与审查代理输出以达成可靠结果。
LLM (Large Language Model， 大型语言模型): 用于生成自然语言与代码的深度学习模型，能够根据提示生成文本/代码，常以 tokens 计费并依赖大量算力。
tokens: 在 LLM 输入/输出与计费中使用的基本单位（通常是子词或字符片段），生成或处理的 tokens 越多，推理成本越高。
FOSS (Free and Open Source Software): 自由开源软件生态与项目，维护者多为志愿或有限资助，因 AI 生成的 PR/补丁增多而面临更大审查与维护负担。
SRE (Site Reliability Engineering): 负责生产系统可靠性、运维与可观测性的工程实践与岗位，讨论中提到自动化可能改变 SWE 与 SRE 的职责与就业稳定性。