Speaker 1: Quantum computing feels like something only physicists in lab codes
Speaker 1: deal with. Right, But what if I told you that today,
Speaker 1: from your own laptop, you can actually write code in
Speaker 1: cube pop and send it to a physical quantum computer
Speaker 1: in the cloud. By the end of this session, you'll
Speaker 1: run a simple QUMAN program locally and submit that same
Speaker 1: job to a cloud quantum device. Microsoft offers as your
Speaker 1: quantum and the QR language, and I'll link the official
Speaker 1: dogs in the description so you have up to date
Speaker 1: commands and version details. Debugging won't feel like magic tricks either.
Speaker 1: It's approachable, practical, and grounded in familiar patterns, And once
Speaker 1: you see how the code is structured, you may find
Speaker 1: it looks a lot more familiar than you expect. Why
Speaker 1: quantum code feels familiar. When people first imagine quantum programming,
Speaker 1: they usually picture dense equations, impenetrable symbols, and pages of
Speaker 1: math that belong to physicists, not developers. Then you actually
Speaker 1: open up cube wars and the surprise hits It doesn't
Speaker 1: look foreign. Cube shares programming structures you already know, name spaces, operations,
Speaker 1: and types. You write functions, declare variables and past parameters.
Speaker 1: Much like you would in CPAs or Python. The entry
Speaker 1: point looks like code, not like physical homework. The comfort, however,
Speaker 1: hides an important difference. In classical programming, those variables hold integers, strings,
Speaker 1: or arrays. In q poscile, they represent cubits, the smallest
Speaker 1: units of quantum information. That's where familiar syntax collides with
Speaker 1: unfamiliar meaning. You may write something that feels normal on
Speaker 1: the surface, but the execution has nothing to do with
Speaker 1: the deterministic flow your past experience has trained you to expect.
Speaker 1: The easiest way to explain this difference is through a
Speaker 1: light switch. Traditional code is binary, it's either fully on
Speaker 1: or fully off, one or zero. A cubit acts more
Speaker 1: like a dimmer switch, not locked at one end, but
Speaker 1: spanning many shades in between until you measure it. It
Speaker 1: lives in a probabilistic blend of outcomes, and when you
Speaker 1: apply qure operations, you're sliding that dimmer back and forth,
Speaker 1: not just toggling between two extremes. Each operation shifts probability,
Speaker 1: not certainty, and the way they combine can either reinforce
Speaker 1: or cancel each other out, much like the way waves interfere. Later,
Speaker 1: we'll write a short q one program so you can
Speaker 1: actually see this dimmer metaphor behave like a coin flip
Speaker 1: that refuses to fully commit until you measure it. So
Speaker 1: syntax is readable. What changes is how you reason about
Speaker 1: state and measurement. Where classical debugging relies on printing values
Speaker 1: or tracing execution, quantum debugging faces its own twist. Observing
Speaker 1: cubits collapses them altering the very thing you're trying to inspect.
Speaker 1: A for loop or a condition still works structurally, but
Speaker 1: its content may be evolving cubits in ways you can't
Speaker 1: easily watch step by step. This is where developers start
Speaker 1: to realize the challenge isn't memorizing a new language, it's
Speaker 1: shifting their mental model of what running code actually means.
Speaker 1: That said, the barrier is lower than the hype suggests.
Speaker 1: You don't need a physics degree or years of mathematics
Speaker 1: before you can write something functional. Qum plans is approachable
Speaker 1: exactly because it doesn't bury you. In new syntax, you
Speaker 1: can rely on familiar constructs, functions, operations, variables and gradually
Speaker 1: build up the intuition for when the dimmer metaphor applies
Speaker 1: and when it breaks down. The real learning curve isn't
Speaker 1: the grammar of the language, but the reasoning about probabilistic states, measurement,
Speaker 1: and interference. This framing changes how you think about errors too.
Speaker 1: They don't come from missing punctuation or mis typed keywords.
Speaker 1: More often they come from assumptions, for example, expecting cubits
Speaker 1: to behave deterministically when they fundamentally don't. That shift is
Speaker 1: humbling at first, but it's also encouraging. The tools to
Speaker 1: write quantum code are within your reach, even if the
Speaker 1: behavior behind them requires practice to understand. You can read
Speaker 1: CUPE one fluently in its surface form while still building
Speaker 1: intuition for the underlying mechanics. In practical terms, this means
Speaker 1: most developers won't struggle with reading or writing their first
Speaker 1: quantum operations. The real obstacle shows up before you even
Speaker 1: get to execution, setting up the tools, simulators, and cloud
Speaker 1: connections in a way that everything communicates properly. And that
Speaker 1: setup step is where many people run into the first
Speaker 1: real friction, long before cubit probabilities enter the picture. Your
Speaker 1: quantum playground setting up cures and azure, so before you
Speaker 1: can experiment with quboille itself, you need a working playground,
Speaker 1: and in practice that means setting up your environment with
Speaker 1: the right tools so your code can actually run both
Speaker 1: locally and in the cloud. With as your quantum none
Speaker 1: of the syntax or concepts matter if the tooling refuses
Speaker 1: to cooperate, So let's walk through what that setup really
Speaker 1: looks like. The foundation is Microsoft's Quantum Development Kit, which
Speaker 1: installs through the EAR and net ecosystem. The safest approach
Speaker 1: is to make sure your net SDK is current, then
Speaker 1: install the QDK itself. I won't give you version numbers
Speaker 1: here since they change often. Just check the official documentation
Speaker 1: linked in the description for the exact commands for your
Speaker 1: operating system. Once installed, you create a new cubeon project,
Speaker 1: much like any other Net project. One command and you've
Speaker 1: got a recognizable file tree ready to work with. From there,
Speaker 1: the natural choice is visual Studio Code. You'll want the
Speaker 1: QR extension, which adds syntax, highlighting, IntelliSense, and templates so
Speaker 1: the editor actually understands what you're writing. Without it, everything
Speaker 1: looks like raw tex and you keep second guessing your
Speaker 1: own typing. Installing the extension is straightforward, but one common
Speaker 1: snack is forgetting to restart VS code after adding it.
Speaker 1: That simple oversight leads to lots of why isn't this
Speaker 1: working moments that fix themselves the second you relaunch the editor.
Speaker 1: Linking to Azure is the other half of the playground.
Speaker 1: Running locally is important to learn concepts, but if you
Speaker 1: want to submit jobs to re Quantum hardware, you'll need
Speaker 1: an Azure subscription with a Quantum workspace already provisioned. After that,
Speaker 1: authenticate with the Azure Cli, set your subscription and point
Speaker 1: your local project at the workspace. And it feels more
Speaker 1: like configuring a web app than like writing code, but
Speaker 1: it's standard cloud plumbing. Again. The documentation in the description
Speaker 1: covers the exact CLI commands, so you can follow from
Speaker 1: your machine without worrying that something here is out of date.
Speaker 1: To make this all easier to digest, think of it
Speaker 1: like a short spoken checklist. Three things to prepare. One
Speaker 1: keep your e net SDK up to date. Two, install
Speaker 1: the Quantum Development Kit and add the quboid extension in
Speaker 1: vs code. Three, create an Azure subscription with a Quantum workspace.
Speaker 1: Then authenticate in the CLI so your project knows where
Speaker 1: to send jobs. That's the big picture you need in
Speaker 1: your head before worrying about any code. For most people,
Speaker 1: the problems here aren't exotic. They are the same kinds
Speaker 1: of trip ups you've dealt with in other projects. And
Speaker 1: if you see compatibility errors, updating net usually fixes it.
Speaker 1: If vs code isn't recognizing your QR project, restart after
Speaker 1: installing the extension. If you submit a job and nothing
Speaker 1: shows up, check that your workspace is actually link to
Speaker 1: the project. Those three quick checks solve most of the
Speaker 1: early pain points. It's worth stressing that none of this
Speaker 1: is Quantum specific frustration. It's the normal environment setup work
Speaker 1: you've done in every language stack you've touched, whether setting
Speaker 1: up APIs or cloud apps, and it's exactly why the
Speaker 1: steepest slope at the start isn't about superposition or entanglement.
Speaker 1: It's about making sure the tools talk to one another.
Speaker 1: Once they do, you're pressing play on your code like
Speaker 1: you would anywhere else. To address another common concern, Yes,
Speaker 1: in this video, I'll actually show the exact commands during
Speaker 1: the demo portion, so you'll see them typed out step
Speaker 1: by step, and in the description you'll find verified links
Speaker 1: to Microsoft's official instructions. That way, when you try it
Speaker 1: on your own machine, you're not stuck second guessing whether
Speaker 1: the commands are used are still valid. The pay off
Speaker 1: here is a workspace that feels immediately comfortable. Your tool
Speaker 1: chain isn't exotic, it's vs Code, Net and Azure, all
Speaker 1: of which you've likely used in other contexts. The moment
Speaker 1: it all clicks together and you get that first job running,
Speaker 1: the mystique drops away. What you thought were complicated quantum
Speaker 1: errors were really just the same dependency or configuration problems
Speaker 1: you've solving for years. With the environment in place, the
Speaker 1: real fun begins now that your project is ready to
Speaker 1: run code both locally and in the cloud. The next
Speaker 1: logical step is to see what a first quantum program
Speaker 1: actually looks like writing your first quantum program. So let's
Speaker 1: get practical and talk about writing your very first quantum
Speaker 1: program in cubeol. Think of this as the quantum version
Speaker 1: of Hello World. Not text on a screen, but your
Speaker 1: first interaction with a cubit In cub plus. You don't
Speaker 1: greet the world. You initialize and measure quantum state, and
Speaker 1: in this walkthrough will actually allocate a cubit, apply a
Speaker 1: Hadamart gait, measure it, and I'll show you the run
Speaker 1: results on both the local simulator and quantum hardware, so
Speaker 1: you can see the difference. The structure of this first
Speaker 1: Cuba program looks surprisingly ordinary. You define an operation qu's
Speaker 1: equivalent of a function, and from inside it allocate a cubit.
Speaker 1: That cubit begins in a known classical state zero. From
Speaker 1: there you call an operation, usually the hadamart, which places
Speaker 1: the cubit into a balanced superposition between zero and one. Finally,
Speaker 1: you measure. That last step collapses the quantum state into
Speaker 1: a definite classical bit can return, log or print, So
Speaker 1: the Hello World flow is simple, allocate, operate, measure. The
Speaker 1: code is only a few lines long, yet it represents
Speaker 1: quantum computation in its most distilled form. The measurement step
Speaker 1: is where most newcomers feel the biggest shift in classical programming.
Speaker 1: Once you print output, you know exactly what it will
Speaker 1: be in quantum computing. A single run gives you either
Speaker 1: a zero or a one, but never both. Run the
Speaker 1: program multiple times and you'll see a mix of outcomes.
Speaker 1: That variability isn't a bug, it is the feature. A
Speaker 1: single run returns one classical bit. When you repeat the
Speaker 1: program many times, the collection of results reveals the distribution
Speaker 1: of probabilities your algorithm is creating. This is the foundation
Speaker 1: for reasoning about quantum programs. You don't judge correctness by
Speaker 1: one run, but by the long run. Statistics and analogy
Speaker 1: helps here. If you think of the cubit as a coin,
Speaker 1: when you first allocate it, it always lands on heads.
Speaker 1: Measuring right away yields a zero every time once you
Speaker 1: apply the Hadamart operation, though, you've prepared a fair coin
Speaker 1: that gives you heads or tails with equal probability. Each
Speaker 1: individual flip looks unpredictable, but the patter and across many
Speaker 1: flips settles into the expected balance. And while that might
Speaker 1: feel frustrating at first, the power of quantum programming comes
Speaker 1: from your ability to nudge those probabilities using different gits,
Speaker 1: tilting the coin rather than forcing a deterministic number. This
Speaker 1: is also a point where your instincts as a classical
Speaker 1: developer push back. In a traditional program, each run of
Speaker 1: the same function yields the same result. Quantum doesn't break
Speaker 1: that expectation, it reframes it. Correctness isn't about identical outputs,
Speaker 1: but about whether your sequence of operations shapes the probability
Speaker 1: distribution exactly as anticipated. As a result, your debugging mindset shifts.
Speaker 1: Instead of checking whether one return matches your expectation, you
Speaker 1: look at the distribution across many runs and check if
Speaker 1: it aligns with what theory predicts. That's why the simulator
Speaker 1: is so useful. Run your cupole program there and you'll
Speaker 1: see clean, probabilistic results without real world noise. When you
Speaker 1: repeat the same simple program many iterations, you'll notice the
Speaker 1: outcomes spread evenly, just as the math says they should.
Speaker 1: This makes the simulator your best debugging partner. A concrete
Speaker 1: tip here, whenever you write a new operation, don't settle
Speaker 1: for one result. Run it many times on the simulator
Speaker 1: so you can validate that the distribution matches your understanding
Speaker 1: before sending the job to actual hardware. On the simulator,
Speaker 1: the only randomness comes from the math. On hardware, physical
Speaker 1: noise and interference complicate that pattern, and this brings up
Speaker 1: an important practical point. Real quantum devices, even when running
Speaker 1: this hellow world program, won't always match the simulator perfectly.
Speaker 1: Hardware might show a subtle bias toward one value simply
Speaker 1: because of natural error sources. That doesn't mean your code failed.
Speaker 1: It highlights the difference between a perfect theoretical model and
Speaker 1: the messy world of physical cubits. In the upcoming section,
Speaker 1: I'll walk through what that means in practice, so you
Speaker 1: can recognize when an odd result is noise versus when
Speaker 1: it's a mistake in your program. Even in this tiny program,
Speaker 1: you can see how quantum work challenges old habits. Measuring
Speaker 1: isn't like printing output. It's an action that changes what
Speaker 1: you're measuring. Debugging requires you to think differently, since you
Speaker 1: can't just peak at the state in the middle of
Speaker 1: execution without collapsing it. These challenges come into sharp focus
Speaker 1: once you start thinking about how to find and fix
Speaker 1: mistakes in this environment, and that brings us directly to
Speaker 1: the next question. Every new quantum programmer asks. If you
Speaker 1: can't observe variables the way you normally would, how do
Speaker 1: you actually debug your code debugging in a world where
Speaker 1: you can't peak. In classical development, debugging usually relies on
Speaker 1: inspecting state, drop a print statement, pause in a debugger,
Speaker 1: and examine variables while the program is running. Quantum development
Speaker 1: removes that safety net. You can't peak inside a cubit
Speaker 1: mid execution without changing it. The very act of measurement
Speaker 1: collapses its state into a definite zero or one. That's
Speaker 1: why debugging here takes a different form. Instead of direct inspection,
Speaker 1: you depend on simulation based checks to gain confidence in
Speaker 1: what your algorithm is doing. This is exactly where simulators
Speaker 1: in Cubepole earn their importance. They aren't just training wheels,
Speaker 1: they're your main environment for reasoning about logic. Simulators give
Speaker 1: you a controlled version of the system where you run
Speaker 1: the same operations you would on hardware, but with extra insight.
Speaker 1: You can analyze how states are prepared, whether probability distributions
Speaker 1: look correct, and whether your logic is shaping outcomes the
Speaker 1: way you intended. You don't read out a cubit like
Speaker 1: an integer, but by repeating the program many times, you
Speaker 1: can see whether the statistics converge toward the expected pattern.
Speaker 1: That shift makes debugging less about catching one wrong output
Speaker 1: and more about validating trends. A practical workflow is to
Speaker 1: run your algorithm hundreds or thousands of times in the simulator.
Speaker 1: If you expected a balanced distribution, but the results skew
Speaker 1: heavily to one side, something in your code isn't aligning
Speaker 1: with your intent. Think of it as unit testing, but
Speaker 1: where the test passes only when the overall distribution of
Speaker 1: results matches theory. It's not deterministic checks line by line,
Speaker 1: it's statistical reasoning about whether the algorithm behaves as designed.
Speaker 1: To make this more concrete, here's a simple triarche checklist
Speaker 1: you can always fall back on when debugging qupas. First,
Speaker 1: run your algorithm in the simulator with many shots and
Speaker 1: check whether the distribution lines up with expectations. Second, add
Speaker 1: assertions or diagnostics in the simulator to confirm that your
Speaker 1: cubits are being prepared and manipulated into the states you expect. Third,
Speaker 1: only move to hardware once those statistical checks pass consistently.
Speaker 1: This gives you a structured process rather than trial and
Speaker 1: error guesswork. Alongside startystical mismatches, there are common mistakes beginners
Speaker 1: run into often. One example is measuring a cubit too early,
Speaker 1: which kills interference patterns and ruins the outcome. If you
Speaker 1: do this, your results flatten into something that looks random
Speaker 1: when you expect it constructive or destructive interference. If the
Speaker 1: demo includes it, will actually show what that mistake looks
Speaker 1: like in the output, so you can recognize the symptom
Speaker 1: when it happens to you. Another pitfall is forgetting to
Speaker 1: properly release cubits at the end of an operation. QUEPA
Speaker 1: expects clean allocation and release patterns, and while the runtime
Speaker 1: helps flag errors, check the official documentation linked in the
Speaker 1: description for the exact requirements. Think of it like leaving
Speaker 1: open file handles. Avoid it early and it saves headaches later.
Speaker 1: CUMA also includes structured tools to confirm program logic. Assertions
Speaker 1: allow you to check that cubits are in the intended
Speaker 1: state at specific points, and additional diagnostics can highlight whether
Speaker 1: probabilities match your expectations before you ever go near hardware.
Speaker 1: These tools are designed to make debugging a repeatable process
Speaker 1: rather than guesswork. The idea isn't to replace careful cod
Speaker 1: but to complement it. You construct checkpoints that verify each
Speaker 1: stage of your algorithm works the way you thought it did.
Speaker 1: Once those checkpoints pass consistently in simulation, you carry real
Speaker 1: confidence into hardware runs. The main mindset change is moving
Speaker 1: away from single run certainty. In a classical program, if
Speaker 1: your print statement shows the wrong number, you trace it
Speaker 1: back and fix it. In quantum, a single zero or
Speaker 1: one tells you nothing, so you widen your perspective. Debugging
Speaker 1: means asking does my program produce the right pattern when
Speaker 1: repeated many times? Does the logic manipulate probabilities the way
Speaker 1: I predict That broader view actually makes your algorithm stronger.
Speaker 1: You're reasoning about structure and flow rather than chasing isolated outliers.
Speaker 1: Over time, this stops feeling foreign. The simulator becomes your
Speaker 1: primary partner, not just in finding mistakes, but invalidating the
Speaker 1: architecture of your algorithm. Assertions, diagnostics, and statistical tests supplement
Speaker 1: your intuition until the process feels structured and systematic, and
Speaker 1: when you do step onto real hardware, you'll know that
Speaker 1: if results drift, it's likely due to physical noise rather
Speaker 1: than a flaw in your logic, which sets up the
Speaker 1: next stage of the journey. Once your algorithm is passing
Speaker 1: these checks locally, how do you move beyond the simulator
Speaker 1: and see it run on an actual quantum device sitting
Speaker 1: in the cloud. From laptop to quantum computer. The real
Speaker 1: difference shows up once you take the same Cuba project
Speaker 1: you've been running locally and push it through to a
Speaker 1: quantum device in the cloud. This is the moment where
Speaker 1: quantum stops being hypothetical and becomes data you can measure
Speaker 1: from a machine elsewhere in the world. For most developers,
Speaker 1: that's the point when quantum programming shifts from theory into
Speaker 1: something tangible you can actually validate on your side. The
Speaker 1: process looks familiar. You're still in visual studio code with
Speaker 1: the same files and project structure. The only change comes
Speaker 1: when you decide where to send the job. Instead of
Speaker 1: targeting the local simulator, you direct execution to Azure Quantum.
Speaker 1: From there, your code is bundled into a job request
Speaker 1: and sent to the workspace you've already linked. The workspace
Speaker 1: then takes care of routing the job to the hardware
Speaker 1: provider you've chosen. You don't rewrite logic or restructure your program.
Speaker 1: Your algorithm stays exactly as it is. The difference is
Speaker 1: in the back end that receives it. The workflow self
Speaker 1: is straightforward enough to describe as a short checklist. Switch
Speaker 1: your target to as youre quantum submit the job, open
Speaker 1: your workspace to check its status. Once the job is complete,
Speaker 1: download the results to review locally. If you've ever deployed
Speaker 1: code to a cloud resource, the rhythm will feel familiar.
Speaker 1: You're not reinventing your process. You're rerouting where the program runs,
Speaker 1: Expect differences in how fast things move. Local simulators finish
Speaker 1: nearly instantly, while jobs sent to actual hardware often enter
Speaker 1: a shared queue that means results take longer and aren't
Speaker 1: guaranteed on demand. There are also costs and usage quotas
Speaker 1: to be aware of. Rather than relying on fixed numbers,
Speaker 1: the best guidance is to check the official documentation for
Speaker 1: your specific provider. Links are in the description. What's important
Speaker 1: here is managing expectations. Cloud hardware isn't for every quick test.
Speaker 1: It's for validation once you're confident in your logic. Another
Speaker 1: adjustment you'll notice is in the output itself. Simulators return
Speaker 1: distributions that match the math almost perfectly. Hardware results come
Speaker 1: back with noise. A balanced Hadamar test, for instance, won't
Speaker 1: give you an exact half and half split every time
Speaker 1: you might see a tilt in one direction or the other,
Speaker 1: simply because the hardware isn't exempt from imperfections. Rather than
Speaker 1: interpreting that as a logic bug, it's better to treat
Speaker 1: it as measured physical data. The smart approach is to
Speaker 1: confirm your program's correctness in the simulator first, then interpret
Speaker 1: hardware results as an overlay of noise on top of
Speaker 1: correct behavior. That way, you don't waste time chasing issues
Speaker 1: in code when the difference actually reflects hardware limits. The
Speaker 1: usefulness of this stage isn't in precision alone, it's in realism.
Speaker 1: By submitting jobs to real hardware, you get experience with
Speaker 1: actual error rates, interference effects, and Q limitations. You see
Speaker 1: what your algorithm looks like in practice, not just what
Speaker 1: theory predicts, and you do so without re architecting your
Speaker 1: whole project. Adjusting one configuration is enough to move from
Speaker 1: simulation into the real world, and that sense of continuity
Speaker 1: makes the process approachable. Think about a simple example, like
Speaker 1: the same coin flip routine you tried locally. Running it
Speaker 1: on the simulator gives you a perfectly even distribution across
Speaker 1: many trials. Running it on hardware is different. You'll download
Speaker 1: results that lean slightly one way or the other. It
Speaker 1: feels less precise, but it's more instructive. Those results from
Speaker 1: find you that your algorithm isn't operating in isolation. It's
Speaker 1: interacting with a physical device managed in a lab. You'll
Speaker 1: never see the trade office speed and cleanliness for authenticity.
Speaker 1: Not long ago, this type of access wasn't even on
Speaker 1: the table. The only way to run quantum programs on
Speaker 1: hardware involved tightly controlled research environments and limited availability. Today
Speaker 1: the difference is striking. You can launch a job from
Speaker 1: your desktop and retrieve results using the same interfaces you
Speaker 1: already know from other as your workflows. The experience brings
Speaker 1: quantum closer to everyday development practice, where experimenting isn't reserved
Speaker 1: for laboratories but happens wherever developers are curious enough to try.
Speaker 1: Stepping onto hardware for the first time doesn't make your
Speaker 1: local simulator obsolete. Instead, it places both tools next to
Speaker 1: each other, the simulator for debugging and validating distributions, the
Speaker 1: hardware for confirming physical behavior. Used together, they encourage you
Speaker 1: to form habits around testing, interpreting, and refining, and that
Speaker 1: dual view ideal math balanced against noisy reality, is what
Speaker 1: prepares you to think about quantum not as a concept,
Speaker 1: but as a working technology, which brings us to the large.
Speaker 1: If you've come this far, you've seen how approachable the
Speaker 1: workflow actually is. The local tool chain gets your code running,
Speaker 1: the simulator helps debug and validate, and submitting to hardware
Speaker 1: grounds the outcome in physical reality. That progression isn't abstract.
Speaker 1: It's something you can work through now as a developer
Speaker 1: at your own machine, and it sets the stage for
Speaker 1: an important realization about where quantum programming fits today and
Speaker 1: how getting hands on now positions you for what's coming next.
Speaker 1: Quantum programming isn't abstract wizardry. It's code you can write, run,
Speaker 1: and debug today. The syntax looks familiar, the tooling works
Speaker 1: inside editors you already use, and the real adjustment comes
Speaker 1: from how cubits behave, not how the code is written.
Speaker 1: That makes it practical and approachable, even if you're not
Speaker 1: a physicist.