Unfortunately, this is one of those HN submissions where people are just knee-jerking to the title without even checking what the submission is. Of course, it doesn't help that it's a long video conference presentation with a "handout" that's beautiful but a little hard to read through on its own.
However, for those that are actually curious, the submission is not itself a cynical or dismissive take. The question in the title is interrogative and contextual, not rhetorical and universal, and the presentation tries to break down some of the bottlenecks and challenges that are leading to AI integration having a different impact on software engineering output than some people might expect.
Rather than suggesting those bottlenecks/challenges are universal or intractable, it just enumerates some of them and presents some survey analyses on how widely encountered they are.
It's actually pretty interesting and the kind of thing that engineers and those who work with them want to be reflecting on, so that they can better engineer their usage and processes around AI itself.
swatcoder
This is something that Brooks had reflected on already in "The Mythical Man Month":
"One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced."
Brooks argues that the coding that happened in the garage is only a fraction of what you need for the final product:
"It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts."
What we're seeing right now does not feel much different. You can greatly accelerate a first draft, a greenfield project, an experiment, or at least the initial iteration of one. Changing a live production system or a widely used library is an entirely different proposition.
rbehrends
I am shipping so much more, but I don't know that our customers would necessarily know it. Total rewrites that needed to be done but were getting pushed off due to the scope are now getting done. Security issues are getting patched. Support ticket open to resolution time is dropping. So yes, shipping a lot faster to create a much better project rather than just focusing on features.
9cb14c1ec0
One dynamic that AI coding has introduced is that features grow and are more "complete" or "complex" after their first development iteration compared to coding pre-AI. An example of this is that I recently built a web crawler for an internal documentation site at my company. My design for scraping, parsing, vectorizing and indexing the data was far more complex/complete than if I had not used AI. This is primarily due to my lack of knowledge in the space and general time constraints for the project.
That increased complexity, while less costly than before, still added time/cost to the project in terms of cognitive load and testing that otherwise wouldn't have been there had the design been "dumber". This notion of increased design complexity could be thought of as a form of Parkinson's Law where the complexity of the design grows to fill the time available.
I think AI is certainly making us write code faster but how much time is really being freed up now that writing code is cheaper? I get the impression that we are often just finding other things to fill that freed up time with, increased design complexity being one of those things.
degreesoffun
More tickets and larger tickets, full migrations that used to take 4 weeks coordinating with 3 teams are now a single PR done in a day.
edit: if you're seeing a slow down in PRs, it's more likely that 10 of your 10x'ers are slinging code in 3-4 plus accounts in codex on the side during their shift on 8 startups.
throwitaway222
I must say the handout PDF backgrounds are adorable and clearly convey each of the speedup and slowdown points in the process.
NortySpock
I feel like I'm going crazy with all the people questioning the impact of AI in software development.
I think people already have forgotten how long and arduous software development was just a few years ago.
The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
MisterPea
The excitement of LLMs has been around the productivity of the engineers, not the quality of the projects. Traditionally, we have bottlenecks at review and QA stages for new work, and a lot of orgs turn on the firehose of new code without fixing those bottlenecks.
If you want to drive at high speed, you need to build a highway first.
choult
We are. A month of work turned into one day.
0xb0565e486
Don't simply answer the question from the title -- you won't be addressing the substance of the presentation or really any other substantive issue.
Either watch the presentation if you want to spare the time (a big ask even at 2x speed) or move on.
The presentation is about the results from an actual investigation on why a particular group only saw modest improvements in shipping. It will probably be more relevant to groups more like the group studied (a large dev org) than others.
The general idea is that there is a process pipeline between code change and shipping, and LLMs don't necessarily speed up all the steps at the same rate, especially in large, mature products.
comments (10)
However, for those that are actually curious, the submission is not itself a cynical or dismissive take. The question in the title is interrogative and contextual, not rhetorical and universal, and the presentation tries to break down some of the bottlenecks and challenges that are leading to AI integration having a different impact on software engineering output than some people might expect.
Rather than suggesting those bottlenecks/challenges are universal or intractable, it just enumerates some of them and presents some survey analyses on how widely encountered they are.
It's actually pretty interesting and the kind of thing that engineers and those who work with them want to be reflecting on, so that they can better engineer their usage and processes around AI itself.
swatcoder
"One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced."
Brooks argues that the coding that happened in the garage is only a fraction of what you need for the final product:
"It costs nine times as much. But it is the truly useful object, the intended product of most system programming efforts."
What we're seeing right now does not feel much different. You can greatly accelerate a first draft, a greenfield project, an experiment, or at least the initial iteration of one. Changing a live production system or a widely used library is an entirely different proposition.
rbehrends
9cb14c1ec0
That increased complexity, while less costly than before, still added time/cost to the project in terms of cognitive load and testing that otherwise wouldn't have been there had the design been "dumber". This notion of increased design complexity could be thought of as a form of Parkinson's Law where the complexity of the design grows to fill the time available.
I think AI is certainly making us write code faster but how much time is really being freed up now that writing code is cheaper? I get the impression that we are often just finding other things to fill that freed up time with, increased design complexity being one of those things.
degreesoffun
edit: if you're seeing a slow down in PRs, it's more likely that 10 of your 10x'ers are slinging code in 3-4 plus accounts in codex on the side during their shift on 8 startups.
throwitaway222
NortySpock
I think people already have forgotten how long and arduous software development was just a few years ago.
The biggest bottleneck now is CI/CD/Experimentation with respect to engineering, and product alignment with respect to the business.
MisterPea
If you want to drive at high speed, you need to build a highway first.
choult
0xb0565e486
Either watch the presentation if you want to spare the time (a big ask even at 2x speed) or move on.
The presentation is about the results from an actual investigation on why a particular group only saw modest improvements in shipping. It will probably be more relevant to groups more like the group studied (a large dev org) than others.
The general idea is that there is a process pipeline between code change and shipping, and LLMs don't necessarily speed up all the steps at the same rate, especially in large, mature products.
jmull