Guidelines for the Application of Hybrid Software Design Patterns

Michal Baczyk

and Ricardo P

erez-Castillo

Alarcos Research Group, University of Castilla-La Mancha, Ciudad Real, Spain

Alarcos Research Group, University of Castilla-La Mancha, Talavera de la Reina, Spain

Keywords:

Quantum Software Engineering, Patterns, Design Patterns, Circuit Design, Quantum Algorithms.

Abstract:

Quantum Software Engineering is increasingly leveraging design patterns to codify best practices for develop-

ing quantum algorithms and applications. In this work, we conduct an extensive review of academic sources

and open-source projects focused on quantum software design patterns. We identify dozens of recurring pat-

terns spanning quantum algorithm structure, state preparation, data encoding, hybrid quantum-classical work-

ﬂows, variational algorithms, and execution strategies. We organize these patterns into a uniﬁed framework,

providing a guide detailing each pattern’s qubit and gate requirements, classical processing needs, and catego-

rization relevant from the application perspective. We observe a key trend of the expansion of pattern catalogs

to support hybrid variational algorithms and NISQ-era challenges (e.g., warm-starting, circuit cutting), and

the emergence of patterns to improve modularity, reusability, and interoperability of quantum software. Our

ﬁndings aim to guide practitioners in applying proven design solutions in quantum application development.

1 INTRODUCTION

Quantum computing promises exponential speedups

for certain classes of problems, but designing cor-

rect and efﬁcient quantum programs remains chal-

lenging. As the ﬁeld matures, there is an increasing

need for systematic software engineering principles

tailored to quantum computing (Piattini et al., 2020;

Serrano et al., 2022). The Talavera Manifesto for

Quantum Software Engineering highlights the impor-

tance of improving quantum software quality through

higher-level abstractions and best practices.

In practice, quantum software rarely exists in iso-

lation but is integrated with classical components,

forming hybrid quantum-classical systems. A well-

deﬁned software architecture for such hybrid systems

fosters key beneﬁts: it enables scalable integration of

emerging quantum hardware, supports modular and

reusable designs, and provides high-level abstractions

that simplify maintenance and evolution. Moreover,

it facilitates smooth interoperability among different

hardware providers (e.g., IBM, Rigetti, IonQ, QuEra,

etc.) and helps standardize best practices that promote

reliability and predictability in quantum software de-

velopment.

In classical software engineering, design patterns

have long been used to capture reusable solutions

to common design problems (Gamma et al., 1994;

Buschmann et al., 1996). Likewise, researchers have

begun identifying quantum software design pat-

terns: recurring strategies that arise in quantum algo-

rithm design and hybrid quantum-classical program-

ming (Leymann, 2019; Weigold et al., 2022). In

recent years, a nascent pattern language for quan-

tum computing has emerged (Weigold et al., 2021;

Jim

enez-Fern

andez et al., 2023), documenting core

quantum algorithm patterns such as state initializa-

tion, oracles, and amplitude ampliﬁcation (B

uhler

et al., 2023; Truger et al., 2024), as well as data

encoding patterns (Weigold et al., 2022; B

uhler

et al., 2023), patterns for variational and hybrid al-

gorithms (Weigold et al., 2021), and execution strate-

gies (B

uhler et al., 2023; Georg et al., 2023; Bechtold

et al., 2023).

These patterns aim to improve reusability, main-

tainability, and interoperability in quantum software,

yet there are few guidelines on how to systematically

select and apply them. This gap hinders the effec-

tive design of hybrid quantum-classical software ar-

chitectures, undermining the realization of their ben-

eﬁts. To address this, we conduct a review and

synthesis of quantum software design patterns re-

ported in academic literature and gleaned from real-

world implementations. Our analysis extends beyond

published research to open-source repositories (e.g.,

Qiskit, PennyLane), extracting practical insights into

Baczyk, M. and Pérez-Castillo, R.

Guidelines for the Application of Hybrid Software Design Patterns.

DOI: 10.5220/0013539500004525

In Proceedings of the 1st International Conference on Quantum Software (IQSOFT 2025), pages 105-111

ISBN: 978-989-758-761-0

105

how these patterns are employed in actual quantum

development workﬂows.

In this paper, we identify all relevant design

patterns for hybrid quantum-classical software sys-

tems and organize them into logical categories. Ta-

ble 1 provides a uniﬁed view of these patterns, detail-

ing their quantum resource requirements (number of

qubits and gates), classical pre-/post-processing, and

typical use cases. We exclude low-level error correc-

tion or mitigation patterns – we focus on higher-level

algorithmic and software-structural guidance.

Section 2 presents a comprehensive catalog of

quantum software design patterns, summarizing their

resource footprints, classical components, and known

limitations, as well as discussing how they address

key challenges in the current Noisy Intermediate-

Scale Quantum (NISQ) era. We then illustrate, in Sec-

tion 3, how modern frameworks such as Qiskit, Cirq,

PennyLane, and Amazon Braket implement these pat-

terns through abstractions for oracle creation, data en-

coding, and hybrid optimization loops. By consoli-

dating these insights, we aim to provide a clear set

of guidelines for selecting and applying design pat-

terns in the development of robust hybrid quantum-

classical software systems.

2 QUANTUM SOFTWARE

DESIGN PATTERNS AND

THEIR APPLICABILITY

Table 1 summarizes quantum software design pat-

terns. Each entry highlights:

• Name / Purpose: Brief description of the pattern

and the main algorithmic function.

• Resource Footprint: Number of qubits, types of

gates, and expected circuit depth.

• Classical Processing: Details on any pre-/post-

processing or real-time feedback loops.

• Topology Constraints: Special hardware con-

nectivity considerations.

• Typical Applications: Common use cases and al-

gorithmic settings.

• Limitations: Known challenges, such as high

gate counts or noise sensitivity.

• Reference: Key literature references for further

reading.

These patterns can be grouped into high-level cat-

egories. The Algorithm Core patterns address funda-

mental quantum operations like Initialization or Ora-

cle building, crucial to tasks such as search or decision

problems. Data Encoding patterns deﬁne how classi-

cal data is loaded into quantum states, impacting re-

source requirements and circuit depth. Hybrid Algo-

rithms focus on parameterized or iterative approaches

that integrate classical optimization. Software Module

patterns promote modular, maintainable code through

reusable components, while Execution and NISQ pat-

terns attend to real-world implementation details, es-

pecially under limited qubit counts and noisy condi-

tions.

2.1 Applicability in Hybrid

Quantum-Classical Workﬂows

The Classical Processing and Topology Constraints

columns in Table 1 are particularly relevant to hybrid

approaches. Patterns like Variational Quantum Al-

gorithm or Ad-hoc Hybrid emphasize iterative feed-

back loops and repeated measurements. Here, hard-

ware constraints and available classical computation

strongly inﬂuence pattern selection. For example,

Circuit Translator patterns are vital when match-

ing a logical circuit to the hardware coupling map or

when bridging different quantum frameworks.

2.2 Guidelines for Pattern Selection

In this subsection, we present guidelines for practi-

tioners to help them choose design patterns for hy-

brid quantum-classical applications. Our approach is

based upon the analysis patterns outlined in Table 1,

which incorporates both usual considerations (e.g.,

Resource Footprint, Classical Processing, Topology

Constraints) and increasingly important factors (e.g.,

Problem Addressed, Quantum-Classical Interaction

Type, Scalability Considerations). By considering all

those factors, we aim to help developers identify pat-

terns that align with their speciﬁc goals, hardware re-

sources, and software architecture.

Below we outline the step-by-step process.

1. Identify the Core Challenge and Relevant Pat-

tern Category:

Begin by clarifying the central problem the hy-

brid system is intended to solve. Whether the

goal involves data initialization (Amplitude En-

coding, Basis Encoding), processing functionality

(Oracle, Entanglement), or optimization (Varia-

tional Quantum Algorithm), identifying this fo-

cus narrows down which categories (e.g., Algo-

rithm Core, Data Encoding, Hybrid Algorithms)

are most useful.

2. Estimate the Resource Footprint and Com-

plexity:

IQSOFT 2025 - 1st International Conference on Quantum Software

106

Table 1: Quantum software design patterns: Core algorithmic patterns, data-encoding strategies, hybrid algorithms, modular

software components, and NISQ execution strategies.

Name / Purpose Resource Footprint Classical Processing Topology Constraints Typical Applications Limitations Reference

Algorithm Core

Initialization Requires qubits for the problem

size; no gates for the all-zero

state (default for many SDKs).

Minimal depth if standard.

No classical overhead unless

advanced prep is used (classi-

cal data might deﬁne angles).

Not sensitive to hardware

connectivity if no entan-

gling gates.

Fundamental for most quan-

tum algorithms (simulation,

cryptography, etc.).

Gate overhead grows for non-

trivial states; prone to prep er-

rors on noisy devices.

uhler et al.,

2023; Leymann,

2019)

Uniform Super-

position

Needs as many qubits as

the input size; typically one

Hadamard per qubit. Depth

about one plus overhead.

No big classical overhead; op-

tional control for adaptive se-

quences.

Single-qubit operations

only, weakly dependent on

connectivity.

Common in Grover’s search,

amplitude ampliﬁcation.

Phase errors may accumulate;

precise single-qubit calibrations

needed.

uhler et al.,

2023; Weigold

et al., 2022)

Entanglement At least two qubits; uses con-

trolled gates (CNOT, CZ).

Depth depends on pairs.

Usually no classical over-

head. Possibly some coordi-

nation in hybrid programs.

Important if qubits are not

directly connected; may re-

quire gate routing.

Central in teleportation, su-

perdense coding, error cor-

rection, EPR pairs.

Sensitive to decoherence and

cross-talk; higher error rates.

(Leymann,

2019; B

uhler

et al., 2023)

Oracle Qubits depend on the function;

custom multi-qubit gates or se-

quences. Depth follows func-

tion complexity.

Classical pre-processing to

build the reversible circuit.

Post-processing to check ora-

cle results.

Routing needed if connec-

tivity is limited. Multi-

controls might need ancil-

las.

Key for search, Boolean

function evaluations, etc.

Large oracles consume re-

sources; mapping from classical

logic can be complex.

(Georg et al.,

2023)

Uncompute Often uses ancillas; same gate

count as forward subcircuit in

reverse. Depth roughly doubled.

No extra classical overhead;

purely quantum. Possibly

some logic for subcircuit

choice.

Constraints mirror the

original subcircuit.

Clears ancilla qubits (restor-

ing them to zero). Common

in arithmetic, phase estima-

tion.

Doubles depth, increasing over-

all error.

uhler et al.,

2023)

Amplitude Am-

pliﬁcation

Depends on scale; oracle plus

diffuser repeated. Gate count

and depth scale with iterations.

Optional measurement at the

end. Feedback loops in adap-

tive variants.

Limited by multi-qubit

gate connectivity.

Used in Grover’s search,

combinatorial optimization.

Iterations grow as square root of

problem size; gate errors accu-

mulate.

(Bechtold et al.,

2023)

Data Encoding

Basis Encoding Uses ⌈log

(k)⌉ qubits for k

states; may need bit-ﬂip gates or

none if already binary. Very low

depth.

Classical data in binary. Min-

imal post-processing unless

partial qubit measurement.

Few connectivity de-

mands; mostly single-qubit

or simple controls.

For categorical states, clas-

siﬁcation, simpler quantum

tasks.

Inefﬁcient for large k; misses

amplitude-based advantages.

(Weigold et al.,

2022)

Amplitude

Encoding

⌈log

(M)⌉ qubits for M-dim

data. Potentially O(M) gates for

arbitrary loads.

Classical pre-processing to

get angles or normalize data.

Post-processing to check ﬁ-

delity.

Can be connectivity-heavy

if multi-qubit gates are

needed.

Used in Quantum Machine

Learning, Principal Compo-

nent Analysis, or amplitude-

based speedups.

Large data = big gate count;

noise sensitivity.

uhler et al.,

2023)

Angle Encoding One qubit per feature; single-

qubit rotations. Depth is how

many rotations.

Feature values mapped to an-

gles. Post-processing checks

ﬁnal correlations.

Low connectivity demands

if no entangling layers.

Popular in near-term QML,

classiﬁers, variational cir-

cuits.

Limited features per qubit; rota-

tion errors matter.

uhler et al.,

2023; Georg

et al., 2023)

Quantum Ran-

dom Access

Memory Encod-

ing

Needs log

(M) address qubits +

data qubits. Multi-controls can

grow depth.

Classical data must be or-

ganized for random access.

Post-processing reads out

lines.

Complex routing if con-

nectivity is limited; multi-

controls.

Enables large-scale QML or

database queries in superpo-

sition.

Building true QRAM is hard;

multi-controlled gates raise er-

ror.

(Georg et al.,

2023)

Quantum Asso-

ciative Memory

Qubit count scales with pattern

dimension. Summation of basis

states. Depth varies by retrieval

method.

Might need classical query

for retrieval. Post-processing

identiﬁes matched pattern.

Controlled gates might be

required; connectivity can

matter.

Used in pattern match-

ing, content-addressable

searches, some QML.

Scalability uncertain; large cir-

cuits can be error-prone.

(Weigold et al.,

2022)

Hybrid Algorithms

Variational

Quantum

Algorithm

Problem-dependent qubits;

param. circuit layers (single-

/two-qubit gates). Depth

depends on layer count.

Classical optimizers update

gate params after measure-

ments. Pre-/post- steps for

param setup routines.

Needs mid-circuit mea-

surement or repeated runs.

Entangling layers may

need good connectivity.

Foundational for near-term

heuristics: QML, chemistry,

optimization.

Sensitive to noise, barren

plateaus, slow or stuck classical

optimization.

(Weigold et al.,

2021)

Variational

Quantum

Eigensolver/

Quantum

Approximate

Optimization

Algorithm

Qubits match system/graph.

Param. ansatz with single-/two-

qubit gates. Depth grows with

layering.

Needs iterative classical opti-

mization. Post-processing ob-

tains ﬁnal params/energies.

Connectivity shapes

ansatz. Distant qubits may

need swaps.

VQE for ground-state ener-

gies, Quantum Approximate

Optimization Algorithm for

combinatorial tasks.

Excess depth undermines ad-

vantage; more layers raise gate

errors.

(Weigold et al.,

2021)

Warm-starting Same qubit/gate needs as main

approach, plus minor overhead

for classical solutions.

A classical solver seeds initial

parameters; post-processing

is standard.

No extra constraints be-

yond regular variational

circuits.

Speeds up hybrid tasks

(portfolio, max-cut) with

classical seeds.

Depends on seed quality; may

fail if guess is poor.

(Truger et al.,

2024)

Software Module

Quantum Mod-

ule

Qubits/gates depend on module

function. Depth varies with rou-

tines.

Classical inputs set params;

post-processing reads states

or outcomes.

Depends on module. Many

entangling gates can be

connectivity-heavy.

Reusable quantum logic

(e.g. arithmetic, oracles,

transformations).

Large modules can be resource-

heavy; must integrate carefully.

uhler et al.,

2023)

Hybrid Module Any size, combining quantum

subcircuits + classical routines.

Depth includes quantum + clas-

sical overhead.

Typically has quantum-

classical loops, measurements

feed classical logic.

Quantum portion needs

connectivity. Classical part

may add latency.

Used for end-to-end hybrid

solutions, iterative or data-

driven workﬂows.

Complex debugging/tuning; re-

peated hardware calls can be

slow.

uhler et al.,

2023)

Circuit Transla-

tor

Rewrites circuits without direct

qubit use. Gate count depends

on decomposition.

Uses classical logic to opti-

mize or rewrite gates.

Must match hardware cou-

pling, so connectivity is

key.

Enables cross-framework or

cross-hardware circuit com-

patibility.

Poor translations can increase

depth or gates, reducing ﬁdelity.

(Georg et al.,

2023)

Execution and Noisy Intermediate-Scale Quantum (NISQ)

Standalone Exe-

cution

Follows ﬁnal compiled circuit’s

qubits/gates. Depth per chosen

algorithm.

Minimal overhead, typically

just job submission and result

retrieval.

Compile-time connectivity

handling, no dynamic

feedback.

For quick prototyping of

small circuits without ad-

vanced mitigation.

Constrained by hardware coher-

ence/ﬁdelity; no built-in mitiga-

tion.

(Piattini et al.,

2020)

Ad-hoc Hybrid Same as circuit, plus overhead

for repeated loop runs.

Host code runs pre-/post-

each quantum run for param-

eter/data adjustments.

No extra constraints, but

repeated calls are time-

consuming.

Prototyping or small-scale

hybrid demos in research

settings.

Inefﬁcient for large param

sweeps; lacks advanced re-

source management.

(Weigold et al.,

2021)

Pre-deployed Supports any qubit/gate scale,

subject to practical limits. Re-

peated instantiation.

Classical logic routes jobs,

collects results, handles

scheduling.

Connectivity matters for

distributed or cloud hard-

ware.

Used by cloud-based

enterprise solutions and

repeated/persistent quantum

jobs.

Scheduling/queue overhead

adds latency; limited real-time

control or debugging.

(Georg et al.,

2023)

Circuit Cutting Splits large circuits into subcir-

cuits. Each subcircuit ﬁts local

qubit limit.

Combines subcircuit mea-

surement results for global

outcome.

Connectivity matters in-

side subcircuits; classical

stitching logic is key.

Distributes large computa-

tions for resource-limited

hardware.

Post-processing grows with

cuts; noise accumulates.

(Bechtold et al.,

2023)

Next, examine the Resource Footprint column for

an overview of the qubit count, gate depth, and

other hardware demands each pattern may intro-

duce. Patterns with sparse multi-qubit operations

Guidelines for the Application of Hybrid Software Design Patterns

107

(e.g., Angle Encoding) often suit near-term hard-

ware constraints, while resource-intensive ap-

proaches (e.g., Oracle, Quantum RAM) may re-

quire more complex routing and additional qubits.

Evaluating these needs in light of available re-

sources can avoid bottlenecks and impractical de-

signs.

3. Determine the Quantum-Classical Interaction

Style:

Consider how the quantum and classical com-

ponents will communicate. For instance, Stan-

dalone Execution assumes minimal back-and-

forth, whereas Variational Quantum Algorithm

and Hybrid Module patterns rely on frequent

quantum-classical feedback loops (e.g., parameter

updates, dynamic data processing). By matching

the quantum-classical interface implementations

to the system’s intended architecture, developers

can achieve the right level of efﬁciency.

4. Check Hardware Constraints (Topology,

Noise, Qubit Count):

Many design patterns are restricted by hard-

ware limitations. The Topology Constraints

column highlights how connectivity or noise

characteristics can inﬂuence pattern selection.

On hardware with linear qubit arrays or high

error rates, techniques like Circuit Cutting

(splitting a large circuit into smaller pieces) or

more straightforward patterns (Initialization,

Uniform Superposition) can offer practical

trade-offs. However, patterns involving complex

multi-qubit gates (Entanglement, Oracle) may

demand additional considerations, such as error

mitigation or deeper circuit scheduling.

5. Weigh Scalability and Performance Consider-

ations:

As quantum hardware and application needs

scale, certain patterns can become gate-intensive

or prone to noise accumulation (e.g., Amplitude

Encoding, QRAM Encoding). It is therefore im-

portant to assess how the pattern performs with

an increasing number of qubits or in repeated

quantum-classical optimization loops.

6. Review Examples and Known Limitations:

Analyzing the Typical Applications and Limita-

tions columns provides real-world insights into

each pattern’s strengths and pitfalls. As an exam-

ple, Uncompute is critical for cleaning up ancillas

but effectively doubles circuit depth, while Vari-

ational Quantum Eigensolver can target chem-

istry or optimization tasks but suffers from barren

plateaus if not carefully tuned. Published tutorials

(e.g., Qiskit’s VQE examples, PennyLane’s tem-

plate library) offer further perspectives on imple-

mentation nuances and best practices.

7. Plan for Modularity and Future Extensions:

Finally, we recommend that developers consider

a pattern’s potential for reuse and evolution.

Approaches like Quantum Module or Hybrid

Module enable a modular structure in which pa-

rameterized blocks or new classical routines can

be swapped in without re-inventing the core quan-

tum logic. When architectures must evolve to ac-

commodate new hardware or newly developed al-

gorithms, using encapsulated designs can simplify

transitions and protect long-term code stability.

By following these seven steps, practitioners can

systematically navigate the rich spectrum of patterns

in Table 1 and select solutions that balance hardware

realities, resource availability, and desired functional-

ity. This approach offers a structured path for building

quantum-classical workﬂows that are both efﬁcient

and maintainable, helping developers avoid common

integration problems and accelerate the path from de-

sign to deployment.

3 REAL-WORLD

IMPLEMENTATIONS OF

QUANTUM SOFTWARE

DESIGN PATTERNS

Current quantum software frameworks (e.g.,

Qiskit (IBM, 2025), Cirq (Google, 2025), Penny-

Lane (Xanadu, 2025), Amazon Braket (AWS, 2025))

provide concrete examples of how these patterns

can be integrated in practice. Table 2 illustrates how

foundational patterns (Initialization, Oracle) and

hybrid strategies (Quantum-Classic Split) appear on

platforms.

A notable observation is that some patterns, such

as Initialization and Superposition, are almost uni-

versally required in quantum applications and are

therefore typically straightforward to implement. On

the other hand, certain patterns critical for demon-

strating quantum advantage, such as Entanglement,

can be introduced with only a few gates (e.g., form-

ing Bell or GHZ states) yet demand careful hardware

consideration when scaling. Meanwhile, Oracle pat-

terns are necessarily problem-speciﬁc and often pack-

aged as reusable modules, as exempliﬁed by Qiskit’s

built-in logic oracles and Braket’s Grover implemen-

tation. These readily available components allow de-

velopers to insert custom functionality while retaining

established best practices for circuit composition and

execution.

IQSOFT 2025 - 1st International Conference on Quantum Software

108

Table 2: Examples of quantum design pattern implementations in major frameworks.

Design Pattern Example Implementation (Framework)

Initialization (State

Preparation)

Qiskit’s initialize() function prepares arbitrary basis states (e.g., setting an initial

state vector) (IBM, 2025). PennyLane provides an AmplitudeEmbedding template

to load classical data into a quantum state (Xanadu, 2025).

Uniform Superposi-

tion

Typically achieved by applying Hadamard gates to all qubits in a register. For in-

stance, Qiskit’s Grover algorithm applies H

⊗n

to n qubits to create an equal super-

position over 2

basis states (IBM, 2025).

Entanglement Entangling operations are implemented by multi-qubit gates. A two-qubit Bell state

is generated by ﬁrst applying a Hadamard gate to one qubit, followed by a CNOT

gate on the other qubit. More generally, frameworks use a cascade of CNOTs (or

CZs) to create GHZ states (one H gate and a chain of CNOTs for n qubits) (Google,

2025). PennyLane offers predeﬁned entangling-layer templates that apply such con-

trolled gates across qubit pairs (Xanadu, 2025).

Oracle (Black Box) Qiskit includes a PhaseOracle class for constructing oracle circuits from Boolean

logic expressions. Amazon Braket’s algorithm library provides a pre-built Grover’s

algorithm that accepts a problem oracle and iterates the oracle+diffusion pattern.

Cirq and PennyLane enable oracles by allowing custom unitary subcircuits to be

deﬁned for a given problem.

Uncompute

(Cleanup)

Many algorithms explicitly “uncompute” temporary results to discard ancillary

qubits. In practice, this is done by inverting the subcircuit that produced the en-

tangled ancilla. For example, implementations of Shor’s algorithm uncompute the

modular exponentiation circuit to disentangle the output register before measurement

(restoring ancillas to |0⟩). Frameworks like Qiskit facilitate this via an automatic cir-

cuit inverse method (e.g., qc.inverse()).

Quantum-Classic

Split (Hybrid)

Hybrid variational algorithms intermix quantum circuits with classical optimization.

PennyLane intrinsically supports this pattern by feeding quantum circuit evaluations

into optimizers and providing gradient computation tools. Similarly, Qiskit’s VQE

and QAOA implementations run a quantum subroutine to evaluate an objective, then

update parameters classically in a loop. Amazon Braket also enables hybrid work-

ﬂows through its SDK (often via PennyLane integration).

Another insight is the importance of uncomputa-

tion (cleanup of ancilla qubits). While initialization

and entanglement patterns are ubiquitous, uncompu-

tation is crucial in algorithms with workspace qubits

or “garbage” outputs, to avoid leaving residual en-

tanglement. However, an empirical study by P

erez-

Castillo et al.(2024) observed that developers some-

times neglect the uncompute step in practice(P

erez-

Castillo et al., 2024), which can lead to incorrect re-

sults if not handled. Tools and best practices are now

emerging to detect and enforce this pattern in quan-

tum programs (P

erez-Castillo et al., 2024).

Finally, the quantum-classical split (hybrid) pat-

tern has become central in the NISQ era, and all ma-

jor frameworks support it. High-level libraries for

variational algorithms (e.g., Qiskit’s algorithm run-

time modules and PennyLane’s optimization routines)

provide built-in loops that alternate quantum circuit

executions with classical computations, automating

the training of quantum models (Bergholm et al.,

2018). This integration enables complex workﬂows

like VQE with minimal user code, abstracting the op-

timization loop as part of the framework. Industry

use-cases, especially in quantum chemistry and ﬁ-

nance, rely on such patterns; for example, Qiskit’s

chemistry module (now part of Qiskit Nature) uses

classical pre- and post-processing around quantum

subcircuits to solve molecular problems, exemplify-

ing a domain-speciﬁc classical-quantum interface.

Overall, these examples illustrate that quantum

software design patterns are not just theoretical pro-

posals from software engineering research, but are

actively informing the development of reusable li-

braries and tools. By encapsulating recurring so-

lutions—whether preparing a uniform superposition

or orchestrating a hybrid optimization loop—into

framework-level constructs, developers can program

at a higher level of abstraction. This leads to more

reliable and maintainable quantum software, echo-

ing the Talavera Manifesto’s call for principled quan-

tum software engineering (Piattini et al., 2020). Each

pattern in Table 2 thus represents a step toward a

Guidelines for the Application of Hybrid Software Design Patterns

109

standardized body of quantum software engineering

knowledge, bridging the gap between high-level al-

gorithm design and low-level circuit implementation.

4 CONCLUSION

In this paper, we have conducted an extensive review

of the quantum software design patterns proposed

in the literature and observed in open-source frame-

works. We identiﬁed a wide range of patterns that

address the unique challenges of quantum applica-

tion development, from foundational circuit-building

strategies to advanced hybrid paradigms integrating

classical optimization. By categorizing these pat-

terns according to their resource requirements, clas-

sical processing needs, and typical use cases, we pro-

vide a structured guide for developers to select, adapt,

and implement solutions that are both conceptually

clear and hardware-aware.

Importantly, we examined how these patterns are

already implemented in leading quantum SDKs such

as Qiskit, Cirq, PennyLane, and Amazon Braket,

illustrating real-world applicability. Our ﬁndings

indicate that many of these frameworks have be-

gun to incorporate design patterns as high-level ab-

stractions, thereby improving maintainability, re-

ducing duplicated effort, and helping developers

avoid common pitfalls. We also highlight emerging

trends—particularly around NISQ-era constraints and

hybrid algorithms by claiming further reﬁnement and

expansion of existing design patterns.

Overall, this work aims to strengthen the foun-

dation of quantum software engineering by offering

both a practical catalog of proven design solutions and

evidence of their real-world adoption. As the ﬁeld

evolves, continuous reﬁnement of these patterns will

be essential to align with new hardware capabilities,

overcome scaling limitations, and foster best practices

that bridge quantum algorithm research with robust

software engineering principles.

ACKNOWLEDGMENTS

This work has been supported by projects SMOOTH

(PID2022-137944NB-I00), QU-ASAP (PDC2022-

133051-I00) funded by MCIU/ AEI/ 10.13039/

501100011033 and by the “European Union

NextGenerationEU/ PRTR”, and ﬁnancial support

for the execution of applied research projects, within

the framework of the UCLM Own Research Plan,

co-ﬁnanced at 85% by the European Regional Devel-

opment Fund (ERDF) UNION (2022-GRIN-34110).

REFERENCES

AWS (2025). Amazon braket documentation.

https://docs.aws.amazon.com/braket/. Accessed:

2025-02-07.

Bechtold, M., Barzen, J., Beisel, M., Leymann, F., and

Weder, B. (2023). Patterns for Quantum Circuit Cut-

ting. In Proceedings of the 30

Conference on Pat-

tern Languages of Programs (PLoP ’23). The Hillside

Group. in press.

Bergholm, V., Izaac, J., Schuld, M., Gogolin, C., et al.

(2018). Pennylane: Automatic differentiation of hy-

brid quantum-classical computations. arXiv preprint

arXiv:1811.04968.

uhler, F., Barzen, J., Beisel, M., Georg, D., Leymann,

F., and Wild, K. (2023). Patterns for quantum soft-

ware development. In 15th International Conference

on Pervasive Patterns and Applications (PATTERNS).

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,

and Stal, M. (1996). Pattern-Oriented Software Ar-

chitecture: A System of Patterns. Wiley.

Gamma, E., Helm, R., Johnson, R., Vlissides, J., and

Booch, G. (1994). Design Patterns: Elements of

Reusable Object-Oriented Software. Addison-Wesley.

Georg, D., Barzen, J., Beisel, M., Leymann, F., Obst, J.,

Vietz, D., Weder, B., and Yussupov, V. (2023). Execu-

tion Patterns for Quantum Applications. In Proceed-

ings of the 18th International Conference on Software

Technologies - ICSOFT, pages 258–268. SciTePress.

Google (2025). Cirq documentation. https://quantumai.go

ogle/cirq. Accessed: 2025-02-07.

IBM (2025). Qiskit: An open-source framework for quan-

tum computing – documentation. https://qiskit.org/d

ocumentation/. Accessed: 2025-02-07.

Jim

enez-Fern

andez, S., Cruz-Lemus, J., and Piattini, M.

(2023). A systematic mapping study on quantum cir-

cuits design patterns. Proceedings of the 25th In-

ternational Conf. on Enterprise Information Systems

(ICEIS).

Leymann, F. (2019). Towards a pattern language for quan-

tum algorithms. In Quantum Technology and Opti-

mization Problems, volume 11413 of Lecture Notes

in Computer Science (LNCS), pages 218–230, Cham.

Springer International Publishing.

erez-Castillo, R., Fern

andez-Osuna, M., Piattini, M., and

Romero-Y

nez, E. (2024). A preliminary study of the

usage of design patterns in quantum software. In 5th

Int. Workshop on Quantum Software Engineering (Q-

SE 2024). In press.

Piattini, M., Peterssen Nodarse, G., P

erez-Castillo, R.,

Hevia Oliver, J. L., Serrano, M., Hern

andez Gonz

alez,

G., Guzm

an, I., Andr

es Paradela, C., Polo, M., Mu-

rina, E., Jim

enez Navajas, L., Marque

no, J., Gallego,

R., Tura, J., Phillipson, F., Murillo, J., Ni

no, A., and

Rodr

ıguez, M. (2020). The talavera manifesto for

quantum software engineering and programming.

Serrano, M. A., P

erez-Castillo, R., and Piattini, M. (2022).

Quantum Software Engineering. Springer Nature. ht

tps://link.springer.com/book/10.1007/978-3-031-053

24-5.

IQSOFT 2025 - 1st International Conference on Quantum Software

110

Truger, F., Barzen, J., Beisel, M., Leymann, F., and Yus-

supov, V. (2024). Warm-Starting Patterns for Quan-

tum Algorithms. In Proceedings of the 16

Interna-

tional Conf. on Pervasive Patterns and Applications

(PATTERNS 2024), pages 25–31. Xpert Publishing

Services (XPS).

Weigold, M., Barzen, J., Leymann, F., and Salm, M. (2022).

Data encoding patterns for quantum computing. In

Proceedings of the 27th Conf. on Pattern Languages

of Programs, PLoP ’20, USA. The Hillside Group.

Weigold, M., Barzen, J., Leymann, F., and Vietz, D. (2021).

Patterns for Hybrid Quantum Algorithms. In Pro-

ceedings of the 15

Symposium and Summer School

on Service-Oriented Computing (SummerSOC 2021),

pages 34–51. Springer International Publishing.

Xanadu (2025). Pennylane templates library (v0.40.0). http

s://docs.pennylane.ai/en/stable/introduction/templates

.html. Accessed: 2025-02-07.

Guidelines for the Application of Hybrid Software Design Patterns

111