Researchers in workflow and process mining (van der Aalst, Russell et al.) catalogued 43 control-flow patterns: ways that tasks can be sequenced, split, merged, cancelled, and looped. The basics are Sequence (A then B), Parallel Split (A then B and C in parallel), Synchronization (wait for B and C then D), Exclusive Choice (A then B or C but not both), and Simple Merge (B or C then D). From there you get multi-choice, discriminator, deferred choice, multiple instances, cancellation (task, case, region), structured loops, and more. The full list is a reference for “what kind of flow am I building?”
For AI-generated code the relevance is this: the model often implements one or two of these patterns (e.g. a sequence or a simple branch) but misses the rest. It might add a parallel split and forget the synchronization. It might add a retry loop but not the cancel path. It might create multiple instances without a join. So the generated code can look right locally but violate the pattern — and that’s when you get stuck states, lost work, or races. Knowing the 43 patterns gives you a checklist: after the model generates code, which pattern is it trying to implement? Is the full pattern there?
You don’t have to implement all 43. Many systems only need a few: sequence, choice, maybe a retry or a timeout. But having the vocabulary helps. When you prompt the model (“add a retry with exponential backoff”), you’re asking for a specific pattern. When you review, you can ask “did we get the full pattern or only part of it?”
Formal workflow languages (BPMN, etc.) encode these patterns explicitly. In code they’re implicit. The gap is where bugs hide. Making the pattern explicit (in a spec or a diagram) and then checking the code against it is one way to keep AI-generated code structurally sound.
Expect more tooling that maps code to these patterns and flags incomplete or inconsistent implementations.
nJoy 😉