you are correct flow is not achieved as this is not programming more like system design, architecture, QA, Product Owner work. It's using the swarm as your own dev team.
But it's also programming as you have to study outputs to ensure they're correct. Some (it seems many) don't do this, and then their outputs usually aren't correct.
In my experience, QA is something like ensuring it responds correctly to input. This is similar, but not the same as code review. I would more liken QA to dynamic review rather than static. Note though that code review can still be a form of QA. (Formal proofing especially.)
That’s what QA departments in software companies do. In many other contexts they examine things produced by machines to ensure they meet the specs and functional requirements for that piece, and if not, either adjust it, have someone else adjust it, or have the adjusted machine spit out another one. They might design tests, fixtures to measure things, etc etc etc but they do not make the things directly.
To be fair, ensuring that machines produce the correct outputs (even by making someone else fix it) is still the kind of process I'm talking about. After all, that's also how it works in software.
It depends on what the machines are supposed to do. I’ve never worked in software QA, but worked as a developer for over a decade and currently work in manufacturing. Is mass-manufacturing totally different? Sure. QA engineers in small high-complexity single-run prototyping shops? It’s not much different.
> It's using the swarm as your own dev team.
reply
Managing high performance dev/ops teams is it's own form of a state of flow. In fact for me, it's much more addicting than any other as the outcomes are usually many multiples of any IC role you could have. Even crazier when you have a "follow the sun" team involved so there the work just gets sequentially handed off and is always in constant motion.
I imagine AI coding is like this for a lot of folks.