> This labour was not the main bottleneck. I’m ready to bet that coding is a small part of the daily activities of a dev.
Labour doesn't mean just "typing", that is your misunderstanding. It means bringing various facets of design together to produce the final code artifact viz. main logic, typing concerns, correctness concerns, exception handling, design/code patterns, elegance, simplicity etc. It is the "cognitive load" that becomes too much. AI frees me up from thinking about all the minutiae but know enough to give instructions which can be followed and later verified. Read Dijkstra's "The Humble Programmer" to understand what i mean.
> That is incredibly wasteful. Requirements are set agains a world model that always evolves against its own set of constraints. Which does ties into the flexibility argument. No need to reinvent the wheel, when only a few things varies and some just stay true for years and decades.
Again a misunderstanding. Fred Brooks said "Plan to throw one away; you will, anyhow". That is exactly what a Prototype/PoC/"naive" MVP is. That doesn't mean you need to throw away everything everytime, it means for complex projects your prototype is often the first time that you have sorted out your requirements, design problems and satisfactorily validated your architecture. Sometimes you have to "throw one away" and restart but usually the product is always evolved (i.e. Product Families, Software Factories etc.) and almost never thrown away completely. That is what design is all about and which the above workflow accommodates. This is standard Software Engineering.
> Nope, it’s not. This is related to having a good mental model of how your software process data, not related to how you design your interface.
Whut? Designing a concrete Interface implies you have sorted out the mental model of how the software structures and processes data. That is why you verify the skeleton app design interfaces w.r.t. your requirements. This is just design philosophy 101. The details of how to drive AI to do this is in your prompt using "architectural constraints", pointers to specific libraries/frameworks/patterns etc.
> As I said, your comments put “code” as a first place citizen, which no experience dev does.
No, it does not, this is your fundamental misunderstanding.
> What I argue about is that it’s always about data, the rules that it follow, which will then be realized by code.
This is just generic platitude but nevertheless taken care of in the workflow above. You allow the tool to do it but with strict guardrails in place. It is manifested in the final approved prototype.
> You don’t write code and assert which type of data that it can handle. That’s a fool errand as the outside world is naturally messy. You define the data first, and then write the code. Meaning when the data changes, the code needs to evolve. You need to have a very good mental how that changes propagate, which you won’t have of you just regenerating code.
This is a fundamental misunderstanding of how DbC works. DbC assertions establish pre/post/inv predicates which define subsets of the program "state space". This means you know the function signature i.e. the types/ranges-of-objects on which you will operate and are establishing their safe subsets within which the code shall operate. You first write the pre/post/inv and then write code to satisfy the constraints. See articles on DbC by Bertrand Meyer given here - https://news.ycombinator.com/item?id=48358691
> That’s why no one builds a factory to produce factories. Although there are common elements, a factory is designed for the product it will create. So you start from the product, you don’t start from the factory. Your methodology is a framework for building factories, but with no mention of any product.
The product is specific to your problem domain and your understanding of it. The above problem-solving workflow can be applied to generate requirements artifacts for a product instead of code if needed. It is a general meta-methodology which you can adapt for any purpose using AI. The stages are just checkpoints to ensure that AI is always under your control i.e. behaves deterministically. As an example, there are now a whole bunch of startups focusing on just "Requirements Modeling", "Specification Driven Development" etc. to structure ambiguous product requirements so that AI does exactly what you want it to do.