Here's a take that might be uncomfortable for developers to hear.
We assumed that when AI arrived, it would be us the technical people who would benefit the most. We already understood the tools. We could integrate them, extend them, build on top of them.
But looking at who's actually winning with AI right now, I'm not so sure that assumption holds.
What I've been noticing
The people I see getting the most leverage from AI aren't always developers.
They're marketers who now produce content at scale without a writing team. They're entrepreneurs who ship MVPs without hiring a dev. They're consultants who automate their entire workflow without writing a single line of code. They're salespeople who personalize outreach at a volume that used to require a full team.
These are people who, a few years ago, were blocked by the technical barrier. They had ideas, they understood their market, they knew how to sell but they couldn't build. AI didn't just help them. It removed the main obstacle that was holding them back.
The obstacle that disappeared
For a long time, technical skill was the bottleneck.
You had a business idea? You needed a developer. You wanted to automate something? You needed to code, or hire someone who could. You wanted to build a product? Months of learning, or a significant budget.
That bottleneck is collapsing.
Now, someone with zero technical background can prompt their way to a working prototype, a functional script, an automated workflow. Not perfectly but good enough to validate an idea, get a first client, or launch a product.
For technical people, AI is an accelerator. For non-technical people with business skills, AI is a key that just unlocked a door they've been standing in front of for years.
That's not the same thing.
Why business skills compound with AI better than technical skills alone
Here's what I think is happening underneath.
When a developer uses AI, we get faster at things we were already doing. We write code more quickly, debug more efficiently, explore new technologies with less friction. The ceiling goes up.
But when someone with strong business instincts uses AI, something different happens. They can now execute on ideas they already knew were good. They understand the market, they know the customer, they know how to position and sell and now they can build too.
They had the strategy. AI gave them the execution.
A developer with no business sense can now build twice as fast. But they're still building the wrong things twice as fast.
A non-technical person with sharp business instincts can now build and sell. That combination is incredibly powerful.
Does that mean developers are losing?
Not exactly and this is where it gets nuanced.
Developers who only have technical skills are in a more vulnerable position than they think. The value of "I can build this" is shrinking as AI makes building more accessible to everyone.
But developers who combine technical depth with business awareness who understand not just how to build but what to build and for whom those people have an extraordinary advantage right now.
They can move faster than a pure business person (who still needs AI to do the technical parts), and they understand the product at a deeper level than someone who's just prompting their way through it.
The winning profile isn't the best developer. It's the developer who learned to think like a business person.
What this means for me
As a developer, this observation changed something in how I think about my own growth.
Getting better at Vue or TypeScript or Python is still valuable. But it's no longer sufficient on its own.
Understanding how to position a product. Knowing how to reach an audience. Building in public. Writing about what I build. Understanding what problems are worth solving before writing a single line of code.
These are the skills I'm investing in now not instead of the technical ones, but alongside them.
Because in an era where AI can build, the people who win will be the ones who know what to build and how to make people care about it.
What do you think are you seeing this pattern too? Do you think developers need to develop business skills to stay relevant, or is technical depth still the main differentiator?
writing honestly about AI, learning, and building.*
Follow along on LinkedIn
Top comments (10)
The strongest point here is that AI lowers the cost of building, which shifts the scarce skill from “can you build it” to “do you know what’s worth building.” That’s a real change, but I’d add a caveat: removing the barrier to a prototype isn’t the same as removing the barrier to a product that survives contact with reality. A non-technical founder can now reach a working demo quickly, yet the hard parts tend to show up later: security, data handling, debugging something they didn’t write, and maintaining it as requirements change. Those are exactly the places where technical depth still matters, and where AI-generated code can fail quietly.
There’s also a survivorship effect in who we notice. The marketer who shipped an MVP is visible, while the many who stalled at the first unexplained bug are not. So the winning profile may be less “business person who can now build” and more “someone who can judge AI output well enough to know when it’s wrong,” which is a skill developers already have a head start on.
That supports your conclusion about combining both sides. Business sense decides what to build, and technical judgment decides whether what got built is sound.
To answer your question: I think business awareness is becoming a differentiator, but technical depth is turning into the thing that lets you trust what the AI produced rather than simply generate more of it.
The survivorship point is the one that actually changes my argument a bit.
You're right that we see the marketer who shipped the MVP. We don't see the many who stalled at the first unexplained error, quietly gave up, or shipped something with a security hole they didn't know was there.
And "judging AI output well enough to know when it's wrong" that's a sharper framing than what I had. It's not just about building faster. It's about knowing whether what got built is trustworthy. That's a skill that still requires real technical depth, and one that AI can't really give you.
So maybe the cleaner version of my argument is this: business sense decides what's worth building, and technical judgment decides whether what got built can actually survive. Both matter. But the second one is harder to fake.
The mechanism you are describing is the standard commoditization of a complementary input. When the cost of synthesizing routine code drops toward zero, economic surplus shifts to whatever input remains scarce. For the last twenty years, writing the software was the scarce complement, so developers captured the rent.
Assuming business operators capture that surplus permanently misses the next pricing equilibrium. When anyone can prompt an MVP or automate an outbound campaign in an afternoon, the barrier to entry collapses on both sides. A marketer who can spin up five niche SaaS tools without engineers is competing against ten thousand other marketers doing the exact same thing.
When software stops being a moat, the surplus flows straight to distribution channels, balance sheets capable of underwriting liability, and proprietary data pipelines. Business people who only bring generic strategy find their margins compressed just as quickly as junior syntax writers.
This reframes the whole argument in a way I hadn't considered.
You're right that I stopped one step too early. I described the first pricing shift surplus moving from technical execution to business strategy without following it to the next equilibrium. If anyone can spin up an MVP in an afternoon, generic business strategy gets commoditized just as fast as junior code.
The surplus flowing to distribution, proprietary data, and liability capacity makes sense. Those are the things that genuinely can't be replicated by prompting.
Which pushes the argument further than I took it: the winning profile isn't just "developer with business skills" it's whoever controls something that AI can't synthesize. Whether that's an audience, a data asset, or institutional trust.
That's a harder thing to build. But probably the more honest answer.
Denise's survivorship point and Dean's commoditisation point together describe something I see often from the build side. The prototype barrier fell, but the gap between a prototype and something a business can rely on barely moved: payments that reconcile, logins that do not leak, data that survives a bad deploy.
So I would frame the winning skill a little differently from thinking like a business person. It is the ability to define one problem precisely enough that someone can tell whether it is solved. Business people who can do that get a lot out of AI. Developers who can do that become the people those founders call when the prototype meets real customers.
In our client work the most valuable hour is usually the one spent writing the finish line down before anything is built, and that hour needs both kinds of judgement. Do you think that scoping skill can be learned from the developer side, or does it mostly come from having sold something?
"Define one problem precisely enough that someone can tell whether it is solved" is the clearest definition of scoping I've read.
And you're right that it sits upstream of everything else. Bad scoping means the prototype solves the wrong problem faster. Good scoping means both the developer and the client can agree on what done actually looks like.
On your question: I think the scoping skill can be learned from the developer side, but it usually requires deliberate exposure to the consequences of bad scope a project that shipped correctly but solved nothing, a client who moved the goalposts because the finish line was never written down.
Selling accelerates that learning because you feel the misalignment immediately, in lost revenue or a churned client. Developers can get there too, but it often takes more time and more failed projects to build the same instinct.
Which is maybe an argument for developers taking on more client-facing work earlier, even uncomfortably early not to become salespeople, but to feel what bad scope costs.
_YES, thats why we need to establish as many businesses as possible, to get out of working job and becoming new business owners _
There's real energy in that idea and AI does lower the barrier to starting something significantly.
But I'd add one nuance: starting a business is easier than ever, which also means more competition than ever. The advantage goes to whoever can identify a problem worth solving before building, not whoever builds fastest.
The direction is right. More builders, more owners, fewer people waiting for permission to create something.
I used to believe mastering technical tools would keep me competitive. This makes me think more about understanding user problems before jumping into implementation.
That shift in thinking is probably one of the most valuable things you can develop as a developer.