India's next software opportunity may not be to write more applications for other people's platforms. It may be to build the open foundations that both humans and AI agents will use to create the next generation of applications.
For decades, India's software industry has demonstrated an extraordinary ability to take specifications, business requirements and existing technologies and turn them into working software at scale.
That model created an enormous industry.
But artificial intelligence is beginning to change the economics of software development.
The important question is therefore not simply whether AI will replace software engineers.
A better question is:
Which parts of software development become cheap when AI can write code, and which parts become more valuable?
The answer may be pointing toward an opportunity that India has not pursued aggressively enough: foundational software.
Instead of competing with AI to write another application, Indian engineers could increasingly build the libraries, engines, protocols, databases, media frameworks, graphics systems, APIs, developer tools and machine interfaces that AI itself will depend upon.
In other words:
Don't compete with AI at typing code. Build what AI needs underneath it.
The AI Coding Revolution Has a Hidden Limitation
The recent progress of AI coding systems is genuinely impressive.
Modern coding agents can read repositories, modify multiple files, run commands, inspect errors, write tests and iterate on implementations. AI can already produce surprisingly sophisticated applications from relatively simple instructions.
But there is an important distinction between writing software and having reliable software foundations available to build upon.
Suppose someone asks an AI:
"Create a reminder application that schedules notifications, stores reminders locally, survives a reboot and allows users to edit or delete reminders."
This is a reasonably approachable problem because modern platforms already provide many of the required building blocks.
The AI can combine a database, notification framework, scheduling system, user interface toolkit and operating-system APIs.
The result may still contain bugs. The architecture may need improvement. Dependencies may conflict. The application may require considerable debugging.
But the fundamental primitives already exist.
Now ask the AI:
"Build a reliable cross-platform video conversion engine that accepts arbitrary video files, decodes multiple codecs, handles audio and video streams, resizes frames, converts formats, encodes the result efficiently, preserves synchronization, muxes the output correctly and works across modern mobile hardware."
The problem changes completely.
The AI is no longer merely assembling mature components. It is suddenly forced to understand an enormous amount of low-level engineering.
Video processing involves codecs, containers, timestamps, buffers, hardware acceleration, pixel formats, audio pipelines, memory management, threading, synchronization and platform-specific behaviour.
Android's own MediaCodec, for example, is explicitly described by Google as a low-level interface to encoder and decoder components and is normally used together with other multimedia components such as MediaExtractor, MediaMuxer, MediaSync and Surface.
This is precisely where the difference between "AI can code" and "the ecosystem has good foundations" becomes visible.
My Own Experiments Pointed to the Same Problem
This is not merely a theoretical observation.
When I experimented with having frontier AI models build Android applications, relatively conventional applications were feasible.
A reminder application could be constructed using Android's existing scheduling, notification, database and UI infrastructure.
But when the task moved toward video conversion and media processing, things became much harder.
The problem was not necessarily that the AI could not write Kotlin or Java.
The problem was that the required abstraction was much weaker.
There was no single clean, modern, universally convenient "VideoEngine.convert(input, output, settings)" foundation that an AI could simply understand and reliably invoke.
Instead, the developer had to deal with lower-level interfaces and a large number of compatibility and implementation details.
This experience reveals something important about the future of AI-assisted programming.
AI becomes dramatically more powerful when difficult engineering problems have already been converted into reliable abstractions.
The AI can then assemble those abstractions.
This suggests that the value of software engineering will increasingly move toward the layers where those abstractions are created.
From Writing Applications to Building Digital Infrastructure
Imagine that somebody creates a mature, well-tested, open-source video foundation.
It provides:
- video decoding
- video encoding
- audio decoding and encoding
- format conversion
- resizing
- cropping
- frame extraction
- subtitle handling
- metadata handling
- hardware acceleration
- streaming
- container manipulation
- progress reporting
- error handling
- cross-platform APIs
- command-line interfaces
- language bindings
- machine-readable documentation
Suddenly, building a video application becomes much easier.
An AI agent might only need to invoke something like:
convert_video(
input="movie.mp4",
output="compressed.mp4",
codec="h265",
resolution="1080p",
quality=75
)
The difficult engineering has not disappeared.
It has simply been moved downward into a reusable foundation.
That foundation can then support thousands of applications.
This is the economic difference between selling implementation and building infrastructure.
The New Software Stack May Have Four Layers
The software industry has traditionally been understood roughly like this:
- hardware
- operating systems
- libraries and frameworks
- applications
AI introduces another layer of interaction.
A future stack could increasingly look like:
- Hardware — CPUs, GPUs, NPUs, storage, networking and accelerators.
- System foundations — operating systems, drivers, compilers, databases, graphics, codecs and networking.
- Agent-ready foundations — APIs, tools, schemas, documentation, state inspection, permissions and machine-readable interfaces.
- Applications — products assembled increasingly by humans and AI agents.
The fourth layer may become progressively cheaper to produce.
The second and third layers could therefore become strategically more important.
AI-Controlled Software Is Different From AI-Generated Software
This distinction is particularly important.
There are at least three different things happening under the broad label of "AI coding".
1. AI-generated code
The AI writes the implementation.
This is what most people think about when they hear "AI coding".
2. AI-controlled software
The software already exists, but an AI agent can operate it through reliable commands.
For example:
create_rectangle(x, y, width, height) create_circle(x, y, radius) boolean_intersection(object_a, object_b) export_image(format="png")
The AI does not need to understand how a geometric intersection algorithm works.
The graphics engine does.
The AI only needs to understand what the operation means and when to use it.
3. AI-generated content
The AI itself generates the resulting image, video, text, sound or other content.
These are very different technological models.
And the second model could become enormously important.
It means existing professional software can become agent-addressable.
The Agentic API Is Becoming a New Kind of Interface
Traditional APIs were designed primarily for programmers.
An engineer reads the documentation, understands the parameters and writes code against the interface.
AI agents introduce a new consumer for APIs.
The interface now needs to be understandable not only by humans but also by machines that reason over descriptions, schemas, examples and available operations.
This is already visible in emerging standards such as the Model Context Protocol (MCP).
MCP defines primitives including tools, resources and prompts. Tools allow models to invoke executable functions, while resources provide structured contextual information.
The significance is larger than one protocol.
It represents a shift in how software can be exposed.
A database does not necessarily have to be operated exclusively through a graphical interface.
A graphics editor does not necessarily have to be operated exclusively through menus and mouse clicks.
A spreadsheet does not necessarily have to be operated exclusively through cells.
A video editor does not necessarily have to be operated exclusively through a timeline.
The underlying capabilities can increasingly become tools that an AI agent can discover and invoke.
That makes the quality of the underlying API extremely important.
Documentation Becomes Part of the Software
This may be one of the most underestimated consequences of agentic software.
Documentation has traditionally been treated as something humans read.
In an agentic environment, documentation increasingly becomes part of the machine interface.
A good foundation should explain:
- what each operation does
- what inputs are accepted
- what outputs are returned
- what errors can occur
- what state is changed
- whether an operation is reversible
- whether an operation is destructive
- what permissions are required
- what performance characteristics exist
- what examples demonstrate correct usage
- what combinations of operations are valid
- what the agent should do when something fails
Modern MCP development is already moving in this direction. The protocol exposes tools with descriptions and schemas, while its broader ecosystem is developing ways to communicate server instructions and agent skills alongside tools and resources.
In other words:
The documentation of tomorrow may be executable knowledge.
This makes extremely detailed documentation an economic asset rather than merely a developer convenience.
What Should Indian Engineers Build?
If this thesis is correct, India should not simply ask:
"Which applications can we build using AI?"
We should also ask:
"Which difficult software capabilities could we turn into reusable foundations?"
There is an enormous list.
Tier 1: Simple Foundations
These may not sound glamorous, but they could provide excellent training grounds.
- notification engines
- scheduling engines
- document generation
- PDF creation and manipulation
- OCR
- text extraction
- speech-to-text
- text-to-speech
- file conversion
- archive management
- image resizing and transformation
- metadata extraction
- search libraries
- local indexing
- configuration management
These are not necessarily billion-dollar products individually.
That is not the point.
The point is to turn difficult recurring engineering problems into reliable reusable components.
Tier 2: Media and Data Foundations
Once engineers become comfortable with these systems, the complexity can increase.
- audio engines
- video engines
- image processing engines
- document rendering engines
- database engines
- search and indexing systems
- data transformation pipelines
- compression libraries
- streaming systems
- networking libraries
- file-system abstractions
- synchronisation engines
- local-first databases
These are much deeper engineering problems.
They require understanding memory, concurrency, algorithms, operating systems, storage, networking and hardware.
They are also exactly the kinds of foundations that thousands of applications could reuse.
Tier 3: Advanced Foundations
Then comes the genuinely difficult territory.
- graphics engines
- rendering systems
- physics engines
- simulation frameworks
- compilers
- language runtimes
- cryptographic libraries
- distributed databases
- distributed storage
- networking stacks
- virtualisation
- container infrastructure
- operating-system components
- GPU compute frameworks
- machine-learning runtimes
These are not ordinary application-development projects.
They require engineers who understand the machine underneath the abstraction.
And Then There Is Hardware
This is where the opportunity becomes particularly interesting for India.
The boundary between software and hardware is becoming increasingly important as AI workloads spread across CPUs, GPUs, NPUs and specialised accelerators.
Open hardware projects and open instruction-set architectures such as RISC-V provide another possible direction.
An engineer who understands operating systems, compilers, runtimes and hardware interfaces can eventually work much closer to the machine itself.
That could mean:
- RISC-V software stacks
- device drivers
- embedded operating systems
- accelerator runtimes
- GPU software
- NPU runtimes
- compiler backends
- hardware abstraction layers
- firmware
- verification tools
- simulation environments
- EDA tooling
This is particularly relevant to India's emerging interest in open silicon.
If India eventually wants to participate seriously in open CPUs, NPUs, GPUs and specialised accelerators, it will need software engineers who can cross the boundary between software and hardware.
The future opportunity is therefore not simply software versus hardware.
It is software deeply integrated with hardware.
The "Daily-Wage Programmer" Problem
There is an uncomfortable economic dimension to all of this.
Large parts of the global software-services economy are structured around selling engineering capacity.
A customer has a requirement.
A company assigns engineers.
The engineers implement the requirement.
The customer pays for the work.
The engineers move to the next project.
There is nothing inherently wrong with this model. It created enormous employment and helped establish India as one of the world's major technology centres.
But economically, it has a limitation.
The value is repeatedly tied to human implementation hours.
AI directly attacks the economics of repetitive implementation.
If an AI agent can produce in one hour what previously required ten engineers for a week, the market value of simply supplying those implementation hours will inevitably come under pressure.
That does not mean software engineering disappears.
It means the location of value changes.
Instead of asking:
"How many programmers can India provide?"
We should increasingly ask:
"How many foundational technologies can Indian engineers create and maintain?"
Foundational Software Is Digital Capital
A reusable software foundation behaves differently from a consulting project.
A consulting project may serve one customer.
A foundation can serve thousands.
A library written once can be integrated into hundreds of products.
A codec can be used by countless applications.
A database can support millions of users.
A graphics engine can power an entire ecosystem.
An open protocol can become infrastructure.
A compiler can support an entire hardware architecture.
This is why foundational software should be understood as digital capital.
It is not simply code.
It is accumulated engineering knowledge converted into a reusable machine.
Open Source Makes the Opportunity Even More Interesting
India does not necessarily need to own every foundation commercially.
Open source changes the equation.
An Indian engineering team could build an open-source foundation and allow companies around the world to build upon it.
Revenue could then emerge from:
- commercial support
- enterprise editions
- hosting
- integration
- certification
- hardware partnerships
- consulting
- specialised implementations
- managed services
- commercial extensions
But the underlying technical asset remains available to the ecosystem.
This creates a very different relationship between Indian engineers and global technology.
Instead of merely implementing somebody else's platform, Indian engineers can help create the platforms that others implement against.
India Already Has the Scale
The interesting thing is that India does not need to start from zero.
India already possesses an enormous technology workforce and a large software-services ecosystem.
NASSCOM's recent industry estimates put India's technology-industry workforce at millions of employees, while engineering R&D, GCCs and digital engineering have become increasingly important parts of the ecosystem. Its 2025 strategic review estimated FY2025 technology-industry revenue at more than $282 billion including hardware and projected the industry toward $300 billion in FY2026.
The question is therefore not whether India has enough engineers.
The question is what those engineers are encouraged to build.
There is a huge difference between having millions of people capable of writing software and having a large community capable of maintaining foundational software.
The second requires a different culture.
We Need More Engineers Who Understand the Machine
The foundational engineer of the future should probably be comfortable moving across multiple layers.
They should understand:
- algorithms
- data structures
- memory
- concurrency
- operating systems
- networking
- file formats
- compilers
- databases
- graphics
- hardware interfaces
- performance profiling
- testing
- security
- API design
- documentation
Languages such as C, C++ and Rust become particularly useful in this world, not because higher-level languages disappear, but because somebody eventually has to understand what is happening underneath them.
And AI itself becomes a powerful assistant for these engineers.
An engineer who understands a system can ask AI to generate implementations, explore alternatives, write tests, inspect code and produce documentation.
The engineer provides the architectural understanding.
The AI provides enormous amounts of implementation leverage.
This could actually make foundational engineering more productive, rather than less relevant.
The Goal Is Not to Eliminate Application Developers
This argument should not be misunderstood.
India should not suddenly tell millions of application developers to abandon their careers and become kernel developers.
That would be neither realistic nor desirable.
Application development will remain enormous.
People will always need products designed around particular businesses, industries, cultures and human needs.
What should change is the proportion of effort spent reinventing low-level capabilities.
If a mature open-source foundation already exists, developers should use it.
If it does not exist, that absence may represent an opportunity.
The application developer of the future may therefore become much more productive.
Instead of spending three months building an internal document engine, they might spend three days integrating a mature one.
Instead of writing a custom media pipeline, they might call a standard media foundation.
Instead of manually integrating dozens of APIs, an AI agent might orchestrate them.
This means foundational engineering does not destroy application development.
It makes application development cheaper and more powerful.
Universities Should Teach the Layers Below the App
This also suggests a change in engineering education.
Students should certainly learn Python, JavaScript, Java, Kotlin and modern AI tooling.
But they should also be encouraged to build things such as:
- a small database
- a file system
- a compiler
- a network protocol
- a simple operating-system component
- a graphics renderer
- a media pipeline
- a search engine
- a compression algorithm
- a small virtual machine
- a RISC-V emulator
- a hardware simulator
These projects teach something that framework-based application development often hides:
what the computer is actually doing.
Once an engineer understands that, AI becomes an accelerator rather than a replacement for understanding.
India Could Build a National Foundation Software Ecosystem
There is an even larger possibility.
India could deliberately identify a few hundred important open-source foundations and treat them as strategic digital infrastructure.
Not every project needs government ownership.
Not every project needs a giant company.
But India could create funding, fellowships, university programmes, industry partnerships and long-term maintenance programmes around strategically important open-source projects.
Consider a hypothetical Indian foundation stack:
| Layer | Examples |
|---|---|
| Basic utilities | Files, scheduling, notifications, archives, conversion |
| Documents | PDF, office formats, rendering, OCR |
| Media | Audio, video, codecs, streaming |
| Data | Databases, indexing, search, synchronisation |
| Graphics | Rendering, 2D/3D, GPU compute |
| AI infrastructure | Inference runtimes, model formats, accelerator APIs |
| Systems | Compilers, runtimes, operating-system components |
| Networking | Protocols, distributed systems, secure communication |
| Hardware | Drivers, firmware, RISC-V, accelerators, simulation |
Each layer would make the next layer easier.
That is how an ecosystem becomes self-reinforcing.
The First Foundations May Look Boring
There is another lesson here.
The first generation of Indian foundational software does not need to be spectacular.
A reliable notification library may be more useful than another flashy AI application.
A truly excellent PDF engine may quietly become part of thousands of applications.
A robust open-source video engine may save developers around the world enormous amounts of engineering effort.
A high-quality document renderer may become infrastructure for countless AI agents.
A well-designed database API may become invisible infrastructure used by applications nobody has imagined yet.
This is how foundational technologies often work.
Their success is measured by how many things can be built without thinking about them anymore.
AI May Actually Increase the Value of Good Foundations
This is perhaps the most important conclusion.
It is tempting to assume that AI makes software less valuable.
But another interpretation is possible.
AI makes well-abstracted software more valuable.
If an AI agent can discover a capability, understand its inputs and outputs, invoke it safely, inspect the result and recover from failure, that capability becomes a building block for automated software creation.
One foundation can therefore become part of thousands or millions of future AI-generated workflows.
The leverage becomes enormous.
This creates a positive feedback loop:
- Engineers build a reliable foundation.
- The foundation receives excellent documentation and APIs.
- AI agents learn how to use it.
- AI agents build applications using it.
- More applications expose new requirements.
- The foundation improves.
- More developers and agents adopt it.
The foundation becomes more valuable precisely because AI makes it easier to build things on top of it.
Don't Build What AI Can Easily Assemble
This could become a useful rule for the next generation of Indian software engineers.
If an application can be assembled from ten mature open-source components in a few hours, building another copy of that application may not be the best long-term engineering opportunity.
Instead ask:
- Which component is missing?
- Which API is painful?
- Which format has poor support?
- Which low-level interface is unnecessarily difficult?
- Which library is abandoned?
- Which important project has poor documentation?
- Which capability is repeatedly rebuilt by thousands of developers?
- Which foundation could make an entire category of applications easier?
That is where the opportunity lies.
The Next Indian Software Story Could Be Deeper Than Services
India's first major software revolution was built around services.
The next could be built around products.
But there is potentially an even deeper stage:
infrastructure.
Not just SaaS products.
Not just mobile applications.
Not just AI wrappers.
Not just consulting.
But the underlying software that makes all of these things possible.
And as the AI era develops, the customer for this infrastructure will no longer be only a human developer.
It will increasingly be another piece of software.
An AI agent.
A coding agent.
A design agent.
A research agent.
A financial agent.
A manufacturing agent.
A scientific agent.
Millions of such agents may eventually need reliable software foundations.
From Software Services to Software Infrastructure
India should therefore think beyond the question:
"How many software engineers will AI replace?"
A much more productive question is:
"What foundations can Indian engineers build so that the next billion software systems can be created more easily?"
That is a completely different vision.
It does not require India to defeat Silicon Valley.
It does not require India to build the next giant consumer platform.
It does not require every engineer to become an AI researcher.
It requires something much more practical:
Build excellent software that other software can depend upon.
Start with the boring problems.
Make them reliable.
Document them obsessively.
Expose clean APIs.
Make them accessible from multiple languages.
Make them usable locally and offline where possible.
Make them friendly to automation.
Make them safe for agents.
Make them open where openness creates ecosystem value.
Then move deeper.
Into graphics.
Databases.
Networking.
Compilers.
Operating systems.
AI runtimes.
Hardware interfaces.
Open silicon.
This is not a retreat from the AI revolution.
It is a way of moving closer to its foundation.
The Opportunity Below the Application Layer
There will always be people who build applications.
There will always be people who design user experiences.
There will always be people who solve business problems.
But increasingly, AI will be able to perform more of the mechanical work involved in turning those requirements into software.
That makes the deeper layers more interesting.
The engineer who understands the machine, the operating system, the protocol, the file format, the compiler, the accelerator and the API can become the person who creates the abstraction that thousands of other engineers — and eventually millions of AI agents — use.
That is a fundamentally different position from selling another block of programming hours.
It is the difference between writing code for a project and building a piece of the digital infrastructure on which future projects will run.
India already has the people.
India already has the software culture.
India already has enormous experience operating at global scale.
What is needed is a stronger deliberate push downward — toward foundational software, open infrastructure, systems engineering and eventually hardware-software co-design.
The age of AI may reduce the value of writing repetitive code.
But it could dramatically increase the value of creating the foundations from which that code can be generated.
India should not merely become the world's largest consumer of AI coding agents.
It should help build the foundations those agents stand on.
That may be one of the most important software opportunities of the next decade.
