10 ms·
> now that we have the compute and proper AI, not just IKBS, we can focus on generating a specification and not the code. A specification that can persist acros
by mirmor23 22d ago
> now that we have the compute and proper AI, not just IKBS, we can focus on generating a specification and not the code. A specification that can persist across the entire SDLC. All a bit like all the other branches of engineering that have drawings, specifications and circuit diagrams and things.
I'm not clear what this is supposed to achieve; if engineers can use AI to generate good specs, what's the issue with using llm in tdd/codegen cycle.
currently, for complex projects with big teams the strategy seems to let llm loose and shoot for impossible deadlines which will likely backfire as llm could generate good code for a small subsystem, it fails frequently in brownfield, large projects resulting in engineering rework;
by considering human effort to code in the release schedule, and then using llm to generate/refactor/tdd a good quality software could be built, without frustrating engineers having to deal with ai slop.
- Lozybug 22d agoGreat 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.