That ones tricky, because most of computing is composing primitives distilled out of the ambiguous mess of a business context. Your implementations are the bones of process left when you've peeled back the skin, cut out all tha musculature, and removed anything resembling a squishy bit, just leaving a skeleton.
So you're asking the computer to look at bones, and vomit forth a description of just WTF you were trying to do in the first place, when the same set of primitives, configured in the same way, could solve problems in thousands of different contexts.
There may be more success going the other way: distilling the config of primitives from the messiness of requirements; which strikes me as something similar to what is called a prompt engineer; however, the biggest difference there is the additional burden of cutting through BS.
yeah, in the case of the second approach it might have to be more of a dialog than a one of translation from requirements, in the same way you might have a dialog with chatGPT to clear up ambiguity.
So you're asking the computer to look at bones, and vomit forth a description of just WTF you were trying to do in the first place, when the same set of primitives, configured in the same way, could solve problems in thousands of different contexts.
There may be more success going the other way: distilling the config of primitives from the messiness of requirements; which strikes me as something similar to what is called a prompt engineer; however, the biggest difference there is the additional burden of cutting through BS.