Quick Answer: Is coding worth learning now? Yes, but the skill that matters has shifted. Zeta CEO Bhavin Turakhia, who started coding at 10, argues that AI is automating routine software development. That makes problem-solving, critical thinking, and the ability to define goals more valuable than typing code. Coding remains the tool for building software, but it is no longer the main source of an engineer's value.
When a CEO who started writing code at 10 says coding is overrated, most developers feel a jolt. Bhavin Turakhia, who leads the banking software company Zeta, made that argument recently, as Moneycontrol reported. His point isn't that programming is useless. It's that AI tools are absorbing the mechanical part of software work. If you're asking whether coding is worth learning, that's the right question to be asking.
What Turakhia Actually Said
The core of his argument is simple. AI is automating large parts of software development, so the skills that differentiate engineers are moving up the stack. He points to three: problem-solving, critical thinking, and the ability to define goals clearly.
Notice what he doesn't say. He doesn't tell people to stop learning to program. He says the act of writing syntax is becoming less scarce, which is a different claim. Starting at 10 gave him decades of hands-on fluency. That's why his view deserves a serious hearing. He knows what the work involves before he argues it's being automated.
So what does that shift look like on a real team? Why would a CEO who loves code call it overrated?
Why AI Is Absorbing the Mechanical Layer
AI coding assistants now handle a large share of routine output. Tools such as GitHub Copilot, Cursor, and Claude Code autocomplete functions, scaffold boilerplate, draft unit tests, and translate code between languages. The effect is real, and the best-known measurement comes from a 2022 controlled experiment that GitHub ran. Developers using Copilot completed a defined programming task about 55% faster than the control group.
Here's the caveat most headlines skip. That was a narrow, well-specified task, not a month-long project in an unfamiliar codebase. The speedup is strongest where you already understand the problem. When you're working in code you don't know, AI suggestions can look plausible while hiding subtle bugs, and you may spend more time verifying them than you saved.
- AI handles well: boilerplate, test scaffolding, syntax lookups, refactors with clear rules, and well-known patterns.
- AI handles poorly: ambiguous requirements, cross-system edge cases, performance trade-offs, and anything that depends on context outside the repository.
That split is the whole story. The mechanical layer is getting cheaper, and the judgment layer is getting more expensive.
Most people stop at "AI writes code now." That misses the more important shift, and it's where the real career implications sit.
Why Defining the Goal Is Becoming the Bottleneck
When generating code is cheap, the costly mistake is building the wrong thing quickly. This is the cause-and-effect chain that matters. Fast code generation increases output volume. Higher output volume makes requirement errors more expensive, because you ship more of the wrong thing before anyone notices.
Consider a composite example. A fintech team asks an AI assistant to build a payment reconciliation feature. The generated code passes every test the team wrote. In production, it misses a settlement cutoff because nobody specified how the system should handle transactions that settle after midnight. The code was correct. The goal was incomplete.
This is why goal definition is now a core engineering skill. Writing a clear spec, defining acceptance criteria, and naming the failure cases before you prompt is the work that prevents that outcome. It's also the part of the job that is hardest to automate, because it requires understanding the business, the users, and the constraints nobody wrote down.
Here's a practical test. Before your next feature, write a one-page spec with explicit edge cases and failure conditions. Then compare how many decisions you had to make that the AI couldn't make for you. The number is usually higher than engineers expect.
The Skills That Compound
If the mechanical layer is shrinking in value, which skills grow? The table below maps the main ones to why AI struggles with them and how you can build them deliberately.
| Skill | Why AI Struggles | How to Build It |
|---|---|---|
| Problem decomposition | Requires knowing which parts of a system interact and which can fail independently | Break one existing feature into components and write dependency diagrams |
| Critical code review | AI output looks confident even when logic is wrong | Review AI-generated pull requests line by line and log every bug you catch |
| Goal and spec definition | Needs business context and unstated user expectations | Write acceptance criteria before any code, then check them against the result |
| System design and trade-offs | Depends on scale, cost, and team constraints outside the codebase | Study architecture decisions in public engineering blogs and write your own alternatives |
| Production debugging | Requires reading logs, metrics, and behavior under real load | Reproduce a live incident from postmortem notes and trace the root cause |
Notice that every row depends on understanding, not output speed. Typing is the part that's getting cheaper.
Where the Argument Is Incomplete
Here's where it gets interesting. The popular reading of Turakhia's view is "stop learning to code." That reading is wrong, and it's dangerous for newer engineers.
The reason is verification. You can only judge whether AI output is correct if you understand the code well enough to spot a wrong assumption. Engineers who skip fundamentals end up trusting outputs they can't evaluate. The skill of defining goals depends on knowing what the system can and can't do, and that knowledge comes from having built things.
There's a harder problem too, and it's one the CEO framing doesn't fully address. Junior engineers have traditionally learned by doing routine work: bug fixes, small features, test writing. AI is absorbing much of that routine work. If companies hire fewer juniors, the apprenticeship path thins out, and the next generation of senior engineers has fewer chances to build judgment. I don't have hard data on how far this has gone, and anyone who claims a precise figure is guessing. But it's a risk worth taking seriously, especially if you're early in your career.
So the honest position is this: coding is less scarce, judgment is more valuable, and judgment is built through coding. Those three claims fit together only if you keep doing the hands-on work.
A 90-Day Plan for Engineers Who Want to Stay Ahead
Abstract advice is easy to nod along to and forget. Here's a concrete sequence, with the reason behind each step.
- Build one small system end to end, and write the spec first. Starting with the spec forces you to make decisions the AI can't make for you. The reason it matters: it turns goal definition from an abstract skill into a habit.
- Review every AI-generated change for one full week. Log each bug you catch and the reason it slipped through. The reason: this trains your critical review instinct on real failure patterns, not hypotheticals.
- Read production code in a mature open-source project. Pick something you use daily, such as a database driver or web framework. The reason: exposure to real trade-offs builds the system-design judgment that AI tools don't provide.
- Take one incident and reconstruct it. Use a public postmortem and trace the root cause using only the information the team had. The reason: debugging under uncertainty is the skill that shows up in senior interviews and on-call rotations.
- Teach one concept to someone else. Explaining a design decision exposes gaps in your reasoning faster than solo study does.
Most people stop after step one. The compounding comes from the reviews and the reconstructions.
Frequently Asked Questions
What is software engineering if AI can write code?
Software engineering is the discipline of defining problems, designing systems, making trade-offs, and maintaining software over time. Writing code is one activity within that work. AI tools accelerate the writing part, but they don't remove the responsibility for correctness, requirements, or long-term maintenance. Engineers who focus on those responsibilities remain central to the work.
How do I future-proof my software engineering career with AI tools?
Focus on the skills AI handles poorly: problem decomposition, spec writing, critical code review, and production debugging. Use AI tools daily, but review their output closely, and keep building systems yourself. The practical goal is to become the person who knows what to build and can verify whether it works.
Why is coding overrated according to some tech leaders?
Leaders who make this argument usually mean that syntax-level coding is becoming cheaper, not that programming has no value. Bhavin Turakhia, CEO of Zeta, made this point as AI automates routine development. The claim is most accurate for mechanical tasks and least accurate for engineers who need to verify and direct AI output.
Is coding worth learning if I'm just starting out?
Yes, but learn it as a means to understanding systems, not as an end in itself. Early-career engineers need hands-on experience to judge AI output and build design intuition. Pair that practice with deliberate work on spec writing and code review, because those skills will carry more weight over time.
Is coding worth learning in the AI era? The answer is yes, as long as you treat it as the route to judgment rather than the destination. Try writing a one-page spec with explicit edge cases before you open an AI assistant on your next feature, then note how many decisions you had to make yourself. Pass this to a junior developer who is wondering whether to keep going.