即刻App年轻人的同好社区
下载
O3 把 swe-bench 刷到了 71%，离 90% 不远了。我甚至觉得 devin 配合 o3 应该吃鸡就 90+% 了。十亿人写代码的时代要来了
熊猫ai甘蔗发表了动态：Anthropic CEO Dario 提到今年年初，swe-bench 的 sota 是 4%，现在是 50%，明年可能到 90% ，那么软件行业会发生什么？ swe-bench 使用真实的 github issue 作为测试。当然目前的 bench 到了 90 后，我们可以增加 bench 的难度，需要更多 context ，只有更少的 test case。但到一定的程度就好像把围棋盘从 19x19 变成 29x29，AI 搜索固然慢了，人自己到时候能理解这个新游戏吗？
5 00
社交上下苦工的也不多？
P小二: 大多数人勤于社交，只有少数人在钻研和提升技术方面下苦工。
2 00
领军人物的重要性。另外维持之前的判断， 几小龙是在浪费资源web.okjike.com
5 00
虽然但是，这读 paper 懂到你这一步至少得招个兼职phd，维护集成得找全栈全职工程师。 媒体招个实习生+GPT 能颠覆 100 次了
AlanJiang: 我就不明白了，那个最新开源的Genesis平台怎么就又颠覆物理引擎了呢？仔细看看作者分布和内容介绍，不就是把一堆之前的工作集合到一个平台里面了吗？即使能颠覆，也需要相当长的路要走，此外，就这个工作量，不招个全栈全职工程师真难维护下去。
1 21
我之前有类似想法 飞书文档+jupyter ，也试过各类其他东西比如 deepnote，observable 后来发现还是直接 colab 最好用，秒开+白嫖 gpu+无敌网速 m.okjike.com //@钱一张: 我有个更大胆的想法
如果飞书的 code block 可以编译+运行，将会是一种非常神奇的体验
当然更直接一点是ide 里可以划词评论+留痕（而不是所有 conversation 都集中在一个 chat tab， 这个conversaton 会留在这段代码上，直至该代码被删除或被解决），可以建立todo
如果飞书的 code block 可以编译+运行，将会是一种非常神奇的体验
当然更直接一点是ide 里可以划词评论+留痕（而不是所有 conversation 都集中在一个 chat tab， 这个conversaton 会留在这段代码上，直至该代码被删除或被解决），可以建立todo
熊猫ai甘蔗: 看了ChatGPT 的 xcode 集成，再结合之前cursor, windsurf, bolt.new, v0，devin等等的尝试， 越发觉得chat interface 至少在编程领域还是未来几年的主流。 完全没看出有什么强烈淘汰 chat ui 的必要。之后 chat coding 大概会和编辑器的语法高亮是一个层次的普遍广泛的存在。或许 2c 领域需要发展出新 UI，coding 领域看到不替代 chat 的存在，反而基于 chat 有非常的东西可以做
2 00
看了ChatGPT 的 xcode 集成，再结合之前cursor, windsurf, bolt.new, v0，devin等等的尝试， 越发觉得chat interface 至少在编程领域还是未来几年的主流。
完全没看出有什么强烈淘汰 chat ui 的必要。之后 chat coding 大概会和编辑器的语法高亮是一个层次的普遍广泛的存在。或许 2c 领域需要发展出新 UI，coding 领域看到不替代 chat 的存在，反而基于 chat 有非常的东西可以做
完全没看出有什么强烈淘汰 chat ui 的必要。之后 chat coding 大概会和编辑器的语法高亮是一个层次的普遍广泛的存在。或许 2c 领域需要发展出新 UI，coding 领域看到不替代 chat 的存在，反而基于 chat 有非常的东西可以做
2 32
我觉得这是团队可以锻炼的能力，并不是某个个人的能力。很少有团队愿意主动锻炼这个能力。加班加点还是容易得多，且是一个更容易感动自己的决定 //@Euphoriaaa: 方案2是有可行性的，就像前后端约定了接口协议之后并行开发代码，但前提要求极高，产品要明确定义客户需求和相应功能，以及对接双方需要有高度执行力和配合习惯，我经历过的大部分团队都做不到
熊猫ai甘蔗: 我有个猜想，很多时候频繁的加班是因为团队喜欢加班（而害怕把刚做的工作扔掉） 假设有一个项目需要两个任务A和B，B的输入是A的输出， 简化之后有两种做法， 1. A完成后，再做B。 这样B的需求明确，不太容易白做。问题是需要等A做完，时间上只好延期，为了赶重要日期，需要加班。 2. A没完成时，按照某个假设开始做B。这样必然导致B任务的部分工作需要重做。 提高整体效率的话，应该选2，但很多时候会选1，“白做了“ 的感觉太坏了，以至于从上到下都想避免。结果就是频繁的加班 理想情况A没完成的时候，资源可以放在其他事情上，不去做B，现实中这样会导致太多的context switch。别说人，就算CPU也没有办法承受大量的context switch，从而才有branch prediction 。 branch prediction 哪怕正确率极低，也只有好处没有坏处，当然这个结论对人不成立，人有feeling，费曼大神曾经说过， “Imagine how much harder physics would be if electrons had feelings. 预测错了， 团队会感觉到工作又白做了。 创业的每一天都是在所有坏选择中选一个不那么坏的。可能culture fit 就是每种坏选择的feeling 尽量一致吧？
1 00
重点是趋势 //@s0j1: 只是 2000/50 的限制，没几天就用完了
熊猫ai甘蔗: AI编程太卷了，github copilot 官宣免费～github 现在也有 150M 用户。前几天我感叹 linkedin 用户超过了微信，现在我觉得Github 用户超过微信也不是那么遥远了。 Now automatically integrated into VS Code, all of you have access to 2,000 code completions and 50 chat messages per month, simply by signing in with your personal GitHub account. Or by creating a new one. And just last week, we passed the mark of 150M developers on GitHub. 🎉
2 00
大家会认为有别的任务，但是（我认为）startup 最重要的是专注和优先级。 //@炫酷的ccc: 如果串行，大家是干等着还是有别的任务可以做呢？如果有别的任务，那看起来是权衡“别的任务”和“降低加班和延期风险”哪个更重要🤔。如果无法接受延期，而且别的任务都不紧急，那看起来还是应该并行。白干并不是真的白干，是在降低加班和延期风险，没那么难以接受？是非常担心工作内容不在最终的产出中体现么？swich也还好？swich本身也很常见？😂
熊猫ai甘蔗: 我有个猜想，很多时候频繁的加班是因为团队喜欢加班（而害怕把刚做的工作扔掉） 假设有一个项目需要两个任务A和B，B的输入是A的输出， 简化之后有两种做法， 1. A完成后，再做B。 这样B的需求明确，不太容易白做。问题是需要等A做完，时间上只好延期，为了赶重要日期，需要加班。 2. A没完成时，按照某个假设开始做B。这样必然导致B任务的部分工作需要重做。 提高整体效率的话，应该选2，但很多时候会选1，“白做了“ 的感觉太坏了，以至于从上到下都想避免。结果就是频繁的加班 理想情况A没完成的时候，资源可以放在其他事情上，不去做B，现实中这样会导致太多的context switch。别说人，就算CPU也没有办法承受大量的context switch，从而才有branch prediction 。 branch prediction 哪怕正确率极低，也只有好处没有坏处，当然这个结论对人不成立，人有feeling，费曼大神曾经说过， “Imagine how much harder physics would be if electrons had feelings. 预测错了， 团队会感觉到工作又白做了。 创业的每一天都是在所有坏选择中选一个不那么坏的。可能culture fit 就是每种坏选择的feeling 尽量一致吧？
1 00