如何通过大型语言模型提高编码生产力
作为一名终身程序员和企业家，我想说，2-4-8倍的AI生产力提升仅仅是个开始。与AI出现之前相比，我目前在16周内的编码生产力达到了40-50倍，并且这个数字还在不断增加，我正在努力寻找方法与更多程序员分享这些技巧。大家好，HN...
我用代码行数来衡量，虽然我知道这不是一个完美的指标，但这是我能用的量化指标，我也有能力了解它的局限性并说，这是真的。我在高中时就编写和销售软件。27岁时，我将一家公司卖给了谷歌，而我为这家公司编写了大约一半的代码（Neotonic [1]）。在那家初创公司中，我每年编写多达60,000行的Python、C和HTML模板。现在，借助AI，我平均每周能产生这么多代码……持续了16周。我在33岁时基本上退休，而现在我52岁，依然每天都在编码。
我使用AI模型的方式与我所知道的大多数人有所不同。我把它们当作一种“文字计算器”来使用，并不会像它们很聪明那样依赖它们。（它们并不聪明。在软件设计权衡方面，它们的表现保守地比高级架构师差100倍，但它们知识丰富且工作非常迅速。它们是你一直希望拥有的“实习生”。）
我通过至少以下三种关键方式来实现这一点：
1. **我在编码时关闭思考。** 我将设计时间的思考和阐述前置，形成设计规范和实现规范，因此在AI编码时，我已经自己解决了所有的模糊性。因此，我关闭思考（或将其调到最低），这样AI就不会重新审视我已经解决的问题。这一点尤其重要，因为我的代码库现在超过了350,000行的相互关联的分层抽象，而不是一个一次性的移动应用。
2. **我保持连接并阅读大部分的文字聊天输出，** 当AI说出任何与我脑海中的设计不符或错误的内容时，我会立即停止它。因为这表明LLM的上下文不一致，它误解了某些内容。
3. **我设计编码优先级以从A到B。** 就像我自己会做的那样，安排功能开发的顺序，以最小化架构风险，消除未知因素，在复杂性层叠之前感受到事物的成型。然后为我们正在处理的部分构建尽可能多的AI可见迭代循环。我会在可能的情况下使用第三方的参考（例如，针对Skia进行像素精确的字体和形状测试，而不仅仅是凭眼睛判断）。我决定这种细节的有用程度，然后将LLM放在一个能够成功的位置。
简而言之，仍然是我在以我的方式构建软件。我尽力让AI在每个阶段都反映我会如何做，因为我发现这个过程更具生产力。我尝试过更多的放手和不干预的替代方案，结果是快速跳跃后又花费整整一天去理清一些AI产生的混乱，代码库在达到60,000行时就变得错综复杂，曾两次陷入困境。
LLM可以一次性编码一个移动应用。它们可以从研究论文中实现一个大致正确的算法，有时也能制作出半漂亮的用户界面。但它们（目前为止）无法直觉出满足你需求的正确权衡。它们无法决定构建什么软件，为什么要构建它，哪些软件部分应该为未来的灵活性而构建，哪些则是现在的实用性。它们无法判断哪些算法最适合现实世界的需求，所有这些都无法做到。
而它们在这些领域的表现比不知道还要糟糕。它们自信地阐述垃圾信息，完全是废话。因此，成为与AI编码高效合作的最有价值的技能，就是能够快速阅读，以跟上进度，并识别出优秀执行与废话之间的区别。
[1] https://en.wikipedia.org/wiki/Neotonic_Software
查看原文
As someone who is a lifelong programmer and entrepreneur, I'm here to say that 2-4-8x AI productivity boost is just the start. I'm currently benchmarking myself at 40-50x coding producivity with AI over 16 weeks, compared to pre-AI, and it's increasing over time, and I am trying to find ways to share these techniques with more programmers. Here we go HN...<p>I measure in lines of code, which I know is an imperfect metric, but it's the quantative metric I have, and I'm qualified to know it's limits and say, this is real. I wrote and sold software in high school. I sold a company to Google when I was 27 for which I wrote half the code (Neotonic [1]). In that startup I wrote up to 60k LOC per year of Python, C, and html templates. With AI I'm producing that much in a week on average... over 16 weeks running. I mostly retired at 33, and here I am 52 and coding all day every day.<p>I use AI models a little differently than most I know. I wield them like a word-calculator, I don't defer to them as if they are smart. (they are not. they are conservatively 100x worse at software design tradeoffs than a senior architect, but they are knowledgeable and they work very fast. They are "the intern" you always wished for)<p>I get there by doing at least these three key things differently:<p>1. <i>I turn off thinking while coding.</i> I frontload the design-time thinking and elaboration, into a design-spec and an implementation-spec, so by the time an agent is coding, I've resolved all the ambiguity myself. So I turn off thinking (or set it as low as I can), so the AI will stop revisiting things I already resolved. THis is especially important because my codebase is now over 350k LOC of interconnected layered abstrction, not a one-shot mobile app.<p>2. <i>I stay connected and read most of the verbal chat output</i> and I stop the AI when it says <i>anything</i> that is wrong or incongruent with the design I have in my head. Becuase that's a sign that the LLM context is unaligned, that it misundertood something.<p>3. <i>I design the coding prioritization to get from A to B</i>... the ordering of the feature development, just like I would do myself, to minimize architecture risk, get the unknowns out of the way, feel the thing taking shape before the complexity layers in..Then build harnesses with as much AI visible iteration loop as is practical for the part we are working on. I use third-party oracle references when I can (like pixel correct font and shape tests against Skia, instead of just eyeballing) And I decide the level of detail where this is useful, then put the LLM in a place where it can succeed.<p>In short, it's still me, building my software, my way. I'm trying my best to get the AIs to mirror the way I would do it, at every stage, because I find that process more productive. I've tried more hands-off eyes-off alternatives, and I would get rapid jumps and then spend entire days untangling some AI slop mess, and the codebases would just get so tangled around 60k LOC they became a morass, twice.<p>LLMs can code one-shot a mobile app. They can implement an algorithm mostly-correct from a research paper, and they can sometimes make semi-pretty UI. But they can't (as of yet) intuit the right tradeoffs to meet your needs. They can't decide what software to build, why you should build it, what parts of the software to build for flexibility in the future vs practicality now. What algorithms will be the best fit for the real world needs, none of it.<p>And what they do in those areas is worse than not-knowing. They confidently expound garbage. Absolute drivel. And so the most valuable skill you can have for being hyper productive with AI coding, is to beable to read fast enough to stay on top of it, and recognize the difference between the excellent execution and the drivel.<p>[1] https://en.wikipedia.org/wiki/Neotonic_Software