AI equalized the part of the job that was never the hard part — writing the code. The hard part was always knowing what to ask. That part it can't hand you, and worse, it hides the fact that you don't have it.

I'm a frontend person. Have been for years. And a few times now I've sat down, asked a model to write a piece of backend I needed, and watched it produce something that looked completely reasonable. Clean structure. Sensible names. It ran.
For a moment it felt like the line between disciplines had just dissolved. I didn't need to go find the person who actually does this. I had the code. It worked.
That feeling is the most honest thing I can tell you about AI right now — and it's also the trap. Because "it ran" and "I understood it" are not the same sentence, and the gap between them is exactly the part of the job AI didn't touch.
Let's be fair to the tools, because they earned it. The mechanical act of producing code in a domain you don't live in used to be a real wall. You'd spend a day fighting unfamiliar syntax, unfamiliar libraries, unfamiliar boilerplate, before you got anywhere near the actual problem. That wall is mostly gone. I can generate plausible code in domains I've never worked in, and so can you.
So if the job were writing the code, then yes — AI would have flattened the difference between a frontend engineer, a backend engineer, a data engineer, someone in infra. We'd all be roughly interchangeable now, each of us holding the same generate button.
But writing the code was never the hard part. It was the visible part. We confused the two for a long time because the visible part was also the slow part, and slowness feels like difficulty. AI removed the slowness and revealed what was underneath: the hard part was always knowing what to ask.
When a backend engineer writes the same code I just generated, they're not mainly typing. They're running a silent checklist I don't even have. Is this transaction boundary right? What happens to this under concurrent writes? Is this idempotent if it gets retried? What does this query do when the table is a thousand times bigger? What's the failure mode nobody put in the happy path?
I don't ask those questions. Not because I'm careless — because I don't know they're the questions. That's the actual content of a domain: not the syntax, but the set of things you've learned to worry about, mostly by being burned. AI gives me the syntax for free. It does not give me the scars.
And here's the move that matters: prompting outside your domain is not "I know a bit less here, I'll be slower." It's "I don't know what I don't know, so I can't even tell when the answer is wrong." Those are completely different situations. The first one you can manage. The second one you can't see.
If AI returned obviously-bad output when you stepped outside your lane, none of this would matter. You'd see the mess, recognize you were out of your depth, and go get help. The danger is the opposite. AI returns fluent output. Tidy, confident, well-organized — the surface texture of work a competent person already finished.
To someone who has the domain, fluent-but-wrong is catchable; the silent checklist fires and something feels off. To someone who doesn't, fluent-but-wrong is indistinguishable from fluent-and-right. The fluency does the one thing you least need it to do when you're out of your depth: it makes the output look trustworthy precisely to the person least equipped to judge it.
So AI doesn't close the competence gap. It hides it. It takes the moment that used to announce itself — "I have no idea if this is correct" — and paints over it with something that looks done.
I want to be careful here, because there's a lazy version of this argument that says stay off my lawn, specialists know best, amateurs with AI are ruining everything. That's not it, and I don't believe it.
The point isn't that other people overreach. It's that everyone has a domain where they're the fluent-but-not-competent one — and AI is now whispering to all of us, in every one of those domains, that we've got it handled. I'm the example in this post, not the exception to it. When I generate backend code and feel that flush of self-sufficiency, I'm doing the exact thing I'd want a backend engineer to be wary of when they generate a component and feel like they've internalized frontend.
Nobody is the villain in this. The pull is structural. The tool is designed to make you feel capable, and it's very good at it.
Strip it all back and here's what's left. The thing a specialist has that AI can't transfer to you isn't ownership of a piece of the codebase. It's understanding — the accumulated context that tells you which questions matter and what a good answer even looks like. Domain knowledge is just understanding with a name on it.
And understanding is the one thing AI categorically does not hand over. It hands over output. The narrative that worries me isn't "AI will replace specialists." It's the quieter one — the slide from the model produced something to therefore I've got this handled. That move has the causality backwards. Producing output isn't the same as validating it, and in a domain you don't live in, you have no way to tell the two apart.
You don't need to stop generating code outside your domain. Generate away — it's genuinely useful for exploring, for drafting, for learning the shape of an unfamiliar problem.
You need one honest check before that code becomes a decision:
Can I independently tell whether this output is correct — or only whether it runs?
If you can verify it, ship it. If the only thing you can confirm is that it executes and looks tidy, you've hit your competence boundary, and that is not a moment to write another prompt. It's the moment to pull in the person who has the silent checklist you don't. That's not admitting AI failed you. That's the correct way to use it — AI to produce, the specialist to grade, you to know the difference.
AI didn't make the specialist unnecessary. It made the cost of not having one invisible — right up until the point where it's expensive.
Was this helpful?