如何利用大型语言模型（LLMs）提升编码效率
3 分•作者: DaveParkCity•10 天前
作为一名终身程序员和企业家，我在此声明，AI 带来的 2-4-8 倍生产力提升仅仅是开始。目前，我通过 AI 在 16 周内将编码生产力提升了 40-50 倍，远超 AI 出现前的水平，并且这个数字还在持续增长。我正努力寻找方法将这些技巧分享给更多的程序员。各位 HN 的朋友们，请看！
我以代码行数来衡量，我知道这是一个不完美的指标，但这是我拥有的量化指标，并且我有能力了解其局限性，并确认这是真实的。我在高中时就编写并销售软件。27 岁时，我将一家公司卖给了谷歌，该公司一半的代码是我编写的（Neotonic [1]）。在那家初创公司，我每年编写多达 6 万行 Python、C 和 HTML 模板代码。现在，我平均每周就能写出这么多代码……这已经持续了 16 周。我 33 岁时基本退休了，现在 52 岁，每天都在编码。
我使用 AI 模型的方式与我认识的大多数人略有不同。我将它们当作计算器使用，而不是像它们很聪明那样依赖它们。（它们并不聪明。在软件设计权衡方面，它们保守估计比资深架构师差 100 倍，但它们知识渊博且速度极快。它们就是你一直想要的“实习生”。）
我通过至少做到以下三点来实现这一目标：
1. **我关闭思考模式进行编码。** 我将设计时期的思考和细化工作全部前置到设计规范和实现规范中，这样当 AI 开始编码时，我已经自己解决了所有歧义。因此，我关闭思考模式（或将其降至最低），这样 AI 就不会反复处理我已解决的问题。这一点尤其重要，因为我的代码库现在已经超过 35 万行相互关联的分层抽象代码，而不是一个一次性的移动应用。
2. **我保持连接并阅读大部分的文本输出**，并在 AI 说出任何错误或与我心中设计不符的内容时立即停止它。因为这表明 LLM 的上下文已失调，它误解了某些内容。
3. **我设计编码的优先级，以从 A 到 B**……即功能开发的顺序，就像我自己会做的那样，以最小化架构风险，消除未知因素，在复杂性层层叠加之前感受到事物的成形。然后，为我们正在处理的部分构建尽可能多地利用 AI 可见迭代循环的框架。我尽可能使用第三方权威参考（例如，与 Skia 进行像素精确的字体和形状测试，而不是仅仅凭肉眼判断）。我决定在哪里使用这种方法，然后将 LLM 放在一个能够成功的环境中。
总之，这仍然是我，以我的方式构建我的软件。我正尽我最大的努力让 AI 在每个阶段都模仿我的做法，因为我发现这个过程更具生产力。我尝试过更多放手不管的替代方案，结果是快速的进展，然后花一整天的时间去清理 AI 造成的混乱，代码库在达到 6 万行左右时就变得难以管理，这种情况发生过两次。
LLM 可以一次性编写一个移动应用。它们可以从研究论文中大致正确地实现一个算法，有时还能生成半漂亮的 UI。但它们（目前）无法根据你的需求直观地做出正确的权衡。它们无法决定构建什么软件，为什么应该构建它，以及为了未来的灵活性而构建软件的哪些部分，而不是为了现在的实用性。哪种算法最适合现实世界的需求，这些它们都做不到。
而它们在这些方面的表现比一无所知还要糟糕。它们自信地胡说八道。绝对是废话。因此，要实现 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