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.
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.
Businesses often overestimate what technology can achieve in the short term,
and underestimate what it delivers over the long term.
Technology evolves rapidly.
Human behaviour adapts slowly.
Real transformation happens when the two align.
The internet is a good example.
It didn’t change everything overnight - but over time, it reshaped how we work, communicate, and build businesses.
AI won’t change everything overnight - but it may leave very little unchanged.
Approach to building an MVP is fundamentally different from building a mature product, and very few teams can successfully navigate this transition. Let me explain why.
An MVP exists to validate the core workflow - the central problem the startup or business aims to solve. The operative word here is IF.
An MVP is designed to check if the technology can solve the intended business problem. It must prove the happy flow, deliver the core value proposition, and demonstrate product-market fit. If it does that, the MVP is considered a success.
But the moment the MVP must evolve into a mature system, everything changes.
The focus shifts from core functionality to edge cases.
From scenarios where the system should work to scenarios where the system could break.
This requires deep analysis of every possible path a user may take, mapping the universe of scenarios, designing the corresponding workflows, and validating them through rigorous testing.
Beyond logic and workflows, a mature product must also deliver on interface quality, user experience, performance engineering, and long-term scalability.
The transition, therefore, is not a linear upgrade. It is a shift from proving possibility to engineering reliability.
Teams that succeed in this transition understand that MVP building is an experiment, but product maturity is an operating discipline. The competitive advantage belongs to those who can evolve from rapid validation to deliberate, scalable engineering without losing speed or control.
