Wow! Thank you. You've got it. If I put up more info on this and what I'm doing (I'm building a tech demo workbench based on these ideas) would that be of interest? Are you doing anything yourself in this area? You obviously understand the process and the issues.
It might be worth adding that with an approach such as this, it would be possible to meet AI software regulations, for example the EU AI Act and others now coming into force around the world. Other 'regulatory packs' could be obtained directly from the specification. Would AI generated code and no-code built systems be able to do that without much post-hoc activity? What do you think?
Great questions. By using the AI to help elicit requirements and then to generate a spec using a formal software development method you bridge the gap between the users intentions and the code. The spec is visible to the user and is in a form that is easily understood by the user. AI is not used to generate the code so token burn is greatly reduced. This maybe of significance enterprises and also if the cost of tokens increases (Chinese llms may help keep costs down here at least for a while). This maybe similar to using llms and test driven development to produce the code. I'll do some more research on llm/tdd/codegen to see how that compares to what I stated to start off this topic. Thank you, I might learn something here.
Your quite correct, the spec does in effect become the code and the workbench that produces that spec is in effect a system compiler because a system is a program that executes exactly once. Can you expand on empty please. You have something useful to say that I am not quite grasping. I can only add that the spec can be reviewed and changed by the user with help from the AI. The spec would use a user friendly specification language that the user can quite easily understand. This gets rid of the black box spaghetti code generated by the AI. The target computer language of choice is then produced but not by using AI. The code is deterministic and suitable for safety, mission and business critical systems whilst satisfying AI software regulations. The spec then persists across the SDLC. Hope that helps, if only a little.
Great site and great idea. I'm not sure I can add much to 'detecting' AI slop when it comes to code except to assume that all AI coding tools, particularly AI no-code tools, produce code slop. For me, the way round that is to take the screens and get the inputs and outputs from that plus any processing rules and get the AI to build a spec. Then from that mechanically produce the code deterministically without AI with zero token usage. The spec of course being target language independent. The spec can of course be reviewed by the user and changed as required before code is produced, I hope that helps.