What 3Blue1Brown’s case for math teaches software engineers in the age of AI

Posted on Oct 25 • Originally published at dineshkumars.dev

AI will not make software engineers obsolete, but it will move the value of our work away from writing code and toward judgment, trust and people. I got there by watching a math video.

Grant Sanderson of 3Blue1Brown recently published There’s never been a better time to go into math. He opens with the anxiety many math students feel about AI, including a PhD student who simply asked him what to do tomorrow. His answer is a careful, hopeful argument that the institution and joy of math survive even if machines get better at proofs.

I’m a software engineer with 16 years of experience, building AI systems at Trimble in Chennai. Watching it, I kept translating every frame into my own field. This post is that translation.

Before talking about AI, Grant lays out the institution of math in three columns.

The quiet surprise is in the last column. Most of the money that sustains mathematicians comes from teaching, not from the theorems themselves. That mismatch is what makes his later scenarios work.

Nobody pays for code. Customers pay for outcomes, for reliability, and for someone accountable when things break. Code is to engineering what proofs are to math: the raw material, not the thing being bought.

The first column is where AI is moving fastest. The last column barely changes: the money still follows outcomes.

I’d add one row to the value column that math doesn’t need: reliability and trust. Software runs payrolls, construction sites and fleets. Being correct and secure at scale is much of what customers actually pay for.

Grant walks through three escalating thought experiments. Each one maps cleanly onto our field.

At every step the human part gets smaller in volume but larger in consequence.

Scenario 1: AI writes the code. This is already happening. In Grant’s version, proofs become raw data and the job shifts to weaving them into theory. For us, lines of code stop being scarce. The work moves to framing problems precisely, designing the system, and verifying that generated code is correct. Some engineers will grieve the loss of the craft. Others will feel freed from getting stuck on implementation.

Scenario 2: AI also designs the systems. Humans remain the bridge to the real world. Someone must understand the customer’s domain, decide trade-offs between cost, risk and compliance, and own the consequences. Grant’s gym analogy holds too. A machine lifting heavier weights is no reason to stop training. Building systems by hand keeps the instincts we need to judge machine output.

Scenario 3: AI does everything end to end. Grant argues teaching stays one of the safest jobs, because learning is relational. Our equivalent is accountability and trust. Customers, auditors and regulators want a human who stands behind the system. Mentoring engineers, aligning stakeholders and signing off on what ships are the hardest parts to automate.

My situation has a twist. I’m not only an engineer whose work AI is changing; I help build the kind of AI that drives that change. I see the shift as the person being disrupted and as the person building the disruptor.

That turns out to be a useful vantage point. Building with AI makes it obvious where they are strong and where they still need a human: understanding the domain, defining what “correct” means, and earning the trust of the people who depend on the result.

Grant’s literal answer to the PhD student was to take a long walk with a friend or colleague. I think engineers should take that advice literally too.

On that walk, talk through two questions. What do you most enjoy about the work you do? What do you want to be known for three years from now? Then write one paragraph answering the second question.

That paragraph will tell you whether to lean toward architecture, toward the domain and customers, toward trust and governance, or toward growing people. All four are durable. The best one is the one you’d pursue with the most energy.

There really has never been a better time to be an engineer who understands what the machines are building.