When Software Is No Longer the Bottleneck

The Shift

For a long time, the basic economics of software gave organizations a fairly limited choice: adapt your work to the software you could afford, or spend a great deal of money changing the software to fit your work.

That was not a failure of imagination. It was a rational response to the cost of building, maintaining, integrating, and supporting custom systems. Packaged software made useful capabilities available to many more organizations. Standardization brought real benefits. A company could trade some local flexibility for a product that was proven, supported, and continually improved.

But the trade was still a trade.

When the software did not quite match how an organization operated, the organization usually moved toward the software. A workflow changed to match a licensing boundary. A report was narrowed to the analytics capabilities that seemed practical. An exception was handled outside the system because modeling it properly was too expensive. Over time, the organization learned to treat those constraints as the shape of the work itself.

AI is beginning to change that calculation.

The important promise is not simply that it may make software cheaper to build. It is that it may change who is responsible for defining how software should work.

The old direction of adaptation

In the previous era, software often shaped the organization.

An enterprise platform came with a model of customers, approvals, work queues, roles, records, and reporting. Those models were often sensible. They had to generalize across many companies, and generalization is exactly what made them economical.

But a general model also has edges. At those edges, organizations made accommodations. They renamed concepts to fit available fields. They built spreadsheets around workflows that the platform did not represent well. They chose a smaller version of a process because the larger version crossed a module, integration, or licensing boundary.

I have watched this happen in different forms throughout my career. At OpenMarket, licensing costs affected what analytics capabilities the business considered practical. At doxo, years of operational learning embedded in Airtable and Tableau were effectively discarded as the organization standardized on Salesforce and Sigma. At ServiceNow, a reasonable strategy of consolidating internal tooling onto the platform could still create a less natural experience for teams doing the work.

These were not obviously bad decisions. In each case, there were compelling reasons to standardize, simplify, or work within the limits of a system. The pattern matters because it was so common: the organization optimized around the constraints of its software, even when those constraints were not the same as the organization’s own operating logic.

Software is becoming more adaptable

AI does not make software free, and it does not eliminate the hard parts of operating a real system. Reliability, security, data quality, governance, and change management remain real work.

What is changing is the cost of exploring and expressing software behavior.

Teams can now turn a rough description into a working interface, an automated workflow, an agent behavior, or a reporting model in hours. They can generate variations, create integrations, and test ideas without waiting for every implementation detail to be settled. More importantly, they can keep changing what they build as they learn.

That creates a different possibility. Rather than asking only, “Which product should we adapt to?” an organization can increasingly ask, “What would software look like if it reflected how we actually want to operate?”

This is a return of agency.

Historically, the direction was often:

Software → organization

As software becomes easier to shape, the direction can become:

Organization → software

That is a meaningful shift. It lets an organization preserve more of its hard-won operational learning instead of treating it as an inconvenience to be standardized away.

More agency is not automatically better

It is tempting to treat that freedom as the whole story. If a team can build anything quickly, surely it can finally get exactly what it wants.

But organizations rarely begin with a complete and shared answer to that question.

They know where the work is painful. They know which exceptions keep recurring. Different people often carry different, equally valid views of the same process. What appears to be a request for a new application may actually contain unresolved questions about ownership, policy, customer commitments, or the meaning of a core business concept.

When software was expensive to change, many of those questions could remain implicit. The limits of the platform, the pace of delivery, and the judgment of specialists absorbed some of the ambiguity.

When software becomes adaptable, ambiguity has somewhere to go: into the system.

An AI tool will not pause because an organization has not decided what a “customer,” “approved,” or “complete” actually means. It will make a plausible choice and move forward. That can be useful during exploration. It becomes dangerous when plausible choices harden into the behavior of a product or workflow without anyone recognizing that a choice was made.

The new constraint is not the ability to generate software. It is the ability to direct it intentionally.

The durable work is understanding

This is why I have become less interested in AI as a layer to add onto existing software and more interested in what organizations need before they automate work, deploy agents, generate new capabilities, or rewrite anything.

They need a way to develop shared understanding of the business they are trying to build.

That does not mean producing a perfect requirements document at the start. It means making the important parts of the operating model visible enough to examine together: the concepts that exist, the relationships that matter, the rules and decisions that shape work, and the areas where people do not yet agree.

That understanding emerges through conversation, observation, prototypes, experiments, and negotiation. It continues to evolve as the business changes. But when it is treated as real work—not just as a prelude to implementation—it gives an organization something durable to carry across tools, teams, and versions of its software.

AI expands an organization’s ability to shape and evolve the systems through which it works, decides, and understands itself. Shared understanding is what makes that agency usable.

The next question is the one I find most interesting: if organizations have more freedom to shape software around themselves, what responsibility comes with that freedom?