WHYTHEFUTUREOFTECHISBUILTONTHINKING,NOTSYNTAX
Jensen Huang's purpose vs. task distinction explains why the real competitive advantage in AI isn't who writes more code: it's who solves the right problems.
Jensen Huang, CEO of NVIDIA - the most recognised figure in modern computing infrastructure - said something very uncomfortable recently:
“Nothing would give me more joy than if none of my software engineers are coding at all.”
Most people read that and panic. And this doesn’t come out of the blue. The narrative that software engineers will be put out of work by AI is everywhere right now. But why does the most recognised man in tech hold this radical standpoint?
Huang makes a distinction between purpose and task, he draws a line between what something is for and what it does to get there. The purpose of a software engineer is to solve defined problems and discover new ones worth solving. Coding (writing syntax, building functions, debugging logic) is a task. One of many. Not the goal itself.
This distinction matters because AI has become very good at the task. It can write code faster, catch errors earlier, and generate working prototypes from a description in plain language. What it cannot do is decide what to build, understand why it matters to a particular business, or recognise which problem is actually the one worth solving.
That gap is the entire game now.
The dominant story you’ve probably read about AI and engineers goes roughly like this: AI will write the code, so engineers will lose their jobs.
But this framing misses the point entirely. What is actually happening is a shift in where the value lives. For decades, being able to write code was itself a competitive advantage. It was a scarce skill that created a barrier between an idea and its execution. You needed technical people to translate business problems into working systems.
That barrier is getting lower - and fast.
When translation becomes cheap, what becomes valuable? The original thought. The judgment on which problem to solve. The understanding of a business's real constraints, not its stated ones. The ability to design a system that fits how people actually work, not how a software vendor assumes they do.
The engineers who will define the next decade are not those who write the most code. They are those who think most clearly about what needs to be built, why, and who can use AI to execute on that thinking at speed.
We know this firsthand. Our founders didn’t start sixtynine.digital as developers. They came from strategy, design, and business operations. For a long time, this could feel like a limitation. You had ideas, but you needed someone else to help you execute. There was a distance between thinking and building.
AI has collapsed that distance. It has removed the barriers and given people who deeply understand business problems, the ability to actually build solutions themselves.
Today we architect custom platforms, build AI-integrated systems, and find technical solutions for companies across industries. And here is what that experience has taught us: the value was never in the code. It was always in understanding the problem enough to know what to build. A company that comes to us and says "we need a webshop" is rarely describing what they actually need. The webshop solves fifteen percent of the problem. Understanding what the other eighty-five percent is: that’s the work. That is what AI cannot shortcut.
It looks like engineers who spend more of their time thinking and less of their time typing. It looks like people who deeply understand business problems being able to build solutions themselves, without needing to delegate to a technical team that has to translate the brief. It looks like the barrier between strategy and execution will shrink to near zero.
And it looks like the organisations that get this right (those that understand the shift from access to judgment) will pull significantly ahead of those that are still competing on who has the most capable tools.
Huang is not predicting a world with fewer engineers. He is describing a world where the definition of engineering has changed.
Where the hard part is not the syntax. It never really was.