A few months ago, hiring a developer was straightforward. You knew exactly what you needed: a Java developer, a Python developer, an Angular developer. Job descriptions read like grocery lists of frameworks and languages, each with a required number of years attached. Resumes were filtered by these lists, teams were structured around them, and careers were built upon them.
That world is quietly disappearing. Most engineering leadership hasn’t yet caught up to what is replacing it.
Recently, I asked my project manager to add headcount to a project I was running. He asked the question he’d been trained to ask for a decade: “Which team?”
Historically, we had a Java team, a Python team, and a React team. Our org chart, hiring funnel, and performance reviews were all built around those buckets. I stood there for a moment, realizing I didn’t know how to answer him.
On my current project, I have used Angular in some components and React in others. I had moved between Python and Node services without a second thought. The AI-assisted coding experience had become so seamless that the choice of framework was now incidental—a context-switch the AI absorbed so the human didn’t have to.
That was the moment I realized: we are recruiting for a world that no longer exists.
Until recently, knowing a programming language was a meaningful proxy for productivity. Deep knowledge of Java meant you could ship features faster than a novice. Productivity scaled with familiarity, and familiarity took years to acquire.
Today, the AI writes the syntax. It remembers the idioms. It knows the standard libraries. It can pivot between Spring Boot, FastAPI, and Express in a single afternoon without breaking stride. The “fluency” we used to pay for has been commoditized overnight.
If language is no longer the differentiator, what is? From running real-world projects with AI in the loop, four priorities have emerged:
The AI can write a controller or a migration, but it cannot reliably decide where those things should live in a codebase intended to last five years. A developer who understands the “shape” of a well-structured project and the trade-offs involved is infinitely more valuable than one who has simply memorized syntax.
This is the new craft. It involves knowing when to trust the AI and when to interrogate it. It’s the ability to phrase a problem so the AI provides a useful answer rather than a “confident wrong” one. Knowing when a solution is technically correct but architecturally unsustainable is a skill that is currently wildly unevenly distributed.
When an AI suggests solving a problem by adding a cache, a human must decide if caching is appropriate for that specific data. Does the business care about staleness? Will downstream systems tolerate it? The AI does not know your business; the developer must.
AI has fundamentally changed the design pipeline. On most projects, the AI generates layouts that are more consistent and accessible than what an average in-house team would ship in the same timeframe.
The Uncomfortable Truth: The UX produced by today’s AI agents has largely eliminated the need for dedicated UX teams on standard business tools.
The role of “UX Designer” for internal dashboards and admin panels is folding into the developer’s role. The remaining work is judgment: Is this flow how our users think? Is this density appropriate for the hardware they use? These are calls a developer with functional understanding can make in the moment.
For years, we measured developers by “output”: lines of code, story points, or velocity. We were measuring how fast a human could translate a requirement into code. That translation is now nearly free.
If two developers use the same AI on the same codebase, their output velocity will look identical. The difference will show up in what they choose to ship, what they refuse to ship, and what they catch before it deploys.
While the industry is still figuring this out, the direction is clear:
The conversation with my PM was uncomfortable because it meant my organizational structure was already obsolete. But pretending the old model still works is a recipe for irrelevance.
The companies that thrive in the coming years won’t be those with the deepest “Java benches.” They will be the ones whose developers prioritize system structure, business context, and the courage to push back against the machine.
The frameworks are no longer the skill. The judgment is. It’s time we hired for it.
