The great mistake of the AI mania is to confuse software-shaped output with a software product. Software is not dying. The panic is simply outrunning the evidence. AI can automate code generation and repetitive development work, but enterprise technology is built on accumulated knowledge, integration, reliability, oversight and trust; making the extinction of engineers, SaaS and IT services far less inevitable than the current mania suggests.
There is a peculiar quality to every technological revolution. First comes the breakthrough. Then comes the excitement. Shortly thereafter comes the conviction that everything that existed before it is now obsolete.
The internet was going to eliminate newspapers. Cloud computing was going to eliminate IT departments. Blockchain was going to eliminate banks. Remote work was going to eliminate offices. Every cycle produces the same prediction: this time, the old world really is over.
Artificial Intelligence has simply inherited the tradition.
Today, one could be forgiven for believing that software engineers, product managers, consultants, SaaS companies, outsourcing firms and perhaps half the GDP of India are all quietly awaiting replacement by a particularly enthusiastic chatbot.”
Reality, as it usually does, is proving less theatrical.
The mistake begins with a simple misunderstanding of what software actually is.
Most discussions about AI assume that software consists primarily of writing code. It is an understandable assumption because code is the visible output. It is the thing that can be measured, generated, and proudly displayed in GitHub repositories.
This is the central confusion surrounding the current AI phenomenon.
We have watched machines become astonishingly good at producing software-shaped objects and concluded that they must therefore be close to replacing the people and organisations that create, maintain, secure, sell and operate software.”
But anyone who has spent time building enterprise software knows that code is only one ingredient; and often not the dominant one.
Artificial intelligence is real, powerful and advancing rapidly. Stanford’s 2026 AI Index reports that organisational adoption of AI has reached 88 per cent. But adoption is not the same as successful production deployment, and production deployment is not the same as profitable transformation. That is respectable progress for a young technology. It is somewhat less impressive as evidence that the salaried population should begin returning its office equipment.
A Product Is Not A Pile Of Code
At its simplest, a software product combines two things: technology and usability.
One determines whether people can accomplish what they need. The other determines whether the software is capable of doing it. Everything else exists to ensure those two qualities survive contact with reality.
These two elements are multiplicative rather than additive. Excellent engineering attached to a dreadful interface produces an expensive curiosity. A lovely interface attached to unreliable technology produces a slightly more attractive expensive curiosity.
Once a product leaves the comfort of an engineering laptop and enters the unforgiving world of paying customers, an entirely different set of concerns emerges.
Can it survive millions of transactions? Can it recover from failure? Can it be upgraded without breaking payroll on a Monday morning? Can it satisfy regulators? Can it integrate with twenty-seven systems that nobody remembers buying but nobody dares switch off? Can it produce an audit trail when someone from compliance inevitably asks why an invoice from fourteen months ago behaved differently from today’s?
A prototype needs to work once, usually while its creator is standing nearby. A production application must work repeatedly, with inconsistent data, unpredictable demand, ageing integrations, careless users, inventive attackers and customers who have discovered an edge case that no reasonable designer would have anticipated because no reasonable person would ever behave that way.
This is why production readiness involves stability, security, scalability, performance, integrations, maintainability, observability and safe upgrades. It involves backups that have actually been tested, permissions that do not accidentally allow an intern to approve a billion-dollar transfer, and deployment processes that can reverse a bad release before the company’s name begins trending for the wrong reason.
None of this diminishes the importance of coding. It places coding inside the larger process to which it belongs.
There is no universal figure for the share of enterprise-product effort represented by writing code. It varies by system, team and stage of development. But suppose, as a useful hypothesis, that direct code production accounts for roughly a fifth of the total work.
Even if AI cut that portion in half, the total effort would not fall by half. It would fall by ten per cent before accounting for new review, integration and verification costs.
The arithmetic is less exciting than the keynote.
The point becomes more pronounced as a product matures. In a new application, much of the work involves creating functionality. In an old application, much of it involves understanding why the functionality behaves as it does and changing it without disturbing everything around it.
Enterprise development gradually changes from an act of invention into a practice of controlled intervention.”
The United States Government Accountability Office reports that federal agencies have typically spent about eighty per cent of their annual IT and cyber budgets on operating and maintaining existing systems. In 2025, the G.A.O. identified eleven critical legacy systems supporting functions including healthcare, taxation, infrastructure and national security. Of ten systems identified for urgent modernisation in 2019, only three had been fully modernised by February, 2025. One of the remaining systems did not yet have a completion date. Government technology, like government itself, appears to have discovered a form of immortality based largely on the postponement of retirement.
The lesson is not that old software is good. Some legacy systems are expensive, insecure and increasingly difficult to staff. The lesson is that replacing software is not equivalent to generating its apparent functionality.
The Coding-Productivity Evidence Is Less Cinematic Than The Demos
AI coding tools are already very good at producing functions, tests, interfaces, documentation and migration scripts quickly.
In one Microsoft Research and GitHub experiment, developers using GitHub Copilot finished a JavaScript task about 55.8 per cent faster than those without it. The task was to build an HTTP server. That is useful evidence, but it is very different from changing the payment logic inside a twenty-year-old banking system whose original developers may now be growing olives somewhere in Tuscany.
Research by METR showed the other side of the story. In an early-2025 study, experienced open-source developers working on codebases they already knew actually took 19 per cent longer when using the AI tools available at the time. Interestingly, the developers still felt that AI had made them faster. Programmers, it turns out, are human too.
The sensible conclusion is not that AI makes developers slower, nor that it makes them ten times faster. It depends on the task, the developer, the codebase and how much accuracy matters.”
That distinction is at the heart of enterprise software.
Writing a new function is a clear task. Changing a live enterprise system often means understanding why something was built a certain way in the first place.
Why was this rule added seven years ago? Is that apparently useless field still being used by an insurance partner? Is the customer called “Test Account” actually one of the company’s biggest clients? Is that ugly piece of code simply bad code, or is it ugly because three external systems have three different definitions of a month?
AI can now inspect repositories, follow dependencies, read documentation and make more targeted changes. Modern coding agents can edit individual files, run tests and show developers exactly what changed. So the future of AI development does not have to mean regenerating half an application every time someone changes a requirement.
That kind of vibe coding is not the future of software engineering. It is mostly bad engineering with better marketing.
But even precise editing does not solve the hardest problem. The AI still has to understand the difference between unnecessary complexity and complexity that exists for a good reason.
That is one reason developer trust remains limited. In Stack Overflow’s 2025 survey, 46 per cent of developers said they distrusted the accuracy of AI tools, compared with 33 per cent who trusted them. Only about three per cent expressed high trust, and experienced developers were among the most sceptical.
These are not people protecting typewriters from progress. They are the people who have to explain what happened when AI-generated code breaks something in production.
Google’s DORA research offers a useful way to think about this. AI is mainly an amplifier.
In a company with good architecture, strong testing, clear documentation and disciplined development practices, AI can make a good team much faster.
In a company with messy systems, weak testing and poor documentation, AI can simply help create more mess, more quickly. AI does not remove the software-development system around it. It inherits that system, including all the problems everyone has spent years avoiding.
Code Is Institutional Memory Wearing Punctuation
Enterprise systems are difficult because organisations accumulate decisions.
A core-banking platform is not merely a program that subtracts money from one account and adds it to another. It embodies decades of rules concerning settlement, reversals, interest, fraud, reporting, holidays, customer categories, regulatory demands and emergencies that once occurred and must never be allowed to occur again.
Every bug fix can become a business rule. Every major customer can become an exception. Every acquisition can produce another integration that nobody particularly likes but nobody dares remove. The source code gradually becomes a compressed record of institutional experience.
The persistence of COBOL is often presented as evidence that banks and governments are technologically backward.
There is some truth in this. There are legacy systems that should have been replaced years ago and remain operational mainly because every proposed modernisation programme acquires a steering committee, a revised budget and, eventually, a commemorative mug.
But COBOL also illustrates something more important: enterprise software accumulates knowledge.
A core-banking system is not merely a way to debit one account and credit another. It contains decades of rules concerning settlement, reversals, interest calculations, fraud, holidays, reporting, reconciliation, regional practices and exceptions created after somebody once lost a very large amount of money.
The value lies not only in what the system was designed to do. It lies in everything the system learned not to do.
IBM says its modern mainframes are designed to process as many as a trillion web transactions a day with high levels of security and reliability. The systems running on them are not retained because chief information officers feel a sentimental attachment to green text. They are retained because transactional integrity has been demonstrated over decades, and because replacing a trusted system with an elegant one is career-enhancing only when the elegant one works.
The safest production system is frequently not the system with the prettiest architecture. It is the one that has already survived ten million Thursdays.”
This creates a profound asymmetry between humans and generative systems. A developer who has maintained a product for five years possesses a mental model of it. Some of that knowledge is documented. Much of it exists as remembered incidents, customer conversations, architectural compromises and the faint dread associated with changing a particular class.
An AI model may read more code than the developer can. But reading the repository does not necessarily reveal why the repository is the way it is.
The future of AI in legacy environments is therefore more likely to involve archaeology than demolition: explaining old code, generating missing documentation, identifying dependencies, building tests around undocumented behaviour, translating interfaces, assisting incremental refactoring and helping scarce experts transfer their knowledge.
This may be less dramatic than generating an entire bank during a conference keynote. Banks, on the whole, prefer it that way.
Tokens Are Cheap, Responsibility Is Not
The economic argument for replacing developers often begins with a superficially persuasive comparison.
An AI model can produce a large quantity of code for a modest token charge. A software engineer costs a salary, benefits, office space, equipment and a manager who schedules meetings to discuss productivity.
The machine must therefore be cheaper.
This compares the marginal cost of text generation with the total cost of accountable work.
It is rather like comparing the cost of flour with the annual salary of a baker and concluding that bread has been overstaffed.
Token prices are genuinely low. As of July, 2026, Anthropic lists introductory Claude Sonnet 5 pricing at two dollars per million input tokens and ten dollars per million output tokens, rising in September to three and fifteen dollars respectively. At the introductory rate, an illustrative agentic session consuming five million input tokens and one million output tokens would carry a direct model cost of about twenty dollars. This is not an estimate of a typical coding task; it merely demonstrates how inexpensive raw generation can be.
But enterprises do not purchase raw tokens. They purchase correct outcomes.
The complete cost includes repository indexing, repeated agent runs, orchestration, security controls, model evaluation, testing infrastructure, data protection, auditability, monitoring, failed attempts, human review, rework and responsibility for whatever finally ships.
The token invoice is the meter reading. It is not the cost of the journey.
The distinction becomes especially important when comparisons are made with labour markets outside the United States. The U.S. Bureau of Labor Statistics reported a median annual wage of $133,080 for software developers in May, 2024. At that level, even modest productivity gains can justify substantial expenditure on automation.
India begins from a very different cost base.
Nasscom estimated that India’s technology industry would generate $315 billion in revenue in fiscal 2026 while employing 5.95 million people. A rough division produces sector revenue of about $53,000 per worker: not salary, and not a like-for-like comparison, but a useful indication of the industry’s underlying economics. The total revenue supported by an average Indian technology worker is far below the median wage of a U.S. software developer. Automation calculations imported directly from San Francisco therefore tend to arrive in Bengaluru suffering from jet lag.
In a high-cost market, replacing five employees may finance an elaborate AI deployment even if the system requires considerable oversight.
In a lower-cost market, the same deployment may save less money, while its integration, verification and governance requirements remain substantial. A capable Indian engineer using AI may be economically superior to both an unaided engineer and an autonomous agent requiring expensive supervision.
India’s real contest is not AI versus the Indian engineer. It is the AI-enabled Indian engineer versus every other delivery model.”
That is a much less apocalyptic proposition for India, provided its workforce and services companies adapt. The work most exposed in India is repetitive, specification-driven and easy to verify.
Routine code conversion, boilerplate implementation, basic testing, simple reporting, documentation drafts and low-complexity support can all be performed with fewer people.
The traditional services model is particularly vulnerable where customers are billed for large teams rather than for outcomes. If 100 people can now perform the work of 140, the customer is unlikely to volunteer to continue paying for 140.
This will pressure entry-level hiring, staff-augmentation contracts and the organisational pyramids through which Indian services companies have traditionally trained junior employees. That is a real disruption. It is not the disappearance of enterprise technology work.
The U.S. Bureau of Labor Statistics draws a useful distinction. It projects employment of narrowly defined computer programmers to decline by six per cent between 2024 and 2034. Yet it projects employment of software developers, quality-assurance analysts and testers as a group to grow by 15 per cent.
The difference is between producing code and taking responsibility for systems.
Indian services companies will have to move from selling effort toward selling domain expertise, modernisation, integration, security, managed operations and measurable outcomes. The evidence so far does not suggest that enterprise customers have stopped buying those services.
TCS reported $30 billion in fiscal-2026 revenue, a $40.7-billion order book and a 25-per-cent operating margin. In its first quarter of fiscal 2027, it reported an annualised AI revenue run rate of $2.6 billion, up 13.6 per cent sequentially.
Accenture reported $2.7 billion of fiscal-2025 revenue from generative and agentic AI and $5.9 billion in related bookings. Those figures exclude its revenue from classical AI, data services and AI used internally to deliver other services.
Company-defined AI revenue should be treated with appropriate care. New categories in corporate reporting occasionally expand with the enthusiasm of a guest list at an Indian wedding. Still, the direction is meaningful.
The firms supposedly being replaced by AI are being paid to help customers deploy AI.
SaaS Is Not Merely Code Rented Monthly
The same mistake appears in predictions of the death of Software-as-a-Service.
Why, the argument goes, would a business continue paying for Salesforce, HubSpot, Zoho, Workday or an inventory platform when an AI can generate a custom application?
Because the business did not want to own a software-development company in the first place.
A small distributor does not wake up hoping to maintain authentication services. It wants to know what is in the warehouse. A dental practice does not have an ideological commitment to subscription software. It wants appointments scheduled, payments collected and patient records available without the receptionist becoming the system administrator.
SaaS customers are not merely renting code. They are transferring responsibility.”
The subscription pays for hosting, updates, backups, security patches, regulatory adaptations, mobile clients, integrations, documentation, customer support, uptime commitments and the continuing employment of someone whose weekend can be ruined instead of theirs.
This is why mature SaaS products remain economically relevant even as software generation becomes cheaper.
ServiceNow ended 2025 with quarterly subscription revenue of $3.47 billion, up 21 per cent from the previous year, and remaining performance obligations of $28.2 billion. It had 603 customers paying more than five million dollars in annual contract value. These customers presumably had access to AI coding tools and nevertheless chose not to generate their own enterprise workflow platform between meetings.
Workday’s fiscal-2026 subscription revenue grew 14.5 per cent to $8.83 billion, with total subscription backlog reaching $28.1 billion. Again, this does not make Workday immortal. It indicates that large enterprises continue to value a supported, integrated and accountable system for finance and human resources even while experimenting aggressively with AI.
SaaS will certainly change.
Simple applications with shallow functionality and weak integrations will become easier to reproduce. Thin products that are essentially databases wearing attractive buttons may face severe price pressure. Per-seat pricing may become less attractive when AI agents perform work previously done by human users. Customers may build more bespoke workflows around standard systems, using AI to customise the edges.
But the more standardised and consequential the business function, the stronger the argument for buying a proven system.
Few companies will vibe-code their own payroll platform merely because the interface can be produced quickly. Payroll software is exciting mainly when it fails.
The more plausible model is to buy the trusted core and generate the differentiating edge.
A business may keep its CRM while creating a custom quotation workflow. It may retain its inventory platform while building an AI assistant that investigates stock anomalies.
It may continue using Workday while automating an internal approval process that no commercial vendor has offered, possibly because no other company employs three deputy vice-presidents responsible for stationery.
AI expands the range of customisation that is economically feasible.
It does not abolish the value of standardisation.
What Is Genuinely At RIsk
The mania is wrong when it treats software creation as a single activity that can be automated uniformly.
The sceptics would be equally wrong to conclude that enterprise complexity protects every existing job and company.
AI is already threatening work that is repetitive, local and readily evaluated. Boilerplate code is at risk. Simple CRUD applications are at risk. Basic website implementation is at risk. Routine unit-test generation is at risk. Documentation first drafts are at risk. Code conversion and migration scaffolding are at risk. Tier-one technical support is at risk. Low-complexity reporting is at risk. Products whose principal distinction is that nobody had yet bothered to build them are particularly at risk.
AI also changes the value of skill levels. An experienced engineer may use it to explore unfamiliar systems, create tests, compare architectural options and automate repetitive changes. A novice may produce impressive code without understanding why it works, which is useful until it does not.
The danger is not simply bad generated code. Humans have produced abundant quantities of that without computational assistance.
The danger is unowned code: software that no one fully understands, generated faster than the organisation can review it, embedded in systems whose consequences exceed the competence of the person supervising the machine.
A team can accumulate technical debt at a much higher velocity when the debt is produced fluently and includes comments.
This makes oversight more important, not less.
The faster implementation becomes, the more valuable architecture, testing, product judgement and operational discipline become. Removing the bottleneck in code production can merely relocate the bottleneck to verification.”
The factory now makes screws ten times faster. Unfortunately, the inspector remains one person with a clipboard.
The Customer Has Not Joined The Revolution
The most durable fact in software economics is that customers do not particularly care how software is created. They care that it works.
A retailer does not award extra points because its inventory system was hand-crafted by humans. Nor does it accept incorrect stock counts because the algorithm that produced them was very advanced. A bank customer does not ask whether the transaction was processed in COBOL, Java or interpretive dance. The money either arrived or it did not.
Customers value reliability, usability, compatibility, support and cost.
AI can improve each of these. It can reduce development time, lower support costs, accelerate customisation and make sophisticated features affordable to smaller businesses. It may allow new competitors to challenge incumbents whose products have become expensive, bloated or indifferent to customers.
But the customer’s indifference to implementation cuts both ways.
A SaaS product does not become obsolete merely because a competitor can reproduce some of its interface cheaply. An IT-services firm does not become irrelevant merely because code generation is faster. A developer does not become unnecessary merely because the first draft of a solution is automated.
The buyer evaluates the finished system, the operational commitment behind it and the price. The AI may write the code: The customer still expects somebody to answer the phone.
After The Mania
Artificial intelligence may become one of the most important general-purpose technologies of this century.
Its capabilities are advancing rapidly. It will reduce development costs, alter team structures, automate repetitive work and change the economics of both services and software products.
Some companies will need fewer employees. Others will attempt more projects because the cost of experimentation has fallen. Many will do both.
The strongest SaaS businesses will use AI to improve their products and reduce the cost of serving customers. The strongest services companies will use it to deliver results with smaller teams while expanding into modernisation, governance, integration and managed operations.
The strongest Indian technology firms will combine their cost advantage with AI-enhanced productivity rather than attempting to compete against AI as though it were an offshore location with unusually cheap office space.”
The mistake is believing that capability arrives without context, that generation eliminates ownership, that intelligence eliminates institutions and that a persuasive demonstration is simply a production system with better lighting.
When payroll fails on Thursday morning, somebody still has to join the call.