HackerNews中文版

我本来对这东西的宣传嗤之以鼻，但 阅读 相关的文章和 亲自体验 之后完全是两码事。如果你手头有旧的代码库，不妨试试，你可能会大吃一惊。我不确定我是否相信它对复杂、遗留的企业系统能长期实现“*提高 90% 的生产力*”，但对于样板代码、库、构建工具和重构来说？收益是巨大的。所有耗时、令人心烦意乱的事情基本上都被解决了。一开始你会像鹰一样检查每一个差异，期望它会搞砸一切，但说实话，很快你就会发现大多数时候根本没必要。你只需保持 IDE 打开，并将“分析代码”的输出反馈给它。在 Java 中，告诉它“添加 checkstyle，运行 mvn verify 并修复”效果很好，你甚至可以去喝杯咖啡，而不是与代码检查器的警告作斗争。理论上，剩下的就只有 逻辑 和 想法 了。当架构变得真正复杂时，我们拭目以待。但就目前而言，让它分支、创建样板代码，并在你迭代规范的同时编写一个简单的测试，效果出奇地好。只有当用纯英语写下规范太烦人时，你才会编写源代码。这引出了一个真正的问题：如果你的竞争对手 Y 为了省钱而解雇了 90% 的开发人员，你会盲目效仿吗？还是你会保留你的团队，利用这个巨大的杠杆，用一个更好的产品来*碾压* Y？

查看原文

i was rolling my eyes at the hype, but reading about this is totally different from experiencing it. if you have any old repos out there - try it, you might actually be amazed.i'm not sure i buy the long-term "*90% productivity*" claims for complex, legacy enterprise systems, but for the boilerplate, libraries, build-tools, and refactoring? the gain is gigantic. all the time-consuming, nerve-wrecking stuff is mostly taken care of.you start off checking every diff like a hawk, expecting it to break things, but honestly, soon you see it's not necessary most of the time. you just keep your IDE open and feed the "analyze code" output back into it. in java, telling it to "add checkstyle, run mvn verify and repair" works well enough that you can actually go grab a coffee instead of fighting linter warnings.the theory is that what remains is just the logic and ideas. we'll see how that holds up when the architecture gets genuinely tangled. but for now, letting it branch off, create boilerplate, and write a simple test while you just iterate on the spec works shockingly well. you only write source code when it's too annoying to write down the spec in plain english.it raises the real question: if your competitor Y just fired 90% of their developers to save a buck, would you blindly follow suit? or would you keep your team, use this massive leverage, and just *dwarf* Y with a vastly better product?

如果人工智能带来 90% 的生产力提升，你会解雇开发者，还是打造更好的产品？