What these LLMs enable is fixing the foundations. If you considered writing a novel database, operating system, or other foundational piece of software two years ago, you had to be mad. Now you still do, but at least you got a chance.
I can highly recommend these talks to get your eyes slightly opened to how stuck we are in a local minima.
You have the unbelievably productive programmers - we all know their names, we use the code they wrote every day. Then you have the programmers who want to be there and will try everything they can to be there - except gain depth of knowledge. They tend to be shallow programmers. If you give them a task and spell it out, they can knock out code for it at a really good pace and wow upper management. But they will always lack the ability to take a task not spelled out and complete it. Vibe-coding is like sugar and crack mixed together for these people.
> If you give them a task and spell it out, they can knock out code for it at a really good pace and wow upper management.
This is so true. I sometimes spend entire days, weeks, all I do is provide those type of engineers the clarity to "unblock" them. Yet I always wonder, if I had just spent that time coding myself, I might have gotten more done.
But it's also this that I think bottlenecks development. The set of people who really know what needs to be done, at the level of detail that these developer will need to be told, or that coding agents will need to be told, is very small, and that's your bottleneck, you have like 1 or 2 devs on all project that knows what to do, and everyone else need a Standard Operating Procedure handed to them for every task. And now everyone is always just waiting on the same 2 devs to tell them what to do.
Development is always a bottleneck. Writing lines of code usually isn’t. I end up pumping out more leetcode during an interview than I do during a week or two on real products. No one has meaningfully measured lines of code as a metric of productivity since my career began in the mid-2000.
On the other hand, there’s tons of people here on HN who will claim that there’s zero connection between lines of code written and developer productivity. Obviously, deleting bad/unused code is good. And obviously, some tricky bugs are fixed in one line. But you can’t build something new without some (usually, very many) lines of code.
This is just so, so wrong. LLMs change the surface of what's "hard" to do in a coding exercise. Many a project has so much boiler plate, edge cases, etc. that months+ can be taken up dealing with what is ultimately a very boring activity. Add on time to assimilate APIs, bug test, etc. This stuff does matter.
About a decade ago, I was the sole developer for a special project. The code took 2 weeks to complete (a very simple Java servlet + JDBC app) but an entire year to actually deliver due to indecisive leadership, politics, and extremely overzealous security policies. By the time it was successfully deployed to prod, I had been chewed out by management countless times, who usually asked questions like “how on Earth can it take so long to do this one simple thing??”.
The bigger and clunkier the corporation is, the slower the speed of deliveries. And actual development FWIW is somewhere in the range of 1-5% of it all.
Sure, code sweat shops have very different % of above, but thats a completely different game altogether.
You can code PRs fast, but CI, review, merge, deployment, monitoring, all takes just as long as it did before. The inner loop is shrinking; the outer loop is the real bottleneck
It's completely absurd how wrong this article is. Development speed is 100% the bottleneck.
Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front."
Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed.
If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well.
If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.
I think you and the article actually agree and you are arguing only with their use of the word "development."
The article uses "development" to refer only to the part where code is generated, while you are saying "development" is the process as a whole.
You both agree that latency in the real-world validation feedback loop leads to longer cycles and fewer promising solutions and that is the bottleneck.
> Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well.
Thank you for articulating something I knew but haven't been able to express as eloquently.
It frustrates me to no end to watch half a dozen non-technical bureaucrats argue for days about something that can be tried (and discarded) in a few hours with zero consequences.
"Let's write a position paper so that everyone involved can agree before we do anything."
Noooo! Just do it! See if it works in practice! Validate the marketing! Kick the tyres! Go for a test drive. Just. Get. Behind. The. Wheel.
> The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise.
I have found that spending more time thinking generally reduces the amount of failed attempts. It's amazing what "thinking hard" beforehand can do to eliminate reprioritization scrambling.
Even if it were not a bottleneck, speed allow use cases you wouldn't consider before.
I use Python differently because uv made many things faster, less costly. Stuff I used to do in bash are now in Python. Stuff I wouldn't do at all because 3rd party modules were an incompressible expense, now I do because the cost is low.
Same with AI.
Every week, there was a small tool I actively chose to not develop because I know that it would save less time by automating the thing than it would take coding it.
E.G: I send regularly documents from my hard drive or forward mails to a specific email for accounting. It would be nice to be able to do those in one click. But dev a nautilus script or thunderbird extension to save max a minute a day doesn't make sense.
Except now with claude code, it does. In a week, they paid off. And now I'm racking the minutes.
Now each week, I'm getting a new tool that is not only saving me minutes, but also reducing context switching. Those turn into hours, which turn into days. These compounds.
And of course, getting out a MVP, or a new feature demo out of the door quickly allows you to get feedback faster.
In general, AI lets you get a shorter feedback loop. Trash bad concept sooner. Get crucial info faster.
I think development speed is merely tagging the correct causal factor which is expertise. I have witnessed development teams requiring weeks to change a single flag in a configuration flag? Were they slow? Well, yes, but I'd argue they were mostly clueless.
Development is often divided into 80% known unknowns and 20% unknown unknowns. AI can only help with one of those, and it's the one that takes the least amount of time to complete.
Research and thinking is always going to be the bottleneck.
I have very much started to re-evaluate whether I believe in this. I always thought something along the lines of "once you have solved it architecturally, typing it out is the least of your worries".
But with LLMs I'm not so sure. I feel like I can skip the effort of typing, which is still effort, despite years of coding. I feel like I actually did end up spending quite a lot of time doing trivial nonsense like figuring out syntax errors and version mismatches. With an LLM I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things.
This in turn means that I can test more things at the top architectural level. If I want to do an experiment, I don't feel a reluctance to actually do it, since I now don't need to concentrate on it, rather I'm just guiding the AI. I can even do multiple such explorations at once.
I would reconcile the seeming paradox that AI-assisted coding produces more code faster, yet doesn't seem to produce products or features much faster by considering that AI code generation and in particular CoPilot-style code suggestions means the programmer is constantly invalidating and re-building their mental model of the code, which is not only slow but exhausting (and a tired programmer makes more errors in judgement).
It's basically the wetware equivalent of page thrashing.
My experience is that I write better code faster by turning off the AI assistants and trying to configure the IDE to as best possible produce deterministic and fast suggestions, that way they become a rapid shorthand. This makes for a fast way of writing code that doesn't lead to mental model thrashing, since the model can be updated incrementally as I go.
The exception is using LLMs to straight up generate a prototype that can be refined. That also works pretty well, and largely avoids the expensive exchanges of information back and forth between human and machine.
lol.... development speed and quality are both the bottleneck my dude. But if you have enough speed, you can fix quality issues as you are able to test and fix things faster.
You have even CEO of car companies that get fired because they mess this up. Or even the Sonos company lost a lot of value, and got their CEO fired because they messed up and can't fix it in time.
Speed is not everything. Developing the right features (what users want) and Quality are the most important things, but development speed allows you to test features and fix things fast and course correct.
Car companies cannot figure what to develop and how to develop it. They could develop 1000% faster and would still get it wrong. Mostly because they see software as a cheap alternative to metal and rubber and developers as degenerate primadonnas - i.e. not true engineers.
Sonos decided they wanted to centralize their architecture so they could tap into it to make extra surveillance money. They trashed things that worked perfectly and replaced them with a cloudshit architecture that nobody asked for and that _cannot_ deliver the same low-latency, quality experience as before. They could have developed things 1000% faster, they would have just drove a cliff sooner.
Even if people could write apps instantly, nothing would prevent them for being stupid and greedy.
Yeah, “development speed” is almost never the real blocker. I’ve worked on teams where folks shipped code at lightning speed… straight into the wrong direction. Turns out it’s way slower to undo that than to just move carefully with clarity.
How fast can you react to the learning you have from the market, that's the bottleneck. And yes, the development is the big chunk of that reaction time.
The article sort of glosses over this, but to me the real question is delivering value over the long run. This takes patience and tenacity not just from developers but also from management. Making a product that lasts and that evolves and that delivers for your clients is definitely a lot more challenging (and finally rewarding) than vibe-coding an MVP in a couple of weeks. I have the impression that in that regard AI coding tools are quite inadequate and don't really deliver the value they purport to.
That's just another great vantage point to consider when looking at product development.
Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing.
And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche.
At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases.
In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.
Validation is definitely the bottleneck, if you make all your product decisions through a/b tests and wait for a statistically significant result for each feature.
But there are people with great product taste who can know by trying a product whether it meets a real user need - some of these are early-adopter customers, sometimes they are great designers, sometimes PMs. And they really do need to try a product (or prototype) to really know whether it works. I was always frustrated as a junior engineer when the PM would design a feature in a written spec, we would implement it, and then when trying it out before launch, they would want to totally redesign it, often in ways which required either terrible hacks or significant technical design changes to meet the new requirements. But after 15 years of seeing some great ideas on paper fall flat with our users, and noticing that truly exceptional product people could tell exactly what was wrong after the feature was built but before it was released to users, I learned to be flexible about those sorts of rewrites. And it’s exactly that sort of thing that vibecoding can accelerate
We have this saying:
Our clients always know what they want. Until they get it. Then they know they wanted something different.
And don't take that as a complaint. It's a basic behavioral observation. What we say we do is different from what we really do. By the same token, what we say we want is different from what we really want.
At a risk of being a bit sarcastic: we say we want regular exercise to keep fit, but we really want doomscrolling on a sofa with a beer in hand.
In the product development context, we have a very different attitude towards an imagined (hell, even wireframed) solution than an actual working piece of software. So it's kinda obvious we can't get it right on the first attempt.
We can be working toward the right direction, and many product teams don't even do that. For them, development speed is only a clock counting time remaining before VCs pull the plug.
Development speed has been a bottleneck in every major product development effort that I have been involved in. From a realtime medical data collection application where president and VP are drumming their fingers on the desk waiting for development to be finished.
Writing a compiler at Sycor, there were teams waiting for us to finish our development. We were successful, being about an order of magnitude faster than the effort we replaced.
And just because google cancels products doesn't suggest anything about development speed.
If I were an LLM advocate (having much fun currently with gemini), I would let the criticism roll and make book using LLMs.
Oh, I agree that in many companies, internally, we create perceptions that development is, indeed, THE bottleneck.
VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare.
And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a pure waste. Some other parts were actually harmful. They frustrated users, drove key metrics down, or have you. They are worse than waste.
But no one cared to check. Good product people, and there are scarcely few of them, would follow up with validation on what worked and what did not. They would argue against "major" releases whenever possible.
And seriously, if Amazon can avoid major releases, almost anyone could.
Suddenly, we might flip the script and have a VP of Product not asking "when will it be done?" but rather trying to figure out what the next most sensible experiments are.
I completely disagree. As a scientist who does a lot of coding, the modern LLM tools give me ability to code something which previously I could not afford, because I simply did not have time for it.
Now if I have an idea, I may be able to test it in an hour of tinkering with claude/gemini. I could technically still code it myself, but in some cases that would require maybe a day of work -- and I simply don't have that.
You mention one fabulous application of AI-supported coding that the article didn't touch upon. It's anything where the target customer group is me. All sorts of automation, pet projects, and serious stuff that improves research, too.
The context of the article is product development, with a bias toward the commercial part of the ecosystem. And of course, as any picture painted with broad strokes, some generalizations were inevitable.
As a scientist, you definitely are familiar with the weight (or lack thereof) of anecdotal evidence. Unless the claim is "it can never work" or "it always works," my individual experience is just that--an individual experience.
Im not a scientist, just a freelancer (kind of) and its similar for me. I know probably only 2 langauges fluently enough that i could write in them without constantly checking for syntax/docs, but over my whole programming journey i got to know multiple languages with different syntaxes, coding styles and patterns, so i can easily read code written in multiple languages and know whether given code will do what i want (and even if i wouldn't, LLM can explain the code for me and in the worst case send me to the documentation to validate it by myself).
Asking LLM for a code and then read/review it is a huge speed up for me in a lot of cases comparing to when i would need to write the same thing by myself (but i agree it may not work well in a big/complex systems... yet).
Most software projects don't even do A/B tests. A lot of them don't need, it's just what someone wants to ship. Another set can't even get to the sample size required.
But fine, let's take the subset of features / projects that can be tested or somehow validated. In my experience (having worked for 13+ years on companies that prefer to A/B almost everything), more than half of the tests fail. People initially might think the solution is to have better ideas, cook them more, do better analysis. That's usually wrong. I've seen PHDs with 20+ years of experience in a given industry (Search) launch experiments and they still fail.
The solution is to have some sort of "just enough" analysis like user studies, intuition, and business needs, and launch as fast and as many as you can. Therefore, development speed is A bottleneck (there's no Silver Bullet so it's not THE bottleneck).
Development speed absolutely is a bottleneck. But coding speed? Like, typing? Yeah, I can definitely type faster than I can think about code, or anything really (typing at 100wpm is a fun party trick but not super useful in the end). Many times over... Even single finger typers who peck at the keyboard probably can, auto-complete has existed for a long time...
Journalists & executives see you as a sort of savant who spends all your time encoding & decoding the little bits and bytes - mostly a construction worker. They correctly recognize that we ought to be able to build some sort of robot that does this for you - why do it by hand?
They don't understand that this AI was built decades ago and has been improved on several times over: Compilers & Interpreters. Furthermore, you don't need billion-dollar neural-network supercomputers, just a vanilla laptop.
It's because of how you talk about the job, though. We automate every other kind of "coding" - why can't we automate yours?
46 comments
[ 2.7 ms ] story [ 62.9 ms ] threadI can highly recommend these talks to get your eyes slightly opened to how stuck we are in a local minima.
https://vimeo.com/71278954
https://www.destroyallsoftware.com/talks/a-whole-new-world
> If you give them a task and spell it out, they can knock out code for it at a really good pace and wow upper management.
This is so true. I sometimes spend entire days, weeks, all I do is provide those type of engineers the clarity to "unblock" them. Yet I always wonder, if I had just spent that time coding myself, I might have gotten more done.
But it's also this that I think bottlenecks development. The set of people who really know what needs to be done, at the level of detail that these developer will need to be told, or that coding agents will need to be told, is very small, and that's your bottleneck, you have like 1 or 2 devs on all project that knows what to do, and everyone else need a Standard Operating Procedure handed to them for every task. And now everyone is always just waiting on the same 2 devs to tell them what to do.
No code -> no software.
Sure, code sweat shops have very different % of above, but thats a completely different game altogether.
Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front."
Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed.
If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well.
If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.
The article uses "development" to refer only to the part where code is generated, while you are saying "development" is the process as a whole.
You both agree that latency in the real-world validation feedback loop leads to longer cycles and fewer promising solutions and that is the bottleneck.
Thank you for articulating something I knew but haven't been able to express as eloquently.
It frustrates me to no end to watch half a dozen non-technical bureaucrats argue for days about something that can be tried (and discarded) in a few hours with zero consequences.
"Let's write a position paper so that everyone involved can agree before we do anything."
Noooo! Just do it! See if it works in practice! Validate the marketing! Kick the tyres! Go for a test drive. Just. Get. Behind. The. Wheel.
I have found that spending more time thinking generally reduces the amount of failed attempts. It's amazing what "thinking hard" beforehand can do to eliminate reprioritization scrambling.
I use Python differently because uv made many things faster, less costly. Stuff I used to do in bash are now in Python. Stuff I wouldn't do at all because 3rd party modules were an incompressible expense, now I do because the cost is low.
Same with AI.
Every week, there was a small tool I actively chose to not develop because I know that it would save less time by automating the thing than it would take coding it.
E.G: I send regularly documents from my hard drive or forward mails to a specific email for accounting. It would be nice to be able to do those in one click. But dev a nautilus script or thunderbird extension to save max a minute a day doesn't make sense.
Except now with claude code, it does. In a week, they paid off. And now I'm racking the minutes.
Now each week, I'm getting a new tool that is not only saving me minutes, but also reducing context switching. Those turn into hours, which turn into days. These compounds.
And of course, getting out a MVP, or a new feature demo out of the door quickly allows you to get feedback faster.
In general, AI lets you get a shorter feedback loop. Trash bad concept sooner. Get crucial info faster.
Those do speed up a project.
Research and thinking is always going to be the bottleneck.
But with LLMs I'm not so sure. I feel like I can skip the effort of typing, which is still effort, despite years of coding. I feel like I actually did end up spending quite a lot of time doing trivial nonsense like figuring out syntax errors and version mismatches. With an LLM I can conserve more of my attention on the things that really matter, while the AI sorts out the tedious things.
This in turn means that I can test more things at the top architectural level. If I want to do an experiment, I don't feel a reluctance to actually do it, since I now don't need to concentrate on it, rather I'm just guiding the AI. I can even do multiple such explorations at once.
It's basically the wetware equivalent of page thrashing.
My experience is that I write better code faster by turning off the AI assistants and trying to configure the IDE to as best possible produce deterministic and fast suggestions, that way they become a rapid shorthand. This makes for a fast way of writing code that doesn't lead to mental model thrashing, since the model can be updated incrementally as I go.
The exception is using LLMs to straight up generate a prototype that can be refined. That also works pretty well, and largely avoids the expensive exchanges of information back and forth between human and machine.
You have even CEO of car companies that get fired because they mess this up. Or even the Sonos company lost a lot of value, and got their CEO fired because they messed up and can't fix it in time.
Speed is not everything. Developing the right features (what users want) and Quality are the most important things, but development speed allows you to test features and fix things fast and course correct.
Sonos decided they wanted to centralize their architecture so they could tap into it to make extra surveillance money. They trashed things that worked perfectly and replaced them with a cloudshit architecture that nobody asked for and that _cannot_ deliver the same low-latency, quality experience as before. They could have developed things 1000% faster, they would have just drove a cliff sooner.
Even if people could write apps instantly, nothing would prevent them for being stupid and greedy.
Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing.
And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche.
At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases.
In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.
But there are people with great product taste who can know by trying a product whether it meets a real user need - some of these are early-adopter customers, sometimes they are great designers, sometimes PMs. And they really do need to try a product (or prototype) to really know whether it works. I was always frustrated as a junior engineer when the PM would design a feature in a written spec, we would implement it, and then when trying it out before launch, they would want to totally redesign it, often in ways which required either terrible hacks or significant technical design changes to meet the new requirements. But after 15 years of seeing some great ideas on paper fall flat with our users, and noticing that truly exceptional product people could tell exactly what was wrong after the feature was built but before it was released to users, I learned to be flexible about those sorts of rewrites. And it’s exactly that sort of thing that vibecoding can accelerate
And don't take that as a complaint. It's a basic behavioral observation. What we say we do is different from what we really do. By the same token, what we say we want is different from what we really want.
At a risk of being a bit sarcastic: we say we want regular exercise to keep fit, but we really want doomscrolling on a sofa with a beer in hand.
In the product development context, we have a very different attitude towards an imagined (hell, even wireframed) solution than an actual working piece of software. So it's kinda obvious we can't get it right on the first attempt.
We can be working toward the right direction, and many product teams don't even do that. For them, development speed is only a clock counting time remaining before VCs pull the plug.
Writing a compiler at Sycor, there were teams waiting for us to finish our development. We were successful, being about an order of magnitude faster than the effort we replaced.
And just because google cancels products doesn't suggest anything about development speed.
If I were an LLM advocate (having much fun currently with gemini), I would let the criticism roll and make book using LLMs.
VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare.
And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a pure waste. Some other parts were actually harmful. They frustrated users, drove key metrics down, or have you. They are worse than waste.
But no one cared to check. Good product people, and there are scarcely few of them, would follow up with validation on what worked and what did not. They would argue against "major" releases whenever possible.
And seriously, if Amazon can avoid major releases, almost anyone could.
Suddenly, we might flip the script and have a VP of Product not asking "when will it be done?" but rather trying to figure out what the next most sensible experiments are.
The context of the article is product development, with a bias toward the commercial part of the ecosystem. And of course, as any picture painted with broad strokes, some generalizations were inevitable.
As a scientist, you definitely are familiar with the weight (or lack thereof) of anecdotal evidence. Unless the claim is "it can never work" or "it always works," my individual experience is just that--an individual experience.
Asking LLM for a code and then read/review it is a huge speed up for me in a lot of cases comparing to when i would need to write the same thing by myself (but i agree it may not work well in a big/complex systems... yet).
But fine, let's take the subset of features / projects that can be tested or somehow validated. In my experience (having worked for 13+ years on companies that prefer to A/B almost everything), more than half of the tests fail. People initially might think the solution is to have better ideas, cook them more, do better analysis. That's usually wrong. I've seen PHDs with 20+ years of experience in a given industry (Search) launch experiments and they still fail.
The solution is to have some sort of "just enough" analysis like user studies, intuition, and business needs, and launch as fast and as many as you can. Therefore, development speed is A bottleneck (there's no Silver Bullet so it's not THE bottleneck).
Development speed absolutely is a bottleneck. But coding speed? Like, typing? Yeah, I can definitely type faster than I can think about code, or anything really (typing at 100wpm is a fun party trick but not super useful in the end). Many times over... Even single finger typers who peck at the keyboard probably can, auto-complete has existed for a long time...
They don't understand that this AI was built decades ago and has been improved on several times over: Compilers & Interpreters. Furthermore, you don't need billion-dollar neural-network supercomputers, just a vanilla laptop.
It's because of how you talk about the job, though. We automate every other kind of "coding" - why can't we automate yours?