Who Builds Tomorrow?
As AI commoditizes coding, advantage shifts to the people who can embed technology into real organizations.
Software has driven the last three decades of our technological tree. Built on the strong hardware foundations of the 80s and 90s—Apple and others—the 2000s saw the rise of giants. Google revolutionized the way we access information, Facebook (now Meta) the way we connect to friends, Netflix the way we consume movies and series. Software changed everything: how we buy, how we work, how we learn, how we communicate. It made sense, therefore, that the creators of those systems—software engineers and developers—became highly rewarded and highly regarded.
But eras don’t end because demand disappears. They end because the bottleneck moves. GenAI might mark that shift for software. One question remains: what comes next?
The inflection point: Coding becomes optional
Early in 2024, Nvidia’s founder and CEO Jensen Huang made headlines by arguing, at a summit in Dubai, that programming should no longer be the primary skill children focus on learning.
“It is our job to create computing technology such that nobody has to program. And that the programming language is human. […] Everybody in the world is now a programmer. This is the miracle of artificial intelligence.” explained Jensen.
Critics pushed back. Some argued AI would not reach human coding level—or at least not “organizational” coding level. Others suggested AI would simply enable more people to code.
We are now two years later. A short amount of time, but enough for Cursor, Codex, Claude Code and others to rise. And despite the criticism, it increasingly looks like AI is good enough at coding to change incentives: not perfect, not magical, but capable of producing senior-level output in many contexts. The same is becoming true at the codebase level: not “solved” in every company, but increasingly viable in real organizations.
So the most interesting remaining question is not whether AI can code. It’s whether it empowered more people to code, or whether it changed the paradigm of building software.
A useful way to think about that is with an analogy: painting.
Painting has long been an art of the brush. You study it, practice it, correct it—then eventually your idea takes shape on a canvas. Then, in the 60s, came interactive drawing software. Anyone with a computer could now “paint” 1. Did this tool kill painting? Not fully. But it did change its economics—and, in many segments, its purpose.
Cartoons were once hand-drawn; now most are made through software. Background illustrations for movie sets, ads, and corporate visuals used to provide a living for skilled drawers and painters. Few people could do it well because it required years of training, and clients understood how long it took because it was a task of the physical world. Digital tools collapsed iteration time. Clients started expecting faster delivery with more edits. The work became more accessible, supply increased, competition intensified, and prices fell. Painting did not disappear—yet the “center of gravity” shifted. Today, its biggest economic use is arguably fine art, where taste, identity, and originality matter more than speed.
Interactive drawing software didn’t kill painting. It shifted the utility of the job: where the jobs are, what customers expect, and which skills get rewarded.
My belief is that the software world will undergo similar shifts in the coming years—maybe decades.
AI-powered tools have made access to software creation much easier. But it didn’t make more people software engineers. It gave more people the ability to produce software-like outcomes without having to learn to code—or even to interact with code. The same way you don’t need to know how to paint with a real brush to produce compelling visuals with modern tools, you increasingly don’t need to know how to code to build an app with platforms like Replit.
This nuance matters. It’s not “AI enables everyone to code.” It’s “AI makes coding optional for many outcomes.”
As with painting, this doesn’t mean the world will require no developers. It means expectations will change. Something that once required a team of ten trained workers over ten months can, in some cases, be prototyped by one person in a day. Developers will still be required—but the number of roles, the nature of the work, and the premium skills will likely shift.
The bottleneck: Adoption
To understand what might come next, it helps to name the main constraint facing AI’s expansion right now: technology adoption.
Model providers—Anthropic, OpenAI, and others—have shown that capability will continue to improve. It might not feel like it, because our brains compress timelines, but remember: four years ago most people had never heard of GPT. Two years ago it was “fun text that gives quick answers.” Today it can generate graduate-level analysis and turn it into a podcast or a website in minutes—work that used to take hours of engineering time.
Yet despite these capabilities—and despite the investment and attention—we still haven’t seen changes to society at the scale that the hype would suggest. If you are a white-collar worker, your personal workflow may have changed a lot. But did your company truly change? Was its business model redesigned? Did it triple revenue because of AI? In most cases, no.
The world is advancing at dual speed: models are getting faster, better, more extraordinary—while many industries are lagging behind.
A plausible reason is adoption. We see an increasing number of pilots, MVPs, and tests, but fewer systems that stick, scale, and reshape core workflows. Adoption is complex, and there are many reasons: corporate structure, the explore–exploit dilemma2, employee training, data readiness, risk and compliance, incentives. Fixing this will likely take years because organizations themselves need to change.
But adoption doesn’t fail only because companies are slow. It also fails because the gap between the people building the technology and the people operating complex industries is wide—and widening.
Incumbent industries are complex. Their processes and operations evolved over decades (sometimes centuries), making it nearly impossible for an outsider to grasp their real functioning quickly. You can learn the basics of metallurgy from a documentary, but you’ll still be extremely far from understanding how a company like ArcelorMittal actually runs day-to-day: its constraints, internal politics, regulatory boundaries, unions, supply contracts, safety culture, asset cycles, and the thousand “small” exceptions that are, in practice, the business.
Yet for AI to transform how such a firm operates, the people implementing AI must build that understanding first.
Most tech employees have scarce knowledge of how other industries work. Many studied STEM, then joined startups or big tech. They may be excellent engineers and still be unprepared for the operational reality of a complex incumbent.
Vice versa, many people in incumbents lack a practical understanding of modern AI systems. They don’t know what LLMs are good at, where they fail quietly, how to evaluate reliability, or what it means to deploy these tools inside regulated or safety-critical workflows.3
This dual knowledge gap is not new. The software world already struggled with it. But as technology becomes more powerful—and therefore more consequential—this gap becomes a harder blocker. It is now a central constraint on adoption.
The gap is complex, but it isn’t immutable.
The rise of the bridge-builders
This gap helped create entire industries: digital transformation consulting (Accenture, IBM, and others). It also created roles inside tech itself: solution architects—often senior technical professionals who design, develop, and implement technical solutions to solve business problems. In a nutshell: people bridging business needs and technical execution to enable adoption.
Until now, in the software-led economy, large tech companies often ran at something like one solution architect for ten software engineers. My bet is that ratio will change.
As code production becomes cheaper and more automated, fewer people will be required to produce the same volume of software. Meanwhile the adoption gap between tech “producers” (Google, OpenAI, Anthropic…) and tech “receivers” (incumbent industries) remains—and in some ways grows—because what matters shifts from “can we build it?” to “can we embed it safely, reliably, and profitably into how work actually happens?”
This creates demand for a broader family of bridge-builders: not just “solution architects” as a title, but people who combine domain knowledge, technical fluency, and organizational change ability. Call them architects if you want. The label matters less than the function.
To illustrate the shift: a company integrating AI into supply chain management may no longer need ten engineers to build everything from scratch. Tools will handle a growing share of generation, refactoring, and integration scaffolding. What the company will desperately need is someone who understands both (1) the real operational constraints of supply chains and (2) the practical capabilities and failure modes of AI systems—well enough to decide where automation creates value, where human judgment must remain, how exceptions get handled, how risk is governed, and how the transition is orchestrated without breaking the business.
That is the architect’s domain.
We’re already seeing early signals: “AI transformation” roles, product teams tilting from building to integration, and growing demand for people who can translate capabilities into operating reality.
Over time, the scarce resource won’t be code. It will be trustworthy change: deciding what to automate, proving it works under real-world exceptions, governing risk, and moving a human organization through the transition without breaking it.
In the software era, leverage came from writing code. In the AI era, leverage comes from shipping new behavior.
The new premium skill isn’t programming. It’s integration.
Or did they? Is creating art with Adobe’s tools “painting”? Or is it another form of art—just as impressive, but different? I would argue this: painting software didn’t make painting more accessible; it created a whole new form of art.
The exploration–exploitation dilemma is a fundamental concept in decision-making. It describes the balancing act between two opposing strategies. Exploitation involves choosing the best option based on current knowledge (which may be incomplete or misleading), while exploration involves trying new options that may lead to better long-term outcomes at the expense of short-term efficiency. Finding the right balance is a crucial challenge for any system trying to maximize long-term benefits.
Note: this isn’t universal. Some people in tech have deep domain exposure; some people in incumbents have serious technical skill. They just aren’t the majority.