The conversation about AI and software development has mostly been about velocity. Developers write code faster. Pull requests ship sooner. Backlogs shrink. That part is real, and it matters.
But there's a bigger shift happening underneath it, and most engineering leaders I talk to are only just starting to feel its weight. AI hasn't just made developers faster. It has fundamentally expanded who can create and ship software.
That changes things in ways that velocity metrics don't capture.
Who Is Building Software in 2026
A marketing team spins up an internal campaign analytics tool using an AI coding assistant. An operations manager builds a workflow automation app to handle supplier onboarding. A product analyst writes a data pipeline that queries production systems and surfaces metrics in a custom dashboard. None of these people are engineers. All of them are shipping software.
This isn't hypothetical. Tools like GitHub Copilot, Cursor, and similar assistants have lowered the floor enough that someone with domain expertise and a clear problem can now produce working, deployable code without a computer science background. And when companies start giving non-engineers access to internal infrastructure - cloud accounts, APIs, databases - the surface area of what's being built grows fast.
According to GitHub's 2024 Octoverse report, the number of developers on GitHub crossed 100 million, with a significant share of that growth attributed to people who don't identify as professional software engineers. The trend isn't slowing down.
For individual contributors, this is genuinely exciting. For the people responsible for keeping production environments secure, stable, and auditable, it's a different kind of problem.
The Operational Consequence: More Apps, Same Team
Every new application is a new operational obligation. It needs to be deployed somewhere. It needs to be monitored. It needs security patches when dependencies have vulnerabilities. It needs access controls so it's not inadvertently touching production data in ways nobody intended. It needs a rollback path if something goes wrong.
When a team of 10 engineers builds software, there's usually a shared understanding of how things get to production. There are reviews, staging environments, deployment pipelines, and someone who has looked at the infrastructure configuration before it goes live.
When a marketing manager builds a tool over a weekend using an AI assistant and deploys it to the company's AWS account using credentials they found in a shared doc, none of that happens. And right now, across a lot of organizations, the second scenario is more common than most engineering leaders realize.
The math here is unforgiving. If your engineering team doubles its output through AI tooling, your operational burden roughly doubles too - more deployments, more services to monitor, more dependencies to patch. If your broader organization starts shipping software, the burden grows much faster than that, and it doesn't come with a proportional increase in DevOps headcount.
The number of deployment events, the number of services running in production, and the number of cloud resources being provisioned are all going up. The number of engineers thinking carefully about how each of those things is configured is not keeping pace.
Governance Is the Hard Problem Now
Here's the reframe that matters: the bottleneck in software delivery is no longer writing the code. It's controlling what happens after the code is written.
Governance - how software moves from someone's laptop to a production environment, who approved it, what security checks ran, what access it has, how it's monitored - is now more important than code generation speed. The two aren't in tension. But organizations that optimize for generation speed without building governance infrastructure are creating risk they're not accounting for.
This isn't about being restrictive. It's about having visibility and control over what's actually running in your environment. A security vulnerability in an internal tool that nobody knew was deployed to production is just as exploitable as a vulnerability in your flagship product. In some ways it's worse, because nobody's watching it.
Compliance exposure follows the same logic. If your organization is subject to SOC 2, GDPR, HIPAA, or similar frameworks, the question auditors ask isn't "how fast does your engineering team ship?" It's "can you demonstrate that everything running in production went through appropriate controls?" An AI-assisted app built by a non-engineer and deployed outside your standard pipeline is a compliance gap, regardless of how useful it is.
Guardrails, Not Roadblocks
The wrong response to this is to lock things down so tightly that the productivity gains from AI get choked off. That creates a different problem: shadow IT. People find workarounds, deploy to personal cloud accounts, use free-tier services - and now you have even less visibility.
The right response is to make the governed path easier than the ungoverned one.
That means giving people safe, repeatable ways to deploy applications - including the non-engineers who are building things - without requiring them to become infrastructure experts or giving them raw access to cloud credentials. It means deployment pipelines that enforce security baselines automatically, not manually. It means monitoring that covers new services by default, not as an afterthought.
It also means access controls that are granular enough to be meaningful. Someone deploying an internal analytics tool doesn't need the same permissions as someone deploying your payment processing service. When every deployment goes through the same governed path, you can calibrate access appropriately without creating friction that drives people off the path.
Platforms built for managing the full application lifecycle - provisioning, deployments, security patching, scaling, and monitoring - become more valuable in this context, not less. When the number of applications in your environment grows faster than your DevOps headcount, you need operational tooling that handles the routine complexity automatically. Cloud 66 is one option here, specifically because it manages that full lifecycle on your own cloud infrastructure rather than adding another layer of vendor dependency on top of what you're already running.
What Engineering Leaders Should Be Thinking About Now
If you're a CTO or VP of Engineering trying to figure out where to focus, here are the concrete questions worth asking:
Do you know what's running in production? Not what's in your main deployment pipeline, but what's actually running in your cloud environment. An audit of active resources against known, managed services is a useful starting point.
Who has deployment access and to what? Cloud credential hygiene matters more as the number of potential deployers grows. If non-engineers are building and deploying, they should be doing it through controlled mechanisms - not with IAM keys they found in a Slack message.
What does your security patching coverage look like for non-core services? Patching coverage tends to be strong for the services engineering teams own directly. It tends to be weak or nonexistent for internal tools that weren't built through standard channels.
Can you trace a deployment event back to a decision? In a governed environment, every production deployment should be attributable. If a service was deployed, there should be a record of who deployed it, what version, when, and whether it went through any review. That trail is what makes both incident response and compliance audits manageable.
What's your governance story for the apps that aren't yet built? The AI-assisted building wave is still early. The policies and tooling you put in place now will either enable safe expansion or scramble to catch up with unsanctioned growth.
None of this requires building something elaborate from scratch. Most of it comes down to extending your existing deployment and access management practices to cover a broader set of actors and a higher volume of applications.
The Governance Gap
The shift from "developers build software" to "knowledge workers build software" is happening whether engineering organizations plan for it or not. The teams that come out ahead will be the ones that treat this as an infrastructure design challenge rather than a policy problem.
Slowing down the builders isn't the answer. Building infrastructure that keeps the governed path the easy path - that's the work.