By Alok Mehta
AI is not simply changing how software is built. It is changing who can build it, how many people it takes, and what enterprises should expect from their technology organizations and their partners.
A Different Kind of IT Organization
For decades, enterprise IT grew by specialization. Business analysts captured requirements, architects designed solutions, developers wrote code, testers validated it, infrastructure teams deployed it, security reviewed it, and project managers coordinated the handoffs. Systems integrators filled whatever gaps were left.
That model was not irrational. Enterprise technology was genuinely hard to build, the skills were scarce, and mistakes were expensive. Layers of expertise and control were how large organizations managed that risk.
The economics underneath the model are now changing fast. AI development tools compress analysis, design, coding, testing, documentation, and deployment into a single working loop. At the same time, years of restructuring have put a great deal of deeply experienced architecture and engineering talent onto the open market. Those two forces are about to collide.
What emerges may look very different from what we are used to: smaller teams, more experience per person, more hands on keyboards, and a much shorter path from business problem to working software.
At the center of that shift sits a role most enterprises have spent two decades moving further and further from implementation. The architect.
The Architect Has to Understand the Business, Not Just the Technology
An architect who only knows technology patterns will not create much leverage in this era. The leverage comes from pairing deep business understanding with enterprise-grade technical judgment.
In insurance, that means knowing how underwriting, policy administration, billing, claims, distribution, and regulatory reporting actually fit together, not just how they appear on an application inventory. In retirement and financial services, it means knowing the products, the customer journeys, the calculations behind the numbers, and the operational workflows wrapped around them.
That knowledge changes the quality of every decision that follows. An architect who knows the business can tell a real requirement from a twenty-year-old habit. They can see when a workflow is complicated for no reason, when a rule belongs in configuration instead of code, when a data dependency is fragile, and when a small design choice will resurface later as an operational problem somebody else has to live with.
The other half of the job is knowing what separates a convincing prototype from an enterprise platform. A demo works with one user and clean data. Production software has to survive bad data, failed integrations, security probes, peak volume, auditors, incidents at two in the morning, and a decade of change after the people who built it have moved on.
Meeting that bar takes real command of identity and access, data architecture, integration, resiliency, observability, automated testing, and cost. It now also takes a working understanding of AI orchestration, guardrails, model risk, data leakage, and one thing that is easy to forget in the enthusiasm: where deterministic logic has to stay deterministic.
The architects who matter most will be bilingual in the truest sense, fluent in the business and fluent in enterprise technology. AI hands those people a kind of leverage they have never had before.
AI Compresses the Distance Between Intent and Execution
The important shift is not that AI can write code. Code generation is useful, and it is the least interesting part of the story.
What actually changes is the distance between intent and execution.
Traditional delivery is a chain of translations. A business leader explains a need to an analyst. The analyst writes requirements. An architect turns requirements into a design. Developers turn the design into software. Testers return to the original requirements to decide whether the software is right. Security, infrastructure, and operations then evaluate the result through their own lenses.
Every one of those roles can add value. Every handoff also adds latency, cost, and one more chance for context to leak out of the room.
An architect with strong business context can now move from requirement to architecture, working code, test cases, documentation, and deployment artifacts in one continuous loop. An idea that used to take three weeks to validate can be tested in an afternoon, and the design can absorb what was learned before anyone has committed to it.
That does not make specialists disappear. It means specialists get spent where specialization genuinely pays, instead of being staffed in bulk to compensate for fragmented context.
A Case Study: What Happens When the Preconditions Are Right
A modernization effort I led recently shows what this can look like in practice.
The platform had roots going back roughly two decades. Its core intellectual property was still valuable: sophisticated business rules, financial calculations, planning assumptions, and domain logic refined over many years. The problem was everything around that logic. The user experience had aged badly, enhancements were slow and risky, integration options were thin, automation was minimal, and the surrounding architecture made the value already sitting inside the platform hard to reach.
Scoped conventionally, with pre-AI tooling and a traditional program management structure, this is an 18 to 24 month effort: a program office, consulting support, business analysts, architects, front-end and back-end teams, testers, security reviews, infrastructure and integration work, and several rounds of deployment and validation.
We approached it instead as an architecture-led, AI-enabled modernization with a very small delivery footprint. The goal was never a flashy prototype. It was to preserve business logic that people already trusted while rebuilding everything around it to modern enterprise standards.
What came out of that work was a redesigned user experience, a cloud-native architecture, modern APIs and integration patterns, conversational AI capabilities, automated regression testing, stronger security and scalability, modernized data structures, and systematic validation of the legacy calculations against the new ones.
The visible result was speed. Work that a traditional program structure, staffed and sequenced the way these efforts were run before AI tooling existed, would have put at roughly two years was delivered in under five months, with foundational capabilities usable well before that.
The Outcomes Matter More Than the Timeline
Speed on its own proves nothing. A project delivered fast without enterprise discipline has simply moved its risk downstream, where it will cost more to fix. What makes this case worth telling is what held up alongside the speed.
The original business logic survived intact. Years of domain knowledge were not thrown away in the name of a fresh start, so the platform could modernize around proven intellectual property instead of reinventing function that already worked.
The experience got dramatically simpler. Financial outputs that used to require an expert to interpret can now be surfaced conversationally, which changes who is able to use the platform at all.
The architecture became cloud-native and API-driven, so the platform can integrate, scale, and support distribution models that the legacy structure would have blocked.
Testing moved into the engineering process instead of sitting at the end of it. Automated regression suites and repeated validation of the legacy calculations are what kept speed from turning into a correctness problem.
AI showed up twice, in how the work was delivered and in the product itself. The same class of tools that compressed the lifecycle also gave users a more natural way to interact with complicated information.
And the small footprint changed the economics. This was not a faster version of a traditional program. It was evidence that under the right conditions, a small architecture-led team can collapse the coordination layer and still produce enterprise-grade results.
Why It Worked
The wrong conclusion here is that anyone with an AI coding tool can now modernize a complex enterprise platform. The lesson is closer to the opposite.
The compression was possible because several conditions were true at the same time: deep knowledge of the business problem, a clear picture of the legacy behavior that had to be preserved, broad architecture experience spanning cloud, integration, data, security, and operations, and enough hands-on depth to look at AI-generated output and know immediately whether it was good, incomplete, unsafe, or simply wrong.
It also took knowing what was negotiable and what was not. Security was not going to be deferred. Data integrity was not going to be traded for speed. The financial calculations had to be right every time. APIs had to be designed for integrations that did not exist yet. Testing had to be automated. Observability, deployment, privacy, and supportability had to be designed in early rather than cleaned up later.
AI accelerated those decisions. It did not make them.
That distinction is the whole argument. The future does not belong to whoever writes the cleverest prompt. It belongs to people who know what should be built and why, who recognize a wrong implementation on sight, and who can now move from judgment to working software faster than anyone could a few years ago.
Smaller Teams May Create Disproportionate Value
A second force makes this moment unusual. Layoffs and restructuring have released an enormous amount of experienced technology talent into the market at precisely the moment AI is multiplying what one experienced person can produce.
Some of those people will go back to large companies. Others will become consultants, independent architects, solopreneurs, or founding members of very small engineering firms. Together they represent a class of competitor that traditional delivery organizations have never had to price against.
Picture five people with twenty years of enterprise experience each, real business knowledge, hands-on architecture skills, and modern AI tooling. Their advantage is not typing speed. It is that they hold more context in fewer heads, decide sooner, translate less, automate the repetitive work, and iterate without waiting on anyone.
That changes the economics of building software. It also changes the economics of buying it.
Systems Integrators Will Have to Choose What AI Means for Their Clients
For systems integrators, this raises an uncomfortable question. The traditional services model is tied to effort. More scope requires more people, more people generate more billable hours, and longer programs produce more revenue.
What happens when AI breaks the link between effort and outcome?
Clients will start asking why an implementation still needs dozens of people, why modernization still takes several years, and where the AI productivity gains went, since they are not showing up in the price, the timeline, or the result.
There are two available answers. Integrators can use AI to protect margin while preserving yesterday’s staffing pyramid and pricing structure. Or they can use it to deliver far more value for every client dollar.
The firms that take the second path will become considerably stronger partners. The firms that take the first should assume their clients will eventually find someone who took the second.
Core Software Providers Are Not Immune
The same logic reaches enterprise software and core-system providers.
Building a serious alternative to a major enterprise platform has historically required hundreds of developers, years of work, substantial capital, and real execution risk. Those barriers are a large part of what has protected established vendors.
AI does not make core platforms easy. Domain complexity, regulatory requirements, integration, data conversion, reliability, and operational support are all still hard problems.
But the barrier is moving.
Consider a small group of architects who among them understand policy administration, underwriting, billing, claims, data, security, cloud engineering, and enterprise operations. Give them cloud services, AI development agents, automated testing, open-source frameworks, and enough time.
What could they build?
Five years ago, that question would have sounded naive. Today it is a reasonable one to ask. Before long the question may not be whether it is technically possible, but whether someone decides the economics are attractive enough to try.
Continuous Self-Disruption Becomes a Leadership Discipline
The biggest change may not be technical at all. It may be cultural.
Enterprises have historically modernized in cycles, with a major platform transformation every five or ten years and a long quiet stretch in between. That rhythm no longer matches the rate at which the underlying capabilities are changing.
Every architecture, platform, vendor relationship, staffing model, sourcing arrangement, and delivery process should now face one recurring question: if we were starting today, with what is available today, would we still build and operate it this way?
When the honest answer is no, that deserves leadership attention. Somewhere, a smaller competitor, an independent architect, a boutique firm, or a team that formed last quarter is asking the same question about you.
The Call to Action
To enterprise leaders: are you prepared to redesign your IT organization before the economics force you to? Are your best architects spending their days reviewing diagrams and sitting in governance meetings, or do they have the tools and the authority to turn architecture into working outcomes?
To architects: are you ready to be hands-on again? Can you understand the business well enough to challenge a requirement, and still design security, data, integration, resilience, and AI at enterprise quality? That combination is about to become extraordinarily valuable.
To systems integrators: as AI raises productivity, will you pass the gains to clients through faster delivery, smaller teams, and lower cost? Or will AI quietly become the thing that protects the old model?
To software and core-platform providers: are you creating enough value, continuously, that building an alternative stays irrational?
And picture the alternative: a handful of very experienced, suddenly available architects who decide to go build the next core platform themselves.
They understand the business. They understand enterprise technology. They know what good looks like. And now they have AI.
That is not a thought experiment about some distant future. Somewhere, that team is already forming.