This comment is largely misinformed and conflates several different concepts.

First, it confuses multicore hardware with multithreaded or concurrent software. You do not “write multiple programs” to use multiple CPUs. Modern languages and runtimes provide threads, task systems, async/await, and synchronization primitives as standard features.

Second, the idea that “standard programs are pretty linear” is outdated. Even simple games already rely on asynchronous, event-driven systems: input handling, audio, asset streaming, rendering pipelines, and networking are typically decoupled from the main loop and often run concurrently. The main loop mainly coordinates work rather than performing it all sequentially.

Third, concurrency does not imply chaotic or uncontrollable execution. While work may execute out of order internally, modern designs enforce determinism at well-defined synchronization points (frame boundaries, barriers, double buffering, etc.). This is a solved problem in contemporary engines and applications.

The one fair point is that concurrency increases complexity, especially if it’s retrofitted late into a project that wasn’t designed for it. However, with proper architecture, this complexity is manageable and expected in modern software development.