AI differs from previous technology waves because it increasingly performs the implementation work that historically created demand for IT services. Drawing on 35 years of experience across ERP, SaaS, cloud, and AI, Vijay Pullur argues that the future belongs to organizations that transform domain expertise into proprietary software products rather than relying solely on labor-based services.

The rapid rise of large language model platforms – Anthropic, OpenAI, Google Gemini – has put the global IT services model in serious jeopardy of becoming obsolete. Dramatic as that sounds, I believe it is precisely the right framing.

Since January 20th, shares of virtually every major global IT services company have dropped between 20 and 30 percent. Accenture is down roughly 30 percent. IBM is down 24% with a single-day 13% decline around February 23rd-24th. Wipro and Coforge have shed nearly 25 percent. TCS, Infosys and HCL Tech are all trading at multi-year Lows.

The only comparable sector decline in such a compressed window was COVID-era 2020 – except that time, the Dow Jones fell 39 percent alongside them. This time, the Dow is essentially flat.

The broader economy is not in crisis. It’s the IT services business model that the market is repricing – and it is signaling a seismic shift.

Previous Platform Shifts	AI
Needed implementation partners	Performs implementation
Expanded services demand	Compresses some services demand
Separate product and service	Increasingly combines them
More consultants required	More automation possible

 

Mounting the Horse: A 35-Year Playbook

AI impacting traditional revenue models built around human capital seems to be the central story for this collapse. However, nearly every major IT services firm has announced an AI partnership. Accenture joined OpenAI’s Frontier Alliance alongside McKinsey, BCG, and Capgemini. TCS, Infosys, and Wipro all have deals with Anthropic, OpenAI, or Google.

In previous cycles, announcements like these would lift a company’s stock for weeks. This time, Accenture’s shares fell 6.6 percent on the very day it announced its OpenAI partnership. The market is not buying the story.

The 35-year IT services playbook used to be: announce a partnership with the rising platform, stand up a competency center, train people, and use the partner’s brand to win enterprise contracts. SAP and Oracle in the ’90s for ERP implementation. Salesforce in the 2000s for SaaS-led services. AWS, Azure, and Google Cloud in the 2010s for Cloud migration. Each time, the software platforms made clear that services were not their business. They left the gap open. Services firms filled it and built empires. I call this “mount the horse and ride.” We did exactly this at Imaginea – the technology services company I co-founded under Pramati, later acquired by Accenture. Pick the fastest horse early enough, and you win.

Not anymore.

 

AI Is Different. You’re Riding a Tiger.

What is an AI platform shift?

Unlike cloud computing or SaaS, AI platforms increasingly automate portions of the software development and implementation process itself, changing the economics of IT services rather than simply introducing another technology stack.

In every previous cycle, technology vendors needed IT services companies. But AI does not need implementers in the same way – it is the product and service – rolled into one. When Claude Code can automate COBOL modernization, and when the CEOs of Anthropic and OpenAI publicly state that software engineering roles will largely disappear within three years, they are not describing disruption. They are describing replacement. On a horse, you are in control. The tiger turns on you eventually.

Jefferies just downgraded TCS, Infosys, HCL Technologies, and three other major IT firms, explicitly citing AI as a structural threat to the business mix. JP Morgan warned that clients will reallocate spending as AI-led efficiencies shrink demand for managed services. This is now the mainstream analytical consensus – not a fringe view.

 

Build the Moat or Become Irrelevant

The answer is not another partnership announcement. The era of scaling revenue by scaling headcount is over. The firms that survive will use their deep domain expertise— the genuine understanding of how enterprises actually work—to build proprietary software assets. Proprietary software assets are reusable software products, platforms, frameworks, or intellectual property that generate value independently of billable engineering hours. Products that clients cannot simply replace with a prompt. Use AI to build at extraordinary velocity but build something that is yours. The most pragmatic path may be acquisition: seed a product culture with companies that already have it and play the game with your software; not just your services.

This blog is originally published on Business Today.

 

FAQs

Q1. What does "mount the horse" mean in tech services history?

"Mount the horse" describes the strategy that helped IT services companies grow through previous technology waves. When platforms such as SAP, Oracle, Salesforce, AWS, Azure, or Google Cloud emerged, services firms built expertise around them, trained engineers, became implementation partners, and helped enterprises adopt those technologies. This approach proved highly successful for decades because platform vendors relied on services firms to drive adoption.

Q2. What is the "riding a tiger" analogy for AI in business?

The "riding a tiger" analogy illustrates why AI differs from previous technology platforms. Earlier platforms depended on IT services companies for implementation, allowing both platform vendors and services firms to grow together. AI, however, increasingly performs some of the implementation work itself. In that sense, AI is not simply another platform to ride - it is a force that can fundamentally reshape or even replace parts of the traditional services business model, requiring companies to rethink how they create long-term value.

Q3. How is generative AI replacing traditional IT implementers?

Generative AI is automating many software development tasks that previously required large implementation teams, including code generation, application modernization, documentation, and testing. While human expertise remains essential for enterprise architecture, governance, and business strategy, AI is reducing the amount of manual implementation work that has historically driven revenue for IT services firms.

AI coding tools have advanced rapidly, but most are still designed around the individual developer. Their effectiveness depends heavily on a user’s ability to write understandable prompts, preserve architectural coherence across sessions, and identify areas that require additional work. This model works for some engineers, but it is far less dependable for a large organization’s development team, where software must align with defined standards, delivery processes and governance requirements.

Today, AI development systems that reduce reliance on individual judgment are coming to market. They bring embedded structure, constraints, and verification directly into the platform. For organizations, customer-facing products and portals, building custom, design-led, mission-critical applications, the question is no longer whether AI can generate code. The real question is what an AI coding platform must look like to enable repeatable, reliable delivery at AI speed.

 

The Limits Of Prompt-Based Development In Enterprise Software Delivery

Software delivery follows established patterns in most mature organizations. Teams work within approved technology stacks, design systems, security policies, and clear expectations around testing and release quality. General-purpose coding agents, however, typically require these constraints to be recreated through prompts. Developers end up pasting in long instructions and specifications, repeatedly re-establishing project context, reminding the model of standards, and defining what “done” looks like despite limited context windows that can drift as the codebase grows in size, scope, and complexity.

This model carries a hidden cost. Teams spend valuable time following and keeping track of instructions instead of building features, and results vary widely depending on who is using the tool. In environments with multi-disciplinary, cross-functional teams, that variability becomes a real risk. It can degrade user experience, undermine architectural integrity and increase review cycles and remediation efforts downstream.

AI coding products built for teams should treat specs, application architecture, context, and guardrails as historical context and information, embedded in the system, rather than as prompts.

 

Rules Before Creativity For High-Functioning Architecture

Historically, clean architecture was rarely the primary challenge in mature application environments. The real priorities were, and remain, user experience, consistency, long-term maintainability, and adherence to established standards. An AI development product built for teams should reflect that reality by providing a range of acceptable output so generated code always aligns with organizational patterns.

For this to be a reality, AI coding platforms must come with realistic, modern defaults and enforceable policies. This includes how components are prioritized, how data is accessed, which security checks are required, how errors are remediated, and which dependencies get the green light. When these constraints are built into the system, developers spend less time reviewing and correcting output and more time focusing on functionality and outcomes.

 

Specifications Should Be Structured, Modular And Enforceable

Specifications used in AI-assisted development are more effective when they are not treated as a single document. A spec should be structured in a way that aligns with how agent-based systems operate and modular enough for teams to apply only the relevant portions to a given feature without reintroducing full project context each time.

In practice, a specification model requires clearly defined sections for scope, constraints, project structure, conventions, and boundaries. Versioning enables changes to be tracked over time, while enforceability allows the system to detect deviations or violations rather than relying solely on text generation that appears compliant. This approach can function as a shared operating model for a team rather than a collection of individual prompts.

 

Structured Intermediate Models Help Preserve The Design

A key design consideration for AI coding systems is whether code is generated directly from natural language input or derived from a intermediary that captures intent before code generation occurs.

For team-based development, a multi-stage approach is often most effective. Here, requirements and design inputs are first translated into a structured representation of the application, such as screen composition, component mapping, bindings, and constraints, before framework-specific code is produced. This effectively eliminates the need to regenerate large portions of the codebase, limiting drift across iterations, and establishing a more stable reference point that can be reviewed and validated.

In design-led workflows, an intermediate representation also supports collaboration by allowing designers and product stakeholders to review intent at a level closer to their domain, while engineers retain responsibility for how that intent is implemented in code.

 

Policies Should Be Built-In And Consistently Applied

Organizations rely on policies or safeguards to manage risk and reduce variability across teams. When AI coding systems require individual users to define these policies in their prompts, the outcomes can vary significantly between developers and teams. Platforms intended for organizational use typically need to apply guardrails at the system level so they are shared and consistently enforced.

These policies should be in place at all levels. Some may take the form of hard constraints that prevent undesirable patterns and others may function as policy checks confirming architectural rules, security requirements and coding conventions. Workflow-related controls, such as review and approval steps, are also relevant. In design-led applications, user interface rules surrounding components, design tokens, and accessibility baselines play a similar role.

The purpose of these policies is not to limit the work being completed, but to ensure that increased development speed does not introduce additional operational risk or quality degradation.

 

Completion Criteria Should Be Provable And Clear

One recurring challenge in AI-assisted development is determining when work is complete. While code generation can be rapidly created, teams still need the confidence to determine when outputs meet acceptance criteria, pass required tests, integrate correctly, and comply with relevant policies. AI coding systems designed for team environments benefit from providing a clear, machine-verifiable definition of completion.

In practice, this involves associating requirements with acceptance criteria, expecting appropriate test coverage, executing checks automatically, and identifying gaps between the specification and the current implementation. Systems that can iterate in a controlled manner, proposing corrections and stopping when criteria are met, reduce the need for repeated reviews and increase confidence in the output.

 

Collaboration And Governance Must Be Supported By The Product

For AI coding systems to be effective in team environments, collaboration and governance capabilities need to be integrated into the product itself. Shared standards, templates, and design systems are necessary to ensure consistency. Role-based permissions help distinguish between who can modify standards and who can generate or modify features. Auditability is also important, enabling teams to understand which specification version informed an output and how changes were introduced.

Integration with existing delivery infrastructure, such as source control, CI/CD pipelines, and issue tracking systems, further supports adoption in established environments. Without these capabilities, AI coding tools are more likely to function as individual productivity aids rather than systems that support organizational delivery processes.

 

Distinguishing Between Tools And Delivery Systems

One way to assess the maturity of an AI coding product is to consider how much it depends on one’s ability to use it. When consistent results require advanced prompting skills and strong architectural judgment, adoption is likely to be limited. Systems that possess structure, preserve intent through stable representations, apply shared policies, and define what completion means are more accessible to typical development teams.

For organizations building design-led, customer-facing applications, this matters. The focus shifts from generating code more quickly to enabling predictable, repeatable delivery that aligns with existing standards and operational expectations.

 

This blog is originally published on DevOps.com

For years, until recently, software did exactly what it was told. Developers meticulously coded precise step-by-step instructions for various processes. When executed, it did exactly that and nothing else. No matter how many times the code ran, the outcome was identical. It was totally deterministic.

AI, however, introduced the idea that software could “think” — assess a situation, evaluate various options, plot the best path forward, and in some situations, execute those steps. Run code multiple times and you may get structurally different code — different variable names, different logic paths, different dependencies.

This variability has been anathema to the need for reliability and consistency that users trusted in software for years — and that the industry has spent half a century trying to eliminate.

Although AI opens up an array of exciting new possibilities, left on its own, AI has demonstrated that it can go wildly off the rails.

Still, the solution isn’t necessarily to try to make AI deterministic, but to architecturally bake guardrails into the system itself to keep variability within acceptable limits.

 

When AI Goes Rogue

The inherent dangers of just throwing AI at a problem have been well publicized. It can hallucinate. It can spill secrets. Even with the right permissions and policies in place, it can do massive damage, not only internally, but also to a company’s reputation.

In one instance involving Cursor, a Claude-based IDE, and Supabase’s Model Context Protocol (MCP), an agent with broad database privileges was tricked into exfiltrating secrets using a user’s support ticket text.

The large language model (LLM) agent did so without violating any database permissions.

In another example, a Replit agent, in the midst of building an application, ignored explicit instructions to freeze changes and instead deleted an entire production database —months of real user data just gone. Leading up to this, despite being repeatedly instructed not to create synthetic data, it had made up thousands of fake database records. Afterward, it created its own human-like apology. Woops, sorry indeed.

The risks — hallucinated dependencies, security vulnerabilities that look correct on the surface, logic errors that only surface in production, and code that no two runs produce identically — are among the reasons Gartner recently predicted that over 40% of agentic AI projects will be canceled by 2027.

Those risks have leaders uneasy. Eighty-three percent of AI leaders now report major or extreme concern about generative AI, an eight-fold increase since 2023, according to a Lucidworks study.

Yet only 1 in 5 (21%) companies in the Deloitte survey report having a mature model for governance of autonomous agents.

Deloitte also found that 10.69% of respondents admit to using AI coding assistants without official permission, in an unverified or unmonitored way, which no doubt has their bosses pulling their hair out.

 

A Hybrid Two-Pass Architecture

So, the question around AI isn’t so much about whether to use it all, but how to limit the damage it can do while still taking advantage of its “thinking” capability — and possibly ability to act as well.

One approach might be a two-pass hybrid model to architecturally put guardrails into the system itself. It might look like this:

Pass One: An LLM, trained on and constrained by a Model Context Protocol (MCP) derived from a deterministic, model-driven code generator, converts natural language intent into a lightweight language-agnostic intermediate markup expressed in a vocabulary the AI has been trained to produce reliably. Because the MCP defines strict boundaries — valid components, allowed patterns, supported data structures — it prevents hallucination.

Pass Two: A proven, model-driven code generator takes that markup and converts it into production code, whether that be JavaScript, Python or React, or even multiple languages. It produces the same reliable output every time and eliminates stylistic differences among different developers. It provides the consistency, compliance, testability, and maintainability that organizations have long relied on.

This hybrid model addresses barriers leaders most often cite — integration with legacy systems, security risks, lack of technical expertise — because each pass enables each of the different technologies to do what it does best. Generative intelligence is focused on understanding intent, interpreting natural language and reasoning about application behavior, and it delegates what it does worst (producing identical, production-grade code across runs) to a system purpose-built for that job.

AI converts natural language to specification. The code generator handles the engineering leap from specification to code.

It gives every developer — regardless of experience, language proficiency, or domain expertise — boundaries for converting their intent into production-quality applications.

This standardization means compliance teams can certify the output once — not re-audit every pull request. Teams can repurpose a single language-agnostic intermediate markup to target multiple platforms. A junior developer produces the same reliable markup as a senior architect because the architecture defines and controls the variability across the organization.

Constraining the AI to a validated pattern library mitigates security vulnerabilities. It reduces technical debt because the generated code follows consistent, maintainable architecture. By generating compact markup instead of verbose code, it reduces token cost and latency. Auditability and compliance are simplified because the deterministic layer produces traceable, repeatable artifacts.

Companies are adding AI capabilities at a staggering rate. In 2025, 84% of developers report using AI coding tools, with over half relying on them daily. Companies surveyed by Deloitte reported broadened worker access to AI by 50% in just one year. And 74% of companies said they plan to deploy agentic AI within two years.

Seventy-two percent of developers who have tried AI coding tools now use them every day. They report that 42% of the code they commit these days is AI-generated or assisted, according to a Sonar survey.

The rise of generative AI introduced extraordinary capabilities, but it’s not just a matter of accepting AI’s non-determinism as the cost of doing business. Deterministic boundaries — systems where AI takes human intent to structured specification, and proven code generators complete the journey from specification to production code — can make AI adoption safe, scalable, and accessible to every developer out of the box.

 

This blog is originally published on Techstrong.ai