Zig's SPIRV support is on the same abstraction level as GPU shading languages (GLSL, MSL, HLSL, WGSL, ...), there's nothing particularly "magic" about turning imperative source code (no matter if Zig or any other language) into a sequence of SPIRV instructions, it's not all that much different from generating x86 or ARM instructions.

The main difference to 'traditional' CPU programming is that you don't write an entire 'application' with a single main function, but instead many small-ish self-contained functions that will run 'per vertex', 'per pixel' or 'per compute invocation' on the GPU.

The Zig toolchain is only concerned about how to compile Zig code into SPIRV blobs, but not about how that code is then 'uploaded' and 'orchestrated' on the GPU, instead this is the job of APIs like Vulkan (e.g. there is no magic integration between CPU- and GPU-side code in the Zig toolchain like in the CUDA toolchain).

SPIRV's specification basically defines what features Zig needs to expose as specialized builtins or language features (e.g. things like `@SpirvType(.sampler);` or `@SpirvType(.{ .image = .{...` or `@extern(*addrspace(.constant)` map directly to SPIRV concepts (the same concepts that dedicated shading languages had to add on top of C or C++).