WEBVTT 1 00:00:00.040 --> 00:00:02.839 Quantum computing feels like something only physicists in lab codes 2 00:00:02.879 --> 00:00:05.120 deal with. Right, But what if I told you that today, 3 00:00:05.160 --> 00:00:07.320 from your own laptop, you can actually write code in 4 00:00:07.400 --> 00:00:09.560 cube pop and send it to a physical quantum computer 5 00:00:09.679 --> 00:00:11.800 in the cloud. By the end of this session, you'll 6 00:00:11.839 --> 00:00:15.119 run a simple QUMAN program locally and submit that same 7 00:00:15.240 --> 00:00:18.000 job to a cloud quantum device. Microsoft offers as your 8 00:00:18.079 --> 00:00:20.359 quantum and the QR language, and I'll link the official 9 00:00:20.399 --> 00:00:22.160 dogs in the description so you have up to date 10 00:00:22.199 --> 00:00:25.760 commands and version details. Debugging won't feel like magic tricks either. 11 00:00:25.800 --> 00:00:29.079 It's approachable, practical, and grounded in familiar patterns, And once 12 00:00:29.120 --> 00:00:31.199 you see how the code is structured, you may find 13 00:00:31.199 --> 00:00:33.840 it looks a lot more familiar than you expect. Why 14 00:00:33.920 --> 00:00:37.280 quantum code feels familiar. When people first imagine quantum programming, 15 00:00:37.479 --> 00:00:40.799 they usually picture dense equations, impenetrable symbols, and pages of 16 00:00:40.799 --> 00:00:43.880 math that belong to physicists, not developers. Then you actually 17 00:00:43.920 --> 00:00:46.320 open up cube wars and the surprise hits It doesn't 18 00:00:46.320 --> 00:00:51.880 look foreign. Cube shares programming structures you already know, name spaces, operations, 19 00:00:51.880 --> 00:00:55.640 and types. You write functions, declare variables and past parameters. 20 00:00:55.719 --> 00:00:58.159 Much like you would in CPAs or Python. The entry 21 00:00:58.200 --> 00:01:01.719 point looks like code, not like physical homework. The comfort, however, 22 00:01:01.799 --> 00:01:06.840 hides an important difference. In classical programming, those variables hold integers, strings, 23 00:01:06.920 --> 00:01:10.359 or arrays. In q poscile, they represent cubits, the smallest 24 00:01:10.400 --> 00:01:13.560 units of quantum information. That's where familiar syntax collides with 25 00:01:13.640 --> 00:01:16.599 unfamiliar meaning. You may write something that feels normal on 26 00:01:16.640 --> 00:01:19.319 the surface, but the execution has nothing to do with 27 00:01:19.359 --> 00:01:22.640 the deterministic flow your past experience has trained you to expect. 28 00:01:23.000 --> 00:01:25.239 The easiest way to explain this difference is through a 29 00:01:25.319 --> 00:01:28.719 light switch. Traditional code is binary, it's either fully on 30 00:01:28.840 --> 00:01:31.400 or fully off, one or zero. A cubit acts more 31 00:01:31.439 --> 00:01:33.760 like a dimmer switch, not locked at one end, but 32 00:01:33.840 --> 00:01:37.040 spanning many shades in between until you measure it. It 33 00:01:37.079 --> 00:01:39.680 lives in a probabilistic blend of outcomes, and when you 34 00:01:39.719 --> 00:01:42.519 apply qure operations, you're sliding that dimmer back and forth, 35 00:01:42.560 --> 00:01:46.400 not just toggling between two extremes. Each operation shifts probability, 36 00:01:46.480 --> 00:01:49.560 not certainty, and the way they combine can either reinforce 37 00:01:49.640 --> 00:01:52.799 or cancel each other out, much like the way waves interfere. Later, 38 00:01:52.879 --> 00:01:54.719 we'll write a short q one program so you can 39 00:01:54.719 --> 00:01:57.359 actually see this dimmer metaphor behave like a coin flip 40 00:01:57.359 --> 00:02:00.280 that refuses to fully commit until you measure it. So 41 00:02:00.879 --> 00:02:03.680 syntax is readable. What changes is how you reason about 42 00:02:03.680 --> 00:02:07.319 state and measurement. Where classical debugging relies on printing values 43 00:02:07.400 --> 00:02:11.240 or tracing execution, quantum debugging faces its own twist. Observing 44 00:02:11.280 --> 00:02:14.560 cubits collapses them altering the very thing you're trying to inspect. 45 00:02:14.759 --> 00:02:17.400 A for loop or a condition still works structurally, but 46 00:02:17.479 --> 00:02:20.120 its content may be evolving cubits in ways you can't 47 00:02:20.159 --> 00:02:22.919 easily watch step by step. This is where developers start 48 00:02:22.919 --> 00:02:25.599 to realize the challenge isn't memorizing a new language, it's 49 00:02:25.680 --> 00:02:28.919 shifting their mental model of what running code actually means. 50 00:02:29.319 --> 00:02:31.800 That said, the barrier is lower than the hype suggests. 51 00:02:31.840 --> 00:02:34.159 You don't need a physics degree or years of mathematics 52 00:02:34.159 --> 00:02:37.879 before you can write something functional. Qum plans is approachable 53 00:02:37.919 --> 00:02:40.719 exactly because it doesn't bury you. In new syntax, you 54 00:02:40.719 --> 00:02:44.639 can rely on familiar constructs, functions, operations, variables and gradually 55 00:02:44.680 --> 00:02:47.199 build up the intuition for when the dimmer metaphor applies 56 00:02:47.240 --> 00:02:50.360 and when it breaks down. The real learning curve isn't 57 00:02:50.360 --> 00:02:54.360 the grammar of the language, but the reasoning about probabilistic states, measurement, 58 00:02:54.400 --> 00:02:57.439 and interference. This framing changes how you think about errors too. 59 00:02:57.520 --> 00:03:01.080 They don't come from missing punctuation or mis typed keywords. 60 00:03:01.159 --> 00:03:04.439 More often they come from assumptions, for example, expecting cubits 61 00:03:04.479 --> 00:03:07.800 to behave deterministically when they fundamentally don't. That shift is 62 00:03:07.840 --> 00:03:10.159 humbling at first, but it's also encouraging. The tools to 63 00:03:10.159 --> 00:03:12.599 write quantum code are within your reach, even if the 64 00:03:12.599 --> 00:03:15.680 behavior behind them requires practice to understand. You can read 65 00:03:15.800 --> 00:03:18.280 CUPE one fluently in its surface form while still building 66 00:03:18.319 --> 00:03:22.319 intuition for the underlying mechanics. In practical terms, this means 67 00:03:22.439 --> 00:03:25.240 most developers won't struggle with reading or writing their first 68 00:03:25.319 --> 00:03:28.080 quantum operations. The real obstacle shows up before you even 69 00:03:28.080 --> 00:03:31.360 get to execution, setting up the tools, simulators, and cloud 70 00:03:31.360 --> 00:03:34.439 connections in a way that everything communicates properly. And that 71 00:03:34.560 --> 00:03:37.120 setup step is where many people run into the first 72 00:03:37.199 --> 00:03:41.000 real friction, long before cubit probabilities enter the picture. Your 73 00:03:41.080 --> 00:03:44.080 quantum playground setting up cures and azure, so before you 74 00:03:44.080 --> 00:03:46.840 can experiment with quboille itself, you need a working playground, 75 00:03:47.199 --> 00:03:50.240 and in practice that means setting up your environment with 76 00:03:50.319 --> 00:03:52.879 the right tools so your code can actually run both 77 00:03:52.960 --> 00:03:55.599 locally and in the cloud. With as your quantum none 78 00:03:55.639 --> 00:03:58.120 of the syntax or concepts matter if the tooling refuses 79 00:03:58.120 --> 00:04:01.000 to cooperate, So let's walk through what that setup really 80 00:04:01.000 --> 00:04:04.599 looks like. The foundation is Microsoft's Quantum Development Kit, which 81 00:04:04.599 --> 00:04:08.520 installs through the EAR and net ecosystem. The safest approach 82 00:04:08.560 --> 00:04:11.400 is to make sure your net SDK is current, then 83 00:04:11.439 --> 00:04:15.000 install the QDK itself. I won't give you version numbers 84 00:04:15.000 --> 00:04:17.680 here since they change often. Just check the official documentation 85 00:04:17.759 --> 00:04:19.920 linked in the description for the exact commands for your 86 00:04:19.920 --> 00:04:23.120 operating system. Once installed, you create a new cubeon project, 87 00:04:23.160 --> 00:04:26.319 much like any other Net project. One command and you've 88 00:04:26.319 --> 00:04:29.279 got a recognizable file tree ready to work with. From there, 89 00:04:29.399 --> 00:04:32.279 the natural choice is visual Studio Code. You'll want the 90 00:04:32.360 --> 00:04:36.040 QR extension, which adds syntax, highlighting, IntelliSense, and templates so 91 00:04:36.120 --> 00:04:39.199 the editor actually understands what you're writing. Without it, everything 92 00:04:39.240 --> 00:04:41.439 looks like raw tex and you keep second guessing your 93 00:04:41.480 --> 00:04:44.680 own typing. Installing the extension is straightforward, but one common 94 00:04:44.720 --> 00:04:47.360 snack is forgetting to restart VS code after adding it. 95 00:04:47.639 --> 00:04:49.920 That simple oversight leads to lots of why isn't this 96 00:04:50.000 --> 00:04:53.000 working moments that fix themselves the second you relaunch the editor. 97 00:04:53.519 --> 00:04:55.759 Linking to Azure is the other half of the playground. 98 00:04:56.040 --> 00:04:58.839 Running locally is important to learn concepts, but if you 99 00:04:58.879 --> 00:05:01.439 want to submit jobs to re Quantum hardware, you'll need 100 00:05:01.439 --> 00:05:05.639 an Azure subscription with a Quantum workspace already provisioned. After that, 101 00:05:05.720 --> 00:05:08.680 authenticate with the Azure Cli, set your subscription and point 102 00:05:08.680 --> 00:05:10.800 your local project at the workspace. And it feels more 103 00:05:10.800 --> 00:05:13.240 like configuring a web app than like writing code, but 104 00:05:13.279 --> 00:05:16.480 it's standard cloud plumbing. Again. The documentation in the description 105 00:05:16.560 --> 00:05:19.040 covers the exact CLI commands, so you can follow from 106 00:05:19.040 --> 00:05:21.319 your machine without worrying that something here is out of date. 107 00:05:21.959 --> 00:05:24.079 To make this all easier to digest, think of it 108 00:05:24.160 --> 00:05:27.319 like a short spoken checklist. Three things to prepare. One 109 00:05:27.519 --> 00:05:30.759 keep your e net SDK up to date. Two, install 110 00:05:30.800 --> 00:05:33.480 the Quantum Development Kit and add the quboid extension in 111 00:05:33.560 --> 00:05:37.480 vs code. Three, create an Azure subscription with a Quantum workspace. 112 00:05:37.800 --> 00:05:40.199 Then authenticate in the CLI so your project knows where 113 00:05:40.199 --> 00:05:42.120 to send jobs. That's the big picture you need in 114 00:05:42.160 --> 00:05:44.920 your head before worrying about any code. For most people, 115 00:05:44.920 --> 00:05:47.040 the problems here aren't exotic. They are the same kinds 116 00:05:47.040 --> 00:05:49.160 of trip ups you've dealt with in other projects. And 117 00:05:49.199 --> 00:05:52.120 if you see compatibility errors, updating net usually fixes it. 118 00:05:52.160 --> 00:05:55.360 If vs code isn't recognizing your QR project, restart after 119 00:05:55.399 --> 00:05:57.759 installing the extension. If you submit a job and nothing 120 00:05:57.800 --> 00:06:00.319 shows up, check that your workspace is actually link to 121 00:06:00.360 --> 00:06:03.240 the project. Those three quick checks solve most of the 122 00:06:03.279 --> 00:06:05.720 early pain points. It's worth stressing that none of this 123 00:06:05.879 --> 00:06:09.480 is Quantum specific frustration. It's the normal environment setup work 124 00:06:09.519 --> 00:06:12.160 you've done in every language stack you've touched, whether setting 125 00:06:12.199 --> 00:06:14.839 up APIs or cloud apps, and it's exactly why the 126 00:06:14.839 --> 00:06:18.000 steepest slope at the start isn't about superposition or entanglement. 127 00:06:18.319 --> 00:06:20.439 It's about making sure the tools talk to one another. 128 00:06:20.959 --> 00:06:23.040 Once they do, you're pressing play on your code like 129 00:06:23.079 --> 00:06:26.399 you would anywhere else. To address another common concern, Yes, 130 00:06:26.439 --> 00:06:28.959 in this video, I'll actually show the exact commands during 131 00:06:28.959 --> 00:06:31.480 the demo portion, so you'll see them typed out step 132 00:06:31.480 --> 00:06:34.519 by step, and in the description you'll find verified links 133 00:06:34.519 --> 00:06:37.759 to Microsoft's official instructions. That way, when you try it 134 00:06:37.759 --> 00:06:40.120 on your own machine, you're not stuck second guessing whether 135 00:06:40.160 --> 00:06:42.160 the commands are used are still valid. The pay off 136 00:06:42.199 --> 00:06:45.480 here is a workspace that feels immediately comfortable. Your tool 137 00:06:45.560 --> 00:06:48.879 chain isn't exotic, it's vs Code, Net and Azure, all 138 00:06:48.879 --> 00:06:51.319 of which you've likely used in other contexts. The moment 139 00:06:51.360 --> 00:06:53.720 it all clicks together and you get that first job running, 140 00:06:53.959 --> 00:06:56.920 the mystique drops away. What you thought were complicated quantum 141 00:06:57.040 --> 00:06:59.759 errors were really just the same dependency or configuration problems 142 00:06:59.800 --> 00:07:02.839 you've solving for years. With the environment in place, the 143 00:07:02.920 --> 00:07:05.279 real fun begins now that your project is ready to 144 00:07:05.360 --> 00:07:07.600 run code both locally and in the cloud. The next 145 00:07:07.639 --> 00:07:10.160 logical step is to see what a first quantum program 146 00:07:10.199 --> 00:07:14.199 actually looks like writing your first quantum program. So let's 147 00:07:14.199 --> 00:07:16.959 get practical and talk about writing your very first quantum 148 00:07:17.040 --> 00:07:19.879 program in cubeol. Think of this as the quantum version 149 00:07:19.879 --> 00:07:22.519 of Hello World. Not text on a screen, but your 150 00:07:22.519 --> 00:07:25.040 first interaction with a cubit In cub plus. You don't 151 00:07:25.079 --> 00:07:28.360 greet the world. You initialize and measure quantum state, and 152 00:07:28.399 --> 00:07:31.519 in this walkthrough will actually allocate a cubit, apply a 153 00:07:31.519 --> 00:07:33.800 Hadamart gait, measure it, and I'll show you the run 154 00:07:33.839 --> 00:07:36.519 results on both the local simulator and quantum hardware, so 155 00:07:36.560 --> 00:07:39.319 you can see the difference. The structure of this first 156 00:07:39.360 --> 00:07:42.800 Cuba program looks surprisingly ordinary. You define an operation qu's 157 00:07:42.800 --> 00:07:46.079 equivalent of a function, and from inside it allocate a cubit. 158 00:07:46.240 --> 00:07:49.759 That cubit begins in a known classical state zero. From 159 00:07:49.800 --> 00:07:52.519 there you call an operation, usually the hadamart, which places 160 00:07:52.519 --> 00:07:56.000 the cubit into a balanced superposition between zero and one. Finally, 161 00:07:56.040 --> 00:07:58.800 you measure. That last step collapses the quantum state into 162 00:07:58.800 --> 00:08:01.680 a definite classical bit can return, log or print, So 163 00:08:01.759 --> 00:08:04.800 the Hello World flow is simple, allocate, operate, measure. The 164 00:08:04.839 --> 00:08:07.759 code is only a few lines long, yet it represents 165 00:08:07.839 --> 00:08:11.439 quantum computation in its most distilled form. The measurement step 166 00:08:11.480 --> 00:08:15.000 is where most newcomers feel the biggest shift in classical programming. 167 00:08:15.000 --> 00:08:17.079 Once you print output, you know exactly what it will 168 00:08:17.120 --> 00:08:20.639 be in quantum computing. A single run gives you either 169 00:08:20.680 --> 00:08:22.959 a zero or a one, but never both. Run the 170 00:08:23.000 --> 00:08:25.439 program multiple times and you'll see a mix of outcomes. 171 00:08:25.959 --> 00:08:28.720 That variability isn't a bug, it is the feature. A 172 00:08:28.759 --> 00:08:31.160 single run returns one classical bit. When you repeat the 173 00:08:31.160 --> 00:08:34.639 program many times, the collection of results reveals the distribution 174 00:08:34.720 --> 00:08:37.799 of probabilities your algorithm is creating. This is the foundation 175 00:08:37.879 --> 00:08:41.200 for reasoning about quantum programs. You don't judge correctness by 176 00:08:41.240 --> 00:08:44.080 one run, but by the long run. Statistics and analogy 177 00:08:44.080 --> 00:08:46.080 helps here. If you think of the cubit as a coin, 178 00:08:46.200 --> 00:08:48.600 when you first allocate it, it always lands on heads. 179 00:08:48.919 --> 00:08:51.600 Measuring right away yields a zero every time once you 180 00:08:51.600 --> 00:08:54.320 apply the Hadamart operation, though, you've prepared a fair coin 181 00:08:54.360 --> 00:08:57.480 that gives you heads or tails with equal probability. Each 182 00:08:57.519 --> 00:09:00.720 individual flip looks unpredictable, but the patter and across many 183 00:09:00.720 --> 00:09:03.480 flips settles into the expected balance. And while that might 184 00:09:03.519 --> 00:09:06.360 feel frustrating at first, the power of quantum programming comes 185 00:09:06.360 --> 00:09:09.639 from your ability to nudge those probabilities using different gits, 186 00:09:09.879 --> 00:09:13.159 tilting the coin rather than forcing a deterministic number. This 187 00:09:13.279 --> 00:09:15.120 is also a point where your instincts as a classical 188 00:09:15.200 --> 00:09:18.240 developer push back. In a traditional program, each run of 189 00:09:18.240 --> 00:09:21.200 the same function yields the same result. Quantum doesn't break 190 00:09:21.200 --> 00:09:25.399 that expectation, it reframes it. Correctness isn't about identical outputs, 191 00:09:25.399 --> 00:09:28.720 but about whether your sequence of operations shapes the probability 192 00:09:28.720 --> 00:09:33.320 distribution exactly as anticipated. As a result, your debugging mindset shifts. 193 00:09:33.440 --> 00:09:36.240 Instead of checking whether one return matches your expectation, you 194 00:09:36.320 --> 00:09:39.159 look at the distribution across many runs and check if 195 00:09:39.200 --> 00:09:41.799 it aligns with what theory predicts. That's why the simulator 196 00:09:41.840 --> 00:09:44.279 is so useful. Run your cupole program there and you'll 197 00:09:44.320 --> 00:09:47.120 see clean, probabilistic results without real world noise. When you 198 00:09:47.159 --> 00:09:50.240 repeat the same simple program many iterations, you'll notice the 199 00:09:50.279 --> 00:09:53.000 outcomes spread evenly, just as the math says they should. 200 00:09:53.159 --> 00:09:56.320 This makes the simulator your best debugging partner. A concrete 201 00:09:56.320 --> 00:09:58.960 tip here, whenever you write a new operation, don't settle 202 00:09:59.000 --> 00:10:01.480 for one result. Run it many times on the simulator 203 00:10:01.480 --> 00:10:04.440 so you can validate that the distribution matches your understanding 204 00:10:04.440 --> 00:10:07.320 before sending the job to actual hardware. On the simulator, 205 00:10:07.360 --> 00:10:10.039 the only randomness comes from the math. On hardware, physical 206 00:10:10.120 --> 00:10:13.200 noise and interference complicate that pattern, and this brings up 207 00:10:13.240 --> 00:10:16.519 an important practical point. Real quantum devices, even when running 208 00:10:16.519 --> 00:10:20.000 this hellow world program, won't always match the simulator perfectly. 209 00:10:20.320 --> 00:10:22.919 Hardware might show a subtle bias toward one value simply 210 00:10:22.919 --> 00:10:25.879 because of natural error sources. That doesn't mean your code failed. 211 00:10:25.919 --> 00:10:28.759 It highlights the difference between a perfect theoretical model and 212 00:10:28.759 --> 00:10:31.639 the messy world of physical cubits. In the upcoming section, 213 00:10:31.759 --> 00:10:33.679 I'll walk through what that means in practice, so you 214 00:10:33.720 --> 00:10:36.120 can recognize when an odd result is noise versus when 215 00:10:36.159 --> 00:10:38.960 it's a mistake in your program. Even in this tiny program, 216 00:10:39.039 --> 00:10:42.360 you can see how quantum work challenges old habits. Measuring 217 00:10:42.440 --> 00:10:44.960 isn't like printing output. It's an action that changes what 218 00:10:45.000 --> 00:10:48.279 you're measuring. Debugging requires you to think differently, since you 219 00:10:48.320 --> 00:10:50.000 can't just peak at the state in the middle of 220 00:10:50.039 --> 00:10:53.720 execution without collapsing it. These challenges come into sharp focus 221 00:10:53.799 --> 00:10:56.000 once you start thinking about how to find and fix 222 00:10:56.039 --> 00:10:59.000 mistakes in this environment, and that brings us directly to 223 00:10:59.039 --> 00:11:01.879 the next question. Every new quantum programmer asks. If you 224 00:11:01.919 --> 00:11:04.759 can't observe variables the way you normally would, how do 225 00:11:04.799 --> 00:11:08.360 you actually debug your code debugging in a world where 226 00:11:08.360 --> 00:11:12.399 you can't peak. In classical development, debugging usually relies on 227 00:11:12.559 --> 00:11:15.919 inspecting state, drop a print statement, pause in a debugger, 228 00:11:16.120 --> 00:11:19.440 and examine variables while the program is running. Quantum development 229 00:11:19.480 --> 00:11:22.039 removes that safety net. You can't peak inside a cubit 230 00:11:22.080 --> 00:11:25.080 mid execution without changing it. The very act of measurement 231 00:11:25.120 --> 00:11:28.120 collapses its state into a definite zero or one. That's 232 00:11:28.120 --> 00:11:31.279 why debugging here takes a different form. Instead of direct inspection, 233 00:11:31.480 --> 00:11:34.159 you depend on simulation based checks to gain confidence in 234 00:11:34.200 --> 00:11:36.960 what your algorithm is doing. This is exactly where simulators 235 00:11:36.960 --> 00:11:39.960 in Cubepole earn their importance. They aren't just training wheels, 236 00:11:40.000 --> 00:11:43.559 they're your main environment for reasoning about logic. Simulators give 237 00:11:43.600 --> 00:11:45.639 you a controlled version of the system where you run 238 00:11:45.679 --> 00:11:48.320 the same operations you would on hardware, but with extra insight. 239 00:11:48.879 --> 00:11:52.039 You can analyze how states are prepared, whether probability distributions 240 00:11:52.039 --> 00:11:54.679 look correct, and whether your logic is shaping outcomes the 241 00:11:54.679 --> 00:11:57.399 way you intended. You don't read out a cubit like 242 00:11:57.440 --> 00:11:59.919 an integer, but by repeating the program many times, you 243 00:11:59.879 --> 00:12:03.039 can see whether the statistics converge toward the expected pattern. 244 00:12:03.320 --> 00:12:06.440 That shift makes debugging less about catching one wrong output 245 00:12:06.720 --> 00:12:09.879 and more about validating trends. A practical workflow is to 246 00:12:09.919 --> 00:12:12.759 run your algorithm hundreds or thousands of times in the simulator. 247 00:12:13.200 --> 00:12:16.200 If you expected a balanced distribution, but the results skew 248 00:12:16.240 --> 00:12:18.960 heavily to one side, something in your code isn't aligning 249 00:12:18.960 --> 00:12:21.320 with your intent. Think of it as unit testing, but 250 00:12:21.320 --> 00:12:23.720 where the test passes only when the overall distribution of 251 00:12:23.720 --> 00:12:26.840 results matches theory. It's not deterministic checks line by line, 252 00:12:26.960 --> 00:12:30.600 it's statistical reasoning about whether the algorithm behaves as designed. 253 00:12:30.919 --> 00:12:33.759 To make this more concrete, here's a simple triarche checklist 254 00:12:33.960 --> 00:12:37.440 you can always fall back on when debugging qupas. First, 255 00:12:37.559 --> 00:12:40.039 run your algorithm in the simulator with many shots and 256 00:12:40.120 --> 00:12:43.720 check whether the distribution lines up with expectations. Second, add 257 00:12:43.759 --> 00:12:47.000 assertions or diagnostics in the simulator to confirm that your 258 00:12:47.039 --> 00:12:51.000 cubits are being prepared and manipulated into the states you expect. Third, 259 00:12:51.320 --> 00:12:54.639 only move to hardware once those statistical checks pass consistently. 260 00:12:55.039 --> 00:12:58.080 This gives you a structured process rather than trial and 261 00:12:58.159 --> 00:13:02.399 error guesswork. Alongside startystical mismatches, there are common mistakes beginners 262 00:13:02.480 --> 00:13:05.799 run into often. One example is measuring a cubit too early, 263 00:13:05.919 --> 00:13:09.240 which kills interference patterns and ruins the outcome. If you 264 00:13:09.320 --> 00:13:12.399 do this, your results flatten into something that looks random 265 00:13:12.559 --> 00:13:15.840 when you expect it constructive or destructive interference. If the 266 00:13:15.840 --> 00:13:18.399 demo includes it, will actually show what that mistake looks 267 00:13:18.399 --> 00:13:20.519 like in the output, so you can recognize the symptom 268 00:13:20.519 --> 00:13:23.720 when it happens to you. Another pitfall is forgetting to 269 00:13:23.720 --> 00:13:26.960 properly release cubits at the end of an operation. QUEPA 270 00:13:27.240 --> 00:13:30.639 expects clean allocation and release patterns, and while the runtime 271 00:13:30.679 --> 00:13:33.559 helps flag errors, check the official documentation linked in the 272 00:13:33.600 --> 00:13:37.000 description for the exact requirements. Think of it like leaving 273 00:13:37.000 --> 00:13:40.279 open file handles. Avoid it early and it saves headaches later. 274 00:13:40.919 --> 00:13:44.519 CUMA also includes structured tools to confirm program logic. Assertions 275 00:13:44.559 --> 00:13:46.919 allow you to check that cubits are in the intended 276 00:13:46.960 --> 00:13:50.440 state at specific points, and additional diagnostics can highlight whether 277 00:13:50.519 --> 00:13:53.799 probabilities match your expectations before you ever go near hardware. 278 00:13:54.279 --> 00:13:56.919 These tools are designed to make debugging a repeatable process 279 00:13:57.000 --> 00:13:59.919 rather than guesswork. The idea isn't to replace careful cod 280 00:14:00.440 --> 00:14:03.120 but to complement it. You construct checkpoints that verify each 281 00:14:03.159 --> 00:14:05.480 stage of your algorithm works the way you thought it did. 282 00:14:05.799 --> 00:14:09.000 Once those checkpoints pass consistently in simulation, you carry real 283 00:14:09.039 --> 00:14:12.279 confidence into hardware runs. The main mindset change is moving 284 00:14:12.279 --> 00:14:15.080 away from single run certainty. In a classical program, if 285 00:14:15.080 --> 00:14:17.399 your print statement shows the wrong number, you trace it 286 00:14:17.440 --> 00:14:20.320 back and fix it. In quantum, a single zero or 287 00:14:20.320 --> 00:14:24.240 one tells you nothing, so you widen your perspective. Debugging 288 00:14:24.279 --> 00:14:27.000 means asking does my program produce the right pattern when 289 00:14:27.039 --> 00:14:30.600 repeated many times? Does the logic manipulate probabilities the way 290 00:14:30.639 --> 00:14:34.000 I predict That broader view actually makes your algorithm stronger. 291 00:14:34.000 --> 00:14:37.879 You're reasoning about structure and flow rather than chasing isolated outliers. 292 00:14:38.240 --> 00:14:41.320 Over time, this stops feeling foreign. The simulator becomes your 293 00:14:41.360 --> 00:14:44.399 primary partner, not just in finding mistakes, but invalidating the 294 00:14:44.480 --> 00:14:48.960 architecture of your algorithm. Assertions, diagnostics, and statistical tests supplement 295 00:14:49.000 --> 00:14:52.320 your intuition until the process feels structured and systematic, and 296 00:14:52.399 --> 00:14:54.799 when you do step onto real hardware, you'll know that 297 00:14:54.840 --> 00:14:57.480 if results drift, it's likely due to physical noise rather 298 00:14:57.519 --> 00:14:59.799 than a flaw in your logic, which sets up the 299 00:14:59.799 --> 00:15:02.679 next stage of the journey. Once your algorithm is passing 300 00:15:02.679 --> 00:15:05.480 these checks locally, how do you move beyond the simulator 301 00:15:05.639 --> 00:15:08.279 and see it run on an actual quantum device sitting 302 00:15:08.279 --> 00:15:11.559 in the cloud. From laptop to quantum computer. The real 303 00:15:11.559 --> 00:15:13.919 difference shows up once you take the same Cuba project 304 00:15:13.960 --> 00:15:15.759 you've been running locally and push it through to a 305 00:15:15.799 --> 00:15:17.960 quantum device in the cloud. This is the moment where 306 00:15:18.039 --> 00:15:21.279 quantum stops being hypothetical and becomes data you can measure 307 00:15:21.279 --> 00:15:23.799 from a machine elsewhere in the world. For most developers, 308 00:15:24.120 --> 00:15:27.559 that's the point when quantum programming shifts from theory into 309 00:15:27.600 --> 00:15:30.639 something tangible you can actually validate on your side. The 310 00:15:30.679 --> 00:15:33.360 process looks familiar. You're still in visual studio code with 311 00:15:33.440 --> 00:15:36.240 the same files and project structure. The only change comes 312 00:15:36.240 --> 00:15:38.399 when you decide where to send the job. Instead of 313 00:15:38.399 --> 00:15:42.440 targeting the local simulator, you direct execution to Azure Quantum. 314 00:15:42.679 --> 00:15:45.039 From there, your code is bundled into a job request 315 00:15:45.279 --> 00:15:48.320 and sent to the workspace you've already linked. The workspace 316 00:15:48.360 --> 00:15:50.679 then takes care of routing the job to the hardware 317 00:15:50.679 --> 00:15:54.799 provider you've chosen. You don't rewrite logic or restructure your program. 318 00:15:54.840 --> 00:15:57.559 Your algorithm stays exactly as it is. The difference is 319 00:15:57.639 --> 00:16:00.320 in the back end that receives it. The workflow self 320 00:16:00.320 --> 00:16:03.399 is straightforward enough to describe as a short checklist. Switch 321 00:16:03.399 --> 00:16:05.840 your target to as youre quantum submit the job, open 322 00:16:05.879 --> 00:16:08.919 your workspace to check its status. Once the job is complete, 323 00:16:08.960 --> 00:16:12.080 download the results to review locally. If you've ever deployed 324 00:16:12.159 --> 00:16:14.720 code to a cloud resource, the rhythm will feel familiar. 325 00:16:15.000 --> 00:16:18.360 You're not reinventing your process. You're rerouting where the program runs, 326 00:16:18.919 --> 00:16:22.879 Expect differences in how fast things move. Local simulators finish 327 00:16:22.919 --> 00:16:26.080 nearly instantly, while jobs sent to actual hardware often enter 328 00:16:26.120 --> 00:16:28.480 a shared queue that means results take longer and aren't 329 00:16:28.519 --> 00:16:31.519 guaranteed on demand. There are also costs and usage quotas 330 00:16:31.559 --> 00:16:34.200 to be aware of. Rather than relying on fixed numbers, 331 00:16:34.279 --> 00:16:36.799 the best guidance is to check the official documentation for 332 00:16:36.879 --> 00:16:40.519 your specific provider. Links are in the description. What's important 333 00:16:40.559 --> 00:16:44.240 here is managing expectations. Cloud hardware isn't for every quick test. 334 00:16:44.440 --> 00:16:47.519 It's for validation once you're confident in your logic. Another 335 00:16:47.559 --> 00:16:50.600 adjustment you'll notice is in the output itself. Simulators return 336 00:16:50.639 --> 00:16:53.919 distributions that match the math almost perfectly. Hardware results come 337 00:16:53.919 --> 00:16:57.440 back with noise. A balanced Hadamar test, for instance, won't 338 00:16:57.440 --> 00:16:59.440 give you an exact half and half split every time 339 00:16:59.519 --> 00:17:01.720 you might see a tilt in one direction or the other, 340 00:17:01.759 --> 00:17:05.160 simply because the hardware isn't exempt from imperfections. Rather than 341 00:17:05.200 --> 00:17:07.720 interpreting that as a logic bug, it's better to treat 342 00:17:07.759 --> 00:17:10.880 it as measured physical data. The smart approach is to 343 00:17:10.960 --> 00:17:14.759 confirm your program's correctness in the simulator first, then interpret 344 00:17:14.799 --> 00:17:17.240 hardware results as an overlay of noise on top of 345 00:17:17.279 --> 00:17:20.240 correct behavior. That way, you don't waste time chasing issues 346 00:17:20.240 --> 00:17:23.319 in code when the difference actually reflects hardware limits. The 347 00:17:23.400 --> 00:17:26.720 usefulness of this stage isn't in precision alone, it's in realism. 348 00:17:27.079 --> 00:17:29.799 By submitting jobs to real hardware, you get experience with 349 00:17:29.880 --> 00:17:33.240 actual error rates, interference effects, and Q limitations. You see 350 00:17:33.240 --> 00:17:35.480 what your algorithm looks like in practice, not just what 351 00:17:35.559 --> 00:17:38.400 theory predicts, and you do so without re architecting your 352 00:17:38.400 --> 00:17:41.359 whole project. Adjusting one configuration is enough to move from 353 00:17:41.359 --> 00:17:43.799 simulation into the real world, and that sense of continuity 354 00:17:43.839 --> 00:17:46.400 makes the process approachable. Think about a simple example, like 355 00:17:46.440 --> 00:17:49.319 the same coin flip routine you tried locally. Running it 356 00:17:49.359 --> 00:17:52.160 on the simulator gives you a perfectly even distribution across 357 00:17:52.160 --> 00:17:54.720 many trials. Running it on hardware is different. You'll download 358 00:17:54.759 --> 00:17:56.799 results that lean slightly one way or the other. It 359 00:17:56.839 --> 00:17:59.920 feels less precise, but it's more instructive. Those results from 360 00:18:00.000 --> 00:18:02.799 find you that your algorithm isn't operating in isolation. It's 361 00:18:02.839 --> 00:18:05.400 interacting with a physical device managed in a lab. You'll 362 00:18:05.400 --> 00:18:08.720 never see the trade office speed and cleanliness for authenticity. 363 00:18:09.240 --> 00:18:11.279 Not long ago, this type of access wasn't even on 364 00:18:11.319 --> 00:18:14.000 the table. The only way to run quantum programs on 365 00:18:14.039 --> 00:18:18.359 hardware involved tightly controlled research environments and limited availability. Today 366 00:18:18.359 --> 00:18:20.440 the difference is striking. You can launch a job from 367 00:18:20.440 --> 00:18:23.240 your desktop and retrieve results using the same interfaces you 368 00:18:23.279 --> 00:18:26.480 already know from other as your workflows. The experience brings 369 00:18:26.559 --> 00:18:30.119 quantum closer to everyday development practice, where experimenting isn't reserved 370 00:18:30.160 --> 00:18:33.839 for laboratories but happens wherever developers are curious enough to try. 371 00:18:34.000 --> 00:18:36.279 Stepping onto hardware for the first time doesn't make your 372 00:18:36.319 --> 00:18:39.880 local simulator obsolete. Instead, it places both tools next to 373 00:18:39.920 --> 00:18:43.440 each other, the simulator for debugging and validating distributions, the 374 00:18:43.480 --> 00:18:47.400 hardware for confirming physical behavior. Used together, they encourage you 375 00:18:47.440 --> 00:18:50.960 to form habits around testing, interpreting, and refining, and that 376 00:18:51.079 --> 00:18:54.960 dual view ideal math balanced against noisy reality, is what 377 00:18:55.079 --> 00:18:57.440 prepares you to think about quantum not as a concept, 378 00:18:57.480 --> 00:18:59.960 but as a working technology, which brings us to the large. 379 00:19:00.799 --> 00:19:02.960 If you've come this far, you've seen how approachable the 380 00:19:03.039 --> 00:19:06.519 workflow actually is. The local tool chain gets your code running, 381 00:19:06.720 --> 00:19:10.119 the simulator helps debug and validate, and submitting to hardware 382 00:19:10.160 --> 00:19:13.680 grounds the outcome in physical reality. That progression isn't abstract. 383 00:19:13.720 --> 00:19:16.039 It's something you can work through now as a developer 384 00:19:16.119 --> 00:19:18.400 at your own machine, and it sets the stage for 385 00:19:18.440 --> 00:19:21.400 an important realization about where quantum programming fits today and 386 00:19:21.400 --> 00:19:24.079 how getting hands on now positions you for what's coming next. 387 00:19:25.160 --> 00:19:28.559 Quantum programming isn't abstract wizardry. It's code you can write, run, 388 00:19:28.599 --> 00:19:32.279 and debug today. The syntax looks familiar, the tooling works 389 00:19:32.279 --> 00:19:35.319 inside editors you already use, and the real adjustment comes 390 00:19:35.359 --> 00:19:37.680 from how cubits behave, not how the code is written. 391 00:19:38.000 --> 00:19:40.359 That makes it practical and approachable, even if you're not 392 00:19:40.400 --> 00:19:41.039 a physicist.