A few months ago, an engineering manager I advise asked me a question that has been rattling around in my head ever since. He was building a small team and wanted my opinion on hiring. Not which stack, not which seniority levels, not which titles. What kind of person he should bet on.
It is an interesting question in this time and not as obvious as it used to be. We are firmly in what I called the Zeitenwende in a previous article. The cost of writing code has fallen by an order of magnitude. The gap between “good idea” and “running prototype” has shrunk from weeks to an afternoon. The usual hiring heuristics (years of experience, framework familiarity, that ridiculous whiteboard interview) were never great to begin with, but they are now visibly broken.
So who does thrive in this new world we are sliding into?
I have been turning this over for months, both as someone advising tech companies and as someone who recently went from corporate executive to solopreneur, with all the reinvention that involved. Let me share what I have come to believe, first about people in general, and then about software engineers in particular.
The Universal Thrivers
They are willing to leave the comfort zone
This sounds like a generic LinkedIn platitude, but I mean it very concretely. The people who thrive right now are the ones who actively seek discomfort. They picked up Claude Code or Cursor without being told. They tried low-code solutions when they were new and all the rage. They built something embarrassing on the weekend. They are not waiting for HR to send them on an AI training course.
I am biased here, of course. Leaving Webfleet to start my own consulting practice was the most uncomfortable thing I have done in years. But the discomfort is exactly where the learning lives. The colleagues of mine who have made similar jumps in the last twelve months are, almost without exception, doing better professionally than the ones who decided to wait this out.
They love getting shit done
There is a personality type in our industry that loves to debate. Architecture meetings that last for hours. Endless Slack threads about naming conventions. Six-month “discovery phases” that produce a deck and not much else.
In the world we are entering, they are going to struggle.
The new game rewards the people who ship. Who would rather have a 70% solution running by Friday than a 99% solution sketched out on a whiteboard. Who treat every artifact as a draft to be improved with feedback from the real world. The agents are tireless, but they need a human partner who actually wants to push Enter.
Why does this matter more than it used to? Because the cost of running an experiment has collapsed. Building a working prototype to put in front of a real customer used to be a planning exercise of its own; today it is an afternoon. And as the saying goes, no battle plan ever survives contact with reality. The same is true of product strategies, architecture decisions, and feature specs. The shippers get real signal from real users while the debaters are still arguing about the best way to set up the meeting. Compound that gap over six months and it becomes enormous.
Daniel Pink had it half right
If you have read Drive, you know Daniel Pink’s three motivators for knowledge workers: Mastery, Autonomy, Purpose. For twenty years, this framework has been more or less correct.
I think one of those three is now in trouble.
The people motivated primarily by mastery, the ones who spent a decade becoming the absolute best at React, or at PostgreSQL internals, or at iOS animation, are going to find the ground shifting under them. Ninety percent of their hard-earned knowledge is being commoditized in real time. I wrote about this before: the syntax, the boilerplate, the memorized libraries. All of that is becoming cheap.
To be precise: mastery itself has not died. It has changed levels. Mastering React is becoming cheap. Mastering your problem domain, mastering how to evaluate AI output, mastering taste, mastering the orchestration of multiple agents toward a complex outcome: these are the new mastery games. The mastery-driven who re-anchor what they are pursuing will thrive. The ones who insist on mastering yesterday’s craft will not.
The people motivated by autonomy and purpose, on the other hand, are about to have the time of their lives. Autonomy is the entire point of an AI-augmented workflow: fewer hand-offs, fewer dependencies, more leverage per individual. And purpose-driven people love this new world, because suddenly they can build things that previously needed a team of ten.
If you are hiring, ask candidates what motivates them. The answer is more diagnostic than it has ever been.
They direct rather than do
This is the pattern I keep coming back to in everything I write about AI: you decide, the agent executes. The thrivers are comfortable with that division of labor. They do not feel diminished by it. They do not feel like they are cheating. They feel like the director of a small studio, and they enjoy it.
The people who insist on typing every character themselves, or who refuse to delegate to an agent because “it might make a mistake”, well, of course it might. So does every developer you have ever hired. The skill is in reviewing, steering, and catching the mistakes early. The same skill, in fact, that good tech leads have always had.
They think clearly
This one might be the most underrated trait on the list, and the one I keep coming back to in my own work.
In an AI-augmented workflow, the ability to articulate intent precisely has gone from “nice to have” to “core competency.” Every prompt is a spec. Every PR description is a contract. Every architecture decision record is leverage. Every Slack message to a teammate is, increasingly, also a hand-off to whatever agent that teammate uses next.
A fair objection at this point: can AI not turn rough thoughts into polished prose? Has the writing skill not also been commoditized? Yes and no. AI is genuinely excellent at adding polish. It is not good at adding clarity that was not there to begin with. If your underlying thinking is fuzzy, the AI output will be polished and fuzzy. It will read beautifully and mean nothing in particular. The agent on the receiving end of your spec will produce something equally polished and wrong, and you will find out a week later when the feature lands in production and does not actually do what anyone needed.
So writing is a symptom. Clarity of thought is the kernel.
The engineers (and managers, and PMs, and founders) who can actually think precisely about what they want, who can hold multiple constraints in their head at once and articulate the trade-offs, are about to look like geniuses. The ones who have always relied on verbal hand-waving and then expected someone else (or now, an agent) to sort it out are going to struggle in ways they will not immediately understand.
A diagnostic, then, for hiring: hand the candidate an AI-generated proposal for a feature and ask them to tell you what is wrong with it. The thrivers will spot the buried assumptions, the hand-waved trade-offs, the missing edge cases. The non-thrivers will say “looks great.”
They know how to attack complex problems
Divide and conquer. Decomposition. The ability to look at a tangled mess and ask: what are the three smaller problems hiding inside this one?
This skill has always been valuable. With agents, it is leveraged tenfold. The engineer who can decompose a problem into well-scoped sub-tasks, hand each one to an agent (or to a junior, or to a contractor), and then integrate the results, that engineer is now doing the work of a small team. The engineer who can only execute on tasks handed to them is doing the work of an agent.
They embrace the new world rather than fearing it
There is a kind of resigned cynicism in some corners of our industry right now. “AI will steal my job.” “It is just a hype cycle.” “Real engineers do not use these tools.”
I get it. Change is hard. But cynicism is not a strategy. Every one of these statements I have heard from someone who is also, quietly, not adapting. The thrivers I know are not naive about the risks. They think about job displacement, about quality, about security. But they engage with the technology rather than dismissing it. They are in the arena.
Software Engineers, Specifically
Most of my readers are tech leaders or engineers, so let me get more specific. If I were hiring software engineers today, here is what I would look for.
Builders over aesthetes
There is a classic split in our profession: the engineers who care about building things that work for users, and the engineers who care about the beauty of the code itself. In the past, both could be valuable in the right roles. Going forward, only one of those types will reliably thrive.
The agents will write code that is “good enough.” It will not always be elegant. It will not always satisfy the aesthete. The engineers who can accept “good enough and shipped” over “perfect and unbuilt” will outproduce their colleagues by a wide margin.
Engineers who think like Product Owners (and know their domain)
Knowing what to build has always been more valuable than knowing how to build it. With AI doing more of the “how,” the gap has widened dramatically.
The engineers who genuinely care about the customer, who can imagine themselves becoming a Product Owner if their career took that turn, who pick up the phone to talk to users. These engineers are going to do extremely well. They are doing the part of the job that agents cannot do.
This is also where deep domain expertise turns into a moat. An agent can write code about anything. It does not know how dispatch actually works in a logistics company, what the regulatory edge cases of fleet electrification look like, or why a particular workflow exists in your industry for historical reasons that nobody documented. Engineers who pair coding skill with genuine industry knowledge are now more differentiated than they have been in a long time, and that gap is unlikely to close anytime soon. If you have spent fifteen years learning the weird corners of an industry, the AI era is, counterintuitively, kind to you.
Quality-obsessed engineers
In a vibe-coding world, you do QA all day long. There is no way around it. The agent produces, you review, you reject, you steer, you accept. The engineers who enjoy finding the edge case, who have an internal alarm bell for “this looks fishy,” are the new gatekeepers.
I wrote in my recent article on coding agents about how testing is now so cheap that “we don’t have time for tests” is no longer a defensible excuse. The flip side is that judgment about quality is more valuable than ever.
UX-aware engineers
Users will expect AI-augmented teams to deliver beautiful, consistent, intuitive interfaces. They will not care that you produced them in a third of the time. The bar is rising, not falling.
Agents can produce competent UI. They can also produce ugly, confusing interfaces that technically work. The engineers who recognize the difference, who can look at a screen and feel that something is off, will be the ones whose products users love.
Engineers who know what good architecture looks like
Agents will happily copy code into new places when they should be refactoring. They will create five slightly different implementations of the same concept across a codebase. They will pile abstraction on abstraction without ever simplifying.
You need someone in the room who knows the difference between a well-factored system and a pile of plausible-looking files. That person is now worth their weight in gold.
And, most importantly, engineers who understand security
I have saved this one for last because it is the one that keeps me up at night.
AIs are getting very good at spotting and exploiting weaknesses in code. In a recent talk that I really recommend watching, Anthropic security researcher Nicholas Carlini walked through what frontier models can already do today, autonomously and without sophisticated scaffolding. The examples are sobering. The first critical vulnerability ever found in Ghost, a content management system with 50,000 GitHub stars and over a decade of history. A heap buffer overflow in the Linux NFS daemon that has been sitting in the kernel since 2003, requiring two cooperating attackers to trigger, the kind of bug that would never be found by fuzzing. Several more remotely exploitable kernel bugs that Carlini openly admits he could not have found himself with a career of security experience behind him.
His own assessment: these models are already better vulnerability researchers than he is. And the capability is roughly doubling every four months.
Let that sink in for a moment. What used to require nation-state-level capability (reverse-engineering binaries, finding zero-days, chaining exploits) is becoming available to anyone with a decent agent and a few hundred dollars of compute. The balance between attackers and defenders that we have lived with for the last twenty years is breaking down, and it is breaking down fast.
Your engineers need to know what the OWASP Top 10 are. They need to understand encryption: when to use what, and what “good” looks like for secrets management. They need to write code that is secure by default, and they need to be able to direct an agent toward that path rather than away from it. And maybe most important of all: in this new world, engineers need to be able to use AI themselves to find and fix security vulnerabilities themselves, assess their impact and make sure to put forward the right solutions for them.
If you are an engineering leader and your team currently has zero people who could be called “security-literate,” I would treat that as the single most urgent gap to close. Not next year. This year. Or better: now.
So, Who Thrives?
When I look at the list, a picture emerges. The thrivers are the engineers who would rather be useful than impressive, who would rather ship than debate, who care about users more than about elegance, and who can be trusted to do the right thing when nobody is looking, including when the “nobody” is the agent.
If I had to compress all six engineering traits into a single word, I would pick taste. Knowing what good looks like (in code, in architecture, in UX, in security, in the customer experience) and being unwilling to ship until you see it. Taste is the new senior skill. It is the thing agents cannot give you, and the thing your customers can feel even when they cannot name it.
The thrivers are not necessarily the engineers with the most experience. They are not necessarily the ones who score highest on a coding interview. They are, in my observation, often the curious ones, the restless ones, the ones who want to be in this strange new moment rather than hiding from it.
If you are leading a tech organization, look at your team with fresh eyes. The people who will carry you through the next five years may not be the ones you assumed.
And if you are an engineer reading this and feeling a bit anxious, good. That is the right reaction. The question is not whether AI will affect your career. It will. The question is which of these traits you already have, and which you need to grow.
The good news? Every single one of the traits above is learnable.
The less good news? The clock is ticking.
If you are a CTO, founder or engineering leader thinking through what your engineering team needs to look like over the next two to three years, this is exactly the kind of question I help with as a Fractional CTO and advisor. Feel free to reach out.
