#FAANG

1个月前

来自 FAANG（别跟我说你不知道）的软件工程师教你如何 Vibe Coding 最一线生产经验，小本本记好 reddit. com/r/vibecoding/comments/1myakhd/how_we_vibe_code_at_a_faang/

#FAANG #软件工程师 #Vibe Coding #一线经验 #Reddit

1个月前

来学习+批判一下 FAANG 这样的大厂是怎么「凭感觉编程（Vibe Coding）」的： “先让足够多的利益相关者点头同意” “然后搞设计评审” “接着是长达几周的文档工作” “再然后是产品经理和项目经理来回拆分任务” 等三个月过去了，终于可以开始 Vibe Coding 了！ --- 我们在 FAANG 是这样「凭感觉编程（Vibe Coding）」的大家好。我之所以想在这里发个帖子，是因为总看到有人抬杠，说 AI 辅助写的代码根本不能用在真正的产品里。这绝对是瞎说。先介绍下背景：我是一名 AI 软件工程师，有十多年的经验，其中一半时间是在 FAANG 度过的。我职业生涯的前半段是做系统工程师，而不是开发，不过我写代码也快 15 年了。闲话少说，下面我就讲讲我们团队是如何开始用 AI 来写真正的**生产代码 (production code)** 的。 1. 你永远要从一份**技术设计文档**开始。这才是整个工作里最核心的部分。这份文档就像一份提案，你需要说服足够多的利益相关者 (stakeholders)，让他们相信你的方案是可行的。只有设计通过了，你才能着手开发系统本身。这份文档里要包含完整的系统架构、与其他系统的集成方案等等。 2. 在投入开发之前，要进行**设计评审 (Design review)**。在这个阶段，团队里的高级工程师 (Senior Engineers) 们会把你的设计文档翻来覆去地“捶打”一遍。这是件好事，我管这叫**“把痛苦前置”**。 3. 如果评审顺利通过，你就可以正式启动开发工作了。最初的几周，大家会花很多时间，为每个开发团队要构建的子系统 (subsystem)，撰写更详细的文档。 4. 接着是**待办事项 (Backlog) 的开发和 Sprint 规划 (sprint planning)**。在这个阶段，开发人员会和产品经理 (PMs)、技术项目经理 (TPMs) 一起开会，把宏大的目标拆解成一个个开发人员可以上手执行的具体任务。 5. **软件开发**。终于，我们可以上手敲代码、消灭任务卡了。而这，正是 AI 发挥神力的地方，它简直是我们的**效率倍增器 (force multiplier)**。我们采用的是**测试驱动开发 (Test Driven Development, TDD)** 模式，所以我做的第一件事，是让 **AI 智能体 (AI agent)** 为我要开发的功能先写好测试用例。*只有当测试写好了，我才会开始让 AI 智能体帮我构建具体的功能*。 6. **代码提交评审**。我们的代码在合并到主分支 (main) 之前，需要有两名开发人员的批准。在这个环节，AI 也展现出了巨大的潜力，可以辅助我们进行评审。 7. **在预发布环境 (staging) 测试**。如果测试一切顺利，我们就正式发布到生产环境 (prod) 了。总的来说，从功能提案到最终上线，我们发现整个流程的**速度提升了大约 30%**。这对我们来说是个巨大的进步。 **太长不看 (TL;DR)：** 永远从一份扎实的设计文档和架构开始；然后一块一块地去实现它；永远把测试写在前面。

#FAANG #凭感觉编程 #AI辅助 #软件开发流程 #效率提升

4个月前

来自 Reddit 一位拥有30多年经验的前FAANG（Facebook、Apple、Amazon、Netflix、Google）高级工程师被一个C++ Bug困扰了4年，花了约200小时却毫无进展。而Claude Opus 4竟然成功地解决了这个问题，并且是唯一能做到的AI智能体。以下是 Reddit 上的帖子： *** Claude Opus 今天帮我解决了折磨我四年的「白鲸」级Bug 背景我是一名拥有超过 30 年经验的 C++ 开发者，曾任职于 FAANG 公司担任高级工程师。我通常是团队里的问题终结者，当其他工程师卡住一周都解决不了问题时，他们来找我，我往往在他们站在我办公室里的时候，就能轻松搞定。但今天，我被 Claude Opus 4 彻底折服了。折磨了我四年的难题四年前，我曾做过一次重构，对约 6 万行的代码进行了重新架构。重构解决了大量问题，但也带来了一个极端情况的 Bug。当某个特定着色器（Shader）以特定方式使用时，这个 Bug 就会显现。以前这个功能是好的，但重构之后，这个特定场景就坏了。过去几年，我断断续续地花了至少 200 个小时想找到原因，但一直无功而返。这个问题非常恼人，但并不是特别紧急，没法完全停下手头的工作专心处理。 Claude Opus 4 的神奇表现今天，我决定用 Claude Code 跑一下 Opus 版本来解决这个难题。我把新旧代码都给了它，告诉它：“去查一查，当年的重构到底是怎么导致这个问题的。” 让我没想到的是，它真的找到了！原来，这个功能在旧架构里之所以能正常运行，纯粹是因为偶然的巧合。重构后的新架构并没有考虑到这个巧合情况，因此就产生了问题。所以严格意义上讲，这并不是简单的逻辑错误，而是新架构的设计本身遗漏了旧版特有的边界条件。整个过程我一共向 Claude 提出了大约 30 个提示，中间重启过一次。之前我也尝试过 GPT 4.1、Gemini 2.5 和 Claude 3.7，都没有任何进展。最终只有 Claude Opus 4 解决了这个困扰我四年的难题。

#FAANG #C++ #Claude Opus #AI #高级工程师 #编程 #Bug解决

9个月前

最近仔细调研了一下，发现一个有点意外的事情，其实即便是FAANG这样的互联网大厂程序员，经常使用GPT的SDE的比例（比如说每周至少用一次，门槛很低了）比想象中低，准确的说，只有50~60% 刚得到这个数据的时候还是有点惊讶的，比直觉上低太多，这已经是排除了所有其他干扰项只看SDE的使用比例数据了互联网公司内部做genAI/LLM工具的组，竟然也得自己分析如何提高公司内部用户留存率，笑死，竟然不是程序员们求着要用，chatGPT都问世已经两年了所以在大厂里做SDE，只需要每周用一次GPT/genAI，就已经在拥抱genAI这项上四舍五入超越了快一半同行🤣 至于可能的原因，估计主要是现有老业务比较熟悉，coding和debug也都是业务逻辑，能用的地方不多，就算用了GPT也提升不大。以至于在公司呆的越久的人用GPT热情越低，也是非常明显的普遍现象另外的原因，估计也是LLM的表现不尽如人意，就算是有公司内部组专门做RAG而且水平不低，神经刀式不稳定降智也是常有的事用公司内部的agent tool的人就更少了，百分比太低，以现在agent处理复杂业务问题的稳定性和可控性水平，能经常性玩转真是不容易我也搜了一下网上其他人的调研进行验证，和我的数据结论基本是接近的，比如Gemini找了不少resource也说大厂weekly使用比例在50~75%之间所以劈柴去年10月说的什么Google内部超过25%的code都是AI写的，那纯粹是画饼都不讲基本法了这还是和genAI离得最近的程序员群体，如果把其他领域算上，那普及率就更低了，半导体员工经常使用公司genAI tool的比例，在20%以下绝大部分传统半导体厂甚至没有内部支持的靠谱RAG（RAG做的非常差劲+不同组之间的资料是全保密的无法access，更不说RAG)，经常用genAI tool工作的比例(定义为每周用一次)能有10~15%不错了 openAI的颠覆所有领域取代程序员取代人的雄心壮志，只能说路漫漫其修远兮，即便是在硅谷，也没那么快作为一个半导体从业者，这一年我也算是尽可能的使用genAI tool了，工作中平均每天的使用次数在10次以上，目前的感受是提高的效率很有限，可能…有5~10%？大概就是每周能节约几个小时的水平 ---------------------------------------- 2025新年resolution，更加积极的使用genAI tool，能通过genAI提高工作效率20%，我就非常非常满意了

#互联网公司 #程序员 #GPT使用率 #FAANG #genAI #LLM工具 #用户留存率 #数据调查