Published Feb 08, 2026 | 3:00 PM ⚊ Updated Feb 08, 2026 | 3:00 PM
Alternative livelihoods.
Synopsis: Zoho co-founder Sridhar Vembu’s ‘warning’ that those who depend on writing code for a living should start considering ‘alternative livelihoods’ has triggered panic and an animated discussion among multiple platforms linked to coders.
A single sentence can do strange things in a country where software is not just an industry, but a promise.
On 6 February, Sridhar Vembu, Co-founder and Chief Scientist of Zoho Corporation, wrote that examples of “AI-assisted Code Engineering productivity” were “pouring in,” and that those who depend on writing code for a living should start considering “alternative livelihoods.”
He included himself in the warning and insisted it was not panic, but “calm acceptance and embrace.”
Within hours, Indian developer circles that usually argue about frameworks, hiring cycles, and technical debt turned into something else: they became platforms for a nationwide argument on the future of the coding class.
Some readers took Vembu literally and heard an exit sign. Others read it as a narrower message: routine implementation is losing scarcity, and careers built only on that layer will be vulnerable. Many heard something more unsettling: even leaders who build software companies are openly uncertain about how many software jobs the next decade will hold.
What made the post hit harder than the usual AI panic was the messenger. Vembu has long positioned himself as one sceptical of hype, focused on shipping usable AI under guardrails rather than selling magic. So when he says the economics of writing code may shift fast enough to threaten livelihoods, people listen.
Vembu framed his warning around examples meant to signal a threshold. He referenced a Bhagavad Gita app reportedly built with AI by someone without coding knowledge.
He also pointed to an AI-built C compiler as evidence that models are now producing complex engineering artefacts that would not normally be dismissed as trivial. Coverage of the episode repeated those examples and the core quote as the trigger for the debate.
Then came the sentence that travelled farthest.
“At this point, it is best for those of us who depend on writing code for a living to start considering alternative livelihoods. I include myself in this. I don’t say this in panic, but with calm acceptance and embrace.”
The phrase “alternative livelihoods” is not a technical term. It reads like life advice. It triggers a very specific fear in a country where engineering has become shorthand for stability: if the ladder narrows, where do the millions climbing it go?
As the post spread, it was frequently repeated in headline-like form, often with the qualifiers removed. A share-post by Navroop Singh, which links to coverage and repeats the phrase as a stand-alone banner line, illustrates how quickly nuance can collapse into a simple imperative that invites maximum alarm.
This is the first analytical anchor of the episode. The controversy is partly about AI, and partly about how information travels. A single sentence can be interpreted as sober preparation, sensational prediction, or performative pessimism depending on what the reader thinks is at stake.
In the public reaction, three separate questions got tangled:
Capability: What can AI do?
Reliability: How often does it do it correctly in real-world conditions?
Economics: Even if it is imperfect, does it change the cost structure enough to reshape jobs?
Vembu’s post is best read primarily as an economic warning grounded in the perceived acceleration of capability. He is not making a narrow claim that AI writes syntactically correct code. He is pointing to what he believes is a pattern: models are moving from assistance to end-to-end construction often enough that the value of routine coding work will compress.
What he did not do was provide labour-market evidence or claim an immediate collapse. People who read it as a doomsday forecast are reading an implication into it. That implication may still be important, but it is not identical to the text.
This distinction matters because much of the backlash responds to the most extreme interpretation: that software engineering is essentially finished. Vembu’s defenders often respond to a different claim: that the economics of routine coding work is deteriorating, even if engineering remains.
Those are not the same argument. The debate becomes clearer once they are separated.
Supportive reactions did not always take the form of “engineers are done.” The more serious supportive argument is about business models and labour economics.
Actor and entrepreneur Arvind Swamy captured that line bluntly. The headcount and arbitrage model, he wrote, will be broken, even if software engineering, architecture, domain ownership, and “AI-governed delivery” remain relevant.
This framing matters because it bridges what otherwise looks like a binary fight. The work can remain while the seat count shrinks. If one engineer with strong AI tools can do what two or three engineers did before, hiring slows, and expectations rise. Entry-level funnels tighten. Middle layers compress. People who built careers on being reliable implementers feel the ground shift.
That is a different claim from “engineering is dead.” It is a claim about scale. How many people can the industry absorb, and what does it pay for?
In India, that question carries extra weight. The employment pipeline has been built on the assumption that demand for coders will continue to scale.
Balance: ‘Engineering relocates’ up the stack
The most useful counterweight to both panic and denial is a balanced view: AI changes the job, and the job survives.
Writer and commentator Arnab Ray pushed back on extreme obsolescence claims, arguing that the rhetoric about “software engineering being dead” ignores how the profession has repeatedly absorbed automation. Compilers replaced assembly in many contexts; the work moved upward. In his view, AI shifts the job again toward judgment and system-level decisions, not toward disappearance.
Two academic papers published in recent years make a similar point in more formal language. They argue that software engineering includes long-term maintenance, reliability, deployment, and practical use, and that generative models may automate routine steps without rendering the discipline irrelevant.
This balanced camp is not saying there is no disruption. It is saying the disruption is being misdescribed.
AI is very good at producing code. But software engineering is not reducible to producing code.
If you remove the most extreme claims, the sceptical view becomes sharper and more actionable.
Akshay Saini, a prominent educator in the developer community, posted a direct disagreement, calling Vembu’s statement bold but premature. His point is the same one working engineers repeat: building software involves problem selection, design, debugging, ownership, and responsibility. AI can assist, but it does not carry accountability.
This sceptical position does not require denying AI’s progress. It argues that AI changes how work is done without cleanly replacing the people who must answer when systems fail.
Where sceptics and supporters quietly converge is on one reality that rarely makes headlines: the marginal cost of producing a draft solution is falling, and the cost of proving it correct is not falling nearly as fast.
That is where the debate becomes real.
The fastest way to cut through the noise is to describe how software actually gets shipped.
Production software is a chain of responsibilities:
AI can help with several steps, but it has a distinct advantage at the most visible part: generating and modifying code quickly. That part looks like progress because it is easy to demonstrate. The harder parts, verification and ownership, decide whether an organisation can depend on what it ships.
This is also why the compiler example, whether impressive or not, cannot settle the jobs question on its own. A compiler is an artefact. A software business is a living system that evolves, breaks, gets patched, faces security threats, and runs inside organisational constraints.
If AI makes it easier to create code, it can also make it easier to create brittle systems at scale. The bottleneck shifts from creation to validation.
Put plainly: if generation becomes cheap and fast, validation becomes the scarce capability.
That is the economic heart of Vembu’s warning, and it is also why many sceptics reject the “engineering is dead” framing while still taking the disruption seriously.
This debate stays abstract until you watch what changes on a Monday morning.
The IT services lead
A client wants the same scope in less time and at a lower cost. The pitch now includes “AI-assisted delivery.” Internal expectations rise. One engineer is expected to ship what a small team shipped before. This does not necessarily mean there is no work. It means the price per unit of work falls, and the pressure per engineer rises.
Even if AI does not replace engineers outright, it can compress timelines and margins. That is how a headcount-driven model breaks without the work disappearing.
The SaaS engineering manager
AI scaffolds features fast. Prototypes look better. Demos get easier. But shipping still depends on correctness, reliability, security review, rollout safety, and long-term maintainability. AI can accelerate drafts. It cannot absorb blame when a release breaks production.
In many organisations, this pushes leaders toward more validation gates, stronger testing discipline, and tighter accountability for what gets shipped. It also raises the bar for engineers.
The job becomes less about producing code and more about owning what that code does in the real world.
These two realities explain why multiple sides of the debate can sound right at the same time.
Vembu is right that the generation is accelerating and changing the cost structure.
Sceptics are right that production responsibility is not solved by generation.
The phrase that triggered the biggest panic is also the least precise.
Read as “leave tech,” it becomes dramatic and, for most people, unrealistic.
Read more carefully, it can imply at least three different moves.
Alternative within tech: Shift toward roles closer to ownership: architecture, reliability, security, platform engineering, domain engineering, governance of AI systems.
Alternative sector: Apply technical ability to industries where constraints are physical and operational: healthcare delivery, infrastructure, climate resilience, agriculture, and local manufacturing.
Alternative philosophy: A prompt to rethink identity tied to white-collar coding in a world where production may become less dependent on human labour in certain domains.
Public discourse tends to default to the first interpretation because it is easiest to translate into career advice. The third interpretation is what makes the statement feel existential, and it is why the reaction was emotional for many readers.
Neither extreme is earned.
It is not defensible to claim that software engineering is finished based on a fast-moving set of examples and demonstrations. It is also not defensible to claim that nothing changes when the barrier to producing functional software has already fallen, and tools are improving rapidly enough to unsettle even sceptics.
A sober conclusion sits between these poles.
AI makes producing code cheaper. Responsibility remains expensive.
That leads to predictable effects:
This is why Vembu’s post matters even if one disagrees with his implied timing. It forces a hard question that many prefer to postpone.
If code becomes abundant, what remains scarce, and who gets paid for it?
The most defensible answer today remains human: judgment, accountability, and the ability to own outcomes.
If you are an engineer trying to turn the debate into a plan, the moves are straightforward.
Early-career engineers
Mid-career engineers
Leaders
None of these steps requires panic. They require clarity about where scarcity is moving.
The episode is not a final judgment on software careers. It is a public reckoning with assumptions.
Vembu’s post sits at the centre because it combines an insider’s credibility with a sentence that sounds like personal advice. Supporters argue the economics of headcount-driven software work will change even if engineering remains. Critics argue the statement overreaches and collapses engineering into code generation, ignoring responsibility and real-world delivery.
As of early 2026, the most defensible takeaway is not that software engineering is dead, nor that it is untouched. It is that the centre of gravity is shifting from generating code to owning outcomes.
Whether Vembu’s warning is premature or prescient may depend on where one sits in the hierarchy, which emerges as code becomes easier to produce, and responsibility remains hard to outsource.
(Raghu Ram Mahamkali is Founder and CEO, KarPing AI Solutions. Views are personal. Edited by Majnu Babu).
