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...

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.

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)

I get there by doing at least these three key things differently:

1. I turn off thinking while coding. 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.

2. I stay connected and read most of the verbal chat output and I stop the AI when it says anything 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.

3. I design the coding prioritization to get from A to B... 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.

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.

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.

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.

[1] https://en.wikipedia.org/wiki/Neotonic_Software