Welcome to AI Reflections Weekly, where I share my honest thoughts about the developments in AI every week.

For those of you who don’t know me, I’m Dr. Nandini Seth - a founding faculty member at Masters’ Union, specializing in AI, data analytics, and statistics.

Getting back to today’s edition: a few weeks ago Dario Amodei told Davos that AI would take over all coding within a year.

I’ve got a lot of DMs since then. Including:

Everyone wants to know what's the right move.

And I keep thinking that this beyond just code, and has to do with how we learn anything at all.

When I was doing my PhD at IIM Bangalore, I spent three years on a problem that a language model could now summarise in two minutes.

That does not mean those three years were a waste of time.

I realised that they were about building the machinery in my head that could recognise an answer when I saw one.

And that machinery comes from getting lost in the rabbit holes, often being wrong, and sitting with confusion long enough to let the clarity hit.

This is what I think most people are getting wrong about AI and coding.

What I see in my classroom

I have students who can get Claude to build functional apps with a clean syntax in minutes, and I also have students who struggle for hours to write something half as elegant.

They have the intuition and have built the right mental models through all that struggling.


On the other hand, the students who prompt, get stuck in the prompting loop when something breaks.


They don't have the machinery to understand what went wrong.


Both groups feel productive, but only one group is really learning.

Meanwhile junior researchers saw minimal gains.

They couldn't tell good outputs from poor ones and lacked the foundation to judge what the AI was giving them.

And it leads me to another question: Where do the experts come from?

They come from struggle.

And from years of doing things the hard way.

From debugging code line by line, building systems that failed and figuring out why, and reading documentation that didn't make sense until it suddenly does.

That's how you build the machinery.

But now we're telling students they don't need to struggle by giving them tools that skip the hard parts.

And are celebrating how fast they can ship without asking what they're learning in the process.

Do you see the trap?

AI amplifies expertise but it also removes the process that creates expertise.

But there’s more to it:

The feedback loop that used to force learning, and the frustration that made you dig deeper, has been bypassed.

No one would want to struggle for hours when Claude can get you to that answer in seconds.

That's rational, but that's also how you never build the machinery.

More about the trap

Most people asking "should I learn to code" are asking the wrong question. 


Code is not a skill to acquire, like learning Excel or picking up Spanish.

And that’s not the point anyway.

The point is building the machinery in your head that lets you solve problems systematically.

It is about developing intuition about how systems work, and being able to look at something broken and understand why.

The devil’s advocate.

A lot of people don't really need that machinery.


If you have an audience, a distribution channel, or deep understanding of a customer problem, you can vibe code a solution and print money.


The barrier to building software has collapsed.

Y Combinator says 25% of their latest batch has codebases that are 95% AI-generated.

Now people are shipping products and making money with zero traditional coding skills.

If you already have the other pieces: Build. Ship. Make money.

I mean it.

But:

If everyone takes that path, who builds the next generation of AI? Who debugs the systems when they break in ways the AI can't fix?

And who sees the problems that don't exist yet?

If disruption could be vibe coded, it would already be disrupted.

The choice

First, understand what Amodei is really saying.

Anthropic engineers don't type code anymore but they still specify what to build, make the design decisions, review outputs, and take responsibility when things break.

Typing has become optional. Thinking is still mandatory.

Second, recognise that the scarce skill has now shifted into knowing when the output is wrong and why.

That requires understanding how systems work at the level of logic, architecture and tradeoffs.

Reply and tell me if you disagree. I want to know if I'm missing something.
Nandini

PS: there’s this one line that I keep thinking about this
To think through code, you had to type it.
It was the tax you paid to access the thinking.

Now, I don’t know…


Keep Reading