You need software engineers and architects to design the flow and hld and to some level lld, but for the grunt worm it may be better to use coders as well, there are more of them and cheaper. And invest in great qa, preferably pessimists who believe there is something wrong with the code.
I’ve experienced a whole host of problems with this approach. The QA team isn’t knowledgeable enough to do anything outside of auditing _process_ compliance. This won’t catch bugs, design flaws, etc.. and the transfer of knowledge from the architects to the ‘coders’ is often riddled with misunderstandings and confusion. Multiply with production schedules and the need to mark something as ‘complete’ (in tools) and you get a massive problem (poor quality) that just has to be resolved further down the pipe. This is particularly problematic in the automotive industry where SOP dates are basically set in stone, with poor upfront scheduling (not matching provided estimates) and new feature demands during the program from the customer.
It’s very tempting. It’s treating the ‘coding’ part like an assembly line. It *can* work so long as estimates are respected in the schedule and you have very effective review processes during the knowledge transfer....but this is where I see it break down, especially when teams are too lean - which usually seems to be the case when you’re tempted by constantly lowering costs.