You inherit a Kotest suite of several thousand tests that takes 40 minutes and runs entirely serially. How would you decide how much of it to run concurrently, and how would you keep the result trustworthy rather than intermittently red?

## Start with data, not settings The first mistake is turning knobs before knowing the shape of the 40 minutes. Collect per-spec durations. Three shapes are common and they lead to different answers. - **Long tail of small tests** — thousands of specs at a second or two, mostly waiting on IO. Coroutine concurrency across specs is close to a free win. - **A few whales** — three specs consuming most of the wall clock. Concurrency across specs cannot beat the longest single spec, so the first fix is splitting those specs, or enabling within-spec concurrency for them specifically. - **CPU-bound bodies** — heavy serialisation, crypto, big in-memory fixtures. Here threads (`parallelism`) matter more than coroutine concurrency, and you are bounded by the agent's cores. Stating this distinction is what separates a principal answer from a mid-level one: the target is not "make it concurrent", it is "identify the bottleneck and apply the matching lever". ## Order of adoption Raise `concurrentSpecs` first. Specs are usually reasonably independent of one another, whereas tests inside a spec frequently share fields on the spec instance and are the likeliest to race. `concurrentTests` is the second step, applied where a whale spec forces it, and it interacts with how much state the spec instance holds. Roll out module by module rather than repo-wide. A module is a unit someone owns and can triage; a repo-wide flip produces a wall of failures that nobody claims and that ends with the flag being reverted. ## Proving it, not hoping Concurrency defects are probabilistic. Establish an acceptance bar before widening: the module runs N times consecutively green, with randomised spec and test ordering enabled. Randomised ordering belongs in the same rollout because it finds the same class of defect — hidden coupling — in a form that is easier to debug than a race. A nightly job that runs the suite several times with concurrency and randomisation, separate from the PR job, is the standard structure. PR runs stay deterministic and fast; the nightly hunts for coupling. That keeps developer trust intact while still surfacing problems. ## Containment versus cure `@Isolate` is the pressure valve: a spec marked with it never runs alongside others, so one offender does not block the whole rollout. The discipline is that every `@Isolate` is recorded as debt with an owner and a reason. Left untracked, the annotation spreads until the suite is serial again, but now with the illusion of concurrency configured. The real fixes are structural: per-test transactional rollback or a schema per worker so the database stops being shared; deleting global mutable state; injecting a clock rather than freezing a global one; unique ports and generated temp paths; per-test rather than static mocking. `.config(blockingTest = true)` handles the narrower case of a body that blocks its thread and would otherwise starve the dispatcher. ## The costs nobody budgets Concurrency multiplies resource demand. Eight concurrent specs may need eight database connections, eight containers, eight ports — on an agent sized for one. The suite can get *slower* from contention, or start failing on pool exhaustion, and the team blames the framework. Size the agents and the pools as part of the change. Debuggability degrades too: interleaved log output means a failure's context is mixed with unrelated work. Per-test output capture and structured logging are worth doing before widening, not after the first confusing failure. ## Knowing when to stop There is a point where more concurrency buys minutes and costs trust. If the suite is at eight minutes and the remaining gain is two minutes at the price of intermittent redness and doubled infrastructure, stop — and put the next increment of effort into deleting redundant tests or moving coverage down the pyramid instead. The goal is a fast suite people believe, not a maximally parallel one.