AI coding tools appear to be moving software development into a faster operating model, with developers increasingly overseeing machine-generated work alongside writing code themselves. BairesDev's Q3 2026 Dev Barometer, as highlighted by Yahoo Finance, found that 42% of developers surveyed said AI writes at least half their code, up from 12% a year earlier. Developers also reported saving 13 hours a week through AI-assisted coding, suggesting that software teams may be reallocating more time toward review, validation, and higher-level engineering decisions.
That shift may be creating a new pressure point around software quality and accountability. The same BairesDev research found that 67% of developers spend more time reviewing AI-generated code, while 52% spend more time debugging AI-introduced problems. Among CTOs surveyed, 78% had increased spending on code review, quality assurance, and validation. The findings suggest that faster code creation can also increase the amount of judgment required before changes reach users, particularly as organizations expand AI adoption across larger and more complex systems.
Security considerations are developing alongside that change. Gartner forecasts that spending on securing AI will reach approximately $4.8 billion in 2027, up 68.7% from 2026. The research also projects that more than half of successful attacks on AI agents could involve access-control weaknesses or prompt injection by 2029. Gartner identifies AI application security, AI usage control, AI governance platforms, and AI gateways as distinct areas of investment, reflecting a broader effort to establish controls around systems whose behavior can change while they are operating.
The question consequently extends beyond how quickly AI can produce software. It also concerns how organizations can retain control over changes after deployment. Research by Faros AI cited by Forbes found that code churn increased by more than 800% under high AI adoption, illustrating how increased code production can coincide with more code being revised or discarded. For enterprise teams, this environment may make runtime control increasingly relevant, particularly where a problematic AI-generated function needs to be isolated without taking an entire application offline.
Egil Østhus, CEO of Unleash, an open-source feature management software company serving enterprise software teams, places this runtime question within a larger change in software delivery. "The real challenge is controlling what actually runs in production, when and how it operates, and how to intervene instantly when something goes wrong," says Michael Ferranti, Vice President of Marketing at Unleash.
Ferranti's observation reflects the distinction between deploying software and controlling its behavior in production. As AI increases the volume and frequency of changes, that distinction can give organizations another point at which to apply governance. Unleash operates in that space through feature management and what the company describes as FeatureOps.
Its model separates the deployment of code from the decision to activate software behavior in production. A capability can be placed behind a flag, activated for specific users, systems, or environments, monitored, and subsequently disabled without requiring another deployment. In an AI-intensive development environment, this provides a mechanism for making software changes reversible at runtime, giving engineering and operations teams a control point after code has already reached production.
The concept becomes more tangible through the AI "kill switch."
"For example, a financial institution could use an AI-enabled workflow to support loan decisions while retaining a rules-based process as a fallback," Ferranti explains. "If monitoring indicates that the AI workflow is producing decisions outside established parameters, the AI capability could be switched off while the underlying loan service remains available."
He notes that the application can then revert to the predetermined process while the source of the discrepancy is investigated. The control applies to the specific functionality in question, which may reduce the need for a full application shutdown.
Ferranti sees this reversibility as an important part of adapting governance to AI-enabled software. "Governance has to evolve into an operational capability," he remarks. The idea moves governance closer to the software itself, where policies can be applied to specific application behaviors, services, workflows, and AI-driven functions as conditions change.
For enterprise organizations, that can create a practical link between governance requirements and the operational systems already used to deliver software.
For enterprises, the value of this control also depends on where it operates. Unleash can run the decision logic behind an AI kill switch within a customer's own environment, rather than requiring every runtime decision to depend on an external service. That gives organizations a control mechanism that remains close to the systems it governs and can continue to operate even if connectivity to an external control plane is disrupted. For critical AI-enabled services, this can make the kill switch part of the application's resilience architecture: a predefined way to disable, restrict, or redirect AI behavior while keeping the underlying service available.
That role becomes particularly relevant as organizations consider how AI-enabled applications should behave when conditions change. A model can be replaced, an AI-generated function can be disabled, or an agent's access to a particular capability can be revoked through a runtime control. Crucially, when an AI kill switch is implemented through FeatureOps, the alternative code path is already deployed in production. Teams can switch from AI-enabled behavior to an established fallback without first writing, testing, and deploying an emergency fix. This makes reversibility part of the system's architecture from the outset, rather than something teams have to create in response to an incident.
For technology leaders, this creates a broader consideration around the relationship between speed and control. AI may continue to reduce the time required to produce software, while organizations still need mechanisms for determining which changes remain active and how quickly they can respond when production behavior diverges from expectations. FeatureOps and the ubiquitous use of AI killswitches represent one possible layer within that model. Ultimately, governance may increasingly extend into runtime architecture. The ability to activate, restrict, , or reverse an AI-driven capability could give organizations a more direct way to manage software behavior as development accelerates. In that environment, the central question may increasingly concern how much autonomy an AI system can exercise while the organization retains an effective means of control.
© Copyright IBTimes 2026. All rights reserved.