No, Coders Don’t Need “Alternative Livelihoods.” They Need an Alternative Understanding of What Coding Is.
Sridhar Vembu — a founder I deeply respect — posted something this week that stopped me mid-scroll.
“At this point, it is best for those of us who depend on writing code for a living to start considering alternative livelihoods.”
He said it with calm acceptance. No panic. Just a quiet surrender to what he sees as inevitable.
And I think he’s wrong. Not about the direction AI is heading — he’s absolutely right about that. But about what it means for the people who build software.
The Pattern We Keep Forgetting
I’ve been in this industry long enough to have lived through multiple “coding is dead” cycles.
In the early 2000s, it was outsourcing. American developers were told their jobs were shipping to Bangalore, and they should start learning “business skills” instead. What actually happened? The global demand for software exploded. There was more work than ever.
In 2012, it was no-code platforms. Drag-and-drop tools were going to eliminate the need for developers. WordPress, Wix, Squarespace, and hundreds of “app builders” — anyone could build anything now. What happened? The companies behind those tools hired more engineers, not fewer. And the complexity of what businesses needed from software only grew.
The pattern is remarkably consistent: every time the barrier to producing code drops, the demand for people who understand what to build, why to build it, and how to make it work at scale goes up.
What Sridhar Gets Right
Let me be fair to his argument, because the underlying observation is correct.
Anthropic did build a C compiler with Claude. That is an extraordinary engineering achievement. The raw capability of AI to produce working code — sometimes complex, sometimes elegant — is no longer in question. I use it every day at Hyperleap AI. My team uses it. It’s real.
And yes, if your entire job is translating a well-defined specification into syntactically correct code — what I’d call “spec-to-syntax” work — then you should be concerned. Not because AI will replace you tomorrow, but because the value of that specific skill is being rapidly commoditized.
But here’s the uncomfortable truth: that job was already on borrowed time.
The “spec-to-syntax” developer was always the most vulnerable role in software. Before AI, they were vulnerable to better frameworks, to low-code tools, to offshore teams. AI just accelerated an existing trend.
The Confusion Between Writing Code and Engineering Software
This is where I think the conversation goes sideways.
There’s a fundamental difference between writing code and engineering software. They look similar from the outside. They happen in the same editor, use the same languages, produce the same file types. But they’re entirely different activities.
Writing code is the act of translating a known solution into a programming language. It’s implementation. It’s the mechanical part.
Engineering software is the messy, human, deeply contextual work of figuring out what problem you’re actually solving, what trade-offs are acceptable, how the system interacts with other systems and with real humans, what happens when things fail, and how to evolve the solution over time.
AI is getting remarkably good at the first part. It can write functions, build components, even architect small systems. But it’s essentially operating in a world where the problem has been fully defined — where the ambiguity has already been removed by a human.
The second part? That’s where the real engineering lives. And it’s not getting automated anytime soon.
Here’s why:
1. The Problem Definition Problem
The hardest part of building software has never been writing the code. It’s been figuring out what to build.
After 11 years at Microsoft, building systems for Office 365 and Outlook.com that served billions of users, I can tell you — the code was the easy part. The hard part was sitting in rooms with product managers, designers, business stakeholders, and customers, trying to reconcile contradictory requirements, budget constraints, performance targets, and organizational politics into a coherent technical direction.
No AI model does this. Not because it can’t write code, but because the inputs are ambiguous, political, emotional, and constantly shifting.
2. The Systems Thinking Gap
A C compiler is a well-defined, bounded problem with a formal specification. Most real-world software is nothing like this.
Real software lives in an ecosystem. It talks to databases that have quirky legacy schemas. It integrates with third-party APIs that change without warning. It serves users who do things you never anticipated. It runs on infrastructure that has hard limits you discover in production at 2 AM.
Understanding this ecosystem — and making sound technical decisions within it — requires the kind of contextual judgment that AI fundamentally lacks. AI can generate code that works in isolation. Engineers build systems that work in context.
3. The Failure Mode Problem
When AI generates a C compiler and it works, that’s impressive. But what happens when it doesn’t work? Who debugs it? Who understands why it failed? Who decides whether the failure mode is acceptable or catastrophic?
This is the part nobody talks about in the “AI replaces coders” narrative. Production software fails constantly — in subtle, context-dependent, non-obvious ways. Diagnosing and resolving these failures requires the kind of deep understanding that comes from having built the system, from understanding the design decisions, the trade-offs, the reasons behind specific architectural choices.
You can’t outsource debugging to something that doesn’t understand intent.
What Actually Changes (And It’s Significant)
None of this means the software industry stays the same. It doesn’t.
Here’s what I think actually happens over the next 3-5 years:
The productivity explosion is real. Engineers who embrace AI tools will be dramatically more productive. At Hyperleap, we’re already seeing this. Tasks that took days take hours. Prototypes that took weeks take days. This is not hype — it’s our lived experience.
The floor rises. The minimum viable competence for a software engineer goes up. You can no longer coast on being a decent coder with good Stack Overflow skills. The baseline expectation is now: you use AI tools fluently, you move faster, you ship more.
Small teams dominate. This is perhaps the most consequential shift. A team of 5 exceptional engineers with AI tools will outperform a team of 50 average ones. This doesn’t mean fewer engineers in absolute terms — it means the organizational structure of software companies changes dramatically.
New roles emerge. “AI-assisted development” is not a buzzword. It’s an entirely new way of working that requires new skills: prompt engineering, AI output evaluation, system-level thinking about where to use AI and where not to, and the ability to debug AI-generated code that you didn’t write yourself.
The demand curve shifts, but doesn’t disappear. There will be fewer opportunities for pure implementation roles and more opportunities for people who can think at the system level, who understand business context, and who can orchestrate AI tools alongside human judgment.
The Real Risk Isn’t AI. It’s Mindset.
Here’s what actually worries me: not that AI will replace engineers, but that talented engineers will hear advice like “consider alternative livelihoods” and actually leave the field.
That would be a tragedy.
The world needs more people who understand how software systems work, not fewer. We need people who can think critically about AI-generated code, who can architect systems that are reliable and safe, who can bridge the gap between what technology can do and what humans actually need.
If you’re an engineer reading this, here’s my honest assessment:
Don’t panic. Don’t leave. But don’t stay still either.
The engineers who thrive in the next decade will be the ones who stop defining themselves as “people who write code” and start defining themselves as people who solve complex problems using software — with AI as the most powerful tool in their toolkit.
That’s not an alternative livelihood. That’s the same livelihood, upgraded.
The Bhagavad Gita Connection
There’s an irony in Sridhar’s post that I want to highlight. He quote-posts a Bhagavad Gita app.
The Gita’s entire message is about performing your duty (dharma) with skill and detachment from the outcome. Chapter 2, Verse 47: “You have the right to perform your duty, but you are not entitled to the fruits of your actions.”
The Gita doesn’t tell Arjuna to find an alternative livelihood. It tells him to master his craft with full commitment, adapting to the reality of his situation.
For engineers, the dharma hasn’t changed. The tools have. The context has. The expectations have. But the core work — understanding problems deeply, building solutions thoughtfully, creating systems that serve people — that remains deeply human work.
The bottom line: AI doesn’t eliminate the engineer. It eliminates the distance between thinking and building. That’s not a threat to the profession — it’s the most exciting evolution our field has seen in decades. The engineers who recognize this will build things that weren’t possible two years ago. The ones who hear “consider alternative livelihoods” and walk away will miss the greatest period of leverage in the history of software.
Don’t look for alternative livelihoods. Build an alternative understanding of what engineering actually is.
What’s your take? Are we witnessing the end of software engineering, or its most important evolution? I’d love to hear from builders who are living this transition.
I’m Gopi Krishna, founder of Hyperleap AI, where we’re building enterprise generative AI infrastructure. Previously at Microsoft for 11+ years, where I built systems for Office 365 and Outlook.com serving billions of users. I write about the second-order effects of AI on Substack.