Microsoft’s Copilot, Agents, and Platform organization is changing how it builds software around agentic coding, but Charles Lamanna’s central message is more conservative than the headlines suggest: AI-generated output is meant to buy engineering time for reliability, performance, security, and product judgment—not simply inflate feature counts. Lamanna, Microsoft’s executive vice president for Copilot, Agents, and Platform, laid out that position in a recent post on X, as reported by Neowin and subsequently republished in closely matching form by ARY News. The two articles should not be treated as independent confirmation of the operational claims: ARY News follows Neowin’s structure, examples, and framing so closely that it appears to be a rewrite rather than separately sourced reporting.
The important development is nevertheless real and broader than a single executive’s social-media post. Microsoft’s own published material confirms that Lamanna runs an organization spanning Copilot, Power Platform, Dynamics 365, SharePoint, OneDrive, Microsoft 365 services, and agent technologies. His remit gives him unusually direct influence over both the company’s AI products and the engineering practices used to ship them.
For Windows administrators and enterprise developers, the practical takeaway is not that Microsoft has announced a new Copilot SKU or a new Windows feature. It is that the company is treating AI-assisted development as a production-engineering change, with the quality of its updates—and the volume of security fixes customers must absorb—becoming the metric that matters.

Developer monitoring AI-powered cybersecurity dashboards with code, analytics, and security alerts.Microsoft is moving engineers toward supervision and verification​

Lamanna’s description of the work is familiar to teams already using GitHub Copilot, Claude Code, or other code agents: engineers increasingly direct systems that can draft implementations, refactor code, construct tests, and investigate failures. In that model, the human role shifts upward toward defining constraints, selecting architecture, reviewing changes, and deciding what should be built.
That shift can create real leverage, but it has an inconvenient property: generation is cheaper than verification. Producing a candidate patch, a test suite, or a new feature is no longer necessarily the slow part. Understanding whether a change is correct across supported configurations, dependencies, accessibility paths, tenant settings, hardware, and customer workloads remains hard.
Lamanna’s most consequential claim is therefore not that Microsoft can ship more features. He says his teams are deliberately trying to hold feature volume steady and reinvest available capacity in reliability, performance, and security. That is the right target, particularly for a company whose products sit at the center of large enterprise estates. A faster release train without stronger validation would merely move the bottleneck from development to IT operations.
Microsoft’s recent Windows security disclosures show the company understands that constraint. In July, Windows and Devices chief Pavan Davuluri said Microsoft is expanding AI use in vulnerability discovery, triage, candidate remediation, regression-test selection, and validation. The company says its internal process uses separate scanning and proof stages to filter false positives before findings reach engineers, while human reviewers remain involved in code review and risk decisions.
The distinction is important. A code agent that creates a plausible patch is not a secure update pipeline. Microsoft is publicly committing to use AI within a process that includes proof, testing, rollout controls, customer telemetry, and Known Issue Rollback. The value of the approach will be measured in whether that process catches regressions before broad deployment, rather than in how much code an agent can write.

The Power Automate ticket claim lacks the numbers needed to judge it​

Neowin reports that Lamanna cited a double-digit, year-over-year decline in Power Automate tickets as evidence of improved customer outcomes. It is a potentially meaningful outcome, but Microsoft has not supplied enough context to make it a usable measure of engineering improvement.
The published reporting does not identify the exact percentage reduction, the start and end dates, the definition of a “ticket,” the customer segment involved, whether the count refers to support cases or internal engineering bugs, or whether a change in product telemetry and case categorization affected the result. It also does not establish which team or release drove the decline. A chart referenced by Neowin is not clearly labeled as Power Automate-specific.
That omission matters because ticket volume is sensitive to factors beyond product quality. It can fall because a service is more reliable, but also because a support workflow changed, self-service documentation improved, customers moved to another channel, incident classification changed, or usage declined in a specific segment. Without a denominator—such as active tenants, executed flows, monthly users, or support contacts per customer—the result cannot be separated from changes in scale.
Microsoft’s public Power Automate material often presents business cases in terms of automation time saved and workflow-development efficiency. Those are useful measures of customer value, but they do not independently verify Lamanna’s stated ticket reduction. No other outlet located in this reporting has published the underlying Power Automate support data or the metric definition.
The company should publish that context if it intends the figure to demonstrate that agentic development has improved service quality. A vague double-digit improvement is a leadership talking point; an auditable service-quality metric would be evidence.

AI is increasing the security workload Microsoft must carry​

The timing of Lamanna’s comments is notable because Microsoft has also acknowledged a different AI effect: vulnerability discovery is accelerating. The company’s MSRC team said in April that recent AI systems can identify software weaknesses more quickly and across a broader surface area than conventional approaches, while Windows leadership said in July that customers should expect a higher volume of fixes in security releases as defenders find more issues.
This creates a direct operational tension. AI can help an engineering group implement a feature more quickly, but it can also uncover flaws at a pace that adds work to the same organization. Microsoft’s answer is to apply automation to the entire chain: scan code, validate candidates, prioritize risk, propose fixes, select likely regression tests, and retain human review where correctness and customer impact are at stake.
The company’s MDASH—its multi-model agentic scanning harness—illustrates why the surrounding process matters more than a single model. Microsoft says the system combines multiple models and specialized agents, then attempts to prove findings rather than simply filing a large number of suspected bugs. In tests against historical Microsoft Security Response Center cases, the company reported high recall for two Windows components, while also acknowledging that retrospective benchmarks cannot predict future discovery rates.
For IT professionals, the outcome is likely to be a continued increase in update volume and a greater premium on disciplined deployment practices. Microsoft itself advises organizations to use the Security Update Guide to map exposure, prioritize high-value assets, test releases, and sequence deployments. The old assumption that a monthly update cycle was a mostly predictable, low-frequency maintenance task is already becoming less reliable.
The risk is not limited to security patches. A development organization that can create more code and more fixes must also decide which changes are ready for release, which need staged rollout, and which should be held back. Lamanna’s emphasis on judgment identifies the true constraint, even if it is less flashy than the claim that engineers can delegate programming work to agents.

“Rebuild the workflow” is a governance demand, not a tooling tip​

Lamanna argues that teams should not simply add AI to existing processes. Taken literally, that is a call to redesign planning, code review, testing, incident response, and accountability around the fact that machine-generated changes can arrive faster than traditional teams were built to assess them.
For a mature enterprise, that does not mean allowing an autonomous agent to merge production code because it passed a superficial test. It means defining boundaries for what agents may access, which repositories and data they can use, where human approval is mandatory, how generated code is attributed and reviewed, and which quality gates cannot be bypassed for speed.
The governance issue is especially acute for organizations building on Microsoft’s stack. Lamanna’s group oversees products used to create customer agents and business workflows, including Copilot Studio and Power Platform. A company that adopts agentic development while also deploying agentic business automation is expanding both its software delivery surface and the number of systems capable of acting on enterprise data.
Microsoft has framed its own approach around keeping people in the loop for risk decisions and code review. Customers should demand the same discipline from internal teams and systems integrators. The right question is not whether an AI assistant produced an application or a fix; it is whether the organization can prove who reviewed it, what it touched, how it was tested, and how it can be rolled back.

What Windows and Microsoft 365 customers should watch next​

There is no new customer-facing release attached to Lamanna’s post, no timetable for adoption across Microsoft product groups, and no published baseline showing how much code his organization now delegates to agents. Microsoft also has not said whether its internal practices will become reusable controls or reporting features for GitHub Copilot, Azure DevOps, Copilot Studio, or Power Platform customers.
The strongest evidence so far is narrower: Microsoft is putting AI into vulnerability discovery and remediation workflows, and Lamanna says his organization is using the capacity created by coding agents to improve existing software rather than merely build more of it. Those claims align with the company’s published Windows and MSRC strategy, but the business-quality result remains largely unquantified.
For administrators, the consequence is concrete. Expect Microsoft’s engineering systems to find and service more issues faster, while retaining the need to test cumulative updates, stage deployments, monitor known issues, and keep rollback plans ready. AI may reduce the time required to create a fix; it does not remove the operational cost of proving that the fix is safe to deploy.

References​

  1. Primary source: Neowin
    Published: 2026-08-06T08:18:01+00:00
  2. Independent coverage: arynews.tv
    Published: 2026-08-06T10:45:14+00:00
  3. Related coverage: techradar.com
  4. Related coverage: windowscentral.com
  5. Related coverage: itpro.com
  6. Related coverage: blogs.windows.com
  7. Related coverage: microsoft.com
  8. Related coverage: microsoft.com
  9. Related coverage: pcworld.com
  10. Related coverage: axios.com
  11. Related coverage: techcommunity.microsoft.com
  12. Related coverage: arstechnica.com
  13. Related coverage: news.microsoft.com
  14. Related coverage: news.microsoft.com
  15. Related coverage: techcommunity.microsoft.com
  16. Related coverage: marketingassets.microsoft.com
  17. Related coverage: fortune.com
  18. Related coverage: learn.microsoft.com
  19. Related coverage: fastcompany.com
  20. Related coverage: cdn-dynmedia-1.microsoft.com
  21. Related coverage: theinformation.com
  22. Related coverage: gossipherald.com
  23. Related coverage: linkedin.com
  24. Related coverage: newsroom.workday.com
  25. Related coverage: s205.q4cdn.com
  26. Related coverage: msrc.microsoft.com
  27. Related coverage: service.alaska.edu
  28. Related coverage: tei.forrester.com
  29. Related coverage: msrc.microsoft.com