Something has been nagging at me for months, and I don't think it's fully landed in the industry conversation yet: AI-assisted development is not making everyone better at the same rate. We talk about it like it's a rising tide — a productivity multiplier that lifts every engineer roughly the same amount. That's not what I'm seeing. Some people are pulling dramatically ahead of their peers with the exact same tools, the exact same models, the exact same access. And the more I've sat with why, the more I think it comes down to one uncomfortable trait: whether you're willing to work outside the domain you're actually good at.
// The Tell From Math
You can see an early version of this happening outside of software entirely. AI is starting to shake up mathematics, not because it's independently discovering new theorems out of thin air, but because it's able to reach into a totally different field — physics, say, or computer science — and drag a concept sideways into a math problem that had never been approached that way before. The interesting part isn't that it knows math. It's that it doesn't respect the walls between disciplines the way a human specialist, trained for a decade inside one of them, naturally does.
I don't think that's a math-specific phenomenon. I think it's a preview of what AI does to expertise everywhere, software included. It's not evenly applied yet — a model isn't master's-level in every field simultaneously — but the direction is obvious, and it's worth planning around now rather than after it's finished arriving.
// Borrowed Expertise
Picture someone with a master's in construction engineering. Sharp in their field, but their math and physics are solid-generalist level, not research level. Historically, that gap was just a permanent ceiling on the ambition of what they could design. AI changes that math, literally. It can take physics and higher-level math reasoning that lives inside the model and map it onto whatever that engineer is planning or iterating on, extending their reach past the formal edge of their own training. They're still the construction engineer. They just stopped being limited by the parts of adjacent fields they never got around to mastering.
That's the mechanism. Now map it onto us.
// The Myth of "Just a Coder"
People outside the industry tend to assume that if you can code, you can code anything. Anyone who's actually done this work knows that's not true. Web development, real-time systems, mobile, edge computing, ML infrastructure — these aren't flavors of the same skill. They're different disciplines wearing the same job title, each with its own constraints and its own instincts for what actually matters.
Put a real-time systems engineer who's written embedded C for twenty years next to a web developer who's spent their career two abstraction layers above the hardware, and ask them both to think about data structures. You will get two genuinely different mental models, not a shallower and a deeper version of the same one. The embedded engineer is thinking about cache lines and allocation cost because a bad choice there is the difference between hitting a deadline and missing it. The web developer has almost never had to think that way, because the runtime has been absorbing that cost on their behalf for their entire career. Neither is wrong. They're just fluent in different constraints.
What AI does is take instincts like that — baked into the model from having seen an enormous amount of both kinds of code — and make them available to whichever engineer is asking, regardless of which discipline they actually came up in. This isn't a new observation. People have been saying "AI lets you work outside your specialty" since the early copilot era. What's new is how unevenly that capability is actually landing on real engineers, and I think I finally understand why.
// Who's Actually Winning
It's not the deepest specialists. It's the people who already had some breadth going in, even a little.
Take a backend engineer who's spent their career on API design and has only ever dabbled in frontend or mobile work — enough to be dangerous, not enough to call themselves competent, but enough that they actually enjoy poking at it. That person is positioned to get vastly more out of AI-assisted development than an equally skilled backend engineer who has never once looked sideways. Not because the tool behaves differently for them. Because they have just enough vocabulary in the adjacent domain to know what a good answer looks like, what question to ask next, and when the model is quietly wrong. The AI is providing the horsepower. Their dabbling is providing the steering.
The purely siloed expert, by contrast, often can't tell when they've left the terrain they actually understand. The model will happily hand them fluent, confident, plausible-looking code in a domain they have no instincts for, and they have no internal alarm to catch the parts that are subtly wrong — wrong in the way that only reveals itself in production. Depth without any adjacent breadth turns out to be a liability in exactly the situation where AI is most useful: operating past the edge of what you already know cold.
The unfair part is that this rewards a trait a lot of people already had before AI showed up — curiosity that wanders past the edge of the job description just because it was interesting. AI didn't invent that advantage. It just started paying it out at a much higher rate.
// Getting Uncomfortable On Purpose
Which is the part worth actually acting on. If leaning into adjacent domains is what's separating the engineers pulling ahead from the ones standing still, then breadth stops being a personality trait you either have or don't, and starts being a skill you can deliberately go cultivate. That means picking the domain you've been avoiding — the frontend you never learned properly, the mobile platform you've always outsourced, the embedded work that always seemed like someone else's problem — and getting uncomfortable in it on purpose, with AI as the thing that makes the on-ramp survivable.
You don't need to become a second specialist. You need enough fluency to steer, to catch the model when it's confidently wrong, to ask the next good question. That's a much lower bar than mastery, and it's exactly the bar the backend engineer with the frontend hobby had already cleared before any of this started.
// What This Doesn't Mean
I don't think deep specialists are going away, and I'm suspicious of anyone confidently predicting exactly how this settles. There's real reason to think dedicated experts — the people who go absurdly deep on one thing — stick around for a long time, maybe indefinitely, in the domains where the cost of being subtly wrong is high enough that you want someone who actually has the internal alarm, not just AI's borrowed version of one. But I do think a meaningful slice of what used to require that depth is going to get commoditized, and I don't think anyone, myself included, knows exactly where that line settles yet.
What I'm confident of is smaller than that: in the meantime, the jack-of-all-trades has a real, measurable edge over the specialist who never looked up from their lane — and that edge is wider than most people building career plans right now seem to think it is.