Microsoft's September 21, 2026 Azure update highlights a new guided Copilot experience for building Azure applications in Visual Studio Code, currently in public preview. It follows the team's September 16 introduction. Read the Azure update.
For cloud engineers, the interesting question is not simply whether an assistant can generate an application. It is whether the journey from an idea to a deployed service gives the team enough opportunities to understand and approve what is happening.
My recommendation: evaluate this preview as a development workflow with review checkpoints, not as permission to skip architecture, security, or deployment discipline.
Three Stages, with Decisions Along the Way
The workflow covers project scaffolding, local development, and deployment. Copilot proposes an architecture and collects missing choices before asking for plan approval. It then scaffolds the application, checks local prerequisites, and helps configure debugging. Before deployment, it presents proposed resources and an estimated cost, generates infrastructure files, and uses Azure CLI and Azure Developer CLI tooling. Microsoft's walkthrough.
I would turn those stages into explicit acceptance gates. A plan is ready when another engineer can explain the application's data flow. Local development is ready when the expected behavior is reproducible. Deployment is ready when the target environment, identity, and resource changes are understood.
That distinction matters because a successful command is only one kind of evidence. It does not establish that a proposed design matches your operational requirements.
The Preview Has a Defined Starting Scope
The initial experience supports JavaScript and TypeScript across scenarios including web apps, Azure Functions, Container Apps, and Static Web Apps. Supporting services include PostgreSQL, Storage, Key Vault, and Azure OpenAI. Python and .NET are roadmap items, not part of that initial language scope. The guided flow complements the existing free-form Copilot experience. Preview scope and roadmap.
Choose a pilot that fits those boundaries naturally. My starting point would be a small internal application with a clear owner, disposable test data, and a straightforward success criterion. Avoid beginning with the most complex production service just because it offers the biggest demonstration.
Write down what the pilot will not cover. A successful small application should not silently become evidence that every language, network topology, or enterprise integration is ready.
Review the Plan Before Reviewing the Code
My proposed architecture review would ask four questions:
Where does sensitive data enter, persist, and leave the application?
Which identities can access each resource, and with what permissions?
Which dependencies must be reachable for the application to function?
What should happen when a dependency is unavailable or slow?
These are team acceptance criteria, not additional capabilities claimed for the preview. Put the answers into the repository so they survive beyond the chat session.
If an answer changes during development, update the plan deliberately. A generated application that no longer matches its approved architecture should receive another review, even when the code compiles.
Treat Generated Infrastructure as a Maintained Artifact
Azure Developer CLI organizes application delivery around project configuration, application code, and infrastructure definitions. Its provisioning command operates on the resources described by that configuration. Azure Developer CLI command reference.
My recommendation is to review generated infrastructure in the same pull request as the application. Confirm the subscription, region, naming, access boundaries, and environment-specific settings before running a deployment.
Keep cost estimates separate from operational limits. An estimate is useful context for a design decision; I would still define who owns the resources, how usage will be checked, and when a pilot environment should be removed. Do not let an abandoned experiment become an ownerless service.
The repeatability test is simple: can a second engineer start from a fresh checkout and reproduce the intended environment using documented configuration? If success depends on unexplained state on the original laptop, the handoff is not complete.
Keep Tool Permissions Narrow
VS Code's agent security guidance emphasizes reviewing changes and controlling tool permissions. Agent-triggered commands can act with the user's credentials, including when interacting with cloud infrastructure. VS Code security guidance.
For this pilot, I would use a dedicated non-production environment and an identity scoped to the work. Read command approvals rather than treating them as a repetitive dialog to dismiss. Keep secrets out of prompts and source control, and inspect unexpected changes before accepting them.
Also separate two questions: whether you trust a tool to execute, and whether its proposed action is appropriate. A familiar tool can still target the wrong subscription or modify more resources than intended.
Practical Cloud Engineer Takeaway
My proposed evaluation checklist is:
Start with the Microsoft Azure Tools extension pack and an empty project folder, following the preview walkthrough.
Choose a supported-language pilot and document its acceptance criteria.
Review architecture, generated code, and infrastructure at separate checkpoints.
Verify the deployment identity and destination before approving changes.
Reproduce the application from a fresh checkout and test one small follow-up change.
Record limitations, resource ownership, and the cleanup procedure.
These are evaluation recommendations, not a claim of hands-on testing of the preview.
Who Should Care?
Azure application developers, platform engineers, and teams assessing AI-assisted development workflows for JavaScript and TypeScript services.
Bottom Line
The strongest pilot will show more than a working application. It will leave behind understandable decisions, reviewable artifacts, and a delivery path that another engineer can repeat.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments