Cybersecurity briefing
/
Who Approves the Code AI Rewrites
Microsoft's AI code migration work raises a release question: who approves AI-generated changes? See how evidence, policy and exceptions fit together.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
The expensive part of an AI-generated software change may soon be deciding whether to accept it. In an October 26 engineering account, Microsoft describes using agents for large-scale code migration and modernization, combining generated changes with static analysis, testing and formal verification. For enterprise leaders, the consequential question is how the organization will authorize changes when software production can outpace human review.
A faster coding tool does not supply that operating model. Someone still has to decide which evidence is sufficient, whose approval matters and which exceptions can survive into production.
Review capacity becomes a business constraint
Microsoft describes an approach in which experts approve knowledge used to guide migrations, concentrating human attention on ambiguous cases rather than reviewing every repetitive fix. Its modernization work also uses feature-level validation and comparisons between original and translated behavior. These are reported engineering practices, not a guarantee that any enterprise can safely automate its own migrations at the same scale.
The practical lesson extends beyond the largest codebases. A midsize company can face the same mismatch when a small development team begins accepting more AI-generated changes than its security and application owners can assess. The queue may shrink in development while growing at the point where someone must accept operational risk.
Consider a hypothetical customer portal undergoing a dependency upgrade. The change compiles, its existing tests pass and the scanner reports fewer findings. Those results are useful, but the release decision also depends on what the tests cover. Did they exercise access to another customer's records? Did they include an expired session, a failed payment or an interrupted transaction?
The business owner does not need to read every changed line. The owner does need an intelligible account of what was checked, what remains uncertain and how a failure would affect customers. Without that account, approval becomes a signature attached to somebody else's confidence.
Correct according to which requirement
Verification always has a scope. A test demonstrates behavior under the conditions it exercises. A formal proof establishes a property under its stated assumptions. Neither makes the choice of requirements disappear.
Microsoft explicitly raises the difficulty of trusting specifications inferred by AI: they may capture existing behavior without capturing intended behavior. That distinction matters for older applications whose workarounds and undocumented exceptions have accumulated over years.
Preserving a legacy permission error perfectly would still preserve the error. Conversely, changing behavior that appears inconsistent may break a contractual requirement or an operational dependency that never reached the design documentation.
Before authorizing a class of automated changes, engineering and security leaders should agree on the boundaries that must hold. A tenant boundary, a transaction limit or a requirement for independent payment approval needs a named owner and an appropriate validation method. The choice should follow the consequence of failure, rather than the availability of a convenient automated check.
Keep those decisions understandable. A release reviewer should be able to distinguish a required check that passed, an optional check that was skipped and a requirement that nobody has tested yet. Combining all three into a single green status removes information precisely where judgment is needed.
Put security policy into the release workflow
Application-security orchestration platforms connect requirements with the development work and evidence needed to satisfy them. Wabbi's Continuous Security Platform combines application context, customer-defined policies and findings from existing security tools to determine and coordinate the required security work.
Its DevSecOps workflows can bring requirements and approvals into development processes, including release gates where configured. The organization defines the policy and validates the relevant integrations. Scanners and other testing tools continue to produce the technical findings; orchestration connects those findings to decisions and follow-up work.
That role sits alongside code verification. It does not prove a rewrite correct, translate software into Rust or establish an integration with Microsoft's engineering systems. Its value is maintaining the relationship between an application's risk, the organization's requirements and the work required before a release proceeds.
For the hypothetical portal, a policy might require an application-security review when an upgrade changes authentication behavior. A routine change elsewhere could follow a lighter path. The distinction needs to come from explicit application context and configured policy, with a route for unusual cases to reach a qualified reviewer.
An exception is a decision with a lifespan
Executive oversight becomes most useful when ordinary rules cannot be met. A deadline may arrive before a required test environment is available. A supplier may delay a dependency fix. A migration may expose behavior whose intended outcome is disputed.
An exception should state the unmet requirement, the business reason for proceeding, the accountable approver and the conditions for revisiting the decision. Temporary acceptance should not silently become the application's permanent baseline.
Leadership reporting can make that visible without drowning executives in scanner output. Track releases awaiting a decision, exceptions past their review dates and recurring failures in required activities. These measures reveal whether the organization has a workable release process, even when developers are producing changes faster.
Begin with one application and one repeatable class of AI-assisted change. Define the evidence, test the approval path and examine a case that should be stopped. Expand only after the responsible teams can explain why a release passed and how an unresolved concern would reach someone empowered to act. The capacity to generate more software is valuable. The capacity to stand behind the resulting change is what makes it usable.
