The ability to Learn, Unlearn and Re-learn every 3-5 yrs - has always been a key to success for most software engineering professionals. In other words, learn (a new and promising tech) in six months, become a pro over the next 6-12 months and maximize earnings over the next ~3 yrs. Repeat this for 3-4 times during the working age and one achieves compounding returns.
AI has disrupted this theory in ways most people, including software professionals, have failed to understand.
This is a completely new chapter in the Capital vs. Labour textbooks.
There is an acute shortage of tech sales professionals / consultants and no one is talking about it.
Most software engineers spend years before they get into sales (client-facing) roles and are responsible for PnL management. The smarter ones among the fresh graduates will compress this timeline to months, instead of years.
The more I use AI, the more I realise that great AI outputs depend less on AI itself and more on two human qualities: (1) clarity of thought and (2) the ability to articulate it well.
This is how the tech landscape has changed...
Some of the best software developers I've worked with - (1) speak average English, (2) think in their native language, (3) but have fantastic clarity in translating business requirements to code.
These developers are now competing with AI-empowered software developers who can articulate requirements and communicate effectively in English.
Every time I attend a technology expo in India or the UAE, I notice a pattern.
Indian stalls are predominantly software.
Chinese stalls are predominantly hardware.
And within India's software identity, core software product development still doesn't receive the recognition it deserves.
---
The journey began in the early 1990s with software services. Indian engineers solving technology problems for businesses in the West.
Then came the BPO, KPO, and ITES wave. While not software development in the traditional sense, it became part of the broader IT narrative. So much so that government policies often treated IT and ITES as a single category.
The next wave was start-ups.
Many built products for global markets. Others built for India using global capital. Much of the software innovation during this period involved adapting proven models to Indian realities.
E-commerce. Aggregation platforms. Marketplaces.
Important businesses, certainly.
But did we build enough foundational technology of our own?
There are notable exceptions. Companies such as Mastek, KPIT and Infosys have developed industry-specific products and platforms, often drawing from decades of services experience.
Yet, for a country with our engineering talent and scale, it feels like we should have covered far more ground over the last three decades.
---
The good news is that we have an opportunity to accelerate.
AI can help us clear technical debt, compress development cycles, and pursue solutions that may have previously been uneconomical to build.
At the same time, we need a stronger hardware ecosystem. Software leadership without hardware capability leaves too much value on the table.
Perhaps the next chapter of India's technology story should not be about services, outsourcing, or adaptation.
Perhaps it should be about building.
Many startup founders have spent years inside large organisations before starting out on their own.
So when they build their companies, they consciously avoid the things they disliked most: layers of approvals, slow decisions, and processes that get in the way of execution.
In the early days, that works brilliantly.
But growth changes the equation.
As teams expand, customers increase, and responsibilities multiply, startups inevitably need systems and processes. The challenge is no longer whether to introduce them, but how to do so without slowing down innovation.
The founders who seem to navigate this transition best understand that processes shouldn't create bureaucracy. They should create clarity, accountability, and the ability to scale.
Interestingly, we've seen a very similar pattern in SMEs once they cross certain growth milestones. Different businesses, different contexts - but often the same underlying questions:
- How do you build an organisation that is structured enough to scale, yet agile enough to keep evolving?
- At what stage did formal systems and processes become necessary in your organisation?
- And what worked - or didn't work - during that transition?
No tool - machine or software - can fix a broken process.
We’ve been solving the wrong problem.
Transactional systems remove redundancy - for efficiency.
Data warehouses add it back - for insight.
Two systems. Two truths.
Neither complete.
AI doesn’t bridge this gap.
It exposes it.
If data can’t move from transaction to insight to action,
it’s not a data problem.
It’s an architecture problem.
Most people collect data.
Few understand the context that turns it into value.
I don’t know how things work in Silicon Valley - I’ve never been to any place west of London.
But here in India, across acres of the software support and systems maintenance ecosystem - call it IT services, outsourcing, offshoring, or GCCs - the most respected people are the ones who can debug.
Not the ones who write the most code.
The ones who can fix what breaks.
These are professionals who have seen so many systems fail, behave strangely, and recover that they’ve internalised how technology really works. Give them a problem and, within minutes, they can trace the root cause and suggest a fix.
Early in my career, I worked with one such professional.
The probability of finding him at the sutta-tapri outside the office was often higher than finding him at his desk. But when something broke, someone would walk up to him, explain the issue, and he would calmly point to the exact place in the system where things had gone wrong.
And, he was almost always right.
That’s the beauty of real technology expertise - people who have seen systems behave in the messy complexity of real-world environments.
Will AI replace such experts?
Maybe. Maybe not.
But will AI create the need for many more such experts?
I would say - yes.
Someone will still have to debug the future.
