The popular/recommended pattern for using Jenkins pipeline is to abstract the course grained build "steps" out to shell scripts and to use Jenkins pipeline to orchestrate the whole build process by running these steps at the right time (in parallel blocks etc), capturing human approval, making it all "durable" (tolerant of restarts) etc etc. If you find yourself putting lots of complex build logic into a pipeline script, then you're probably doing something wrong.

Doing it this way reduces the tie to the "product" and also means that you can easily test the individual self-contained steps outside of the product.

I can confirm that this is the pattern that folks on Concourse have moved towards as well.

When the CI system has high-level primitives for showing and organising build graphs, it makes sense to surface those instead of burying them inside a relatively opaque build tool.

Many teams opt to keep most of the logic of their process inside shell scripts or build tools (like Maven or Make). I'm not sure if there is any standard way of defining a Pipeline in the way I think you are asking that is tool agnostic.

Building locally is a good one and thats something I am thinking about in the long term.