AI Won’t Take Your Job. This Engineer Might.
The New Age of Engineer
AI isn’t taking your job. But an engineer who knows how to use it properly might.
I’ve been recruiting engineers for nearly a decade. I’ve seen the market shift with cloud, with mobile, with data. Each time, the narrative was the same: the sky is falling, jobs are disappearing, everything is changing.
Each time, the best engineers adapted. The rest caught up eventually. A small number didn’t move and got left behind.
We’re in one of those moments again. Except this one feels different — faster, more fundamental, and less forgiving of a “wait and see” approach.
Across the market — from scaling startups to enterprise transformation programmes — I’m seeing a new type of brief emerge. Not a search for AI researchers. Not prompt engineers in the narrow sense. Senior software engineers who have genuinely woven AI into how they build things — at system level, not just at the IDE level.
Here’s what I’m seeing, and why it matters.
The bar has moved. Most job specs haven’t noticed.
The majority of engineering job descriptions I see still read like it’s 2022. Senior engineer. Five years of experience. React, Python, AWS. Strong communication skills.
Fine. But incomplete.
The engineers who are genuinely raising the bar right now aren’t just writing better code faster. They’re doing something qualitatively different. They’re using AI as a first-class part of the system — not as an autocomplete tool, but as an active participant in build, test, review, and validation workflows.
The difference between those two things is enormous, and most hiring processes aren’t designed to see it.
What these engineers actually look like
I’ve been fortunate to engage with some exceptional engineers recently who illustrate this shift clearly. Here’s what stands out — anonymised, but very real.
Engineer A works at a major global financial data business. They’ve moved well beyond individual contribution — their focus is now on building systems where AI autonomously handles complex, large-scale code transformations across huge numbers of repositories. Think breaking library upgrades, interpreter migrations, the kind of work that traditionally takes teams months of careful, manual effort. They’ve built the orchestration pipelines, the evaluation frameworks to check correctness and safety, and the monitoring infrastructure to make autonomous code modification viable in a critical production environment. Not a proof of concept. This is running at enterprise scale.
Engineer B works at a well-known consumer technology platform. Their background spans the full lifecycle of AI and ML systems — from backend and cloud infrastructure through to model deployment, orchestration, and production inference. They’ve driven meaningful reductions in infrastructure costs through smart platform work, built internal tooling that significantly cut incident resolution times, and are actively working across LLM-powered applications, RAG pipelines, and agentic architectures. What stands out is the breadth: equally comfortable in infrastructure, software engineering, and machine learning, and shipping across all three.
Engineer C works at one of the world’s most recognised technology companies. Their work sits at the intersection of LLM systems, agentic workflows, and AI infrastructure — designing and shipping production-grade AI features end to end. Multi-agent pipelines that combine language models, browser-based tooling, and structured reasoning. Guardrail systems covering validation, schema enforcement, and behavioural boundaries. Before this role, they built an entire AI platform from scratch as a founding engineer at an early-stage startup — from zero to a functioning, deployed product. The through-line across their career is a preference for building things properly from the ground up.
Get Daniel Holden’s stories in your inbox
Join Medium for free to get updates from this writer.
Three engineers. Three different companies, domains, and stacks. But the same thread running through all of them: they’re not using AI as a shortcut. They’re using it as infrastructure.
The distinction that actually matters
There’s a version of “AI-fluent engineer” that means someone who uses Copilot to write boilerplate faster. That’s fine. It’s table stakes now, not a differentiator.
The engineers above are doing something else. They’re thinking about AI at the system design level. They’re asking: where in this workflow can an agent take a step autonomously? What does a human checkpoint look like, and when is it necessary? How do I make LLM outputs deterministic, testable, and safe enough for production? How do I build something that another engineer can understand, modify, and trust?
That last question is the one most AI prototypes fail. It’s not hard to get an LLM to produce an output. It’s genuinely hard to build a system around one that’s reliable, maintainable, and fit for an enterprise environment.
The engineers I’m describing have solved that problem — or are actively working at the frontier of solving it. That’s a different skillset to “uses AI tools.”
What this means for companies hiring right now
Across the market, I’m seeing a shift in how the smartest engineering leaders are thinking about headcount. It’s less about adding volume and more about adding leverage. A smaller number of high-capability, AI-fluent engineers who can rebuild products, establish new ways of working, and set the quality bar for everyone around them.
The trigger is usually honest self-assessment: AI experiments that stalled, an engineering population that struggled to operate effectively with modern AI tooling, and a budget that doesn’t stretch to simply hiring more of the same. The answer isn’t more engineers. It’s different engineers.
If you’re a leader in that position— the question isn’t whether to hire for this. It’s whether your hiring process can actually identify it.
Most can’t. The tell-tale signs of a process that will miss these engineers: over-reliance on take-home tests, rigid problem statements, language-specific filters, and interview panels that don’t have the vocabulary to probe agentic AI experience. You’ll screen out the people you most need.
What this means for engineers
If you’re a senior engineer reading this and you haven’t yet seriously engaged with agentic AI — not the hype, but the actual building of it — now is the time.
Not because your job is going away next quarter. But because the ceiling on what one engineer can deliver is rising, and the engineers who understand how to build with AI as a system-level tool are going to increasingly set the standard against which everyone else is measured.
The good news: this isn’t about becoming an AI researcher or pivoting to a new specialism. It’s about doing what good engineers have always done — staying curious, pushing into new territory, and building things that actually work.
The engineers I described above aren’t superhumans. They’re people who leaned in early, built real things, reflected on what worked, and kept going. That’s available to anyone willing to do the same.
The new age of engineer isn’t a different type of person. It’s the same intellectual curiosity, the same rigour, the same instinct to build things properly — applied to a new set of tools with a new set of possibilities.
That’s not a threat. It’s an invitation.
If you’re building a team with this capability in mind, or you’re an engineer who recognises yourself in the above, I’d love to connect. Find me on LinkedIn.
