大家有没有觉得有了Vibe Coding之后工作轻松了不少，感觉大厂程序员的活小学生都能干
AI 编程工具如 Vibe Coding 极大地提升了开发效率，引发了关于程序员角色、就业前景、工作轻松度及责任归属的广泛讨论。尽管 AI 在 CRUD 和前端代码方面表现出色，但在复杂系统和多文件协作方面仍有局限，需要程序员具备扎实的专业知识、批判性思维和代码审查能力。AI 时代对 Product Sense 和清晰描述问题能力要求更高。新增观点认为，AI 提高生产力后，公司可能用一个程序员审查多个低效程序员的代码，暗示 AI 普及可能导致公司减少招聘，并加剧对就业市场和薪资的担忧。同时，有用户回顾了 20 年前 CS 行业被视为“夕阳产业”的历史，并认为 AI 时代既是挑战也是机遇，程序员应关注特定领域（如芯片代码）的发展，并警惕过度依赖 AI 生成代码，尤其是在 Bug 修复方面。
1. 关键信息
- (之前已归纳) 用户普遍认为 AI 辅助编程（如 Vibe Coding）显著提升了工作效率，甚至有人开玩笑说“小学生都能干”。
- (之前已归纳) AI 在处理 CRUD 和前端代码方面表现较好，但在复杂系统、细分领域（如 Linux Kernel、模拟器 QEMU/Gem5）或涉及多文件协作的代码生成上，仍存在细节错误、逻辑不通或单测不准的问题。
- (之前已归纳) 有用户尝试使用 AI 进行木工设计，发现 AI 在处理 SVG 和 3D 模型方面有一定能力，但对于拆解组装、缺口计算等复杂逻辑仍显不足。
- (之前已归纳) 有用户担心 AI 的普及可能导致大规模裁员，并出现“AI 替人背锅”的讨论。
- (之前已归纳) 有用户提出，程序员之所以抱怨辛苦，是因为他们常在社媒发声，声音较大，而其他职业也存在类似甚至更辛苦的情况。
- (之前已归纳) 用户认为 AI 辅助编程需要程序员进行代码审查和决策，否则项目质量会受影响。
- (之前已归纳) 当 AI 生成过多代码实例时，程序员会因无法全部理解和审查而感到压力，这与炸鸡排等无需动脑的食物不同。
- (之前已归纳) 用户 illusionwing 询问关于矢量图 LLM 的具体模型和方案，表明在特定领域（如 SVG 处理）对 AI 能力的进一步探索。
- (之前已归纳) 用户 258 推荐使用 Gemini 3.1 Pro 模型来处理复杂任务，并认为其在工程方面有提升，可能适用于 zero-shot 或工作流集成。
- (之前已归纳) 用户 AppleVisionPro 分享了因疏忽检查 AI 生成代码而导致数据库表被意外删除的惨痛经历，再次强调了代码审查的极端重要性。
- (之前已归纳) 用户 jzj 引用文章“AWS would rather blame engineers than AI”，暗示 AI 出现问题时，工程师可能成为替罪羊，这加剧了对程序员角色的担忧。
- (之前已归纳) 用户 msft 反驳了“小学生都能干”的说法，指出在开发复杂 UI 和调试 Bug 时 AI 仍有很大局限性，程序员需要大量投入。该用户还观察到 AI 加速了公司内部的“两极分化”和“pip coaster”现象。
- (之前已归纳) 用户 bujidao 提到等待 Claude Code 运行 token 的问题，暗示 AI 工具的效率可能受限于其处理速度。
- (之前已归纳) 用户 收束观测者 提出了与 AI 协作的新方法论：应让 AI 自我构建工作流并进行端到端测试，将其视为一个能自我测试的独立个体来协作，而非将其视为测试对象。
- (之前已归纳) 用户 vczh 认为 AI 时代就业机会减少，换工作的选择也随之变少，并强调程序员自身知识和能力的重要性，指出在不清楚如何做的情况下，AI 难以高质量完成任务。
- (之前已归纳) 用户 vczh 针对 AI 难以验证 Bug 的问题，提出了使用 UI Automation 或 Playwright 等工具进行自动化测试的解决方案。
- (之前已归纳) 用户 BigCummer 认为 Vibe Coding 可以取代大部分初中级 SDE，但高级 SDE 的把控方向作用更加重要，并担忧未来可能出现初中级 SDE 人才断层。
- (之前已归纳) 用户 Define_P 反驳了 BigCummer 的观点，认为实际上是许多水平较差的 SDE 正在利用 Vibe Coding 生成比自己手工编写更好的代码，暗示 AI 在提升低水平开发者能力方面有作用。
- (之前已归纳) 用户 maax 认为 AI 时代，Product Sense（产品感觉）和清晰描述问题的能力变得更加重要，而这恰恰是许多程序员所缺乏的。
- (之前已归纳) 用户 无名之辈 希望管理层能理解 AI 带来的工作变化。
- (之前已归纳) 用户 msft 认为，虽然 AI 提升了效率，但前期对 AI 进行端到端测试的工作量巨大，尤其是在需求不确定的高速试错阶段，并提出这可能更适合瀑布式开发而非敏捷。
- 新增：LeeKuanYew 提出，AI 提高生产力后，公司可能用一个程序员审查多个低效程序员（例如印度程序员）的代码，暗示 AI 普及可能导致公司减少招聘，并加剧对就业市场的担忧。
- 新增：vczh 认为，在 AI 时代，程序员最好的时间是 20 年前，当时人们普遍认为 CS 行业日薄西山，而现在 AI 带来了新的挑战和机遇。
- 新增：有用户提到，在 AI 辅助开发过程中，如果依赖 AI 生成代码，当出现 Bug 时，可能会面临“等别人修你的 Bug”的困境。
- 新增：有用户回顾了 20 年前 CS 行业被视为“夕阳产业”的历史，当时收入不高，甚至有人因此转行教书，但也有观点认为，当时需求不明确，缺乏互联网的放大效应。
- 新增：有用户提到，即使在“CS 行业日薄西山”的时期，国内也有像华为这样的公司提供了不错的机会，但当时收入天花板仍是谷歌和微软。
- 新增：有用户认为，写芯片代码的程序员虽然也面临危机，但情况可能比其他领域稍好一些。
- 新增：gogo 总结了 AI 编程工具的效率提升、对程序员角色和就业市场的影响，以及对代码审查、责任归属和 AI 协作模式的讨论。
2. 羊毛/优惠信息
- 无
3. 最新动态
- (之前已归纳) 有用户建议使用 Gemini 作为 SVG 处理的基座模型，认为其能力“断崖式领先”。
- (之前已归纳) 有用户分享了与 3D 打印相关的 GitHub 项目（mcp），并希望 AI 能够自主寻找、尝试并展示结果。
- (之前已归纳) 有用户在寻找“世界基础模型”的 API，但发现目前似乎没有可购买的 API，只能选择自建或本地部署。
- (之前已归纳) 用户 258 推荐 Gemini 3.1 Pro 模型，表明该模型在工程任务上可能有所提升。
- (之前已归纳) 用户 vczh 提出的使用 UI Automation 或 Playwright 进行自动化测试，为 AI 代码的验证提供了具体的技术路径。
- (之前已归纳) 用户 msft 提出的关于 AI 端到端测试工作量巨大的问题，以及对敏捷开发模式在 AI 时代适用性的质疑，是关于 AI 实践落地的新思考。
- 新增：LeeKuanYew 的观点反映了对 AI 影响程序员就业市场和薪资水平的即时担忧。
- 新增：vczh 对程序员职业生涯黄金时期的回顾，为理解当前 AI 时代程序员所处的环境提供了历史视角。
- 新增：关于 AI 生成代码的 Bug 修复责任归属和效率问题，是新增讨论的焦点。
- 新增：对过去 CS 行业发展历史的回顾，为理解当前 AI 带来的变化提供了背景信息。
- 新增：对芯片代码等特定领域程序员现状的提及，反映了行业内部分化和不同领域受 AI 影响程度的差异。
- 新增：gogo 的总结为讨论提供了一个最新的概括，强调了 AI 效率提升、就业担忧、历史视角和特定领域发展等关键点。
4. 争议或不同意见
- (之前已归纳) 有人认为 AI 只是让工作变轻松，但仍需要程序员具备编写和审查代码的能力，否则项目质量会下降。
- (之前已归纳) 对于 AI 在复杂系统开发中的能力持怀疑态度。
- (之前已归纳) 关于“AI 一个人干完一个组的活”的可能性存在疑问，认为“自己干完的别人可能大概率用不了，做了也白做”。
- (之前已归纳) 有人认为，如果一个人效率过高，可能会被团队排挤，就像在团队摸鱼时，一个人过于努力会显得格格不入。
- (之前已归纳) AI 辅助编程并非完全取代人工，程序员仍需承担审查和决策的关键角色。
- (之前已归纳) 用户 msft 认为“小学生都能干”的说法过于乐观，指出在复杂 UI 和 Bug 修复方面 AI 仍有很大局限性，程序员的投入不可或缺。
- (之前已归纳) 关于 AI 出现问题时，谁该承担责任（AI 还是工程师）的讨论，暗示了 AI 普及后可能带来的责任归属模糊问题。
- (之前已归纳) 用户 收束观测者 提出的 AI 协作方法论，与用户 msft 将 AI 视为“小弟”的观点形成对比，引发了关于如何定义和实现与 AI 协作的讨论。
- (之前已归纳) 用户 vczh 的观点与 BigCummer 关于 AI 取代初中级 SDE 的看法存在分歧，vczh 认为 AI 实际上是提升了低水平 SDE 的能力，而非简单取代。
- (之前已归纳) 关于 AI 时代就业前景的讨论，vczh 的“没公司给你换”的说法，与之前关于“AI 替人背锅”的担忧，共同指向了 AI 普及可能带来的就业压力和不确定性。
- (之前已归纳) 关于 Product Sense 在 AI 时代重要性的讨论，maax 认为这是许多程序员的短板，与 AI 辅助编程的效率提升形成了新的考量点。
- (之前已归纳) 用户 msft 对 AI 辅助开发在敏捷模式下的可行性提出了质疑，认为高速试错和需求不确定性使得前期 AI 测试工作量巨大，可能更适合瀑布模型。
- 新增：LeeKuanYew 的观点直接触及了 AI 对程序员就业市场和薪资水平的潜在负面影响，这是对“工作轻松”论调的直接反驳，并引发了关于公司可能如何利用 AI 来优化人力成本的讨论。
- 新增：vczh 对“最好的码农时间”的看法，与当前 AI 带来的挑战和机遇的讨论形成了对比，引发了对程序员职业发展历程的思考。
- 新增：关于 AI 生成代码的 Bug 修复责任和效率问题，存在“依赖 AI 可能导致 Bug 难以修复”的担忧，这与之前关于责任归属的讨论相呼应。
- 新增：对 CS 行业过去“夕阳产业”的看法，与当前 AI 带来的机遇和挑战的讨论形成了对比，引发了对行业周期性发展的思考。
- 新增：关于芯片代码等特定领域程序员受 AI 影响程度的看法存在差异，有观点认为相对较好，但也有危机感。
5. 行动建议
- (之前已归纳) 持续关注 AI 在编程领域的进展，并根据自身情况调整技能发展方向。
- (之前已归纳) 在使用 AI 工具时，仍需保持批判性思维，并对生成的代码进行严格审查和测试。
- (之前已归纳) 对于复杂的、非 CRUD 类的编程任务，AI 的辅助效果可能有限，需要谨慎评估。
- (之前已归纳) 对于需要精细逻辑和规则的领域（如木工设计），可以考虑将规则 hardcoding 成工具，并期望 AI 能够辅助生成这些工具。
- (之前已归纳) 如果 AI 无法自主解决问题，可以尝试通过 API 调用或本地部署更强大的模型来辅助开发。
- (之前已归纳) 程序员在接受 AI 辅助的同时，应明确自身在代码审查和决策中的核心价值，避免因 AI 生成过多内容而导致工作压力过大。
- (之前已归纳) 用户 illusionwing 对特定领域（如 SVG 处理）的 AI 方案表现出探索兴趣，提示关注特定领域 AI 工具的发展。
- (之前已归纳) 用户 258 推荐 Gemini 3.1 Pro，建议尝试使用其处理复杂任务，并探索其在 zero-shot 或工作流中的应用。
- (之前已归纳) 用户 AppleVisionPro 的经历警示，务必对 AI 生成的代码进行严格审查，避免潜在的严重后果。
- (之前已归纳) 用户 jzj 和 msft 的评论表明，AI 普及可能加剧行业两极分化，并可能导致工程师在出现问题时承担不公平的责任，因此程序员应提升自身不可替代的技能，或适应与 AI 共存的新工作模式。
- (之前已归纳) 用户 收束观测者 提出的 AI 协作新方法论，建议将 AI 视为一个能够自我构建工作流并进行端到端测试的独立个体，这为如何更有效地利用 AI 提供了新的思路。
- (之前已归纳) 用户 vczh 的观点提示，程序员应持续提升自身的核心能力，尤其是在对解决方案不确定时，AI 无法替代人类的专业判断和高质量输出。
- (之前已归纳) 用户 vczh 提出的自动化测试方法（UI Automation, Playwright）可作为实践建议，用于提高 AI 生成代码的验证效率和准确性。
- (之前已归纳) 对于初中级 SDE，AI 可能成为提升其能力和代码质量的工具，但同时也需要警惕 AI 带来的就业结构性变化和潜在的人才断层风险。高级 SDE 应继续发挥其在方向把控和复杂问题解决上的核心作用。
- (之前已归纳) 用户 Define_P 的观点暗示，AI 工具可能成为低水平开发者提升自身能力的“垫脚石”，这为如何利用 AI 进行技能再培训提供了新的视角。
- (之前已归纳) 在 AI 时代，程序员应着重培养 Product Sense 和清晰描述问题的能力，这有助于更好地与 AI 协作，并弥补 AI 在这方面的不足。
- (之前已归纳) 管理层需要理解 AI 对软件开发流程带来的转变，并可能需要重新审视敏捷开发模式在 AI 辅助开发中的适用性，考虑在需求不确定性高的情况下，如何平衡 AI 的效率与前期测试的投入。
- 新增：面对 AI 提高生产力可能带来的就业和薪资缩水担忧，程序员需要关注行业动态，并可能需要考虑提升自身不可替代性，或探索新的职业发展方向，例如成为能够高效审查和管理 AI 生成代码的“代码审查专家”。
- 新增：vczh 的观点提示，程序员应回顾历史，理解不同时期行业的发展特点，并根据当前 AI 带来的变化，调整自身职业发展策略，认识到 AI 时代既是挑战也是机遇。
- 新增：在 AI 辅助开发中，应警惕过度依赖 AI 生成代码，尤其是在 Bug 修复方面，需要为可能出现的“等别人修 Bug”的情况做好准备，并强调独立解决问题的能力。
- 新增：回顾 CS 行业历史，可以帮助程序员理解当前 AI 带来的变革并非孤立事件，而是行业发展周期的一部分，从而更理性地看待挑战和机遇。
- 新增：对于特定领域（如芯片代码），虽然 AI 带来危机，但仍可能存在相对较好的发展空间，建议关注这些细分领域。
以前还会因为写代码掉头发，现在就边吃零食边等代码生成
每天上班脑子都不用动，远程那几天坐家里边看视频边等Claude Code写代码。in office day坐下之后就打开Claude Code给指示，然后大多数时间都是在等Claude Code跑token，等的同时还能跟同事聊聊家常，感觉每天轻松了不少
接下来如果能拿人格训练个agent是不是就能进化到在家里睡觉拿工资了
是轻松多了，马上就没工作了，能不轻松吗
现在仍然需要你会写代码会读代码，不然项目会加速屎化
是的，还是得会写代码，只不过招的人少了
其实我确实不太懂，我自己的应用是那种轻前端重后端逻辑，也没什么crud的（比较细分领域，不是2c的），感觉claudecode和codex都写不太对，是有个大的框架但是细节不对或者单测不对或者bug修不对，不知道是不是我agent设计的不合理，还是就是对ai比较困难
写单点功能（文件级别的）在提示词很清晰的情况下还行，一旦涉及一些比较难的问题，或者复杂架构（十几个文件共同作用）就开始错了
有搞系统的朋友反映写系统方面的内容ai比较智障。我日常写crud和前端能处理得不错。
【引用自 xeraz】:
接下来如果能拿人格训练个agent是不是就能进化到在家里睡觉拿工资了
公司支付的工资减去训练所需 token 的能源和硬件成本的这部分，是在为什么买单？你的人格比隔壁只要一半工资的 John Doe 的人格值钱在哪里
我能想到的一点价值是替 AI 扛盆子，工资越高抗的 scope 越大，AI 翻大车了就把这个人抓进去吃牢饭
其实这种活很多，但只有程序员天天在网上说自己的活谁都能干。。。
我现在感觉和玩魔兽三人族第四关一样 survive for 30 minutes 然后等着乌瑟尔拿着大包进来裁了
我们公司要求每个人至少有4-5个instance同时在跑 感觉脑子根本不够用
有2个月甜蜜期，然后公司来了一波大裁员，我们组8个人裁到剩2人，然后我们2个要做8个人的工作 实在做不过来怎么办？公司直接印度csw 3个人，再让我们两个人来review代码
我自己想做一个木工ai
输入：想复刻的家具和尺寸
输出：木条怎么切，切几段。joinery细节。先组装哪个再组装哪个。
反复尝试Claude、Gemini 的API都是幻觉严重。他们告诉我要拆解，先生成线图，再图片渲染。但来来回回几轮，昨天几个小时花了$70 claude credit，还是没做出来，生成的图幻觉严重。组装过程也不合逻辑。快气死了。
真的假的，至少linux kernel和模拟器什么qemu gem5 啥的ai不说乱秒但至少大差不差 没试过那种更复杂的分布式
meta是了（非贬义）。
【引用自 打豆豆】:
木工ai
太麻烦了 不如上门服务
纯llm肯定没法做
svg推荐用gemini做基座模型处理 能力断崖领先
github.com
GitHub - OctoEverywhere/mcp: A free 3D Printing MCP server that allows for...
A free 3D Printing MCP server that allows for getting live printer state, webcam snapshots, and printer control.
github.com
GitHub - ahujasid/blender-mcp
通过在 GitHub 上创建帐户来为 ahujasid/blender-mcp 开发做出贡献。
帮你把标题的拼写错误改了，逼死强迫症。
svg claude给我找了个python库感觉还行，到了3d也还行。
但是拆解组装就很智障，唉。joinery缺口计算也有问题，心累
这个时候你需要的世界基础模型
那劳烦打老师指挥开发一个 直接上市
【引用自 打豆豆】:
joinery缺口计算也有
感觉还是要hardcoding rule 写成tools吧
一直就有人抨击程序员老在抱怨自己辛苦，很多其他职业的人也是996，甚至更苦，赚得还少。那还是程序员常在社媒上发声，声音大
有没有卷怪用LLM一个人干完一个组的活？
那个人会被全组集体排挤，就跟大家都一天摸8个小时鱼，你要从早上8点工作到凌晨1点
【引用自 258】:
GitHub - ahujasid/blender-mcp · GitHub
等周一试试这个，要是ai也能自主去找这些，然后自动分叉去试所有的，然后展示结果让我验证就好了
【引用自 AppleVisionPro】:
世界基础模型
搜了一下好像没有api能买，所以只能手搓或者本地部署吗（没设备啊，现在还是公司电脑挂载nas做开发）
【引用自 258】:
hardcoding rule 写成tools吧
要是ai也能告诉我怎么办就好了（我感觉工作中也是一样，有的事不知道要怎么做，ai也白瞎
【引用自 猎户葱】:
卷怪用LLM一个人干完一个组的活
真的可行吗，自己干完的别人可能大概率用不了，做了也白做
【引用自 打豆豆】:
ai
帮你穷举组合规则 写成固定的tool
没区别原来是写代码大头，现在是review占大头，毕竟你老板问你报告里数字正确不，你不能让AI做保证
没事，以后还是有机会把乌瑟尔屠了的
【引用自 YGintheHouse】:
每个人至少有4-5个instance同时在跑
要有这么多活才会有这么多instance 同时在跑呀，而且也是要交互的，不是一直跑
我现在办公室四个屏幕了 每天先和真人说话 然后和假人说话
代码可能30分钟就写完，review几小时都不一定，因为可能产生很多shi代码
也要看是什么活的，陈年老屎山显然不行，需要的context太多了，而且很多都是codebase以外的context（比如某个活领导喜欢/不喜欢，修改的代码是否染指了别人的地盘，infra的各种奇奇怪怪限制，这么写code的话reviewer会有什么意见。。。）
不轻松，因为老板知道现在你都是用AI了，不用自己写了
原来一周的ticket直接算成1-2天给你，然后老板自己还说一个电脑开几个session让AI跑
我是准备躺平，不和他卷，我一次就处理一个事情，让我git clone几个branch 本地run AI，我都不知道前面那个任务是啥了。他是聪明脑袋多线程思维，苦了我们这种average的人
AI以后更卷了
【引用自 xeraz】:
在家里睡觉拿工资了
尸化和员工有什么关系
公司倒闭换一家
确实，假如以前一天做3个tasks，现在一天要你做30个
【引用自 xeraz】:
每天上班脑子都不用动
现在人人都是TL，指导一堆AI干活。AI就跟以前的Junior和new grad一样，理直气壮地跟你说，这NMD能跑就行，凭什么要按照你的设计走。
但凡有一点需要探索的开放问题，AI抓到一个解决方案就跟落水一样紧抓不放。但是，如果我知道所有可能的解决方案，我为什么不让每一个session直接写一个PoC。
现在完完全全能感受到我当初虐待TL的感觉了。
【引用自 xeraz】:
感觉每天轻松了不少
综上，每天太累了，明明是IC。还要管理人，还是按小时结算的临时工。
【引用自 wotvod】:
我当初虐待TL
我干的没那么快
现在的AI确实代替了很多简单功能和prototype的实现，mid及以下的人存在的意义已经不大了。
社会治理并没有跟上AI发展的脚步，现今社会缺的是消费力而非生产力，财富加速向少数企业和人集中破坏了大众的消费能力。这些人拿了钱并不会拿来消费，只会继续扩大生产进一步收割形成垄断巩固自己的地位，造成了进一步的产能过剩，财富无法回流到具有消费能力的普罗大众手里。
所以说并没有解放劳动力，反而上面对出货效率的期望值越来越高了
感觉可以买爱马仕股票了，毕竟富人的消费最终还得通过奢侈品来回流到普通人身上。
感觉“2”跟翟东升的人本主义政治经济学挺像
说的太对了
虽然看起来让 AI 写代码很爽很方便，但当你看到 AI 已读乱回，“抓到一个解决方案就跟落水一样紧抓不放”——真是太对了
我感觉其实更稀缺的是我自己的心智负担——其实我能 reasonably 地和 LLM 交互的机会是有限的。纯粹写代码反而是更简单快乐
edit：md 我怎么自己打字都一股 AI 味，破折号不要钱一样
青蛙说水温稍微热一点好舒服啊。
是的，要 review，要 make decision；多了我也看不过来啊，4-5个 instance，那不用休息了，又不是炸鸡排，不用动脑子理解，做完你的做你的。。。
【引用自 258】:
svg推荐用gemini做基座模型处理
请教一下这是说哪个模型，现在有啥比较好的矢量图llm方案吗
Google – 19 Feb 26
Gemini 3.1 Pro: A smarter model for your most complex tasks
3.1 Pro is designed for tasks where a simple answer isn’t enough.
试一试3.1 Pro？ 似乎主要在工程上的提升
zero-shot可能就不错？或者用作工作流的一部分
某天我就这样, 几个instance生产的代码, 有一个忘了检查, 直接提交
把llm好死不死直接把我前一步的table 给drop掉了
theregister.com
AWS would rather blame engineers than AI
: Protect the robot, sacrifice the human
感觉这工作前景很好啊。
小学生还是够呛。前两天尝试vibecode一个所见即所得的markdown editor，费死劲了，一些奇奇怪怪的UI bug根本不好需要形容，ai也基本很难验证bug到底有没有修复，都得我去给他当小弟
在公司里，我觉得ai会加速两极分化，我们公司开始pip coaster了。
【引用自 xeraz】:
然后大多数时间都是在等Claude Code跑token
你们公司没有要求要同时跑5个claude么？
直接生成的svg code基本不行
我们现在是用特定的prompt和grid让nano banana生成满足要求的位图 然后手动ps转成矢量图
可以画一些简单的单个物体和绝大部份的单色图标
但是那种cover art级别的还得找artist做
那还行。不过我的应用需要比较精确的矢量图（有点像gcode那种感觉），这种基于trace的方案可能不是很适合，但是可以试试
现在做应用的门槛确实降低了不少，小学生能用 cursor 生成一个 CRUD 应用，但真正卡住的还是——出了问题怎么判断是模型的锅还是架构的锅？Vibe Coding 降低的是实现门槛，但 debug 和设计的门槛其实反而高了，因为要理解不是你自己写的代码。
程序员的活里最贵的那部分不是打字。
就连泥潭觉得最容易被替代的UI前端, 我觉得的ai还是差不少
很多组件qa的要求都是pixel perfect的, claude配合figma mcp可以做到70-90%, 但是剩下的20%还得人来干, 恰恰这部分是最耗时间的
还有html和css的神奇特性导致的一些让人都很摸不着头脑的bug, claude就更无能为力了
【引用自 msft】:
小学生还是够呛。前两天尝试vibecode一个所见即所得的markdown editor，费死劲了，一些奇奇怪怪的UI bug根本不好需要形容，ai也基本很难验证bug到底有没有修复，都得我去给他当小弟
这是方法论问题
你觉得费劲是因为你human in the loop去给AI当测试
你应该做的事情是应该让它给自己造轮子把workflow打通让它可以自己end to end测试
一旦打通以后飞轮就转起来了
你这个听起来是webapp那么你甚至不需要写新的mcp，直接找个现成的能操作浏览器的mcp接上就可以了
跟AI协作的基本原则很简单的：把AI当个人
你会去给一个写代码自己不测试的人当测试吗？
有道理，主要是现在我写research代码，不好定义unit test
有专门的写复杂系统的框架，不是简单的vibe coding，核心就是把复杂项目分解成简单明确的子项再让AI写码
马上就没工作了 更轻松啦
【引用自 flywire】:
公司倒闭换一家
已经没公司给你换了
【引用自 wotvod】:
但是，如果我知道所有可能的解决方案，我为什么不让每一个session直接写一个PoC。
是这样的，如果你自己都不知道怎么做，别指望AI能帮你高质量完成。纯vibe coding适合去写那种用户接受实现差的软件，比如最近就有一个新闻，AI一口气写了60万行代码，造了一个比sqlite慢两万倍的rdbms，当然只要用户接受满两万倍，你的任务就算完成了
【引用自 msft】:
ai也基本很难验证bug到底有没有修复，都得我去给他当小弟
让他用UI Automation去验证就好了，rich edit上有什么一清二楚
如果用的是网页，那也可以用playwright，但是检查的速度会慢很多
所以现在vibe coding可以取代大多数初中级SDE 但是还得有senior SDE来把控方向盘避免太过shit-rization
但是没有新鲜初中级SDE进入市场 等现在这帮老登SDE都FIRE了怎么整
【引用自 BigCummer】:
可以取代大多数初中级SDE
其实是很多水平很差的 SDE 在用 vibe coding 生成比他们手工还要 的码
反而觉得product sense更重要了, 但是很多码农这方面是缺乏的… (就算不是直接做product, 也需要“描述清楚问题的能力”…)
都怪木工没有开源精神，不愿意把具体做的过程用大白话写清楚然后放在网上给大家免费用
感觉苦的是刚毕业的大学生
希望leadership能理解吧
有道理，但是这前期去vibe e2e test的工作量也太大了。前期基本app长什么样子都不确定，完全是在高速试错。按你的说法大厂应该不要搞agile重回waterfall，这样最适合ai
要vibe的是workflow infra
test让它自己说应该测哪些然后自己做plan自己执行
最后不满意你再来让它改了plan再做
【引用自 msft】:
按你的说法大厂应该不要搞agile重回waterfall
你说对了
现在AI重写成本这么低，外加AI基本不具备critical thinking，极容易受当前思路影响，无法从屎坑里backtrace跳出来的情况下，重写出来的效果可能比让它直接改更好
agentic coding的时代software engineering会重燃光芒的，因为一切反人性的要求原则和流程现在都有现实的严格执行的可能了
哪个小学生
那各位还有工作的也要不保了
工资也会大幅缩水
AI 提高了你的 productivity，然后公司就可以用你一个人 review 三个印度人的 code。
所以当码农最好的时间在20年前，正好就是人人都不想做觉得CS日薄西山的时候
20年前收入比硬件低
15年之后才比硬件明显多
等别人修你的BUG的时候就好玩咯。
【引用自 vczh】:
正好就是人人都不想做觉得CS日薄西山的时候
【引用自 flywire】:
20年前收入比硬件低
还有这段历史
之前我考古 剑侠情缘 开发团队归宿的时候（不知道那一代程序员后面去哪了，是退休了还是继续在网易腾讯里写游戏），看到一个人的博客，零几年毕业当程序员，然后觉得没前途就考教师资格证，然后去大学当讲师教编程去了。
【引用自 打豆豆】:
还有这段历史
中国有
因为华为
但其实当时即使国内收入天花板还是谷歌和微软
美国得再往前二十年
感觉我们这种写芯片代码的稍微好一点点
但也是处于危机
【引用自 收束观测者】:
再往前二十年
那时候都想象不到有什么需求（都是to B银行之类的萝卜坑是不是），也没互联网放大impacc，确实是夕阳产业了
我有个同事一路从思科雅虎谷歌过来，说没什么区别，都是差不多的活，还说03 08经济危机也没太明显的感受（没被裁员），下次如果还能遇到再采访一下他。
driver?
x.com
@