Two Dan Luu posts that go together: Some reasons to work on productivity and velocity and the newer We should be more ambitious with the software we build. The first is pre-LLM and makes the case for getting faster. The second is what that case looks like now that the speedup comes from the models instead of from you.
The velocity post
The standard pushback on working on speed is that picking the right thing matters more than doing it fast. Dan’s response is that the two feed each other:
If anything, each of these is a force multiplier for the other. Having strong execution skills becomes more impactful if you’re good at picking the right problem and vice versa.
His example is a machine health project where the first few weeks of ideas were all dead ends. He got to the one that worked because he could try and throw out ideas quickly. If each attempt had taken a quarter, he’d have dropped the problem.
The other objection is Amdahl’s law: you only spend 1% of your time typing, so typing speed can’t matter. Dan’s answer is the line I keep coming back to:
I spend time on things that are high ROI, but those things are generally only high ROI because I’ve spent time improving my velocity, which reduces the “I” in ROI.
Getting faster changes which things are worth doing at all. The long-shot doc with a 5% chance of landing is only worth writing if docs are cheap to write.
The moral version of the objection (optimizing yourself is grim, go live life) he flips around. He says he works no more than the median person at his company:
A lot of my productivity gains have gone to leisure and not work.
The ambitious post
This is the one I care about. It takes the “I in ROI” idea and applies it to agentic coding. Dan asked what would bottleneck him if models were 10-100x faster, and the answers were ripgrep, Rust compile times, and filesystem overhead. So he wrote a regex engine, forked ripgrep to use it, and patched the Rust toolchain to speed up his builds. For someone without a background in regexes or compilers:
this set of projects would’ve taken a year or more to get to “works for me” quality. Instead, this was a low single-digit number of hours of my time.
The core observation, via Michael Malis:
it doesn’t even occur to people to do these things that are now easy.
People are “implicitly carrying around a pre-agentic cost model.” Ten years ago the person who wrote a compiler because their compiler was slow was, in Dan’s words, “the kind of person who never ships anything.” Now that’s a reasonable afternoon, but most of us still have the old reflex that says don’t go down that hole.
My favorite example is the small one. He built a submarine game based on a book series he liked:
I never would’ve spent 10-20 hours implementing a game so that I could play it for an hour or two, but I’d spend 5 minutes.
That’s the whole thing in one sentence. There is a huge pile of software that was never worth writing at the old price: one-person tools, games you’ll play twice, a formatter that matches your exact taste. The price dropped and the pile hasn’t been picked over yet.
Pinecoder’s “My old job feels very distant now” is the same observation from the inside, written as a diary of each model generation. In the Opus 5.5 section they type a 15ms performance constraint when they meant 150ms, hit enter anyway, and the model does it:
Wow. I realize… I need to re-evaluate what I think of as possible and not.
Then they idly prompt a port of their Electron notes app to native Swift on iPhone and walk away. A few hours later a working build shows up on their phone, installed over the network so the model could ask them to QA it:
It used 40% of my 5-hour limit on my $20 subscription. Its not feature complete, but it works?. I use the importer and import all my notes… It looks great. Its a few moments of staring at the screen, dumbfounded.
Same cost model problem Dan describes. The project was always “someday,” and someday turned out to be an afternoon they weren’t even paying attention to.
The counterargument
Dan includes an appendix from Yossi Kreinin arguing most people should be less ambitious with AI “or they’ll experience abject failure.” Lots of problems don’t have a clear pass/fail an agent can loop on, and most people are bad at reasoning about giant black boxes they didn’t write.
Dan’s answer: AI speeds up some tasks a lot and others not at all, so if you do exactly what you’d have done five years ago with AI bolted on, Amdahl’s law bites. The move is to pick the things that are now cheap, which are usually “things that were previously too expensive to do,” and to build in self-checks (fuzzing, property tests, consistency checks) even where people say it won’t work.
Just because other people are pumping out vast quantities of barely working slop doesn’t mean that you have to do the same thing.
Where I land
This is the software-specific version of you-can-just-do-things. The agency part was never really the constraint for me; the cost estimate was. Every time I think “that would be a fun tool but it’s a weekend,” the weekend number is probably from 2022.
The same argument, applied to posting and launching instead of building, is actions-per-minute.
One caveat Dan is honest about: he gets farther from “it just works” with each better model, because he keeps moving to harder things where the model can implement more than it can verify. More ambition means more checking. Which ties back to the testing notes in vibe-coding and the Claude Code setup in agentic-systems.
Pinecoder gets at what the checking turns into. Less line-by-line review, more “I think about the QA I want to do,” plus dashboards and tools the model can use to track its own state:
As the code moves faster, how can I continue to understand it? I come up with new metrics, new dashboards. I think harder about the the most important parts of the design and the constraints are. That is the only place that deserves attention and effort.
And the ending, which is the part I liked most:
Everything is upside down yet again. I think about the future. But I work in the present. How I work is changing again; we adapt as we must. If I forget about my fear, I instead become very excited.
Many things about the old ways of working, I miss. Many things I do not. The old way of working feels like just yesterday; but also it feels to be drifting off into the distance.