I have been talking to people in my network lately - hiring managers, staff engineers, a few founders - and a phrase keeps surfacing in different words but with the same spine: if someone has not, by now, folded AI-assisted work into how they actually build software, they are not who we want to hire next.

It is not being said as cruelty. It is being said as fatigue. The market for strong engineers is still tight in pockets, but the definition of “strong” is updating faster than job descriptions.

From optional to obvious

A year or two ago, “uses Copilot sometimes” felt like a personality trait - interesting, not decisive. Today, in many of the conversations I am in, it is drifting toward a hygiene factor, like version control or code review. Not because AI is magic, but because the throughput gap is visible.

Teams that have integrated tooling well are not merely faster at typing. They are faster at exploration: more branches considered, more tests sketched, more edge cases surfaced before a human reviewer burns an hour. The opposite is also visible. Engineers who treat AI as a toy, or as something that “does not apply to real systems,” often end up anchored to an older cadence. In a hiring loop, that reads less like principle and more like stagnation.

So the blunt question people are quietly asking is not “are you good at LeetCode?” It is closer to: can we put you in a modern pipeline without re-teaching basic leverage?

“Unhireable” is the wrong word - but the bar moved

I want to be careful with language. Declaring whole groups of people “unhireable” is how we manufacture shame and miss nuance. There are excellent engineers who are skeptical for good reasons - security, quality, licensing, team norms - and there are environments where AI adoption is genuinely constrained.

What I am hearing is narrower and more managerial: for many roles, especially senior and staff-shaped roles, fluency with AI-assisted workflows is becoming a non-negotiable. Not because every line must be machine-written, but because the job is increasingly orchestration under uncertainty. If you cannot use the tools your peers use to reduce iteration cost, you are asking the org to subsidize your learning curve indefinitely. Few teams can afford that bet when the alternative candidate already ships in the new rhythm.

In other words, the risk is not “you never get a job anywhere.” The risk is “you are not competitive for the roles you actually want.”

What hiring managers think they are buying

When a leader says they want “AI-native” engineers, they are often sloppy in vocabulary. Strip the hype, and the purchasing intent is usually one of these:

Velocity without recklessness. They want someone who can move the exploration phase faster and still know when to slow down for design, threat modeling, and review.

Taste under acceleration. The failure mode is not “too much AI.” It is “AI-shaped sludge” merged behind a green build - correct enough to pass, wrong enough to rot.

Operational maturity. Logging spend, handling secrets, understanding model limits, and not turning the repository into an unreviewable diff machine.

Teachability. The field is moving weekly. The useful engineer is not the one who memorized today’s tool; it is the one who updates habits when the tool changes.

If you cannot demonstrate those behaviors, you are not failing a buzzword test. You are failing a proxy for modern craft.

The second-order effect for engineering managers

This shift is going to collide with fairness unless we handle it deliberately.

If “AI fluency” becomes a gate, we will accidentally filter for privilege: people who had employer-paid seats, time to experiment, and roles with enough slack to learn. We will also filter for early adopters who are not always the best collaborators. A hiring bar that rewards the loudest experimenter is a bar that mistakes confidence for judgment.

So the managerial work is not to post a slogan on the job description. It is to define what we mean, assess it without theater, and invest in bringing people across the gap before we treat the gap as moral failure.

Practically, that might look like:

  • Calibration in interviews. Ask candidates to work the way they would on the job. If your team uses assisted coding day to day, simulate a constrained task where assistance is allowed - and then probe decisions, not vanity metrics.

  • Explicit enablement budgets. If AI fluency is “non-negotiable,” then onboarding must include time, tooling, and guardrails. Non-negotiable is not the same as “you should have figured it out alone.”

  • Separating skepticism from refusal. Skepticism with evidence is a feature. Refusal without experimentation is a signal. Managers need language to tell the difference in performance conversations, not just in hiring.

What I am not saying

I am not saying traditional skills vanished. Systems thinking, communication, ethics, debugging under pressure, and the ability to hold a production incident in your head while humans panic - these remain scarce and valuable.

I am also not saying the tools are stable. Betting your identity on a single vendor feature is fragile. Betting on the habit of learning leverage is less fragile.

What I am saying is that the social proof in my network has shifted. The question is no longer whether AI changes engineering. For many hiring loops, the question is whether a candidate has done the ordinary work of changing with it.

I focused this post on engineers, but I think the same is also true for Engineering Managers. If you haven’t already started to pull AI into your workflow, the risk is the same.

Questions I have been pondering or asking people

When you listen to your own peer conversations, is AI fluency still a “nice to have,” or has it quietly become a filter - and are you comfortable with what that filter rewards and punishes?

If you are a manager, how do you test for judgment under acceleration without turning interviews into a gadget show?

And if you are an engineer who has held back: is your resistance anchored in a real constraint you can name, or in the discomfort of becoming a beginner again - because one of those is negotiable with a good leader, and the other is a career risk that compounds.

I do not enjoy drawing lines in public. But I would rather name the line my network is already drawing than pretend the hiring market is still scoring the old rubric.