> The whole things kinda read as an idealistic and very wrong view of software engineering.
You have not correctly understood what i wrote.
The above is a battle-tested methodology based on experience/studies/trial-and-error and now being adapted to AI with extra tweaks. Labour which was the main bottleneck earlier is now cheap and hence we can afford to be "idealistic" since the tool is immensely powerful.
You need to expand and iterate each stage above (both individually and as a group with previous stages) in stepwise-refinement to get to what you want.
The rest of your comment is just generic platitudes and some common red herrings which i often see on HN, viz.
> main thing that drives it is the set of requirements...By analyzing the requirements,..But often requirements are evolving concepts.
Everybody just keeps parroting this without understanding. Requirements change but always in a staged manner and not willy-nilly. Hence there is always a window of time when your "Requirements Document" is frozen and you can implement a PoC/Prototype against it. The is the "naive" MVP i mention above. Later when requirements change you reiterate and regenerate your prototype and continue.
Note that the gp already had his UML design and only wanted a way to convert it to code. Hence i did not discuss requirements gathering and analysis here. Nonetheless, i had discussed this earlier in some previous comments - https://news.ycombinator.com/item?id=48274873 https://news.ycombinator.com/item?id=48264680
> Platform...libraries...frameworks...design patterns...
These are all covered under (1.c) above where you explicitly list out what to use and what not to use. These are all part of the "architectural constraints".
> So what's left then is the assembly...So you don't want your structure (architecture) to be that rigid. You can't really know the direction of evolution, so you try to predict it in some way and add flexibility in a few places. This is more an art, but there are general techniques that works well enough.
This is covered under (1) above where i enforce rigid adherence to "modularity" and "separation of concerns" by making each module's public interface narrow and extensible (eg. ioctl like) and its parameters future-proof by using versioned struct/class inheritance (eg. sockaddr). These are all well-known code patterns used in OS implementations/libraries.
> The assembly itself is a matter of data and process. How each module is initialized, its lifecycle, which data it consumes, which data it produces.
This is taken care of by having modules follow the LKM model with ioctl interface as explained above.
> Programming concepts like type checking, memory safety, paradigms (oop, functional, relational,...), formal verification,... are all about data. Code always come in second place. So think hard about your data and its transformation.
DbC methodology is the quintessential "data-driven" programming since the pre/post/inv are predicates to establish sets of data values on which the subsequent code can operate safely i.e. DbC establishes the data path for the code.
> Labour which was the main bottleneck earlier is now cheap and hence we can afford to be "idealistic" since the tool is immensely powerful.
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.
> Later when requirements change you reiterate and regenerate your prototype and continue.
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..
>> The assembly itself is a matter of data and process. How each module is initialized, its lifecycle, which data it consumes, which data it produces
> This is taken care of by having modules follow the LKM model with ioctl interface as explained above.
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.
—-
As I said, your comments put “code” as a first place citizen, which no experience dev does. What I argue about is that it’s always about data, the rules that it follow, which will then be realized by code.
> DbC methodology is the quintessential "data-driven" programming since the pre/post/inv are predicates to establish sets of data values on which the subsequent code can operate safely
Like the one above. 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.
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.
> 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.
Maybe we’re talking past each other. But my main point is that the framework you proposed should be more geared towards a thinking model instead of a recipe to blindly to produce code. Code are highly contextual of the data you have to process.
So you can get AI to produce code, but you should refine your mental model alongside it and not try to build a scaffold as that would always be too generic and wrong. As a scaffold good enough is already code. So exoskeletons mindset, more than hive mindset.
As i point out in my last para, the above methodology is generic and at a meta level in order to use AI deterministically. You need to come up with the specifics for your end goal (i.e. product) at each stage. The iteration on the mental model and its refinement into concrete interfaces and thence onto a prototype (i.e. for "Algorithms+Data Structures=Programs" courtesy Niklaus Wirth) is built into the Top-Down and Stepwise-Refinement meta principles themselves.
I suspect your confusion lies in not looking at the end-to-end aspects of Software Engineering and only focusing on local aspects of Design.