Episode Details

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 BackThink 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 ProgrammerThat’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