加载失败
文章主张在 LLM/agent 浪潮下，“设计”比逐行编码更重要，作者认为 AI 使得为自身问题量身定制的小型代码库可行，从而削弱了传统框架的必要性。评论区围绕几条主线争论：一是 agents 在实际现场（如 AWS re:Invent 的 SRE agents 演示）与个人项目中确有提速；二是生产环境的安全、状态恢复与问责带来严重担忧；三是实践层面要涌现新技能（prompt 工程、agents.md、测试与多模型互审）。讨论中多次引用具体模型与术语：Claude / Opus（Anthropic 的大模型与版本）、Gemini（Google 的模型）、tokens（计费单位）和 temperature（采样随机性），并区分单人业余项目与高风险企业级系统的不同适用性。
一部分评论者用现场演示与亲身经验证明 LLM/agents 能显著提升工程效率：在 AWS re:Invent 上有 SRE agents 三人组示例（一个读日志、一个分析/分级、一个提交 PR）在几分钟内定位并修复引入的 bug。多位独立开发者报告用 Gemini/Claude 把原本要花数周或数月的“繁琐工作”压缩为几天到几周，并用 LLM 做 pair-programming、写测试、探索多种实现策略。实务者把 LLM 当作“快速打字的初级工程师”（jr dev），在 IDE 深度集成后能迅速原型、生成调试器或数据处理脚本，从而把精力放在设计与验证上。总体结论是：熟练使用这些工具的工程师能把重复劳动与样板化工作自动化，从而把生产力成倍放大。
很多评论强调 LLM 生成代码在安全和可审计性上存在实质性风险：自动生成的代码常会漏掉认证/授权检查（有人举例指出几乎能看到无校验的 POST /api/create/admin 接口），并且当 bug 导致数据库处于未知状态时，即便后续把代码修好，业务状态与数据恢复仍可能不可逆。线程中有真实项目回顾：用 prompts 快速替换遗留系统在短期可行但长期因为 subtle 回归、测试覆盖不足与 token 成本问题被放弃，显示出生产环境下微妙错误难以由 AI 自动检测并回滚。更严重的是责任链模糊——当核心逻辑来自“黑盒”模型，事后追责与取证变得困难，这在金融／医疗等高风险领域尤为致命。
另一批评论认为框架与库依然是工程中的重要资产，LLM 在常见框架（如 Django、React、Flask）上表现更好，因为训练数据中充斥这类范式。框架带来的共享心智模型、社区维护、安全补丁与文档是自造轻量替代品难以复制的长期价值；多人协作时统一框架还能显著降低对接与上下文切换成本。实务经验指出，让 LLM 生成对既有框架友好的代码通常比让它完全重写基础设施更高效且更容易审查，因此更常见的做法是把 agents 当作“会用框架的助手”而非完全替代框架本身。
一部分评论明确警告存在“粗暴觉醒”情形：依赖 vibe coding（把大量实现留给 LLM 而不深入理解系统） 的开发者和企业在遭遇复杂故障或合规要求时可能面临生存威胁。支持者引用模型的不确定性、掌握度下降的研究结果，以及近期模型（如 Opus/Claude 的不同版本）表现的不稳定性来证明风险的现实性。担忧还包括岗位弃守——管理层会以更低成本替换部分工程岗位，从而导致失业或职业重整。评论同时提到这不是必然结局，但若不坚持审计与工程原则，后果可能严重。
讨论多次回到组织层面的硬现实：LLM 的 token 计费、订阅费和会计周期（一次性 vs 分摊）会直接影响项目可行性。实战案例显示短期用 prompts 快速交付能节省时间，但长期看 token 成本、回归调试与维护支出会复杂化总成本评估，导致一些项目被弃用或搁置。另有观点指出企业管理通常更看重短期交付与度量（KPI），代码改善与长期健康常被忽视或难以拿到预算，从而限制 AI 在工程化阶段的长期收益。综上，AI 工具的价值不仅取决于模型能力，也与公司文化、会计与预算机制密切相关。
不少评论认为真正的变革是方法论层面：工程师需要把重心从逐行编码转到架构设计、prompt 工程、agent 协调与测试自动化（例如维护 agents.md、并用 git worktrees 或 conductor 同时驱动多 agent）。具体实践包括用 agent 专门做 code-smell 检查、写测试用例并让不同模型互相验证输出，以及把代码保持为可信的 source-of-truth 来降低模型幻觉的风险。确定性讨论（temperature、T=0）与多模型互审也被反复提出作为减少非确定性输出、实现可重复性的手段。总体看，prompt 设计、测试与维护可审计流程成为新技能集，设计能力被认为比逐行编码更值钱。
vibe coding: 指大量把实现交给 LLM/agents、以自然语言快速生成可运行代码但不深入理解或建立长期架构的做法；讨论中把它视为易于原型但在生产或可维护性上存在风险的工作流。
agents / agentic programming: 由 LLM 驱动的自治代理（agents），能执行特定开发任务（例如读日志、分析错误、提交 PR 或重构），常与持续反馈回路、agents.md 等约定一起使用。
LLM: Large Language Model（大语言模型），用于生成自然语言与代码的核心模型，讨论中指代如 Claude、Gemini、Opus 等模型及其不同版本。
tokens: 用于衡量与计费 LLM 请求和响应长度的单位；token 消耗直接影响使用成本和工程决策。
temperature（T）: 控制生成随机性的采样参数；较高 temperature 导致更发散的输出，T=0 常被提到作为趋向确定性、减少幻觉的做法。
de-slopify: 线程中常用的俗称，指用工具或代理清理和改进原本混乱（sloppy）的代码库，使其更可读、更可维护；也有人担心 AI 会产生新的“slop”。
SRE: Site Reliability Engineering（站点可靠性工程），在讨论中以 SRE agents 的示例出现，强调运行时监控、日志与自动化修复的角色。