最新

嗨，HN， 我对涌现的AI编码工具感到有些沮丧。大多数列表只是嘈杂且无结构的链接堆砌，无法帮助你决定实际使用哪个工具。 因此，我为自己构建了一个我想要的目录。我的目标是提供有价值的信息，而不是更多的噪音。 它的不同之处在于： - 结构化分析：我使用一致的框架，根据开发者关注的标准（如IDE集成、离线使用、模型透明度等）来比较工具，而不是简单的功能列表。 - 定性评分：采用透明的方法论，快速了解工具的优缺点，超越单纯的功能计数。 - 专注于“待完成的工作”：帮助你找到适合特定任务的正确工具。 这是一个版本1的个人项目。它是通过自定义的Node.js脚本生成的静态网站，托管在Netlify上。我知道它并不完美，还有一些工具缺失。我在这里发帖是希望能得到你的反馈，以便改进。 我很想知道： - 这种方法对你真的有用吗？ - 分析是否公平？我哪里做错了？ - 我应该添加哪些必备工具？ 感谢你抽时间查看。谢谢！

我相信你对英国目前的严峻形势非常清楚，我对这个国家和不断下降的生活水平感到厌倦。 我一直在申请美国公司的职位，我认为自己是一名相当优秀的SRE/平台工程师，但我意识到，身处这里可能会成为一个巨大的障碍，尤其是最近H1B签证备受关注。 那么，我是在浪费时间吗？还是说我可以做些什么来脱颖而出？

最近，我的雇主一直在大力推动在工程团队中采用大型语言模型（LLM），期望能够提高生产力。工程团队也随之而动，因此我收到了很多明显是由人工智能生成的拉取请求（PR）。这些请求的差异有时达到100行，而实际上可能只需要10行，遗漏了错误案例，违反了约定。这不仅仅是初级工程师的情况，现在常常也出现在其他高级工程师身上。 在我们的激励结构下，似乎没有好的方法来防止质量的下降。我很难量化“粗糙代码”为什么是坏事，但我的直觉是： 1. 代码库对人类工程师变得难以阅读。 2. 代码库中更多的糟糕示例会为未来的LLM变更创造一个负反馈循环。也许这已经成为新常态，但—— 3. 一旦有足够的糟糕代码进入，未来的事件/严重故障（SEVs）将变得越来越难以解决。 （3）似乎是唯一一个对业务有实际影响的原因。即使真的发生了，我也不知道是否能将响应缓慢/收入损失与AI生成的糟糕代码联系起来。 我看到其他帖子对“随意编码”的弊端表示遗憾，但在LLM时代，有没有具体的方法来证明代码质量的重要性？我认为，跟踪一些代码质量指标，比如圈复杂度，可能会有助于观察与回归之间的相关性，但这似乎有些薄弱（而且是事后诸葛）。