Speed is not velocity
I’ve been thinking a lot about the gap between how powerful LLMs feel when you’re using them, and how little that seems to matter for actually getting meaningful work over the line.
Not because I don’t use them. I do. A lot.
At this point, they probably write more than 90% of the code I produce. If you measure output in lines of code per second, I’m obviously much faster than I was before. But if you measure the thing that actually matters - shipping something useful to production - the improvement is much smaller. Certainly nowhere near the 10-100x some people keep claiming.
If something really made a team 10x faster, that would not be subtle. Something that used to take a month would now take three days. Something that used to take a year would be done in five weeks. We would all notice.
I think part of the confusion is that we’re mistaking speed for velocity.
Speed is how quickly code appears on the screen. Velocity is whether the system is actually moving in the right direction. LLMs are extremely good at speed. But the direction problem is still mostly there, and in some ways more visible than before.
The easy part was never the hard part
Getting something that vaguely works on your laptop was never the whole job. The job is making it hold up inside a real codebase, with actual constraints, with other people touching it, using it, deploying it, debugging it and living with it afterwards.
People point at how quickly they can generate code now, and they are not lying. They probably are generating code much faster. But writing the code was never the only bottleneck, and in many cases not even the main one.
The hard parts are still the hard parts: deciding what should exist, agreeing on the shape of it, and dealing with the consequences afterwards.
More output, same throughput
LLMs absolutely increase output. They make it easier to start. Easier to explore. Easier to get to a rough first version. Easier to open ten threads of work instead of one.
But more output is not the same thing as more progress. Quite often it just means more unfinished work.
LLMs move quickly. But they do not know where to go in the deeper sense. They do not know which tradeoff matters, which future constraint will hurt, which messy edge case is actually the product, or which feature should simply not exist.
Now there is always something that could be running. Another prompt. Another refactor. Another tiny tool. Another MVP. Another experiment that is suddenly cheap enough to start, but not cheap enough to finish.
And of course we keep pressing the button.
Why wouldn’t we?
You describe something in plain English, wait a few seconds, and there it is: a first iteration, a quick hack, something working. Even when the result is mediocre, it still gives you that little reward of momentum. Something moved. Something appeared. The machine answered.
The loop is so short, and the payoff so immediate, that it becomes difficult not to reach for it again. Not because the result is always good, but because the experience itself is rewarding.
Output does not equal value
If you spend enough time close to the actual work, it becomes very hard to get excited by demos of prototypes, huge line counts, or vague claims about replacing entire functions of a company.
Because there currently is an enormous amount of noise.
And one of the easiest ways to generate noise right now is to confuse “I can produce more artifacts” with “I can create more value”.
Those are not the same thing.
This is also why some of the current hype feels shallow. Stories about how many lines got written, endless demos of things that vaguely work on first pass. None of that really addresses whether anything of value got created, other than the act of making more software-shaped output.
Friction was doing us a favour
LLMs remove friction from building. But friction was sometimes doing us a favour.
When building something took longer, you had to choose more carefully. You had to kill more ideas earlier. You had to be more selective about which direction deserved a week of your time.
Now the cost of indulging every passing idea is much lower, so you can follow all of them a little bit. The result is not necessarily more clarity. Sometimes it is the opposite.
You end up with more code, more branches, more prototypes, more motion.
But some things just take time.
Understanding a domain takes time. Building trust in a product takes time. Seeing how real users respond takes time. Learning whether a project deserves years of maintenance takes time. No amount of generated code removes that.
Maybe that is why so much of this can feel vaguely hopeless even while the tooling keeps improving. LLMs get better and better at helping us do work that was never the true bottleneck.
And yes, I use LLMs heavily. I am not writing this from the outside. They are useful. Sometimes extremely useful. But I also think they make it easier to confuse acceleration with direction.
And if you accelerate without improving direction, you do not necessarily get where you want to go faster.
You just get lost at higher speed.