Like many others in the comments, I feel there are a lot of assumptions in this piece. Before, coding is only 14% therefore, small slice. I think that's a very superficial assumption. That was because coding was expensive and we needed to be sure we didn't code the wrong thing. If code is as cheap as it is now, we will optimize differently, we will structure around it. Instead of so many meetings we will code 5 different versions of the same thing and choose, etc.
Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore. Therefore the risk of "coding the wrong thing" is less.
Is it? The temptation to start without a thorough design is now much stronger because the implementation osnperceived to be cheap and easy to replace. But if you start building the wrong thing fast, you still get the right thing later than when you had checked properly at the start.
CICD and iterative development and agile work because interactive building leads to better product. Otherwise we'd all build perfect software using waterfall methodologies and release only once a year. If implementation is cheap then you implement, review and then re-implement. Not even iterate in the extreme case. Throw it away if needed and start from scratch if needed.
Lots os engineering projects took as long as you mentioned because they were horribly specified. Then the engineer either waits for an answer (which they generally do not get) or takes a decision (which might not be ideal without domain knowledge). Then you release and the customer suddenly starts explaining what they want.
You can improve some parts with LLM (make more prototypes, iterate faster), but if humans are the bottleneck and the problem itself is complex it will not be 10x improvement.
Of course, maybe we talk about different type of project, there are also the type of projects like "a web-shop that sells stuff" that someone considered "expensive to code".
Specification is hard because you are trying to predict a future state in a vacuum. You need to do that because creating the product is very expensive coding wise. If instead you could instantly build to your current specification then you could iterate on the specification against a real product. Even if all that code is thrown out the end result would be a better specification.
For some projects specification is also hard because of interdependence between modules or data or parts of the project. To which you might answer "make more tests". And we turn in circles, because it is hard to test something you did not thought of.
My experience is that users (customers) even when presented with a prototype (done fast by AI, or previously, in the slow way) can take days to "discover" or "think" about things they wish. Then more days to understand why some wishes can't be done because it breaks other stuff they want.
Maybe you have smarter, faster, more experienced and decided users. Then I can only say: good for you, you are lucky!
> Coding was expensive in the sense that once you decided what to do, it took a few engineers months / years to do moderately complex projects. That's not true anymore.
This conflates two orthogonal concerns; understanding what needs to be done with encoding a solution for what needs to be done. I am reminded of an axiom I have long held:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> Therefore the risk of "coding the wrong thing" is less.
I disagree with the proposition that being able to generate "wrong code faster" has anything to do with understanding what ultimately needs to be done. In fact, exploratory efforts having the intent to refine problem domain understanding (a.k.a. "proof of concept" projects) is an established industry technique whose work product is best discarded.
> Before, coding is only 14% therefore, small slice.
But also, no, because they write:
> “coding” (not including bug fixing, testing, etc.)
What if bug fixing includes "coding", or "writing code", or however one would want to define that? Especially in the enterprise setting they evoke, a lot of work will not be "coding" in the sense of churning out new features, but "coding" in the sense of fixing bugs. I know a lot of my "coding" is in this category. But we're not given a number for it. I suspect the slice would be bigger if they included this type of "coding".
Basically yes, there will be more coding in that phase, more prototyping, the PRD phases will be shorter too, there will be more pressure to deliver quickly and the PRDs will be under more pressure to move more quickly. This is what I'm already seeing to be honest.
