Code review 没有过时，但我们可能 review 错了对象 AI can produce a diff. Review decides whether the team is willing to own the change. AI会产出代码，但是团队应该决定是否拥有这个改变 上一篇：AI 时代还需要 Estimate 吗？ 床位系统那个 bug 暴露以后，我反复想过一个问题： 我们明明做了 code review，为什么还是没有发现这个bug？ 实现并不离谱。代码在判断查询时刻是否落在预约区间内，局部逻辑说得通，边界也长得像正常的时间处理。 只是业务真正问的是“这一天是否已经被占用”，代码回答的却是“当前这一秒是否落在区间”。 我们不是没看代码。我们看了一个错误问题的正确答案。 这件事让我意识到，AI 时代关于
AI 时代还需要 Estimate 吗？ Don't estimate how long it takes to generate code. Estimate what it takes to trust the change. 不要只估算生成代码需要多久，要估算团队需要付出什么，才能相信这个 change。 上一篇：别再用更多 Ticket 衡量 AI Productivity 下一篇：Code review 没有过时，但我们可能 review 错了对象 如果现在有人问 engineer：“这个 ticket 要多久？”答案可能越来越像这样： “代码今天能出来。至于什么时候敢上线，我不知道。” 这不是
别再用更多 Ticket 衡量 AI Productivity Code is cheap. Verified outcomes are not. AI 可以廉价制造代码，但不能廉价制造可信结果。 上一篇：AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力 下一篇：AI 时代还需要 Estimate 吗？ 有一种项目周会，特别容易让 EM 心情愉快。 这个 sprint 完成的 ticket 比以前多了，PR 数量涨了，commit 也很活跃。自从团队开始用 AI，dashboard 上的每一条线都在往右上角走。管理层一看：不错，AI productivity 已经兑现了。 然后 reviewer 默默打开
AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力 When generation becomes abundant, attention is all we have. 当生成变得充裕，注意力就是团队最后的稀缺资源。 上一篇：AI 几乎写完了代码，项目为什么只从六个月缩短到四个月？ 下一篇：别再用更多 Ticket 衡量 AI Productivity 上一篇写到，我们用 AI 做床位管理项目，AI 几乎取代了人工代码输出，但项目周期只是从预计的六个月缩短到四个月。 Coding 快了很多，code review 和 QA 的绝对耗时却增加了。 这件事有点像把高速公路前半段拓宽到十条车道，却忘了后面的收费站还是两个窗口。入口看起来特别繁荣，车都在往前冲，最后大家整整齐齐堵在下游。 软件项目也一样。 AI 没有消灭瓶颈。它只是非常高效地把瓶颈从“谁来写代码”，搬到了“
AI 几乎写完了代码，项目为什么只从六个月缩短到四个月？ AI can generate code. It cannot own the outcome. AI 可以生成代码，但它不会替团队对结果负责。 下一篇：AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力 我们最近做了一个床位管理项目。 按照过去的开发方式，团队估计大概需要六个月。这一次，AI 几乎取代了人工代码输出，项目最后用了四个月。 四个月当然比六个月好。我也很高兴。 但这个结果有点别扭：写代码这件事几乎都被 AI 接管了，整个项目为什么没有出现同样幅度的压缩？剩下的时间去哪儿了？ 项目结束后回头看，我们确认了几件事： * Implementation 明显变快； * Code review 的绝对耗时增加； * QA 的绝对耗时增加； * 团队投入了更多验证工作； * 最终返工和缺陷反而减少。 这些事实不支持“AI 只帮我们省了两个月”这种简单结论。
团队里最难处理的，往往不是最差的同事，而是那些卡在board line上，挤挤能出活、但不挤就磨洋工的low performer 同事。 这类 low performer 一出现，很多Manager的第一反应就是：ownership 不行。问题是，这句话太空了，空到几乎没法行动。 我更喜欢用一个简单的框架看这件事：先判断原因，再调整支持，接着设观察期，最后做去留决定。 先判断：到底是哪一类问题 low performance 不等于 low ability。常见情况其实不一样： * 不会做：能力还没到，拆问题、推进、沟通都卡住。 * 不想做：知道怎么做，但投入不够。 * 做错方向：很努力，但目标理解偏了。 * 岗位不匹配：人不差，只是不适合这个角色。 比如： * 一个同事总是晚交，但每次都能把问题讲清楚，可能是任务切太大了。 * 一个同事总返工，
This is Andy's base: Tech, AI, Career, a brand new site by andy that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when
Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去，帮他们解决一个支付系统的问题。 简单来说，我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所，然后机构可以统一管理下属场所的账单，支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树，让父结点能看到子节点的账单，并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统，所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id，但是这个id 和我们内部使用的id 并不一致，所以我们需要自己把客户的id 和他们的支付账户连接起来。然而： * 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明，用客户的last-name 属性存储了我们的id * 第一个雷：用户的last-name是可以由用户自行修改的。如果他们修改了，我们的对应关系就乱套了。 * 但是这个id A存错了，应该存储机构的id，A存成了下属场所的
争取整个短文系列，迎合短视频的潮流。 base前段时间整了个活，提出了一个新的概念叫flashblocks。 在有flashblocks之前，每个区块的状态是要么这个区块还不存在，没法拿到区块的任何状态和信息；要么就是这个区块已经存在了，它的状态是不可变的，拿到就是最终区块。base链每2秒产生一个新的区块，即任何的交易需要2秒钟才能确认。 如下图，区块A生成之后，2秒内用户只能看到区块A，直到区块B生成。 flashblocks呢，它允许用户提前获取正在打包的区块的状态。正在打包的区块每200ms更新一次状态，直到10次更新之后，正在打包的区块变成一个完整的区块。 如下图，区块A打包200ms后，用户可以立刻看到区块B的状态0. 再200ms后，可以看到区块B的状态1，直到区块B的状态9，然后区块B稳定，开始生成区块C的状态1。 flashblocks的好处是什么呢？它可以在一个区块完全打包好之前，让用户提前知道自己的交易是否有被打包进当前的区块，加速交易状态的确认。 缺点又有哪些呢？ 首先这个确认属于预确认（preconfirmation）， 这个预确认还没有状态更新
CIRCLE的股价自从6月5号 上市之后，从发行价的25刀一路涨到220刀， 翻了9倍。随之而来的就是各路媒体，自媒体上的各种讨论，”啥是稳定币“， “GENIUS法案是啥”，“稳定币凭啥稳定”，“CLEAR法案又是啥”。 作为一个从2024年开始在币圈边缘讨口子的菜鸟，希望能通过这篇文章给大家一个扫盲。 开天辟地之比特币 2009年，有个叫中本聪的哥们，由于各种原因，提出了比特币这个概念。比特币当时集合了几种很玄乎的概念，但是其核心就是： * 用一个叫比特币的代币来进行交易 * 没有传统的账号密码系统。通过密码学，任何人只要能证明对账户的所有权（私钥）即可控制账户里的资产 其他去中心化啊什么的都不重要，简单理解就是这哥们建立了一套独立于银行之外的支付体系，并且不需要通过银行来进行认证，任何人都可以创建一个私钥，然后开始交易。 比特币之我钱呢？ 随着比特币逐渐走入大家的视野，很多人发现了这个系统的巧妙之处：几分钟就可以转账；手续费低廉；最关键的是账户全是匿名的，方便搞一些见不得台面的东西。 于是在各方利益相关推动之下，比特币居然真的成为了共识货币。这里我们也不讨
Resources for IC6(Staff) Eng interview preparation * Coding: * As usual, Leetcode is your best friend. Notice to not pay too much attention to hard questions. Focusing on medium is sufficient. * ^ time your coding. Companies like Meta especially ask to solve 2 medium questions in 40 minutes coding round. * System design:
1月19日 19号的时候，我有个同事从国内刚回美。我们约了半个小时的1:1。期间，聊到了在当前经济形势下，Google会不会像其他科技公司一样大规模裁员。当时我跟他说，裁应该是裁的，不过他本身rating还不错，做的项目也很重要，就算裁员应该也不会裁到他头上的 1月20日 从早上6点多开始，我就陆续收到微信消息，不过因为手机是静音模式，直到7点才被推送消息提醒。看着20多条未读消息，我第一反应就是“国内朋友们在提前发红包么？” 点开消息，发现内容都在讨论Google裁员。我脑子当时嗡了一下，闪过两个念头：1. 我这么乌鸦嘴？2. 我没被裁吧？ 急忙忙的点开邮箱去搜Sundar的邮件。他在凌晨两点多发了一个关于全球裁员12000人的邮件。再点开内部群，微信群，看同事们都在讨论怎么知道自己有没有受到影响。 10点多的时候，各路消息灵通人士们大概总结出来几种方法看自己是否收到影响：比如有没有收到hr的邮件；是否还能访问内部系统等等等等。多方验证之下我大概可以确定我暂时没有被影响到。 暂时确认后，心情稍微平复了一下。从早上刚听到消息时的茫然，震惊，变成三分侥幸，七分慌张。侥幸自