There is a second, quieter shift happening alongside all of this. When creating a new tool is easier than finding out whether one already exists, people will default to creating one. I think that flips one of the oldest assumptions in software: creation is expensive and reuse is cheap. AI is making creation cheap while discovery and reuse stay exactly as hard as they have always been, and for a risk function that means the population of unreviewed software an organization is carrying grows faster than any control process built for the old economics can absorb.

CIO/CTOs should start preparing for abundance, not scarcity

Developers don’t disappear from this picture. If anything, the Perplexity example argues the opposite: when a system genuinely matters, experienced engineers still make the architectural calls, test the assumptions and take responsibility for what reaches production. What changes is how much software those same people can create and oversee at once, and that shifts the question CIO/CTOs need to be asking. It used to be whether a team could build something. Increasingly, it’s whether it should, whether the organization already has something like it, who owns it and what happens when the person who built it moves on. Those aren’t engineering questions. They’re portfolio and governance questions, and most organizations don’t have a clear owner for them yet.

There’s a pattern in how enterprises absorb this kind of shift. When storage got cheap, companies didn’t end up with fewer data problems; they accumulated far more data. When cloud infrastructure became easy to provision, the worry shifted from “can we get the compute” to “how do we control the sprawl and the cost.” Software is headed toward the same transition, and the CIO/CTOs who prepare for abundance now will have a real advantage over the ones still planning around scarcity.