For years, companies faced a familiar constraint: there were more software ideas than engineering teams had capacity to build.
A department identified a problem. Someone proposed an internal tool. The request entered an engineering backlog, competed with product priorities and, quite often, never got built.
AI is changing that constraint surprisingly fast.
Marketing can create an AI workflow without waiting for engineering. Sales can build an agent around a repetitive process. Operations can assemble an internal tool. A developer can spin up a dashboard for a problem too small to justify a formal software project.
Each decision makes sense individually.
The interesting problem appears when all of them succeed.
Most companies have traditionally controlled software partly because building it was expensive.
Development required engineering resources, technical expertise, infrastructure and time. Those constraints naturally limited how much custom software could exist inside an organization.
AI-assisted development lowers that barrier.
Small applications and automations that previously weren't worth building can now be created quickly. Employees don't necessarily need to wait for a formal development project to experiment with software.
That can be enormously useful. People closest to a business problem can test solutions themselves instead of describing the problem to another department and waiting weeks for implementation.
But lower creation costs introduce a different cost: ownership.
Imagine several teams independently creating useful tools over the course of a year. Six months later, relatively simple questions can become difficult to answer.
Who owns each tool? Which ones are still being used? What company or customer data can they access? Which external services do they depend on? Who updates them when an API changes? And who notices when an automated process quietly stops working?
The challenge is no longer simply building software.
It is knowing what the organization has built.
Shadow IT isn't a new problem. Employees have always adopted applications outside official technology processes.
But AI changes its potential scale.
Traditional shadow IT often meant someone signing up for an unapproved SaaS product. The organization might lose visibility over a subscription or where particular data was being stored.
Now employees can potentially create the software itself.
That software may contain custom business logic, connect several company systems, process internal data and trigger automated actions.
And unlike a commercial SaaS product, there may be no external vendor responsible for keeping it operational.
A small experiment can quietly become part of an important business process without ever going through the transition from experiment to infrastructure.
That is where software sprawl becomes an operational issue.
Technology decisions were traditionally framed around two alternatives:
Should we build this or buy it?
AI introduces a third:
Should we build it with AI?
For many smaller internal applications, that option can be attractive. It can be faster than traditional development and more flexible than purchasing another SaaS product.
But easier creation doesn't eliminate the consequences of ownership.
The first version may take a day to build. The company could still be responsible for it years later.
Someone needs to understand how it works. Access permissions need to remain appropriate. Integrations need maintenance. Security vulnerabilities need attention. Business logic needs updating when processes change.
The cost of creating software and the cost of owning software are becoming increasingly disconnected.
That distinction should influence how companies evaluate AI-assisted development.
The answer isn't necessarily to put every AI experiment through a traditional IT approval process.
Doing that could remove much of the advantage AI provides.
Instead, companies may need a lightweight way to distinguish experimentation from operational software.
An employee testing an automation for a week doesn't need the same controls as an agent processing customer information every day.
But once an experiment becomes important to how the business operates, several things should become clear: ownership, purpose, data access, dependencies and what happens if the tool stops working.
The objective is visibility, not bureaucracy.
Teams should be able to experiment quickly while the organization retains the ability to identify which experiments have quietly become infrastructure.
AI is changing software economics in an unusual way.
For decades, the central question was:
Increasingly, companies may need to ask another question:
When software creation becomes easier, good technology management becomes less about controlling scarcity and more about managing abundance.
The companies that benefit most from AI-assisted development may therefore not be those that build the largest number of tools.
They may be the ones that can experiment freely without losing track of what those experiments eventually become.
What is software sprawl?
Software sprawl occurs when the number of applications, internal tools, automations and systems within an organization grows faster than its ability to effectively track, manage and maintain them.
How is AI contributing to shadow IT?
AI-assisted tools make it easier for employees outside traditional engineering teams to create applications, agents and automated workflows, potentially introducing systems that IT or engineering teams don't know about.
Should companies prevent employees from building tools with AI?
Not necessarily. AI-assisted experimentation can improve productivity and help teams solve problems faster. The more important requirement is having appropriate visibility and ownership once those tools become important to business operations.
What is Build vs Buy vs Build-with-AI?
It expands the traditional software decision between developing a system internally and purchasing an existing product. AI-assisted development creates a third option in which teams can create smaller custom solutions much faster, while still assuming responsibility for their long-term ownership and maintenance.
How to Assess the Health of Your Software Delivery Process
Why a Strong Definition of Done Protects Product Delivery
