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

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.

Grant’s map of how math works

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

What mathematicians do: prove theorems, ask questions, build theories, and apply them.
Why math is valuable: applications today and in the future, problem-solving muscles, and aesthetic joy.
Where the funding comes from: teaching, public funding, private foundations, and industry.

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.

The same map for software engineering

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.

Three scenarios, replayed for engineers

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.

Seeing it from both sides

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.

Seven things I’m doing about it

Measure myself by the proof standard, not by code. If code becomes raw data, the scarce skill is deciding what counts as correct. For AI systems, that means trust and safety: knowing, and being able to show, that the system behaves as it should. Whoever sets that bar holds the engineer’s version of mathematical rigor.
Be a theory builder. The theory of any system is its conceptual model: the core abstractions, the boundaries between them, and the rules that govern them. AI can generate services; it cannot yet pick the right abstractions for a business. I want to write these models down, in papers, design principles and a clear platform narrative.
Own the bridge to the domain. Trimble’s customers are surveyors, contractors and fleet operators. General-purpose AI is weak in those workflows. Years of experience plus domain data is a real advantage, so I’m pushing to understand a few customer workflows deeply.
Treat trust as the product. Teaching funds math; trust funds AI adoption. Enterprises pay for AI they can rely on. Safety, governance and responsible-AI practices aren’t overhead. They are evidence that someone accountable stands behind the system.
Invest in people. Grant’s safest job is the teacher. At a senior level, that means making it easy for newcomers to contribute and mentoring engineers through the shift from writing code to directing and verifying it.
Get excellent at speaking. This was Grant’s most practical advice. When anyone can generate a design document, explaining a system live and handling hard questions is what proves understanding. Every architecture review and leadership update is practice.
Keep going to the gym. I still build things by hand, and I’m studying the mathematical foundations of generative AI. Not to compete with the machine, but to notice when it is confidently wrong.

What to do tomorrow

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.

Reference

Grant Sanderson (3Blue1Brown), There’s never been a better time to go into math, YouTube.