How many hours have you lost wrestling with boilerplate code just to get an Azure app running? Most developers can point to days spent setting up configs, wiring authentication, or fighting with deployment scripts before writing a single useful line of code. Now, imagine starting with a prompt instead. In this session, I’ll show a short demo where we use GitHub Copilot for Azure to scaffold infrastructure, run a deployment with the Azure Developer CLI, and even fix a runtime error—all live, so you can see exactly how the flow works. Because if setup alone eats most of your time, there’s a bigger problem worth talking about.

Why Boilerplate Holds Teams Back

Think about the last time you kicked off a new project. The excitement’s there—you’ve got an idea worth testing, you open a fresh repo, and you’re ready to write code that matters. Instead, the day slips away configuring pipelines, naming resources, and fixing some cryptic YAML error. By the time you shut your laptop, you don’t have a working feature—you have a folder structure and a deployment file. It’s not nothing, but it doesn’t feel like progress either. In many projects, a surprisingly large portion of that early effort goes into repetitive setup work. You’re filling in connection strings, creating service principals, deciding on arbitrary resource names, copying secrets from one place to another, or hunting down which flag controls authentication. None of it is technically impressive. It’s repeatable scaffolding we’ve all done before, and yet it eats up cycles every time because the details shift just enough to demand attention. One project asks for DNS, another for networking, the next for managed identity. The variations keep engineers stuck in setup mode longer than they expected. What makes this drag heavy isn’t just the mechanics—it’s the effect it has on teams. When the first demo rolls around and there’s no visible feature to show, leaders start asking hard questions, and developers feel the pressure of spending “real” effort on things nobody outside engineering will notice. Teams often report that these early sprints feel like treading water, with momentum stalling before it really begins. In a startup, that can mean chasing down a misconfigured firewall instead of iterating on the product’s value. In larger teams, it shows up as week-long delays before even a basic “Hello World” can be deployed. The cost isn’t just lost time—it’s morale and missed opportunity. Here’s the good news: these barriers are exactly the kinds of steps that can be automated away. And that’s where new tools start to reshape the equation. Instead of treating boilerplate as unavoidable, what if the configuration, resource wiring, and secrets management could be scaffolded for you, leaving more space for real innovation? Here’s how Copilot and azd attack exactly those setup steps—so you don’t repeat the same manual work every time.

Copilot as Your Cloud Pair Programmer

That’s where GitHub Copilot for Azure comes in—a kind of “cloud pair programmer” sitting alongside you in VS Code. Instead of searching for boilerplate templates or piecing together snippets from old repos, you describe what you want in natural language, and Copilot suggests the scaffolding to get you started. The first time you see it, it feels less like autocomplete and more like a shift in how infrastructure gets shaped from the ground up. Here’s what that means. Copilot for Azure isn’t just surfacing random snippets—it’s generating infrastructure-as-code artifacts, often in Bicep or ARM format, that match common Azure deployment patterns. Think of it as a starting point you can iterate on, not a finished production blueprint. For example, say you type: “create a Python web app using Azure Functions with a SQL backend.” In seconds, files appear in your project that define a Function App, create the hosting plan, provision a SQL Database with firewall rules, and insert connection strings. That scaffolding might normally take hours or days for someone to build manually, but here it shows up almost instantly. This is the moment where the script should pause for a live demo. Show the screen in VS Code as you type in that prompt. Let Copilot generate the resources, and then reveal the resulting file list—FunctionApp.bicep, sqlDatabase.bicep, maybe a parameters.json. Open one of them and point out a key section, like how the Function App references the database connection string. Briefly explain why that wiring matters—because it’s the difference between a project that’s deployable and a project that’s just “half-built.” Showing the audience these files on screen anchors the claim and lets them judge for themselves how useful the output really is. Now, it’s important to frame this carefully. Copilot is not “understanding” your project the way a human architect would. What it’s doing is using AI models trained on a mix of open code and Azure-specific grounding so it can map your natural language request to familiar patterns. When you ask for a web app with a SQL backend, the system recognizes the elements typically needed—App Service or Function App, a SQL Database, secure connection strings, firewall configs—and stitches them together into templates. There’s no mystery, just a lot of trained pattern recognition that speeds up the scaffolding process. Developers might assume that AI output is always half-correct and a pain to clean up. And with generic code suggestions, that often rings true. But here you’re starting from infrastructure definitions that are aligned with how Azure resources are actually expected to fit together. Do you need to review them? Absolutely. You’ll almost always adjust naming conventions, check security configurations, and make sure they comply with your org’s standards. Copilot speeds up scaffolding—it doesn’t remove the responsibility of production-readiness. Think of it as knocking down the blank-page barrier, not signing off your final IaC. This also changes team dynamics. Instead of junior developers spending their first sprint wrestling with YAML errors or scouring docs for the right resource ID format, they can begin reviewing generated templates and focusing energy on what matters. Senior engineers, meanwhile, shift from writing boilerplate to reviewing structure and hardening configurations. The net effect is fewer hours wasted on rote setup, more attention given to design and application logic. For teams under pressure to show something running by the next stakeholder demo, that difference is critical. Behind the scenes, Microsoft designed this Azure integration intentionally for enterprise scenarios. It ties into actual Azure resource models and the way the SDKs expect configurations to be defined. When resources appear linked correctly—Key Vault storing secrets, a Function App referencing them, a database wired securely—it’s because Copilot pulls on those structured expectations rather than improvising. That grounding is why people call it a pair programmer for the cloud: not perfect, but definitely producing assets you can move forward with. The bottom line? Copilot for Azure gives you scaffolding that’s fast, context-aware, and aligned with real-world patterns. You’ll still want to adjust outputs and validate them—no one should skip that—but you’re several steps ahead of where you’d be starting from scratch. So now you’ve got these generated infrastructure files sitting in your repo, looking like they’re ready to power something real. But that leads to the next question: once the scaffolding exists, how do you actually get it running in Azure without spending another day wrestling with commands and manual setup?

From Scaffolding to Deployment with AZD

This is where the Azure Developer CLI, or azd, steps in. Think of it less as just another command-line utility and more as a consistent workflow that bridges your repo and the cloud. Instead of chaining ten commands together or copying values back and forth, azd gives you a single flow for creating an environment, provisioning resources, and deploying your application. It doesn’t remove every decision, but it makes the essential path something predictable—and repeatable—so you’re not reinventing it every project. One key clarification: azd doesn’t magically “understand” your app structure out of the box. It works with configuration files in your repo or prompts you for details when they’re missing. That means your project layout and azd’s environment files work together to shape what gets deployed. In practice, this design keeps it transparent—you can always open the config to see exactly what’s being provisioned, rather than trusting something hidden behind an AI suggestion. Let’s compare the before and after. Traditionally you’d push infrastructure templates, wait, then spend half the afternoon in the Azure Portal fixing what didn’t connect correctly. Each missing connection string or misconfigured role sent you bouncing between documentation, CLI commands, and long resource JSON files. With azd, the workflow is tighter: - Provision resources as a group. - Wire up secrets and environment variables automatically. - Deploy your app code directly against that environment. That cuts most of the overhead out of the loop. Instead of spending your energy on plumbing, you’re watching the app take shape in cloud resources with less handholding. This is a perfect spot to show the tool in action. On-screen in your terminal, run through a short session: azd init. azd provision. azd deploy. Narrate as you go—first command sets up the environment, second provisions the resources, third deploys both infrastructure and app code together. Let the audience see the progress output and the final “App deployed successfully” message appear, so they can judge exactly what azd does instead of taking it on faith. That moment validates the workflow and gives them something concrete to try on their own. The d