Explain the build-time vs runtime processing model in Quarkus?

Quarkus's core architectural idea is splitting application processing into two clearly separated phases: an augmentation phase that happens once during the build, and a runtime phase that happens every time the application actually starts and serves traffic.

During augmentation, every active extension's build steps run, consuming and producing BuildItems, ultimately generating optimized bytecode (or, for a native build, feeding GraalVM's native-image tool) that already reflects the fully-resolved application — beans wired, configuration validated, reflection registrations determined.

Because that heavy lifting is finished before the artifact even exists, the runtime phase has almost nothing left to figure out: it loads the already-optimized result and starts serving requests, which is the mechanical reason Quarkus applications start so much faster than frameworks that perform this same discovery and wiring work fresh on every single boot.