HackerNews中文版

我对这种炒作曾经翻了个白眼，但实际上，阅读这方面的内容和体验它是完全不同的。如果你有任何旧的代码库，试试看，你可能会感到惊讶。我不确定对于复杂的遗留企业系统，长期的“*90% 生产力*”的说法是否可信，但对于模板、库、构建工具和重构来说，收益是巨大的。那些耗时且令人紧张的工作大部分都得到了处理。一开始你会像鹰一样仔细检查每一个差异，期待它会破坏东西，但老实说，很快你会发现大多数情况下这并不是必要的。你只需保持IDE开启，将“分析代码”的输出反馈给它。在Java中，告诉它“添加checkstyle，运行mvn verify并修复”的效果很好，你甚至可以去喝杯咖啡，而不是与linter警告作斗争。理论上，剩下的只是逻辑和想法。当架构真正变得复杂时，我们将看看这一点是否成立。但目前，让它分支、创建模板并编写简单的测试，同时你只需在规格上进行迭代，效果出奇地好。只有在写下规格用普通英语太麻烦时，你才会编写源代码。这提出了一个真正的问题：如果你的竞争对手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%的生产力提升，你会解雇开发人员还是打造更好的产品？